Lo stesso bug, due esiti: Telestai, Ravencoin e che cosa eredita un fork

Ieri abbiamo scritto del bug di consenso di Ravencoin: un campo nHeight non validato nell'intestazione del blocco che permetteva di falsificare la proof of work, e la riorganizzazione della catena profonda tre giorni che è servita per disfarlo.

Quella storia ha una seconda metà, ed è la più utile. Un'altra catena aveva esattamente lo stesso bug esattamente nello stesso punto. Non è mai stato sfruttato.

La differenza fra i due esiti merita di essere capita, perché non è una differenza di codice.

Telestai ha ereditato il difetto, perché è ciò che fanno i fork

Telestai è un fork di Ravencoin. La sua base di codice discende da quella di Ravencoin, passando per Meowcoin: le note di rilascio di Telestai Core 3.0.1 elencano ancora una «purga dei sorgenti Meowcoin» fra le pulizie, il che dice quanto di recente quella discendenza fosse ancora visibile nell'albero dei sorgenti.

La validazione delle intestazioni di Ravencoin non controllava l'nHeight dichiarato rispetto alla posizione reale del blocco nella catena. Nemmeno quella di Meowcoin. Nemmeno quella di Telestai. Nessuno ha introdotto il bug in Telestai; è arrivato insieme a tutto il resto, nel modo in cui un fork eredita le parti di una base di codice che nessuno guarda insieme a quelle che qualcuno guarda.

È la meccanica poco affascinante con cui un singolo difetto diventa il problema di più catene. I fork non sono copie che vanno alla deriva verso l'indipendenza. Sono copie che si portano dietro l'intera storia di presupposti del genitore — incluso, qui, il presupposto che qualcuno avesse già validato quel campo.

Che cosa ha fatto Telestai con due giorni di preavviso

L'exploit di Ravencoin è stato divulgato pubblicamente l'11 agosto 2026. Telestai Core 2.1.8 è uscito il 13 agosto, intitolato senza giri di parole «Security: KAWPOW nHeight bind».

Le sue note di rilascio non usano perifrasi:

