Maturità della coinbase · tutta la catena
La regola della catena è scaduta, ma i wallet trattengono ancora per 6,480 blocchi le monete appena minate.
Il blocco 979,920 è passato, quindi la regola temporanea della catena è finita. La policy di propagazione arrivata insieme a lei, però, non è legata a quella finestra e continua a chiedere 6,480 conferme prima che una ricompensa si possa spendere. È un comportamento del client, non una regola di questo pool, ed è una questione ancora aperta a monte.
Che cosa ha fatto PyBLØCK. Il nostro nodo gira già su v29.4.3.knots20260508, dal 2026-10-27. Avevamo detto che avremmo aggiornato con RC2, e l'abbiamo fatto.
Che cosa cambia per te, detto chiaro. Vale già, e non ha aspettato il blocco 973,440: il nostro nodo non propaga più la spesa di nessuna ricompensa con meno di 6,480 conferme. Riguarda che cosa trasmette il nostro nodo, non se la moneta è tua: una ricompensa minata prima del blocco 973,440 matura alle solite 100 conferme e il tuo saldo la mostra spendibile, perché lo è. Le tue monete non sono congelate e non le teniamo noi. Sono valide, sono già tue sulla catena, e qualsiasi altro wallet o nodo continua a trasmetterle: la maggior parte della rete non ha aggiornato. Quel che cambia è il nostro nodo, non la tua proprietà.
Perché qui è più sopportabile che altrove. La tua ricompensa è scritta direttamente nella coinbase del blocco, al tuo indirizzo: è già tua sulla catena, e qui non tratteniamo niente: non possiamo spenderla e non ci paghiamo per primi. Un pool custodiale invece incassa tutta la coinbase e ti paga dopo dal proprio saldo; finché quella coinbase è bloccata, deve finanziare ogni pagamento con le riserve. Noi non anticipiamo nulla, quindi qui non c'è niente che possa finire.
Perché la data arriva prima dei 45 giorni: la regola conta blocchi, non tempo. 6,480 blocchi sono circa 45 giorni al solito ritmo di 10 minuti, ma questa catena sta andando più veloce (~45 giorni al ritmo recente), quindi lo sblocco cade prima. L'altezza del blocco è la parte fissa; ogni data qui è una stima che si muove con la catena.
Finora una ricompensa di blocco si poteva muovere dopo 100 blocchi, circa 16 ore. Questa è una regola del client Bitcoin BLAKE2b, non di questo pool: vale per ogni coinbase della catena, chiunque l'abbia minata, e non c'è niente che possiamo cambiare dalla nostra parte. Quello che ti spetta non cambia: cambia solo quanto resta fermo prima di muoversi. I pagamenti continuano a essere scritti direttamente nella coinbase del blocco stesso, al tuo indirizzo, senza che noi tratteniamo nulla. Vuol dire anche che la tua parte è bloccata come la nostra: non ci paghiamo per primi.
Perché questo parte prima del blocco 973,440. La parte wallet e propagazione di questa release applica l'attesa lunga a ogni ricompensa, di proposito e indipendentemente dalla regola della catena: la proposta lo dice a chiare lettere. Abbiamo fatto girare la release su un nodo isolato nostro per esserne certi: il taglio sta esattamente a 6,480 conferme a prescindere da quando la ricompensa è stata minata, e vale già con l'attivazione ancora nel futuro. Quindi non è qualcosa che si sistema prima del flag day: è quello che fa il client, ed è un comportamento del client più che una regola di questo pool.
Lo stesso annuncio dice che chi mina senza far girare un nodo e un gateway propri non sta davvero minando e in futuro potrebbe non essere pagato affatto. È un'intenzione dichiarata in il cambiamento stesso: non è codice, e oggi non esiste nessun meccanismo del genere. Non faremo finta di sapere come verrebbe amministrata. Te lo diciamo perché meriti il quadro completo. Se mai diventerà una regola vera, lo leggerai qui per primo.
Quello che ti consigliamo, per quel che vale. Se comunque dovrai aspettare una maturità più lunga, è un buon momento per far girare un nodo tuo e un gateway DATUM. Non perché ti esenti dall'attesa: non lo fa, e chi ti dice il contrario sbaglia — la regola vale per ogni coinbase della catena, chiunque abbia costruito il blocco. Fallo perché ti conviene e basta. Il tuo nodo sceglie le transazioni, quindi non vediamo mai la tua selezione e non potremmo censurarne una nemmeno volendo. E ti resta di più, perché non c'è la quota del node-runner quando il node-runner sei tu: 99% su CAROUSEL, contro 22% sul nostro stratum (CHIRP paga già il 100% in ogni caso: gira al 100% su DATUM). L'attesa è la stessa in ogni caso; quel che cambia è quanta parte del blocco è tua quando si sblocca, e chi ha deciso che cosa ci è finito dentro. Come farlo girare →
Far girare un nodo e un gateway propri è quello che WAVICLES fa già, e ora è disponibile anche per CAROUSEL e CHIRP: vedi PATUM, l'installer con un clic.
Il tuo nodo costruisce il blocco. La pool fissa solo la ripartizione: tutti quelli con lavoro nella finestra, in proporzione al lavoro · commissione 0% con il tuo nodo, 0% tramite lo stratum di PyBLØCK · pagata nella coinbase. La pool non trattiene mai un satoshi.
| Miner | Hashrate · 10 min | Quota della finestra | Riceverebbe | Ultima share |
|---|---|---|---|---|
| Ancora nessun lavoro nella finestra — collega un nodo e la ripartizione compare qui. | ||||
| Blocco | Quando | Costruito da | Pagato ai miner | Output della pool | Miner pagati |
|---|---|---|---|---|---|
| Ancora nessun blocco WAVICLES — il primo compare qui e in BLOCCHI. | |||||
Dal blocco 977,350, il lavoro inviato dalle porte SV1 pubbliche di PyBLØCK cede il 77 % della sua parte alla pool. Minando con il tuo gateway DATUM (PATUM) si evita.
| Gateway | Software | Share | Lavoro | Collegato | Ultima share |
|---|---|---|---|---|---|
| Nessun gateway collegato in questo momento. | |||||
CONVOYMining/datum_gateway dal 2026-09-02 in poi (commit b9ea7dc+). Le build precedenti falliscono dopo l’handshake con "Invalid data structure in configuration" — pull, rebuild, riconnessione; la configurazione non cambia.| Sintomo nel log del gateway | Causa | Soluzione |
|---|---|---|
Invalid data structure in configuration → Waiting on DATUM server… 0 | build di CONVOY precedente al 2026-09-02 | aggiorna a master (≥ b9ea7dc), ricompila, riconnetti |
decryption failed | pool_pubkey errata o troncata | copia la chiave completa da 128 hex (clicca sul blocco di configurazione), riavvia il gateway |
| Handshake OK ma 0 share sulla pool | i miner puntano alla pool invece che al tuo gateway | i miner vanno su IP-del-gateway:porta-stratum, mai su :28915 |
| i miner lavorano sul tuo gateway, ma dopo 30+ min ancora 0 share | la soglia predefinita di DATUM vardiff_min = 16384 è su scala ASIC SHA-256; una GPU o CPU BLAKE2b non la raggiunge mai | "stratum": {"vardiff_min": 1} (una potenza di due; 1 è quello che usa il gateway GPU di PyBLØCK), riavvia il gateway |
| coinbase "solo pool" in un blocco | il template non ha lasciato spazio per gli output di pagamento | blockreservedweight=100000 nel bitcoin.conf del tuo nodo |
| si collega, poi cade ogni pochi minuti con una chiave gateway nuova ogni volta | il gateway si riavvia subito dopo l’handshake: il suo nodo non restituisce lavoro BLAKE2b (RPC mal configurato, non sincronizzato, o manca la regola blake2b) | leggi il log del gateway dopo "DATUM Pool MOTD"; sul nodo esegui bitcoin-cli getblocktemplate '{"rules":["segwit","blake2b"]}' |
| la tua identità mostra lavoro ma pagamento 0 / "not payable" | lo username del miner sul tuo gateway è un nome di worker, non un indirizzo | i miner si collegano con un indirizzo Bitcoin-BLAKE2b (bc1q… / 1…); un worker dopo il punto va bene: bc1q….rig1 |
| poche identità pagate in un blocco | un budget di coinbase troppo piccolo per la lista dei pagamenti | risolto lato pool il 2026-09-14: ogni gateway riceve ora la classe da 16 KB (~400 pagamenti), CONVOY di serie compreso. Nulla da cambiare da parte tua. |
blockreservedweight=100000 in bitcoin.conf. Il default di Knots lascia spazio per ~55 output di coinbase. Il firmware dei tuoi miner decide quanti pagamenti può portare una coinbase: i firmware moderni (Whatsminer, S21, ePIC) accettano coinbase grandi e pagano tutta la finestra; una coinbase di serie da ~730 byte ne contiene ~15, e allora la ripartizione va a chi ci sta — mai trattenuta dalla pool. Con una finestra grande la tua coinbase può portare centinaia di output (ogni pagamento bech32 = 124 WU); riserva peso perché non sposti mai transazioni. I template Bitcoin-BLAKE2b oggi sono ~110 kWU, quindi c’è spazio in abbondanza.mining.pool_address decide chi viene pagato se mai mini senza la pool, e il gateway senza uno valido non parte nemmeno. Su ogni miner, come username Stratum, decide chi viene accreditato nella finestra. Impostali entrambi. Poi controlla la tabella Node runner qui sopra: se le share salgono, ha funzionato.mining.pool_address. È obbligatorio. Con uno non valido il gateway stampa Could not generate output script for pool addr ed esce in meno di un secondo, quindi se il tuo gateway gira, questo campo è già a posto. È anche l’indirizzo che incassa il 100% di qualsiasi blocco trovi mentre la pool è irraggiungibile, che è il caso qui sotto.x. Un nome di worker dopo il punto va bene: bc1q….rig1. Con la configurazione che pubblichiamo sopra (pool_pass_full_users: true) questo username è ciò che accreditiamo, quindi ogni miner sul tuo gateway viene pagato all’indirizzo con cui si collega.pool_pass_full_users a false e ogni miner sul tuo gateway viene accreditato a mining.pool_address, qualunque cosa scrivano i miner. È l’impostazione giusta se i rig sono tutti tuoi, e quella sbagliata se stai ospitando qualcun altro.bad-username, e quelle share non guadagnano nulla. Quindi un errore di battitura ti costa lavoro vero, in silenzio, finché non guardi. Ricontrolla sempre dopo aver cambiato uno username: la tua riga nella tabella Node runner deve mostrare share in salita e reject piatti.:28915, che è dove il tuo gateway parla con noi e mai dove vanno i miner; oppure sono GPU o CPU e non raggiungono mai la soglia predefinita di share, pensata per ASIC SHA-256. Per quest’ultimo caso imposta "stratum": {"vardiff_min": 1} e riavvia. La scheda Clients del tuo gateway è il modo più rapido per distinguere il primo caso dagli altri: se è vuota, il problema è dalla tua parte del gateway, non fra noi.pooled_mining_only. Lasciato a true, come lo pubblichiamo, il tuo gateway scollega i miner piuttosto che minare senza pool. A false, il tuo nodo continua a costruire blocchi da solo e qualsiasi blocco trovi paga il 100% a mining.pool_address. Nessuna delle due è sbagliata. La prima impedisce al tuo hashrate di andare dove non hai scelto; la seconda lo tiene a guadagnare. È anche la seconda ragione per cui quel campo deve essere un indirizzo che controlli davvero.7491a509 o successivo. Le build precedenti contano male i byte della coinbase BLAKE2b e troncano la lista dei pagamenti: un blocco trovato con una di quelle lascerebbe quasi tutta la finestra senza pagamento. Le rifiutiamo all’handshake con un messaggio che lo dice, invece di lasciartelo scoprire su un blocco. Nota che un semplice git pull di master non basta se master porta ancora il bug. Vanno bene anche i fork della linea OCEAN e i pacchetti StartOS.wavicles_api.php?mode=snapshot&hash=… e non può cambiare dopo che il blocco esiste.max_payees) == i beneficiari dello snapshot, ciascuno pagato on-chain.python3 tools/verify_wavicles_block.py --height H \ --conf bitcoin.conf --url https://b.pyblock.xyz/wavicles_api.php