Bitcoin Core 32.1 è uscito il 27 ottobre 2026: perché la 32.0 è stata ritirata, i tre bug divulgati e il nuovo stimatore delle fee

1. Che cos'è Bitcoin Core 32.1, e perché non esiste una 32.0?

Bitcoin Core è l'implementazione di riferimento di Bitcoin, il software che valida i blocchi, inoltra le transazioni e fa girare il wallet dietro molti servizi. Pubblica una major release circa ogni sei mesi e mantiene le tre più recenti. La versione 32.1, pubblicata il 27 ottobre 2026, è la prima release pubblica della serie 32.x, con un nuovo stimatore delle fee, valori predefiniti più alti per le connessioni, un indice delle transazioni più compatto, PSBT versione 2 come predefinito nelle RPC del wallet e una serie di correzioni di sicurezza. Non cambia alcuna regola di consenso: blocchi e transazioni validi prima restano validi dopo.

La 32.0 esiste solo come tag. Il maintainer fanquake l'ha taggata il 21 ottobre e il 26 ottobre ha scritto nella issue sul calendario delle release che, per problemi di ultimo minuto, la 32.0 non sarebbe stata né annunciata né pubblicata e nessun binario sarebbe stato caricato; la 32.1 sarebbe seguita con lo stesso contenuto più correzioni aggiuntive. La pull request che ha finalizzato la 32.1, integrata quel pomeriggio, fa il backport di esattamente tre modifiche di Antoine Poinsot: il monitoraggio delle eccezioni dei socket allineato tra i backend poll e select, un timeout di 20 minuti per i peer il cui buffer di invio non si svuota mai, e posizioni a 64 bit nei file dei blocchi e nei file undo. Sono le correzioni delle tre vulnerabilità divulgate due giorni dopo, descritte nella sezione 3. Il progetto non ha detto altro sulle ragioni.

2. Quando è uscito? Le date chiave

Le date vengono dalla issue sul calendario delle release di Bitcoin Core, dal server di download di bitcoincore.org e dai post di disclosure. Stato al 1 novembre 2026.

3. Quali vulnerabilità sono state corrette e divulgate?

Tre, tutte pubblicate il 28 ottobre 2026 e tutte trovate per la stessa via: una scansione automatica del codice con un large language model, condotta come Project Loupe da Elias Rohrer di Spiral, con Gregory Sanders a validare ogni segnalazione e a riferirla al team di sicurezza di Bitcoin Core. Due sono state riscoperte in modo indipendente da altri ricercatori prima che uscissero le correzioni. La policy di Bitcoin Core è divulgare i bug che giudica facili da scoprire non appena esistono release corrette per ogni ramo mantenuto, ed è per questo che i resoconti sono arrivati un giorno dopo la 32.1.

CVE-2026-117349, gravità media: un peer che dichiara di non supportare i ping BIP 31 non viene mai disconnesso per averli ignorati, e se legge anche i messaggi molto lentamente il nodo continua a mettergli in coda annunci di transazioni senza limite. Il post stima la crescita fino a circa 2 MB all'ora per un peer in ingresso e 5 MB all'ora per uno in uscita; i nodi che girano con blocksonly sono molto meno esposti. Segnalata il 15 settembre, corretta dalla pull request #36667, che disconnette un peer in pausa che non ha svuotato il suo buffer di invio entro 20 minuti.

CVE-2026-117350, gravità media, riguarda solo Windows, macOS e BSD: il codice dei socket basato su select controllava le condizioni eccezionali anche mentre le letture erano in pausa per backpressure, quindi un peer che inviava dati urgenti TCP poteva forzare letture che aggirano il limite di memoria per peer finché il nodo non esaurisce la memoria. Linux usa poll e non è interessato. Segnalata il 23 ottobre, tre giorni prima che le correzioni fossero integrate, e corretta dalla pull request #36665.

CVE-2026-117346, gravità bassa: le posizioni nei file dei blocchi e nei file undo erano a 32 bit, quindi una volta che un file undo superava i 4 GiB i dati nuovi sovrascrivevano quelli vecchi, e una reorg successiva che avesse bisogno di quei dati avrebbe spento il nodo fino a una reindicizzazione su una versione corretta. Su Windows e sui sistemi a 32 bit le scritture falliscono oltre i 2 GiB. Il post definisce impraticabile lo sfruttamento sui sistemi a 64 bit: un miner avrebbe bisogno di diverse migliaia di blocchi di transazioni non standard, circa un mese di blocchi, piazzati con precisione, più una specifica reorg di due blocchi. Segnalata per la prima volta l'8 luglio, corretta dalla pull request #36669, che memorizza le posizioni come interi a 64 bit senza cambiare il formato su disco; i sistemi a 32 bit restano interessati.

