Bukod sa crash na alam na ng publiko, pinahintulutan ng CVE-2018-17144 ang isang miner na palobohin ang supply ng Bitcoin sa mga bersyong 0.15.X hanggang 0.16.2, sa paggastos ng isang output nang dalawang beses sa iisang transaksyon. Itinago muna ng developers ang bahaging iyon para magkaroon ng panahon ang mga system na lumipat sa 0.16.3 o 0.17.0rc4. Pinaniniwalaang patched na ang mahigit kalahati ng hashrate, walang kilalang pagtatangkang i-exploit ito, at hinihimok na mag-upgrade ang mga apektado.
Dahil sa CVE-2018-17144, nagka-crash ang Bitcoin Core 0.14.0 hanggang 0.16.2 sa block na may transaksyong dalawang beses gumagastos ng iisang input, at sinabihan ang users na mag-upgrade agad sa 0.16.3. Miner lang na handang isuko ang hindi bababa sa 12.5 BTC na pinapayagang kita ang makakagawa ng ganoong block.
Hindi na tinatablan ang verifytxoutproof RPC sa Bitcoin Core 0.16.2 ng magastos na atake sa SPV proofs na isiniwalat noong unang bahagi ng Hunyo, bagaman nananatiling lantad ang mga totoong SPV client. Sa hiwalay na ayos, binubura na ng abandontransaction ang lahat ng descendant ng isang transaksyon sa halip na huminto sa mga child nito.
Hindi na nire-relay ng Bitcoin Core 0.16.1 ang OP_CODESEPARATOR sa legacy signature scripts, pagbabago sa policy na magpapadali sa pag-deploy ng mga ayos sa hinaharap para sa mga block na mabagal i-validate. Nawala sa miners ang -blockmaxsize option kapalit ng -blockmaxweight, at naayos ang bug na maaaring nagpabawas sa kita nila kapag nakagawa ng dalawang block nang mabilis na magkasunod.
Segwit na ang default ng wallet sa Bitcoin Core 0.16.0: p2sh-segwit ang mga bagong address maliban kung iba ang sinabi ng -addresstype, at puwede nang gumawa at magbayad sa native na bc1 addresses ayon sa BIP173. HD lang ang mga bagong wallet at tinatanggihan ito ng mas lumang bersyon, habang naka-on na bilang default ang BIP125 RBF sa send screen ng GUI.
Bilang pag-iingat sa mga fork ng network sa hinaharap, dinidiskonekta ng Bitcoin Core 0.15.1 ang mga peer na may chain na mas mababa sa minimum-chain-work habang nasa initial sync, pati ang outbound peers na naghahain ng headers na alam nang invalid. Kapag 30 minutong natigil ang tip, nagdadagdag ito ng outbound connection. Hindi na direktang magagamit ng miners ang blockmaxsize, na deprecated na at nagpapahiwatig na lang ng weight limit.
Isang startup crash sa GUI ang dahilan ng Bitcoin Core 0.15.0.1: bumagsak ang ilang client na nag-upgrade sa 0.15.0 dahil sa custom fee setting na wala na sa interface. Isang minimal na patch, ang #11332, ang humahawak sa invalid na value.
Umaabot na sa 1,008 block ang fee estimates sa Bitcoin Core 0.15.0, mula 25, at puwede nang taasan ng GUI users ang fee ng unconfirmed na transaksyon sa pamamagitan ng Replace-By-Fee. Pinapabilis nang 30-40% ng per-output chainstate database ang initial block download. Awtomatiko ang conversion sa unang pagbukas at inaabot ng mga 5 hanggang 30 minuto.
Walang kaugnayan ang mga regular na contributor ng Bitcoin Core sa btc1, ang implementasyon ng Segwit2x, at itinatanggi ng proyekto na kailangang update ito; kontrobersyal na paglihis daw ito sa mga patakaran ng network. Walang kinalaman sa hard fork na iyon ang Segwit, ang soft fork na inaasahan sa loob ng ilang araw, at wala itong hinihingi sa karamihan ng users. Babala rin ng pahayag, walang planong malakas na replay protection ang Segwit2x.
Pinapayuhan ang sinumang nag-enable ng UPnP na i-install agad ang Bitcoin Core 0.14.2: dahil sa integer signedness error sa kasamang miniupnpc, ang CVE-2017-8798, makakapagdulot ang mga umaatake sa local network ng denial of service o posibleng iba pang pinsala. Naka-off pa rin bilang default ang UPnP, kaya ligtas ang mga node na hindi kailanman bumuhay nito.
Magagamit pa rin ng non-segwit miners ang getblocktemplate pagkatapos ng activation, dahil inaalis ng Bitcoin Core 0.14.1 ang segwit transactions sa template. Naging 450MiB ang default na -dbcache at nasusunod na ang limitasyon kahit sa flush peaks. Masisira ang mga tawag na gumagamit ng named arguments mula 0.14.0 dahil pinalitan ang pangalan ng arguments sa createrawtransaction at disconnectnode.
Makakapagpadala at makakatanggap na ang wallet ng bagong node bago matapos ang sync sa hybrid na full block SPV mode sa roadmap ng Bitcoin Core, na kumukuha muna ng blocks simula sa pinakalumang key ng wallet habang tumatakbo sa background ang buong validation. Mawawala ang privacy leaks ng Bloom filter kapalit ng mas malaking bandwidth, at dapat maghintay ng 6 o higit pang confirmation ang mga bayad.
Kapag pinalitan ng Schnorr signatures ang ECDSA, liliit ang 50-of-50 multisig sa laki ng single-key spend at maitatago ang policy nito sa mga nagmamasid. Cancellation ang pangunahing hadlang ayon sa roadmap ng Bitcoin Core, kung saan ibinabawas ng malisyosong pumipirma ang key ng ibang user. Delinearization ang sagot sa atakeng iyon, bagaman nasa peer review pa ang security proof nito.
Signature caching sa Bitcoin-Qt 0.7.0, Ultraprune kasama ang LevelDB sa 0.8.0 at headers-first sync sa Bitcoin Core 0.10 ang tampok sa unang bahagi ng pagbabalik-tanaw sa mga pagpapabilis ng reference software. Sa benchmarks ng developers, 35% hanggang 100% ang naidagdag ng parallel script verification nang mag-isa.
5.7 beses na mas mabilis natapos ng mga bagong node ang initial block download sa Bitcoin Core 0.14.0 kaysa sa 0.13.2 sa pagsubok sa Amazon EC2 gamit ang default settings: 6 oras at 24 minuto laban sa 1 araw, 12 oras at 40 minuto. Assumed valid blocks at memory na pinaghahatian ng mempool at UTXO cache ang nasa likod nito. Mayroon ding opsyonal na fee bumping ang mga wallet, naka-off bilang default.
Hindi na nagbabalik ng RPC error ang mga wallet send na tumatama sa limitasyon ng unconfirmed chains sa Bitcoin Core 0.13.2. Tagumpay na ang iniuulat ng mga ito, at inuulit ang pagpasok sa mempool sa rebroadcast nang hindi kailangan ng restart. Naka-disable ang fee estimates para sa 1-block target, at naayos ang paghawak sa mga invalid na compact block.
Pinakamalaki ang gastos sa bytes kapag binalot ang segwit sa P2SH: 19% na dagdag sa P2WSH/P2SH at 11% sa P2WPKH/P2SH para sa 180-byte na transaksyon, ayon sa pagtutuos ng Bitcoin Core sa dala ng BIP141. Kailangan ng validation ang mga limang dagdag na SHA256 hash bawat transaksyon. Tinitimbang bilang panganib ang mga bug, mas malalaking block at mas mababang fees, at walang posisyon ang mga may-akda sa activation.
May code na ang miners para mag-signal para sa segwit soft fork sa Bitcoin Core 0.13.1, at bukas ang signaling mula 15 Nobyembre 2016 sa simula ng susunod na retarget period. Kailangan ng 95% ng mga block sa isang period na may 2,016 block para sa lock-in, at isang period pagkatapos ay activation. Compatible pa rin ang wallets, kaya baka miners lang ang kailangang kumilos.
Dalawang grupo ang kailangan ng Segwit: miners na nagsi-signal ng bit 1 sa 95% ng mga block sa isang retarget period, at sapat na full node na may Bitcoin Core 0.13.1 o compatible na implementasyon. Magbubukas ang signaling sa unang retarget na papatak sa o pagkatapos ng 15 Nobyembre 2016. May hiwalay na hakbang para sa miners, node operators, wallet users at developers, kabilang ang mga pipiliing hindi mag-upgrade.
Nasa Bitcoin Core 0.13.0 na ang code ng Segwit pero hindi pa aktibo sa mainnet; para magamit doon, kakailanganin ang mas bagong bersyon, na inaasahang 0.13.1. Binabawasan ng compact block relay (BIP152) ang mga biglang taas ng bandwidth, at BIP32 HD keys ang gamit ng mga bagong wallet kaya sapat ang isang backup para sa lahat ng susunod na private key. Kasama na rin sa opisyal na downloads ang Linux ARM builds.
