L’implementazione di riferimento di Bitcoin. Il suo sito pubblica gli annunci delle nuove versioni, gli avvisi di sicurezza e le dichiarazioni del progetto.
Oltre al crash già reso pubblico, la CVE-2018-17144 consentiva a un miner di gonfiare l'offerta di Bitcoin nelle versioni dalla 0.15.X alla 0.16.2, spendendo due volte un output nella stessa transazione. Gli sviluppatori hanno tenuto nascosta quella parte per dare ai sistemi il tempo di passare alla 0.16.3 o alla 0.17.0rc4. Si ritiene che oltre metà dell'hashrate sia aggiornata, non risultano tentativi di sfruttamento e a chi è coinvolto si raccomanda di aggiornare.
Per colpa della CVE-2018-17144, Bitcoin Core dalla 0.14.0 alla 0.16.2 va in crash su un blocco contenente una transazione che spende due volte lo stesso input, e agli utenti viene detto di passare subito alla 0.16.3. Solo un miner disposto a rinunciare ad almeno 12,5 BTC di ricavi consentiti potrebbe produrre un blocco simile.
La RPC verifytxoutproof di Bitcoin Core 0.16.2 non cade più nel costoso attacco alle prove SPV reso noto a inizio giugno, anche se i veri client SPV restano esposti. Una correzione a parte fa sì che abandontransaction scarti ogni discendente di una transazione invece di fermarsi ai figli.
Bitcoin Core 0.16.1 smette di inoltrare OP_CODESEPARATOR negli script di firma legacy, una modifica di policy che semplifica il rilascio di future correzioni per i blocchi lenti da validare. I miner perdono l'opzione -blockmaxsize a favore di -blockmaxweight e ottengono la correzione di un bug che poteva costare ricavi quando producevano due blocchi in rapida successione.
Segwit diventa il default dei wallet in Bitcoin Core 0.16.0: i nuovi indirizzi sono p2sh-segwit salvo diversa indicazione di -addresstype, e gli indirizzi nativi bc1 secondo BIP173 si possono generare e pagare. I nuovi wallet sono solo HD e le versioni precedenti li rifiutano, mentre la schermata di invio della GUI attiva di default RBF BIP125.
Per precauzione contro futuri fork della rete, Bitcoin Core 0.15.1 scarta durante la sincronizzazione iniziale i peer che offrono una catena sotto il minimum-chain-work, insieme ai peer in uscita che servono header noti come invalidi. Una punta ferma da 30 minuti fa scattare una connessione in uscita aggiuntiva. I miner perdono l'uso diretto di blockmaxsize, deprecato, che ora implica soltanto un limite di peso.
Un crash all'avvio della GUI ha portato a Bitcoin Core 0.15.0.1: alcuni client aggiornati alla 0.15.0 cadevano su un'impostazione di commissione personalizzata che l'interfaccia non offre più. Una patch minima, la #11332, gestisce il valore non valido.
Le stime delle commissioni di Bitcoin Core 0.15.0 arrivano a 1008 blocchi in avanti, contro i 25 di prima, e dalla GUI si può alzare la commissione di una transazione non confermata con Replace-By-Fee. Un database del chainstate per singolo output velocizza del 30-40% il download iniziale dei blocchi. La conversione parte da sola al primo avvio e richiede da circa 5 a 30 minuti.
I contributori abituali di Bitcoin Core non hanno legami con btc1, l'implementazione di Segwit2x, e il progetto respinge l'idea che sia un aggiornamento necessario, definendola una rottura controversa delle regole della rete. Segwit, il soft fork atteso a giorni, non ha nulla a che vedere con quell'hard fork e alla maggior parte degli utenti non chiede nulla. Segwit2x non prevede nemmeno una forte protezione dal replay, avverte la nota.
Chi ha attivato UPnP è invitato a installare Bitcoin Core 0.14.2 senza indugio: un errore di signedness degli interi nel miniupnpc incluso, la CVE-2017-8798, permette a chi è sulla rete locale di causare un denial of service o forse altri danni. UPnP resta spento di default, quindi i nodi che non l'hanno mai attivato non sono coinvolti.
I miner non segwit possono continuare a usare getblocktemplate dopo l'attivazione, perché Bitcoin Core 0.14.1 toglie le transazioni segwit dal template. Il default di -dbcache passa a 450MiB e il limite ora regge anche nei picchi di flush. La nuova denominazione di alcuni argomenti di createrawtransaction e disconnectnode rompe le chiamate con argomenti nominati scritte per la 0.14.0.
Il wallet di un nuovo nodo potrebbe inviare e ricevere già prima della fine della sincronizzazione con la modalità ibrida full block SPV prevista dalla roadmap di Bitcoin Core, che scarica i blocchi a partire dalla chiave più vecchia del wallet mentre la validazione completa prosegue in background. Spariscono le fughe di privacy dei Bloom filter al prezzo di più banda, e per i pagamenti conviene attendere almeno 6 conferme.
Sostituendo ECDSA con le firme Schnorr, un multisig 50-di-50 occuperebbe quanto una spesa con una sola chiave e ne nasconderebbe la policy agli osservatori. La roadmap di Bitcoin Core indica come ostacolo principale la cancellation, con cui un firmatario malevolo sottrae la chiave di un altro utente. La delinearizzazione risponde a questo attacco, anche se la sua prova di sicurezza è ancora in peer review.
Caching delle firme in Bitcoin-Qt 0.7.0, Ultraprune con LevelDB nella 0.8.0 e sincronizzazione headers-first in Bitcoin Core 0.10 sono i protagonisti della parte 1 di questa retrospettiva sulle accelerazioni del software di riferimento. La sola verifica parallela degli script ha dato dal 35% al 100% nei benchmark degli sviluppatori.
I nuovi nodi hanno completato il download iniziale dei blocchi 5,7 volte più in fretta con Bitcoin Core 0.14.0 rispetto alla 0.13.2, in un test su Amazon EC2 con impostazioni predefinite: 6 ore e 24 minuti contro 1 giorno, 12 ore e 40 minuti. Merito degli assumed valid blocks e della memoria condivisa tra mempool e cache UTXO. I wallet ottengono anche il fee bumping opzionale, spento di default.
Gli invii del wallet che toccano il limite sulle catene non confermate non restituiscono più un errore RPC in Bitcoin Core 0.13.2: risultano riusciti, e l'inserimento in mempool viene ritentato al rebroadcast senza riavvii. Le stime delle commissioni con obiettivo di 1 blocco sono disattivate, ed è corretta la gestione dei compact block invalidi.
Il costo in byte più alto è quello di incapsulare segwit in P2SH: il 19% in più per P2WSH/P2SH e l'11% per P2WPKH/P2SH su una transazione da 180 byte, secondo il conteggio di Bitcoin Core su quanto porterebbe BIP141. La validazione richiede circa cinque hash SHA256 in più per transazione. Tra i rischi vengono valutati bug, blocchi più grandi e commissioni più basse, e gli autori non prendono posizione sull'attivazione.
I miner trovano in Bitcoin Core 0.13.1 il codice per segnalare il soft fork segwit, con segnalazione aperta dal 15 novembre 2016 all'inizio del successivo periodo di retarget. Il lock-in richiede il 95% dei blocchi in un periodo da 2016 blocchi, l'attivazione arriva un periodo dopo. I wallet restano compatibili, quindi potrebbero dover intervenire solo i miner.
Per Segwit servono due gruppi: i miner che segnalano il bit 1 nel 95% dei blocchi di un periodo di retarget e abbastanza full node con Bitcoin Core 0.13.1 o un'implementazione compatibile. La segnalazione si apre al primo retarget che cade il 15 novembre 2016 o dopo. Le istruzioni sono separate per miner, gestori di nodi, utenti di wallet e sviluppatori, compreso chi sceglie di non aggiornare.
Il codice segwit arriva in Bitcoin Core 0.13.0 ma resta inattivo su mainnet: per usarlo lì servirà una versione successiva, che dovrebbe essere la 0.13.1. Il compact block relay (BIP152) riduce i picchi di banda e i nuovi wallet usano chiavi HD BIP32, così un solo backup copre tutte le future chiavi private. Tra i download ufficiali entrano anche le build Linux ARM.