Questa release corregge un problema di consenso/DoS in KAWPOW in cui il campo di intestazione nHeight (che seleziona l'epoca ethash) non era vincolato alla catena. La stessa classe di bug è stata sfruttata sulla mainnet di Ravencoin. I nodi Telestai che eseguono versioni precedenti restano esposti finché non aggiornano.

La correzione stessa è a strati, e la stratificazione è la parte interessante:

• Un limite assoluto di epoca viene imposto immediatamente, prima che avvenga qualsiasi calcolo di hash della proof of work.
• Il vincolo stretto height == prev + 1 si attiva al blocco 1.100.000 — in stile soft fork, senza riscrivere la storia.
• La proof of work viene calcolata solo dopo che il blocco genitore è stato trovato e l'altezza verificata, il che chiude una via di esaurimento di memoria in cui un nodo poteva essere indotto a lavoro costoso su un'intestazione che avrebbe dovuto rifiutare subito.
• Gli stessi controlli si applicano in ConnectBlock e VerifyDB, così un nodo che reindicizza il database non può riaccettare in silenzio ciò che le nuove regole vietano.

La mainnet era intorno all'altezza 1.057.000 quando è arrivata la 2.1.8. L'applicazione è stata fissata a 1.100.000. Quel divario — circa 43.000 blocchi — era voluto: pista sufficiente perché exchange, pool, explorer e operatori di nodi aggiornassero prima che la regola entrasse in vigore, e non tanta da lasciare la finestra aperta all'infinito.

Telestai ha anche citato la fonte. Le note rimandano a 2miners/Ravencoin, ramo rvn-nheight-fix — la stessa patch nata dall'incidente di Ravencoin — e ringraziano i ricercatori che hanno documentato la correzione più completa sull'accettazione delle intestazioni. Il rimedio ha viaggiato sulla stessa strada percorsa dal bug.

I due esiti, uno accanto all'altro

Due catene. Un'eredità di codice. Un identico difetto latente.

Quello di Ravencoin è stato trovato prima da un attaccante. Il risultato: quattro giorni di blocchi contraffatti prima della divulgazione pubblica, exchange che sospendono depositi e prelievi, un calo di prezzo intorno al 20% e una riorganizzazione di tre giorni per rimuovere il ramo avvelenato.

Quello di Telestai è stato trovato leggendo il rapporto d'incidente di qualcun altro. Il risultato: una patch due giorni dopo, un'altezza di attivazione fissata con margine e — non essendoci storia non valida da rimuovere — nessuna riorganizzazione. Non è stato annullato nulla perché nulla aveva bisogno di esserlo.

È tutta qui la differenza. Non codice migliore. Non un bug diverso. Solo chi se ne è accorto per primo, e con quanta rapidità chi mantiene la catena ha agito sulla brutta settimana di un altro.

Poi Telestai ha cambiato del tutto algoritmo

Sei giorni dopo la patch di sicurezza, Telestai ha rilasciato Core 3.0.0, con un fork al blocco 1.150.000 — intorno al 16 ottobre 2026 — verso Meraki, il proprio algoritmo di proof of work. Meraki resta un parente di KAWPOW (un derivato di Ethash con sapore ProgPoW, e il miner è nato come fork di kawpowminer), proposto come meno energivoro e alla portata di GPU modeste.

Vale la pena essere cauti sulla causalità qui, perché la tentazione di tracciare una linea retta è forte e la linea non è retta. Meraki era già in corso prima di agosto: le build di rodaggio su testnet per la 3.0.0 sono state pubblicate il 13 e il 14 agosto, gli stessi giorni della release di sicurezza, e non è un calendario che si mette insieme in quarantotto ore. Il cambio di algoritmo era lavoro pianificato che per caso è atterrato accanto a un incidente, non una reazione a esso.

Nell'elenco delle release c'è anche una piccola lezione sulle parti meno affascinanti del mantenere una catena. Fra la correzione di sicurezza e il fork, Telestai ha rilasciato la 2.1.9 per un motivo che con il consenso non c'entra nulla: la 2.1.8 era stata compilata contro una Berkeley DB più recente, e aprirci un vecchio wallet.dat poteva riscrivere i log del portafoglio al punto che i client più vecchi non riuscivano più a leggere il file. Così l'hanno ricompilata contro Berkeley DB 4.8 e ripubblicata. Una release di sicurezza serve a poco se aggiornarsi mette a rischio i file di portafoglio dei tuoi utenti.

Perché conta al di là di due piccole catene

Quasi nessuno di chi legge possiede RVN o TLS. Ciò che si generalizza è lo schema.

Le catene forkate condividono una superficie di bug, e quasi nessuno la traccia. Litecoin, Dogecoin, Bitcoin Cash, Ravencoin, Zcash e decine di altre discendono da Bitcoin Core, e ognuna porta un punto di divergenza oltre il quale le correzioni a monte smettono di arrivare da sole. Una vulnerabilità divulgata in una catena è una domanda aperta per ogni catena a valle dello stesso codice — e più un fork si è allontanato, più lavoro serve anche solo per sapere se la correzione si applica. Telestai ha risposto a quella domanda in due giorni. Non tutti i fork hanno qualcuno il cui mestiere è quello.

«Nessuno l'ha sfruttato» non equivale a «non c'era». Il software di nodo di Telestai è stato vulnerabile per tutta la sua esistenza. Il bug è stato reale per tutto il tempo; nuova era solo l'attenzione. Le catene che non ricevono mai il rapporto d'incidente di una sorella non lo scoprono per questa via.

Una correzione che arriva prima dell'exploit non costa quasi nulla. La stessa correzione dopo costa una riorganizzazione. Il lavoro tecnico in Telestai 2.1.8 e nell'hard fork di Ravencoin è a grandi linee la stessa patch. A differire è stato tutto il contorno: se c'era storia non valida da scartare, se gli exchange dovevano fermarsi, se le conferme degli utenti significavano qualcosa per tre giorni.

È lo stesso ragionamento dietro le build riproducibili e lo scrutinio delle dipendenze: quasi tutto ciò che ti protegge sta a monte di qualsiasi cosa tu possa vedere da dentro un wallet, ed è mantenuto da persone che fanno attenzione per conto tuo.

Che cosa significa in SSP

In pratica: per te non cambia nulla.

SSP supporta Ravencoin, e il nostro nodo gira in 4.8.0 sulla catena recuperata — nel pezzo di ieri abbiamo verificato gli hash dei blocchi su entrambi i lati della riorganizzazione contro la catena di riferimento. SSP non supporta Telestai, quindi non c'è alcun saldo Telestai nel tuo wallet di cui preoccuparsi.

Scriviamo di una catena che non supportiamo perché la storia illustra in modo pulito qualcosa che invece prendiamo sul serio. Gestire infrastruttura di nodi significa seguire il lavoro di sicurezza a monte per ogni catena che portiamo, comprese quelle le cui basi di codice condividono antenati. Il valore di tutto ciò è del tutto invisibile quando funziona: un nodo aggiornato ha esattamente lo stesso aspetto di uno non aggiornato, fino al giorno in cui non ce l'ha più.

L'agosto di Telestai è come appare questo dall'interno: chi mantiene il progetto legge dell'exploit di un altro, ne riconosce la forma nel proprio albero di codice, e rilascia. Nessun incidente, nessuna riorganizzazione, nessun annuncio che qualcuno all'esterno ricorderebbe. Solo un numero di versione che sale.