Bitcoin Core 32.0, la prossima versione maggiore del software di riferimento per i nodi Bitcoin, è arrivata alla quarta release candidate: il tag v32.0rc4 è stato creato su GitHub il 12 ottobre 2026. La bozza delle note di rilascio elenca più connessioni in ingresso, un indice delle transazioni che, se ricostruito, occupa meno della metà dello spazio e una nuova stima delle commissioni basata sul mempool. Per chi gestisce un nodo cambiano anche alcuni default e arrivano nuovi comandi per i wallet watch-only.
Bitcoin Core 32.0: a che punto è il rilascio
Al momento della stesura, il repository ufficiale di Bitcoin Core contiene i tag v32.0rc1, rc2, rc3 e rc4, ma non ancora un tag v32.0 definitivo. Una release candidate è una versione quasi finale, distribuita per essere provata prima del rilascio. Bitcoin Optech segnalava la rc3 nella newsletter n. 426 del 9 ottobre, con una guida al test per chi vuole collaborare.
Il ritmo è quello previsto dal ciclo di rilascio del progetto, che dichiara l’obiettivo di una versione maggiore ogni sei mesi. La precedente, Bitcoin Core 31.0, è stata pubblicata il 20 aprile 2026, secondo le release di GitHub. Con l’arrivo della 32.0, la bozza indica che le versioni 29.x e precedenti passano a fine supporto (End of Life), cioè non riceveranno più aggiornamenti.
Una precisazione: le note di rilascio sono una bozza che, come si legge in cima alla pagina del wiki degli sviluppatori, può essere modificata da chiunque secondo il processo del progetto. I dettagli possono quindi cambiare prima della versione finale.
Rete peer-to-peer: più connessioni e relay delle transazioni più leggero
Secondo la bozza delle note di rilascio, il numero massimo 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 potranno usare al massimo il 50% degli slot in ingresso, valore regolabile con la nuova opzione -inboundrelaypercent. Le connessioni in uscita automatiche restano invariate. Chi imposta -maxconnections a mano mantiene il proprio valore, ma il nuovo limite del 50% sul relay in ingresso si applica comunque: per conservare i vecchi limiti la bozza indica -maxconnections=125 -inboundrelaypercent=100.
Cambia anche il modo in cui il nodo limita l’invio di transazioni agli altri peer. Il limite non è più calcolato peer per peer, ma su un arretrato globale: il valore predefinito resta 14 transazioni al secondo (moltiplicato per 2,5 per i peer in uscita), con in più un tetto di banda di 12 MB di transazioni ogni 10 minuti. Lo scopo, scrivono gli sviluppatori, è ridurre memoria e CPU nei periodi di traffico intenso.
Sul fronte privacy, i servizi nascosti Tor creati automaticamente da Bitcoin Core avranno le difese a proof-of-work (un piccolo calcolo richiesto a chi si connette, per frenare gli abusi) attive, se il demone Tor le supporta. La stessa bozza cita anche la correzione di una possibile fuga dell’indirizzo IP di chi trasmette una transazione con -privatebroadcast=1, quando una connessione v2 fallita veniva ritentata in v1 senza passare da Tor.
Meno spazio su disco e una nuova stima delle commissioni dal mempool
L’indice delle transazioni (-txindex) salva meno dati su disco: un indice ricostruito da zero occupa meno della metà dello spazio, indica la bozza delle note di rilascio. Chi ha già un indice non vede il risparmio finché non lo ricrea, cancellando la cartella indexes/txindex e riavviando il nodo: la ricostruzione può richiedere fino a qualche ora e l’indice nuovo non è più leggibile dalle versioni precedenti. Anche l’indice -txospenderindex usa meno spazio.
Il comando estimatesmartfee combina ora due stimatori: quello esistente, basato sui blocchi passati, e uno nuovo che guarda il contenuto attuale del mempool (la sala d’attesa delle transazioni non ancora confermate). Il nuovo stimatore risponde solo quando i blocchi recenti indicano un mempool in salute; il risultato restituito è il più basso dei due, quindi può solo abbassare la stima rispetto a prima. Con l’opzione fee_rate_estimator si può tornare al vecchio comportamento.
Tra le impostazioni nuove c’è anche -prevoutfetchthreads, che legge in parallelo dal database i dati degli input durante la validazione dei blocchi: 8 thread di default, fino a 16, 0 per disattivare. La bozza lo introduce per accelerare la validazione quando quei dati devono essere letti da disco.
Wallet e RPC: watch-only esportabile e nuove interfacce
Per i wallet, la bozza delle note di rilascio introduce exportwatchonlywallet, che crea da un wallet a descrittori un file watch-only con descrittori pubblici, transazioni e rubrica, ma senza chiavi private: si importa su un altro nodo con restorewallet. Arrivano anche addhdkey e derivehdkey, quest’ultimo pensato per coordinare configurazioni multisig, dove ogni firmatario condivide una xpub con un percorso di derivazione diverso. I comandi send e sendall non sono più marcati come sperimentali, e createpsbt e comandi collegati creano per default PSBT versione 2.
Per chi sviluppa applicazioni, il nuovo RPC getopenrpcinfo restituisce una descrizione leggibile da macchina, in formato OpenRPC 1.4.1, dei comandi disponibili sul nodo in esecuzione. Bitcoin Optech descrive inoltre la correzione n. 36365 allo stimatore basato sul mempool, unita al ramo principale di Bitcoin Core (la newsletter non indica se sia già nella rc4): se lo stimatore da mempool non è disponibile, il nodo ricade sulla stima basata sui blocchi, e non lo usa subito dopo un riavvio se il mempool non si è caricato.
| Area | Novità in Bitcoin Core 32.0 | Effetto pratico |
|---|---|---|
| Connessioni | Massimo automatico da 125 a 200 (-maxconnections) | Più capacità in ingresso, soprattutto per peer che inoltrano solo blocchi |
| Relay in ingresso | Al massimo 50% degli slot per peer che inoltrano transazioni (-inboundrelaypercent) | Impostazione regolabile da 0 a 100 |
| Relay in uscita | Arretrato globale, 14 tx/s e 12 MB ogni 10 minuti | Obiettivo dichiarato: ridurre memoria e CPU con molto traffico |
Indice txindex | Meno della metà dello spazio se ricostruito | Serve ricostruire l’indice per risparmiare spazio |
| Stima commissioni | Due stimatori combinati, vale il più basso | Stime che possono scendere con mempool sano |
| Validazione blocchi | Prefetch in parallelo (-prevoutfetchthreads, 8 di default) | Lettura in parallelo dei dati degli input durante la validazione dei blocchi |
| Wallet | exportwatchonlywallet, addhdkey, derivehdkey | Esporta un watch-only senza chiavi private; derivazione di xpub per il multisig |
| RPC | getopenrpcinfo | Elenco dei comandi in formato OpenRPC |
Tutte le righe della tabella provengono dalla bozza delle note di rilascio di Bitcoin Core 32.0, citata sopra.
Cosa viene deprecato, rimosso o corretto
La bozza delle note di rilascio segnala anche diverse rimozioni. L’opzione -walletrbf è deprecata e sparirà alla versione successiva, e la casella «Enable Replace-By-Fee» scompare dalla schermata di invio della GUI: le transazioni create dall’interfaccia seguono l’impostazione del wallet, che per default segnala la sostituibilità. La chiave bip125-replaceable non compare più nelle risposte degli RPC del mempool, salvo richiesta esplicita con -deprecatedrpc=bip125.
Sul piano tecnico, la libreria libevent è stata sostituita da un server HTTP interno, più rigoroso su alcuni casi limite. Chi prova a connettersi da indirizzi non ammessi da -rpcallowip viene ora disconnesso subito, senza ricevere un errore 403. Sul fronte sicurezza, la bozza descrive la correzione di un problema per cui, su sistemi non Windows, un chiamante RPC autenticato e autorizzato a creare wallet poteva eseguire comandi arbitrari tramite -walletnotify scegliendo un nome di wallet costruito ad arte.
Guardando avanti, la bozza avverte che il supporto alla compilazione con MSVC su Windows è previsto per la versione maggiore successiva, quando il supporto a clang-cl sarà pronto, e che il progetto sta valutando di eliminare il supporto a CJDNS, una rete poco adottata dai nodi. Per le novità sui messaggi tra nodi, BitcoinLive24 ha raccontato la proposta di Anthony Towns sugli alias a un byte per il protocollo BIP324, mentre per la sicurezza dei nodi resta utile rileggere la patch di sicurezza di Bitcoin Core 31.1. La stessa newsletter di Bitcoin Optech dedica spazio a Shielded Bitcoin, la proposta di transazioni private che abbiamo già analizzato.
Perché le release candidate contano per chi usa Bitcoin
Bitcoin Core è definito da Bitcoin Optech l’implementazione predominante dei nodi completi, e ogni versione maggiore è un banco di prova per la rete: le release candidate esistono per far provare i cambiamenti a sviluppatori e operatori prima che diventino la versione stabile. Bitcoin Optech invita a considerare l’aggiornamento alle nuove versioni o ad aiutare a testare le release candidate, e rimanda a una guida al test per chi vuole contribuire.
Il quadro che emerge è di un software che lavora su tre fronti: ridurre il costo di gestione di un nodo (disco, memoria, banda), aggiornare gli strumenti dei wallet (watch-only, multisig, PSBT) e togliere funzioni vecchie. Per i prossimi passaggi conviene seguire il tag definitivo v32.0 e le note finali, che sostituiranno la bozza.
BitcoinLive24 seguirà il rilascio. Per ricevere gli avvisi sulle notizie Bitcoin in tempo reale, scarica l’app BitcoinLive24.
Domande frequenti su Bitcoin Core 32.0
Quando esce Bitcoin Core 32.0?
Nelle fonti consultate non c’è una data: al 13 ottobre 2026 esistono i tag da rc1 a rc4 ma non il tag definitivo v32.0, come si vede nella pagina dei tag del repository ufficiale. Il ciclo di rilascio del progetto prevede una versione maggiore ogni sei mesi.
Cosa cambia per chi gestisce un nodo?
Secondo la bozza delle note di rilascio, le connessioni automatiche massime salgono da 125 a 200, il limite sul relay delle transazioni diventa globale e l’indice txindex ricostruito occupa meno della metà dello spazio.
Cos’è una release candidate?
È una versione quasi finale di un software, pubblicata per essere provata da sviluppatori e operatori prima del rilascio stabile. Se non emergono problemi gravi, può diventare la versione definitiva.
Bitcoin Core 32.0 cambia le regole di consenso di Bitcoin?
Nelle note di rilascio consultate non compaiono modifiche alle regole di consenso: l’elenco riguarda rete, indici, stima delle commissioni, wallet, RPC e strumenti di compilazione. L’unico riferimento ai soft fork è nel logging: i bit di versione da 5 a 28 vengono ignorati nella segnalazione, come previsto da BIP 323.