Le note di rilascio della 32.1 elencano altre correzioni che non sono CVE: un nuovo tentativo di private broadcast che poteva far trapelare l'IP del mittente aggirando il proxy Tor, un percorso di esecuzione di comandi tramite nomi di wallet costruiti ad arte con walletnotify sui sistemi diversi da Windows, e tetti di 10.000 transazioni in coda per il private broadcast e di 1.000 tentativi di invio ciascuna. Le note dicono anche che tra due settimane il progetto divulgherà tre vulnerabilità di gravità media e alta corrette nella 30.0 (e nessuna di gravità bassa nella 32.1), quindi un altro post di disclosure è atteso intorno al 10 novembre.

4. Come cambia il nuovo stimatore le fee che paghi?

Se usi un wallet o un servizio che chiede una fee a un nodo Bitcoin Core tramite estimatesmartfee, la 32.1 cambia quello che si sente rispondere. Finora Core usava solo il suo stimatore basato sui blocchi (block policy), che guarda indietro alle tariffe delle transazioni confermate entro un numero di blocchi obiettivo. È prudente e lento a scendere: dopo un picco di congestione continua per un po' a proporre tariffe alte perché lo storico dice ancora "alto". La 32.1 aggiunge uno stimatore basato sulla mempool (mempool policy) che guarda a ciò che è in attesa in questo momento, ed estimatesmartfee restituisce il più basso dei due. Lo stimatore della mempool può solo abbassare il risultato, mai alzarlo, quindi un wallet basato su Core smette prima di pagare troppo una volta che i blocchi si svuotano, e si comporta come prima quando la mempool è piena.

La stessa idea sta dietro le tariffe che mostra la maggior parte degli explorer. Al 1 novembre 2026 mempool.space, che stima solo dalla mempool, mette l'obiettivo a mezz'ora a 1 sat/vB, $0.11 per un trasferimento tipico con un prezzo del BTC di 77.891 USD:

Le tariffe di Bitcoin in questo momento (mempool.space)

Per gli sviluppatori la RPC guadagna un oggetto di opzioni: fee_rate_estimator accetta auto (il predefinito, combinato), block_policy (il vecchio comportamento) o mempool_policy, i valori sconosciuti vengono rifiutati, la verbosità 2 aggiunge mempool_health_statistics, e in modalità auto la risposta indica quale stimatore ha usato. I dati della block policy si spostano in fees/block_policy_estimates.dat e vengono migrati al primo avvio. La selezione delle monete del wallet usa la stima combinata. Cosa non cambia: la fee resta una tua scelta, replace-by-fee e child-pays-for-parent salvano ancora una transazione che ha pagato troppo poco, e le fasce sat/vB della nostra guida alle fee si aggiornano ogni minuto dalla mempool.

5. Cosa cambia per gli operatori di nodi?

Aggiorna, e controlla su quale ramo sei. La 29.x ha raggiunto il fine vita il 27 ottobre 2026 e la 29.5 del 28 ottobre è la sua release finale, quindi un nodo sulla 29.x non riceverà più correzioni; la 30.x resta mantenuta finché non esce la 33.0, la 31.x fino alla 34.0 e la 32.x fino alla 35.0. L'aggiornamento diretto da una versione a fine vita alla 32.1 è supportato, anche se la migrazione della directory dei dati può richiedere tempo. Le piattaforme supportate sono Linux con kernel 3.17 o successivo, macOS 14 o successivo e Windows 10 versione 1903 o successiva.

Due valori predefiniti cambiano l'impronta del nodo. Il maxconnections predefinito sale da 125 a 200, e una nuova opzione inboundrelaypercent (predefinito 50) limita la quota di slot in ingresso concessi ai peer che inoltrano transazioni; per mantenere il vecchio comportamento avvia con maxconnections=125 e inboundrelaypercent=100. L'inoltro delle transazioni in uscita ha ora un limite di velocità con una coda globale (txsendrate, predefinito 14 transazioni al secondo, 2,5 volte tanto per i peer in uscita, più un tetto di banda di 12 MB ogni 10 minuti). Gli hidden service Tor creati automaticamente ricevono difese proof-of-work quando il demone Tor le supporta. Il server RPC non usa più libevent, e una nuova opzione rpcmaxconnections (predefinito 16) limita i client HTTP simultanei.

