L’implementazione di riferimento di Bitcoin. Il suo sito pubblica gli annunci delle nuove versioni, gli avvisi di sicurezza e le dichiarazioni del progetto.
Un miner poteva spingere un file di undo di Bitcoin Core oltre i 4 GiB, mandando in overflow le posizioni a 32 bit e corrompendo i dati: se poi arriva la reorg giusta, i nodi si spengono. Windows e i sistemi a 32 bit cedono già a 2 GiB, senza bisogno di reorg. La CVE-2026-117346, di gravità Bassa, richiederebbe circa un mese di tutti i blocchi della rete. Le versioni 32.1, 31.2, 30.4 e 29.5 risolvono sui sistemi a 64 bit; restano esposti i nodi a 32 bit e chi tiene i blocchi su FAT32.
In Bitcoin Core 29.5 poll() e select() monitorano allo stesso modo le eccezioni dei socket (#36665), e per i peer con invio in pausa scatta un timeout obbligatorio (#36667). Le posizioni dei flatfile diventano interi a 64 bit (#36669), i nodi presumono il supporto v2transport per gli indirizzi ricevuti dai seed e sparisce un DNS seed.
Fingendo di non supportare i ping BIP 31, un peer malevolo poteva schivare la disconnessione dopo 20 minuti e leggere con lentezza, gonfiando la coda di invio del nodo fino a 2MB l'ora per ogni peer in entrata e 5MB per ognuno in uscita. La CVE-2026-117349, di gravità Media, è chiusa dalla #36667, presente nelle versioni 32.1, 31.2, 30.4 e 29.5 di Bitcoin Core; i nodi -blocksonly erano molto meno esposti.
I nodi su Windows, macOS e BSD potevano finire in crash per colpa di un peer connesso che inviava dati TCP urgent: aggirando le letture in pausa nel backend select(), accumulavano memoria senza limite (CVE-2026-117350). Chi gira su Linux usa poll() e resta fuori dal problema. Il bug, di gravità Media e scovato da una scansione con LLM nell'ambito di Project Loupe, è corretto in Bitcoin Core 32.1, 31.2, 30.4 e 29.5.
Con Bitcoin Core 30.4 i bit BIP 9 da 5 a 28 non valgono più come segnali di soft fork, in linea con BIP 323: i blocchi che li attivano smettono di generare avvisi su deployment sconosciuti (#34779). Sul fronte rete arriva un timeout obbligatorio per i peer con invio in pausa (#36667), mentre le posizioni dei flatfile passano a interi a 64 bit (#36669).
Il private broadcast ha ora un tetto in Bitcoin Core 31.2: la coda delle transazioni che la rete non ha ancora rimandato indietro si ferma a 10.000 voci e, una volta piena, rifiuta i nuovi invii, lasciando al chiamante il compito di svuotarla con abortprivatebroadcast (#35406). I version bit da 5 a 28 non contano più come segnali di soft fork, come prevede BIP 323.
Il private broadcast di Bitcoin Core 32.1 non rischia più di rivelare l'IP del mittente: la fuga poteva verificarsi quando una connessione v2 fallita ritentava in v1 direttamente, senza passare da Tor. Il valore predefinito di -maxconnections sale da 125 a 200, e il limite al relay delle transazioni in uscita passa da un conteggio per peer a un backlog globale.
Le pesanti letture e scritture su disco durante il normale funzionamento dipendevano da un bug, corretto in Bitcoin Core 29.4: il database del chainstate riscriveva di continuo ampie parti di sé. La soluzione disattiva la seek compaction di LevelDB e compatta il chainstate a intervalli regolari (#35465).
Stop alle riscritture continue del chainstate su disco con Bitcoin Core 30.3, che sistema anche un crash del feebumper quando la commissione combinata di bump non è disponibile (#34870) e un bug della coin selection che calcolava un importo come booleano (#34888). Per le PSBT, le pubkey MuSig2 vengono ora validate durante la deserializzazione di pubnonce e firme parziali (#34219).
Bitcoin Core 31.1 chiude una fuga di indirizzi IP in -privatebroadcast: alcune connessioni uscivano su clearnet invece che sulla rete privata attiva. L'aggiornamento elimina anche le riscritture del chainstate all'origine dell'eccessiva attività su disco e respinge una lista di pubkey vuota nell'aggregazione di chiavi MuSig2 (#35316).
Un handshake v2 fallito può esporre l'indirizzo IP del mittente in Bitcoin Core 31.0: con -privatebroadcast attivo, il nuovo tentativo in v1 salta il proxy Tor e si collega direttamente al peer. Il probabile innesco è un peer malevolo che chiude di proposito l'handshake. In attesa della 31.1, si può disattivare la funzione, impostare -v2transport=0 oppure instradare su Tor le connessioni IPv4/IPv6 in uscita.
Le versioni di Bitcoin Core successive alla 0.14.0 e precedenti alla 29.0 potevano leggere memoria già liberata durante la validazione di un blocco invalido creato ad arte, con conseguente crash del nodo. La CVE-2024-52911 è classificata Alta, anche se l'attaccante deve spendere proof-of-work valido sulla punta della catena, e l'esecuzione di codice da remoto è ritenuta improbabile. L'ha segnalata Cory Fields; la correzione è nella 29.0.
La cluster mempool manda in pensione il vecchio design in Bitcoin Core 31.0: ai limiti su antenati e discendenti subentrano cluster da massimo 64 transazioni e 101 kB, e sparisce il CPFP carveout. Il -dbcache predefinito sale a 1024 MiB sulle macchine con almeno 4096 MiB di RAM, e la nuova opzione -privatebroadcast invia le trasmissioni di sendrawtransaction solo via Tor o I2P.
Due errori legati ai wallet senza nome trovano soluzione in Bitcoin Core 28.4: la migrazione dei wallet legacy (#34156) e createfromdump, che in caso di fallimento cancellava la cartella dei wallet (#34215). Da chainparams viene anche tolto un DNS seed (#33723).
Bitcoin Core 29.3 smette di penalizzare i peer che inviano transazioni invalide per il consenso (#33050). La validazione guadagna una cache per input del midstate sighash per gli script legacy, P2SH e segwit v0 (#32473) e individua il witness stripping senza rieseguire i controlli Script (#33105); addPackageTxs del miner perde un overflow di intero senza segno (#33475).
Niente più migrazioni fallite sui wallet legacy senza nome con Bitcoin Core 30.2 (#34156), e createfromdump non cancella più la cartella dei wallet quando fallisce su uno di essi (#34215). E premere Ctrl-C non blocca più tutto durante le chiamate di attesa IPC (#33511).
In rari casi, una migrazione di wallet.dat non riuscita in Bitcoin Core 30.0 o 30.1 può cancellare tutti i file della directory dei wallet, mettendo a rischio i fondi. Gli sviluppatori hanno ritirato quei binari e chiedono di non migrare da GUI o RPC fino alla 30.2. Il bug si manifesta solo con un wallet.dat predefinito e senza nome che non riesce a migrare o a caricarsi; gli altri utenti non sono coinvolti.
I wallet di Bitcoin Core 30.1 non prendono più in considerazione le monete TRUC non confermate che hanno antenati (#33528). Sul lato IPC le opzioni non richiedono più l'argomento -m (#33229), il logging dei messaggi pesa meno (#33517) e le chiamate waitNext in corso si possono annullare (#33676).
Transazioni non standard costruite ad arte potevano impegnare un nodo Bitcoin Core per qualche secondo ciascuna senza far disconnettere il mittente, offrendo a un attaccante un modo per ritardare la propagazione dei blocchi. La CVE-2025-46598, classificata Bassa, è stata segnalata da Antoine Poinsot e mitigata nella v30.0 riducendo il tempo di validazione nel caso peggiore.
Blocchi oltre 1GB potevano mandare in overflow un controllo sulla dimensione nei nodi Bitcoin Core a 32 bit e provocarne il crash durante la scrittura su disco, ma solo se inviati come compact block e solo contro una vittima con -maxmempool sopra i 3GB e 1GB di transazioni dentro. La CVE-2025-46597, di gravità Bassa, l'ha trovata Pieter Wuille; a chiuderla nella 29.1 e nella 30.0 è stato il tetto a -maxmempool sui sistemi a 32 bit.
