Bitcoin Core 32.1 è disponibile per il download: le versioni 29.x e precedenti passano a fine supporto e tra due settimane saranno divulgate tre vulnerabilità corrette nella 30.0, secondo le note di rilascio ufficiali. La 32.1 sostituisce la 32.0, che era stata taggata ma non annunciata né rilasciata del tutto.
La pagina dell’annuncio sul sito del progetto indica il 27 ottobre 2026, mentre la release su GitHub risulta pubblicata il 28 ottobre alle 14:23 UTC. Nella stessa finestra di pochi minuti sono comparse anche la 31.2, la 30.4 e la 29.5.
Bitcoin Core 32.1: perché esce al posto della 32.0
Le note di rilascio aprono con una frase netta: a causa di problemi dell’ultimo minuto, la 32.0, pur essendo stata taggata, non è mai stata annunciata né rilasciata del tutto. La 32.1 la sostituisce. BitcoinLive24 aveva raccontato lo stato della quarta release candidate della 32.0, quando una versione definitiva non era ancora stata annunciata.
Le novità della serie 32 sono descritte nelle note della 32.1. Sul sito del progetto i binari sono scaricabili da bitcoincore.org/bin/bitcoin-core-32.1, e la pagina GitHub avverte di non usare i link generati automaticamente da GitHub, perché solo quelli del sito sono prodotti in modo deterministico e firmati.
Fine supporto per la 29.x e tre vulnerabilità da divulgare
Le note dichiarano che con questa nuova versione maggiore le versioni 29.x e precedenti raggiungono la fine del supporto (End of Life) e non riceveranno più aggiornamenti. Chi usa ancora quelle versioni può aggiornare direttamente, anche se, avvertono le note, la migrazione della cartella dati può richiedere tempo.
Il progetto annuncia anche il calendario di divulgazione delle falle. Secondo le note, tra due settimane verranno rese pubbliche le vulnerabilità di gravità media e alta corrette nella 30.0: sono tre. Le vulnerabilità di gravità bassa corrette nella 32.1 sono invece zero. Il testo non descrive il contenuto delle tre falle, quindi per ora non è possibile dire di che tipo siano.
Un’altra correzione di sicurezza è già descritta per intero. Sui sistemi non Windows, un chiamante RPC autenticato e autorizzato a creare wallet poteva eseguire comandi arbitrari con l’account del processo del nodo, se era configurata l’opzione -walletnotify, scegliendo un nome di wallet con caratteri speciali delle espressioni regolari (PR #36048).
Ora i segnaposto vengono sostituiti trattando il nome del wallet in modo letterale.
Privacy: la fuga di IP nella trasmissione privata
La 32.1 corregge una possibile fuga dell’indirizzo IP di chi invia una transazione con sendrawtransaction quando è attivo -privatebroadcast=1. In questa modalità il nodo forza le connessioni verso peer IPv4 e IPv6 attraverso il proxy Tor. Il problema, spiegano le note, nasceva se il tentativo con il protocollo P2P v2 falliva: la riconnessione con il protocollo v1 ignorava la richiesta di proxy e poteva avvenire in chiaro (PR #35410).
Le note precisano che la fuga richiedeva più condizioni insieme: un indirizzo IPv4 o IPv6 annunciato come compatibile con la v2, Tor configurato dal mittente, nessun proxy impostato per IPv4 e IPv6 e un destinatario che in realtà non supporta la v2. Per la stessa funzione la coda di trasmissione privata è ora limitata a 10.000 voci e ogni transazione a 1.000 tentativi di invio.
Cosa cambia per chi gestisce un nodo
Il numero predefinito di connessioni automatiche (-maxconnections) passa da 125 a 200, per dare più capacità in ingresso ai peer che inoltrano solo blocchi. I peer che inoltrano transazioni possono occupare al massimo il 50% degli slot in ingresso, valore regolabile con la nuova opzione -inboundrelaypercent. Per mantenere i limiti precedenti le note indicano -maxconnections=125 -inboundrelaypercent=100.
Anche l’uso di disco cambia. L’indice delle transazioni (-txindex), se ricostruito da zero, occupa meno della metà dello spazio.
Chi ha già un indice non vede il risparmio finché non lo ricrea: bisogna fermare il nodo, cancellare la cartella indexes/txindex e riavviare, con una ricostruzione che può richiedere fino a qualche ora. Dopo la ricostruzione l’indice non è più leggibile dalle versioni precedenti, quindi un eventuale ritorno indietro lo rifarà nel vecchio formato.
Sul fronte delle prestazioni, la validazione dei blocchi può ora leggere in parallelo dal database gli input delle transazioni: l’opzione -prevoutfetchthreads usa 8 thread per impostazione predefinita, fino a un massimo di 16, e si disattiva con il valore 0. Il vecchio server HTTP basato su libevent è stato sostituito da uno personalizzato, con un comportamento più aderente agli standard RFC: i client non autorizzati da -rpcallowip vengono ora disconnessi subito invece di ricevere un errore 403.
Le note elencano anche modifiche che possono rompere script esistenti: taproot è stato rimosso da getdeploymentinfo, fundrawtransaction non accetta più un booleano come secondo argomento, i nomi di wallet che sono percorsi relativi con elementi . o .. non sono più permessi, la chiave bip125-replaceable sparisce dalle risposte RPC del mempool, salvo l’opzione -deprecatedrpc=bip125, e il nuovo -rpcmaxconnections limita per impostazione predefinita a 16 i client HTTP connessi.
Commissioni, wallet e PSBT
Il comando estimatesmartfee combina ora due stimatori: quello storico basato sui blocchi e uno nuovo basato sul contenuto del mempool. Restituisce il valore più basso tra i due, quindi il nuovo stimatore può solo abbassare la stima. Chi vuole il comportamento precedente può scegliere esplicitamente lo stimatore a blocchi con l’opzione fee_rate_estimator. I dati dello stimatore a blocchi finiscono in un nuovo file, fees/block_policy_estimates.dat.
Per i wallet arrivano exportwatchonlywallet, che crea un file watch-only senza chiavi private importabile su un altro nodo, addhdkey, che aggiunge al wallet una chiave estesa BIP 32 senza doverla importare in un descriptor separato, e derivehdkey, che ricava una xpub o una xprv da un percorso di derivazione e può servire a coordinare un multisig. I comandi createpsbt, walletcreatefundedpsbt, converttopsbt e psbtbumpfee creano ora per impostazione predefinita PSBT di versione 2 (le PSBT sono le transazioni parzialmente firmate usate per firmare offline), mentre send e sendall non sono più sperimentali.
| Elemento | Dato | Fonte |
|---|---|---|
| Versione | Bitcoin Core 32.1 | Note di rilascio |
| Release su GitHub | 28 ottobre 2026, 14:23 UTC | release GitHub |
| Versioni a fine supporto | 29.x e precedenti | Note di rilascio |
| Vulnerabilità da divulgare tra due settimane | 3 (media/alta, corrette nella 30.0) | Note di rilascio |
| Connessioni automatiche predefinite | da 125 a 200 | PR #28463 |
| Thread di prefetch predefiniti | 8 (massimo 16) | PR #35295 |
| Coda trasmissione privata | massimo 10.000 voci | PR #35406 |
Cosa aspettarsi
Il primo appuntamento è la divulgazione delle tre vulnerabilità corrette nella 30.0, attesa tra due settimane secondo le note. Per chi ha un nodo, l’aggiornamento comporta alcune scelte pratiche: i nuovi limiti di connessione, l’eventuale ricostruzione degli indici e l’eventuale scelta dello stimatore delle commissioni a blocchi.
Le note segnalano inoltre che il progetto valuta se abbandonare il supporto a CJDNS (discussione #36041) e che la prossima versione maggiore prevede di smettere di supportare la compilazione su Windows con MSVC, una volta pronto il supporto a clang-cl.
Le versioni di manutenzione uscite insieme alla 32.1 riportano tra le modifiche principali l’esclusione dei bit 5-28 di BIP 9 dalla segnalazione dei soft fork, come previsto da BIP 323, secondo le note della 31.2 e della 30.4. Sul tema della sicurezza del codice, BitcoinLive24 ha già scritto della nuova policy di sicurezza di Bitcoin Core per i fix rapidi dei bug semplici.
Scarica l’app BitcoinLive24 per ricevere le novità sul software dei nodi Bitcoin.
Domande frequenti su Bitcoin Core 32.1
Che cos’è Bitcoin Core 32.1?
Bitcoin Core 32.1 è la versione del software di riferimento per i nodi Bitcoin che sostituisce la 32.0, taggata ma mai annunciata né rilasciata del tutto, come indicano le note di rilascio.
Devo aggiornare se uso la versione 29.x?
Sì, se vuoi continuare a ricevere correzioni: le note dichiarano che le versioni 29.x e precedenti sono a fine supporto. Il passaggio diretto è possibile, ma la migrazione della cartella dati può richiedere tempo.
Quando saranno rese note le vulnerabilità corrette nella 30.0?
Tra due settimane dalla pubblicazione delle note: il progetto segnala tre vulnerabilità di gravità media o alta corrette nella 30.0, mentre per la 32.1 ne indica zero di gravità bassa.
Come si ricostruisce l’indice -txindex?
Bisogna fermare il nodo, cancellare la cartella indexes/txindex e riavviare: secondo le note la ricostruzione può richiedere fino a qualche ora e l’indice nuovo non è più leggibile dalle versioni precedenti.
