Circa quattro nodi Bitcoin Core raggiungibili su dieci, rilevati in una scansione di rete del 18 ottobre, usano linee di rilascio che blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il progetto non corregge più: le correzioni di sicurezza più rapide adottate da Bitcoin Core il 22 ottobre non arriveranno fino a loro. CryptoSlate, in un articolo pubblicato il 24 ottobre, ha contato 3.671 peer Core su 8.422 che dichiarano la propria versione (43,6%) su versioni a fine vita, partendo da un’istantanea del Karlsruhe Institute of Technology (KIT). Coindaro ha ricontato lo stesso file del KIT e ha trovato una quota simile, circa il 44%.
La cifra è una stima ricavata da una sola scansione, con stringhe di versione che i nodi riportano su sé stessi. Non è nemmeno nuova: una quota intorno al 43% veniva già citata a maggio. Quello che è cambiato è la politica che la circonda. Bitcoin Core rilascerà ora alcune correzioni nel giro di pochi giorni, e solo per le tre linee di rilascio che mantiene. Un nodo bitcoin fermo su una linea più vecchia resta fuori da questo circuito.
Come è stato fatto il conteggio dei nodi bitcoin
Il KIT gestisce da tempo un monitor della rete Bitcoin e pubblica le istantanee grezze dei peer che raggiunge. Non pubblica una percentuale di nodi obsoleti. Il 43,6% è un calcolo di CryptoSlate sul file dell’istantanea del 18 ottobre, che elenca 9.691 peer raggiungibili via IPv4 e IPv6. CryptoSlate ha tenuto gli 8.422 che si identificano come Bitcoin Core e ha messo da parte gli altri, compresi i nodi che usano Bitcoin Knots.
Il campione ha dei punti ciechi, che lo stesso articolo segnala. I nodi raggiungibili solo tramite Tor, quelli che non accettano connessioni in entrata e l’infrastruttura privata di exchange, custodi e miner non vi compaiono. Qualunque versione eseguano, nessun crawler esterno può vederli.
Anche la ripartizione di CryptoSlate lascia un piccolo scarto. I suoi quattro gruppi (31.x, 30.x, 29.x e 28.x o precedenti) sommano 8.261 peer, non 8.422. L’articolo non spiega i 161 peer mancanti.
Coindaro ha scaricato il file del KIT e ha ordinato i 9.691 record per user agent. Contando solo le stringhe Bitcoin Core semplici (della forma /Satoshi:31.1.0/, senza etichette aggiuntive) risultano 8.418 agent Core, molto vicini agli 8.422 di CryptoSlate. Altri 1.096 agent citano Knots (l’11% di tutti i peer) e 177 appartengono ad altri client o a build modificate. Tra gli 8.418 agent Core, 3.742 erano alla versione 28 o precedente, 242 dei quali nell’antica serie 0.x. Fa il 44,5%. Le piccole differenze con il conteggio di CryptoSlate dipendono da scelte di classificazione, come il trattamento di Knots, delle release candidate e delle build modificate.
| Linea di rilascio | Stato al 25 ottobre 2026 | Conteggio CryptoSlate (KIT, 18 ott.) | Riconteggio Coindaro (stesso file) |
|---|---|---|---|
| Release candidate 32.0 | Non ancora rilasciata | non indicato | 37 |
| 31.x | Mantenuta fino alla 34.0 | 3.243 | 3.278 |
| 30.x | Mantenuta fino alla 33.0 | 712 | 721 |
| 29.x | Mantenuta fino alla 32.0 | 635 | 640 |
| 28.x e precedenti | Fine vita (28.x dal 19 aprile 2026) | 3.671 (43,6%) | 3.742 (44,5%) |
| Base della quota | 8.422 peer Core | 8.418 agent Core, Knots esclusi |
Valgono per entrambi i conteggi altre due avvertenze. Il file non è un singolo istante: la connessione più recente risale al 18 ottobre, ma le voci più vecchie arrivano al 26 gennaio 2026, quindi vi sono mescolati peer ormai inattivi. Tenendo solo i 5.384 agent Core visti dal 1° ottobre, Coindaro ha comunque trovato il 43,3% su linee a fine vita. E un nodo può dichiarare la stringa di versione che vuole, quindi i dati mostrano quello che i nodi dicono di eseguire, non quello che eseguono davvero.
Una quota simile circolava già a maggio
I lettori non dovrebbero prendere il dato del 18 ottobre come un peggioramento recente. Il 6 maggio 2026, il giorno dopo la divulgazione da parte di Bitcoin Core del bug CVE-2024-52911, The Block riportava che una stima molto citata, che collegava alla dashboard dei nodi di Clark Moody, collocava circa il 43% dei nodi su software precedente alla versione 29. Quel dato veniva da un altro tracker con un altro metodo, quindi i due numeri non si possono mettere in fila per ricavarne una tendenza, in un senso o nell’altro.
Altri tracker offrono ancora altri quadri. CryptoTicker, con un’istantanea di btcnodes.io del 15 settembre, ha contato 26.516 nodi e ha collocato il 60,40% di quelli con un identificatore standard sulla serie 29 o precedente, un taglio che include la linea 29.x, ancora mantenuta. Preso da solo, 28.x e precedenti valeva il 27,09% di quel campione. Come il KIT, l’istantanea lascia fuori i nodi raggiungibili solo via Tor. Mostrava inoltre 4.459 nodi (17,2%) che dichiarano Knots, contro l’11% del file del KIT. I tracker che contano circa 25.000-26.000 nodi e i 9.691 peer IPv4 e IPv6 del KIT non misurano la stessa rete, quindi le loro percentuali non vanno mai mescolate.
Le correzioni rapide raggiungono solo 31.x, 30.x e 29.x
La nuova regola, annunciata da Antoine Poinsot sulla mailing list bitcoindev, crea una categoria per i bug facili da individuare, per esempio con una semplice richiesta a un modello di intelligenza artificiale. Per questi, la consueta attesa di mesi prima della divulgazione viene meno. «Per questi problemi facili da individuare, è lo scambio sbagliato», ha scritto Poinsot nel suo messaggio del 22 ottobre. La correzione esce rapidamente in una versione di manutenzione per ogni linea mantenuta, insieme a un avviso. I dettagli della regola sono nel nostro articolo del 23 ottobre sulla nuova politica di sicurezza di Bitcoin Core.
«Ogni linea mantenuta» è l’espressione chiave. La pagina del ciclo di vita di Bitcoin Core dice che il progetto mantiene sempre le ultime tre versioni maggiori, oggi 31.x, 30.x e 29.x, e che le versioni a fine vita in genere non ricevono correzioni di sicurezza. La versione 28.x ha raggiunto la fine vita il 19 aprile 2026; la 27.x il 10 ottobre 2025.
Il gruppo delle versioni supportate sta per ridursi ancora. La versione 32.0 era ancora allo stadio di release candidate il 24 ottobre, senza una data. Quando uscirà, la 29.x perderà il supporto. Sul campione di CryptoSlate, questo porterebbe 4.306 peer, cioè il 51,1%, su linee non supportate se nessuno aggiornasse. Il riconteggio di Coindaro dà 4.382 su 8.418, cioè il 52,1%. In ogni caso, più o meno la metà.
Fine vita di Bitcoin Core non significa nodo compromesso
Un nodo su una linea non supportata continua a scaricare e verificare ogni blocco con le stesse regole di consenso. La nuova politica non tocca queste regole, e CryptoSlate ha sottolineato che il suo conteggio misura l’idoneità alle correzioni, non una compromissione. Nel materiale esaminato da Coindaro non risulta documentato alcuno sfruttamento contro nodi vecchi di nessuno dei bug divulgati. Al 23 ottobre non era ancora stato pubblicato alcun avviso in base alla regola dei bug facili da individuare.
Il rischio è di altro tipo: arresti anomali e denial of service causati da bug già pubblici. Il caso più chiaro è CVE-2024-52911, un use-after-free nella validazione di blocchi e script, divulgato il 5 maggio 2026. Secondo gli avvisi di sicurezza del progetto e The Block, un miner poteva mandare in crash i nodi con un blocco non valido costruito ad arte, un attacco che costa vera proof of work. Il progetto lo ha classificato come High e ha giudicato improbabile l’esecuzione di codice da remoto; The Block ha aggiunto che le regole di consenso non erano coinvolte. Il difetto è presente in tutte le versioni dalla 0.14.0 alla 28.x. Cory Fields del Digital Currency Initiative del MIT lo ha segnalato in privato il 2 novembre 2024, e la correzione è uscita nella 29.0 in aprile 2025, 388 giorni prima della divulgazione pubblica secondo il conteggio di CryptoSlate.
Un gruppo di bug divulgato il 24 ottobre 2025, corretto nella versione 30.0, comprendeva un raro arresto anomalo da remoto sui sistemi a 32 bit (CVE-2025-46597), un attacco di esaurimento del processore tramite transazioni non confermate (CVE-2025-46598) e due modi per riempire il disco di un nodo (CVE-2025-54604 e CVE-2025-54605). La pagina degli avvisi non indica quali versioni più vecchie siano interessate.
C’è una ragione strutturale per cui le linee vecchie accumulano più bug pubblici, e questa è la lettura che Coindaro dà del testo della politica, non una dichiarazione del progetto. Per i problemi di gravità media e alta, Bitcoin Core aspetta due settimane dopo la fine vita dell’ultima linea interessata prima di pubblicare i dettagli. Quindi, per costruzione, i bug che vengono divulgati sono quelli che non sono più corretti in nessun posto da cui un nodo vecchio possa riceverli. La nostra guida su dove avvengono davvero gli attacchi alle crypto spiega perché il punto debole è di solito il software attorno alla blockchain, non la blockchain stessa.
Perché chi gestisce un nodo bitcoin aggiorna lentamente
I nodi in ritardo sono un fenomeno vecchio. In uno studio pubblicato a febbraio 2024, lo sviluppatore Jameson Lopp ha misurato, con i dati settimanali di Bitnodes, quanto tempo serve perché il 95% del picco di adozione di una versione passi oltre. Quel tempo è salito da circa un anno prima di luglio 2018 a circa due anni. Dal 2021 il picco di adozione arriva da sei a nove mesi dopo il rilascio. La spiegazione di Lopp, che ha presentato come un’ipotesi, è la diffusione di hardware e software per nodi plug and play, spinta in parte dagli utenti di Lightning, i cui proprietari tendono a essere meno tecnici e meno inclini ad aggiornare a mano.
Molte di queste macchine sono state configurate una volta e poi lasciate stare. Per loro, una politica che accelera le correzioni sulle linee mantenute non cambia nulla, a meno che il proprietario, o il fornitore del pacchetto, non porti il nodo avanti.
Come controllare la versione del proprio nodo bitcoin
Chi esegue Bitcoin Core da riga di comando può digitare bitcoin-cli getnetworkinfo. La documentazione RPC elenca un campo «subversion», la stringa di versione del server (per esempio /Satoshi:31.0.0/), accanto a un campo numerico «version». Tutto ciò che inizia con 28 o meno è su una linea a fine vita.
- La pagina del ciclo di vita raccomanda l’ultima versione di manutenzione della versione maggiore più recente che si può usare; oggi è l’ultima versione di manutenzione 31.x.
- Come per qualunque aggiornamento software, scaricare dal sito ufficiale, bitcoincore.org, e controllare le firme dei file di rilascio prima di installare.
- Su un pacchetto per nodi come Umbrel o Start9, Bitcoin Core di solito si aggiorna tramite l’app store del pacchetto, ed è lì che va cercata la versione disponibile.
Chi deve muoversi per primo dipende dal bug. Nella discussione sulla modifica su GitHub, Poinsot ha fatto l’esempio di un difetto nella creazione dei template di blocco, per il quale i miner dovrebbero aggiornare il prima possibile mentre i commercianti possono procedere con più calma. È una delle ragioni per cui il progetto vuole che gli avvisi contengano dettagli. Una nota a margine per chi pensa di passare in seguito alla 32.0: CryptoSlate riferisce che questa porta il formato PSBT predefinito alla versione 2, e il 14 ottobre un utente ha scoperto che i file del nuovo wallet grafico non si importavano nei co-firmatari Core più vecchi, con una correzione rinviata alla 32.1.
Bitcoin Core non è l’unico software per nodi sotto pressione per correggere più in fretta; l’implementazione Lightning Eclair ha rilasciato a metà ottobre una correzione che impedisce alle pagine web di inviare comandi ai nodi Lightning. Altro contesto sulla rete è nella nostra pagina su Bitcoin.
Che cosa ancora non si sa
La data di rilascio di Bitcoin Core 32.0 non è stata fissata, e con essa il giorno in cui la 29.x esce dal supporto. Nessun bug è stato ancora trattato nella categoria dei bug facili da individuare, quindi nessuno ha visto quanto in fretta arrivi in pratica una versione di manutenzione. I 161 peer mancanti dalla ripartizione di CryptoSlate restano senza spiegazione. E la quota di software obsoleto dentro exchange, custodi e mining pool, che non compaiono mai nelle scansioni pubbliche, non è affatto nota.
Due cose da seguire: il primo avviso pubblicato in base alla regola dei bug facili da individuare, e la composizione delle versioni nelle istantanee del KIT una volta uscita la 32.0.