L’implementazione di riferimento di Bitcoin. Il suo sito pubblica gli annunci delle nuove versioni, gli avvisi di sicurezza e le dichiarazioni del progetto.
Le modifiche al consenso e al peer-to-peer dietro segwit toccano 1486 righe di codice, con altre 3338 righe di test. I test sono passati dalla versione di Pieter Wuille sulla sidechain Elements nel 2015 a segnet, fino alla normale testnet di Bitcoin nel maggio 2016. Firme Schnorr e MAST figurano tra gli aggiornamenti futuri che segwit renderebbe più semplici.
I miner hanno tempo fino al blocco 419328 per agire: il soft fork CSV è andato in lock-in al blocco 417312 dopo che 1946 blocchi su 2016 (96,53%) hanno segnalato per BIP68, BIP112 e BIP113. Tutti i nodi di mining e di backup devono girare con Bitcoin Core o Knots 0.12.1, e chi ha la versione del blocco scritta nel codice deve togliere il bit 0.
Con BIP9 i miner possono segnalare la disponibilità per un massimo di 29 soft fork simultanei tramite i bit dell'header del blocco. Una proposta va in lock-in quando la segnala il 95% dei blocchi di una finestra da 2016 e si attiva un retarget dopo, oppure decade alla scadenza. A differenza di IsSuperMajority, non rende orfano un blocco che non segnala ma rispetta le nuove regole.
I peer che usano il compact block relay (BIP152) si scambiano uno sketch di ogni nuovo blocco, circa 9KB per un blocco medio da 1MB, più l'overhead per le transazioni che mancano al ricevente. Negli esperimenti reali ad alta banda con al massimo 6 transazioni precaricate, ben oltre il 90% dei blocchi si è propagato senza richieste successive.
Con Bitcoin Core 0.12.1 la segnalazione del soft fork CSV parte alla mezzanotte del 1° maggio 2016, ed è il primo deployment tramite i version bits di BIP9. Comprende BIP68, BIP112 e BIP113; OP_CHECKSEQUENCEVERIFY permette di congelare le monete per un certo tempo dopo la conferma, funzione da cui dipenderà Lightning Network. Il sistema di alert p2p è ora spento di default.
Marco Falke è il nuovo maintainer Testing & QA di Bitcoin Core, ha annunciato Wladimir van der Laan. Si occuperà di fare il merge delle pull request del framework di test, passo naturale dopo un anno dedicato a unit test, copertura e revisione del lavoro altrui.
Problemi di sicurezza e nuove versioni hanno ora una lista di annunci dedicata di Bitcoin Core, a iscrizione volontaria e di soli annunci. Gli utenti chiedevano un modo per ricevere soltanto le comunicazioni critiche, e il progetto prevede volumi molto bassi.
Una soluzione di Sudoku 16x16 è stata venduta per 0,10 BTC nel primo Zero-Knowledge Contingent Payment riuscito su Bitcoin, mostrato dal vivo a Financial Cryptography 2016 alle Barbados. Il venditore era Sean Bowe del team Zcash, che ha curato quasi tutta la parte tecnica. Con questo protocollo i dati passano di mano solo se il pagamento avviene, senza terzi a fare da arbitri.
OpenSSL esce dalla verifica delle firme in Bitcoin Core 0.12.0: al suo posto libsecp256k1, che riduce a meno della metà i tempi di reindicizzazione e validazione dei nuovi blocchi. Le mempool ricevono un tetto predefinito di 300 MB, chiudendo una via con cui gli attaccanti potevano mandare in crash i nodi con poca RAM. Altre novità: Replace-by-Fee opt-in (BIP 125) e -maxuploadtarget per limitare il traffico in upload.
Bitcoin Core precisa che il sito che ospitò per primo il paper di Bitcoin non ha legami con il progetto, che ha un proprio sito ufficiale. Lo sviluppo passa da IRC, GitHub e dalla mailing list bitcoin-dev. Il progetto declina ogni responsabilità per altri forum e chiede alla comunità di non fare brigading né lanciare attacchi denial of service.
Fine della malleabilità da parte di terzi per le transazioni con input tutti segwit, perché le firme passano in un witness che non entra più nel txid. Ne beneficiano sia chi sviluppa wallet sia Lightning Network. Anche l'hashing delle firme diventa lineare, con ogni byte sottoposto a hash al massimo due volte; con il vecchio schema, un singolo blocco ha richiesto 25 secondi di validazione.
Gli sviluppatori possono ora provare Segregated Witness su una rete dedicata compilando il branch segwit e aggiungendo -segnet a bitcoind e bitcoin-cli. Ledger, Trezor, Electrum e Bitgo hanno annunciato il supporto a segwit, mentre mSIGNA e Green Address offrono anteprime.
Un video mostra l'attività dei commit del 2015 nel repository di Bitcoin Core, un anno con 2 versioni principali, 5 release di manutenzione e due soft fork attivati: BIP66 e BIP65, quest'ultimo con CHECKLOCKTIMEVERIFY. Revisori, tester e traduttori non compaiono nei dati dei commit, fa notare il progetto.
Le regole di consenso non spetta al team di Bitcoin Core deciderle, dicono i suoi contributori: decidono gli utenti scegliendo quale software usare, ed è per questo che il programma non ha l'aggiornamento automatico. La preferenza va ai soft fork, con gli hard fork riservati a rari casi di accordo quasi unanime, e per scalare a livelli altissimi la strada indicata sono i layer aggiuntivi sopra il protocollo.
Con il nuovo limite di costo di segwit i blocchi possono arrivare a poco meno di 4 MB, ma i calcoli di Anthony Towns stimano intorno a 1,6 MB un blocco di transazioni P2PKH a firma singola e a 2,0 MB uno di multisig 2-di-2. Il calendario provvisorio delle FAQ prevede segwit nella 0.13.1 a ottobre 2016, con weak block, IBLT o Lightning a seguire nel 2017.
Firmando la roadmap sulla capacità, 57 persone tra cui Pieter Wuille, Gregory Maxwell e Wladimir J. van der Laan la definiscono il miglior modo di proseguire il loro lavoro sulla scalabilità in Bitcoin Core. La lista resta aperta ad altre firme.
La roadmap di Gregory Maxwell, inviata alla mailing list bitcoin-dev alla chiusura di Scaling Bitcoin Hong Kong, poggia su libsecp256k1, sui versionbits BIP9 e sulla Segregated Witness di Pieter Wuille. Maxwell riferisce che ConnectTip gira 7 volte più veloce nella 0.12 e descrive segwit come un soft fork che porta le firme fuori dall'attuale limite di dimensione del blocco, pari nel caso peggiore a un aumento di 4MB.
Contributori tecnici, tra cui Wladimir J. van der Laan e Pieter Wuille, hanno firmato una lettera che invita la comunità a non giudicare in anticipo le proposte di scaling. Indicano invece il processo di consenso e due workshop aperti Scaling Bitcoin: Montreal il 12 e 13 settembre e Hong Kong il 6 e 7 dicembre.