Due opzioni risparmiano disco e tempo. L'indice delle transazioni memorizza meno dati: un txindex ricostruito occupa meno della metà dello spazio, ma il risparmio lo ottieni solo cancellando indexes/txindex nella directory dei dati e riavviando, cosa che può richiedere ore; il txospenderindex si riduce allo stesso modo. La validazione dei blocchi precarica in parallelo gli output precedenti con prevoutfetchthreads, predefinito 8, massimo 16, 0 per disattivare. Le sessioni I2P ElGamal legacy saranno rimosse entro la v34 e il supporto a CJDNS è in fase di revisione, quindi gli operatori che dipendono dall'uno o dall'altro dovrebbero seguire le prossime note di rilascio.

6. Cosa cambia per sviluppatori e wallet?

La modifica incompatibile è la versione 2 dei PSBT. createpsbt, walletcreatefundedpsbt, converttopsbt e psbtbumpfee ora producono PSBT versione 2 per impostazione predefinita; un nuovo argomento psbt_version seleziona la versione 0 per gli strumenti che non sanno ancora leggere la v2. Se un dispositivo di firma, un coordinatore o uno script nel tuo flusso non è stato testato con PSBTv2, passa l'argomento prima di aggiornare il nodo con cui parla.

Diversi campi e opzioni sono deprecati: vsize nelle RPC della mempool e in getrawtransaction (usa vsize_adjusted, o vsize_bip141 per la dimensione BIP 141 grezza), l'opzione di avvio walletrbf e la chiave bip125-replaceable (i nodi inoltrano le sostituzioni di qualunque transazione da Core 28), e la RPC removeprunedfunds, che ora richiede deprecatedrpc=removeprunedfunds. I nomi di wallet con elementi di percorso fatti di punti, o un wallet chiamato con una sola barra, vengono rifiutati.

Novità nell'interfaccia RPC: exportwatchonlywallet, addhdkey e derivehdkey; send e sendall non sono più segnati come sperimentali; getblockchaininfo riporta l'avanzamento della validazione in background di assumeutxo; getbalances aggiunge un saldo nonmempool; getnetworkinfo riporta la versione dell'asmap; exportasmap e getopenrpcinfo; un comando bitcoin-util getchainparams. Il server HTTP sviluppato in casa è più rigido sugli header, quindi controlla qualsiasi client che ne invii di insoliti. Nulla di tutto questo tocca il modo in cui una transazione viene costruita o trasmessa, quindi gli SDK che parlano con un nodo tramite la RPC standard, ChainGate compreso, continuano a funzionare.

7. Chi usa Bitcoin deve fare qualcosa?

No. La 32.1 non cambia alcuna regola di consenso, quindi non c'è un fork, non c'è una nuova moneta e nulla da migrare; le tue chiavi, i tuoi indirizzi e i tuoi saldi sono gli stessi. Se usi un wallet leggero o tieni le monete su un exchange, l'aggiornamento avviene sulle macchine di altri.

Quello che potresti notare è un wallet collegato a un nodo Core che propone fee più basse nelle ore dopo un periodo di traffico intenso, dato che lo stimatore ora legge la mempool. Se gestisci un tuo nodo, aggiorna; se sei sulla 29.x, dal 27 ottobre sei su un ramo non più mantenuto. Chiunque ti dica di spostare o "aggiornare" i tuoi bitcoin per via di una release di Core sta tentando una truffa.

8. Cosa è confermato e cosa resta aperto?

9. Cosa viene dopo?

Il prossimo appuntamento con una data è la disclosure delle tre vulnerabilità corrette nella 30.0, che le note di rilascio promettono due settimane dopo la release, quindi intorno al 10 novembre 2026. La aggiungeremo qui, insieme a qualsiasi release di manutenzione 32.x. Il registro degli aggiornamenti qui sotto riporta cosa è cambiato e quando.

Nel frattempo, la guida alle fee di Bitcoin mostra le fasce sat/vB in tempo reale a cui il nuovo stimatore si sta allineando, la guida all'hash della transazione spiega come seguire una transazione in attesa, e l'articolo sulla chiusura di Binance Pool copre cosa succede alle transazioni bloccate una volta che quell'acceleratore chiude il 10 novembre.

Aggiornamenti di questo articolo

• 31 ottobre 2026: prima pubblicazione. Date dalla issue sul calendario delle release di Bitcoin Core, dal server di download e dalle pagine delle release di bitcoincore.org; dettagli delle vulnerabilità dai tre post di disclosure del 28 ottobre; contenuto della release dalle note di rilascio della 32.1 e dalla pagina del ciclo di vita.

Domande frequenti