Pe lângă crashul deja făcut public, CVE-2018-17144 îi permitea unui miner să umfle oferta de bitcoin în versiunile 0.15.X-0.16.2, cheltuind o ieșire de două ori în aceeași tranzacție. Dezvoltatorii au ținut secretă această parte ca să lase sistemelor timp să treacă la 0.16.3 sau 0.17.0rc4. Se crede că peste jumătate din hashrate e deja actualizat, nu se cunosc încercări de exploatare, iar utilizatorii afectați sunt îndemnați să facă upgrade.
Din cauza CVE-2018-17144, Bitcoin Core de la 0.14.0 la 0.16.2 se prăbușește la un bloc cu o tranzacție care cheltuie aceeași intrare de două ori, iar utilizatorilor li se cere să treacă imediat la 0.16.3. Doar un miner dispus să renunțe la cel puțin 12,5 BTC din veniturile permise ar putea produce un asemenea bloc.
RPC-ul verifytxoutproof din Bitcoin Core 0.16.2 nu mai cade pradă unui atac costisitor asupra dovezilor SPV, dezvăluit la începutul lui iunie, deși clienții SPV propriu-ziși rămân expuși. O remediere separată face ca abandontransaction să renunțe la toți descendenții unei tranzacții, nu doar la copiii ei.
Bitcoin Core 0.16.1 nu mai retransmite OP_CODESEPARATOR din scripturile de semnătură legacy, o schimbare de politică ce ușurează lansarea viitoarelor remedieri pentru blocurile lente la validare. Minerii pierd opțiunea -blockmaxsize în favoarea -blockmaxweight și primesc o reparație pentru un bug care îi putea costa venituri când produceau două blocuri în succesiune rapidă.
SegWit devine implicit în portofelul Bitcoin Core 0.16.0: adresele noi sunt p2sh-segwit, dacă -addresstype nu spune altfel, iar adresele native bc1 conform BIP173 pot fi generate și pot primi plăți. Portofelele noi sunt doar HD, iar versiunile anterioare le resping, în timp ce ecranul de trimitere din GUI pornește acum implicit BIP125 RBF.
Ca măsură de precauție împotriva unor viitoare forkuri de rețea, Bitcoin Core 0.15.1 renunță la peerii care oferă un lanț sub minimum-chain-work în timpul sincronizării inițiale, dar și la peerii de ieșire care servesc headere cunoscute ca invalide. Un vârf de lanț blocat timp de 30 de minute declanșează acum o conexiune de ieșire suplimentară. Minerii nu mai pot folosi direct blockmaxsize, opțiune depreciată care doar implică o limită de greutate.
Un crash la pornire în GUI a dus la apariția Bitcoin Core 0.15.0.1: unii clienți care treceau la 0.15.0 cădeau din cauza unei setări de comision personalizat pe care interfața nu o mai oferă. Un patch minimal, #11332, tratează valoarea invalidă.
Estimările de comision din Bitcoin Core 0.15.0 ajung la 1008 blocuri în avans, față de 25, iar utilizatorii GUI pot crește comisionul unei tranzacții neconfirmate prin Replace-By-Fee. O bază de date chainstate pe ieșiri accelerează cu 30-40% descărcarea inițială a blocurilor. Conversia se face automat la prima pornire și durează cam 5-30 de minute.
Contributorii obișnuiți ai Bitcoin Core nu au nicio legătură cu btc1, implementarea Segwit2x, iar proiectul respinge afirmațiile că ar fi o actualizare necesară și o numește o ruptură controversată de regulile rețelei. SegWit, soft forkul programat în câteva zile, nu are legătură cu acel hard fork și nu le cere nimic majorității utilizatorilor. Segwit2x nu plănuiește nicio protecție solidă împotriva atacurilor replay, avertizează comunicatul.
Cine a activat UPnP e îndemnat să instaleze fără întârziere Bitcoin Core 0.14.2: o eroare de semn la un întreg din miniupnpc-ul inclus, CVE-2017-8798, le permite atacatorilor din rețeaua locală să provoace un denial of service sau, posibil, alte daune. UPnP rămâne dezactivat implicit, așa că nodurile care nu l-au pornit niciodată nu sunt afectate.
Minerii fără SegWit pot folosi în continuare getblocktemplate după activare, pentru că Bitcoin Core 0.14.1 scoate tranzacțiile SegWit din șablon. Valoarea implicită -dbcache trece la 450 MiB, iar limita se respectă acum și la vârfurile de flush. Argumentele redenumite din createrawtransaction și disconnectnode strică apelurile care folosesc argumente numite din 0.14.0.
Portofelul unui nod nou ar putea trimite și primi înainte de finalul sincronizării, în modul hibrid SPV cu blocuri complete din foaia de parcurs Bitcoin Core, care aduce întâi blocurile de la cea mai veche cheie a portofelului, în timp ce validarea completă continuă în fundal. Scurgerile de confidențialitate ale filtrelor Bloom dispar, cu prețul unei lățimi de bandă mai mari, iar plățile ar trebui să aștepte cel puțin 6 confirmări.
Înlocuirea ECDSA cu semnături Schnorr ar micșora un multisig 50-din-50 la dimensiunea unei cheltuieli cu o singură cheie și i-ar ascunde politica față de observatori. Foaia de parcurs Bitcoin Core numește drept principal obstacol cancellation, atacul în care un semnatar rău intenționat scade cheia altui utilizator. Delinearizarea îi răspunde acestui atac, deși dovada ei de securitate e încă în peer review.
Cache-ul de semnături din Bitcoin-Qt 0.7.0, Ultraprune cu LevelDB în 0.8.0 și sincronizarea headers-first din Bitcoin Core 0.10 apar în prima parte a unei retrospective asupra accelerărilor din software-ul de referință. Doar verificarea paralelă a scripturilor a adus 35-100% în testele dezvoltatorilor.
Nodurile noi au terminat descărcarea inițială a blocurilor de 5,7 ori mai repede pe Bitcoin Core 0.14.0 decât pe 0.13.2, într-un test pe Amazon EC2 cu setări implicite: 6 ore și 24 de minute, față de 1 zi, 12 ore și 40 de minute. Câștigul vine din blocurile presupuse valide și din memoria partajată între mempool și cache-ul UTXO. Portofelele primesc și creșterea opțională a comisionului, dezactivată implicit.
Trimiterile din portofel care ating limita lanțurilor neconfirmate nu mai întorc o eroare RPC în Bitcoin Core 0.13.2. În schimb raportează succes, iar inserarea în mempool se reia la retransmitere, fără repornire. Estimările de comision pentru o țintă de 1 bloc sunt dezactivate, iar tratarea blocurilor compacte invalide e reparată.
Împachetarea SegWit în P2SH are cel mai mare cost în octeți: 19% în plus pentru P2WSH/P2SH și 11% pentru P2WPKH/P2SH la o tranzacție de 180 de octeți, potrivit calculelor Bitcoin Core despre ce ar aduce BIP141. Validarea cere cam cinci hash-uri SHA256 în plus pe tranzacție. Bugurile, blocurile mai mari și comisioanele mai mici sunt cântărite ca riscuri, iar autorii nu iau poziție privind activarea.
Minerii primesc în Bitcoin Core 0.13.1 codul de semnalizare pentru soft forkul SegWit, cu semnalizarea deschisă de la 15 noiembrie 2016, la începutul următoarei perioade de ajustare. Lock-in-ul cere 95% din blocurile unei perioade de 2016 blocuri, iar activarea vine o perioadă mai târziu. Portofelele rămân compatibile, așa că doar minerii ar putea avea ceva de făcut.
SegWit are nevoie de două grupuri: minerii care semnalizează bitul 1 în 95% din blocuri într-o perioadă de ajustare și suficiente noduri complete cu Bitcoin Core 0.13.1 sau o implementare compatibilă. Semnalizarea începe la prima ajustare care cade pe 15 noiembrie 2016 sau după această dată. Pași separați îi vizează pe mineri, operatorii de noduri, utilizatorii de portofele și dezvoltatori, inclusiv pe cei care aleg să nu facă upgrade.
Codul SegWit ajunge în Bitcoin Core 0.13.0, dar rămâne inactiv pe mainnet; folosirea lui acolo va cere o versiune ulterioară, probabil 0.13.1. Retransmiterea compact block (BIP152) reduce vârfurile de lățime de bandă, iar portofelele noi folosesc chei HD BIP32, astfel că un singur backup acoperă toate cheile private viitoare. Și compilările Linux ARM intră în descărcările oficiale.