Além da queda já tornada pública, a CVE-2018-17144 permitia a um minerador inflar a oferta de bitcoin nas versões 0.15.X a 0.16.2, gastando uma saída duas vezes na mesma transação. Os desenvolvedores seguraram essa parte para dar tempo de os sistemas migrarem para a 0.16.3 ou a 0.17.0rc4. Acredita-se que mais da metade do hashrate já esteja corrigida, não se conhecem tentativas de exploração, e a orientação aos usuários afetados é atualizar.
Com a CVE-2018-17144, o Bitcoin Core de 0.14.0 a 0.16.2 cai diante de um bloco com uma transação que gasta o mesmo input duas vezes, e a recomendação é atualizar de imediato para a 0.16.3. Só um minerador disposto a abrir mão de pelo menos 12,5 BTC em receita permitida conseguiria produzir um bloco assim.
O RPC verifytxoutproof do Bitcoin Core 0.16.2 deixa de ser vulnerável a um ataque caro a provas SPV divulgado no início de junho, embora clientes SPV de verdade continuem expostos. Outra correção faz o abandontransaction descartar todos os descendentes de uma transação, em vez de parar nos filhos.
O OP_CODESEPARATOR em scripts de assinatura legados deixa de ser retransmitido pelo Bitcoin Core 0.16.1, mudança de política que facilita futuras correções para blocos lentos de validar. Os mineradores perdem a opção -blockmaxsize em favor de -blockmaxweight e ganham a correção de um bug que podia custar receita ao produzirem dois blocos em sequência rápida.
O segwit vira padrão da carteira no Bitcoin Core 0.16.0: endereços novos são p2sh-segwit, salvo indicação em contrário via -addresstype, e endereços nativos bc1 do BIP173 podem ser gerados e receber pagamentos. Carteiras novas são só HD, e versões anteriores as rejeitam, enquanto a tela de envio da interface gráfica agora liga o RBF do BIP125 por padrão.
Como precaução contra futuras bifurcações da rede, o Bitcoin Core 0.15.1 desconecta pares que oferecem uma cadeia abaixo do minimum-chain-work durante a sincronização inicial, além de pares de saída que servem cabeçalhos sabidamente inválidos. Uma ponta parada há 30 minutos agora aciona uma conexão de saída extra. Os mineradores perdem o uso direto do blockmaxsize, descontinuado, que só implica um limite de peso.
Uma queda na inicialização da interface gráfica motivou o Bitcoin Core 0.15.0.1: alguns clientes que atualizaram para a 0.15.0 quebravam por causa de uma configuração de taxa personalizada que a interface não oferece mais. Um patch mínimo, o #11332, trata o valor inválido.
As estimativas de taxa do Bitcoin Core 0.15.0 alcançam 1.008 blocos à frente, contra 25 antes, e quem usa a interface gráfica pode aumentar a taxa de uma transação não confirmada via Replace-By-Fee. Um banco de dados chainstate por saída acelera o download inicial de blocos em 30-40%. A conversão é automática na primeira inicialização e leva de 5 a 30 minutos, aproximadamente.
Os colaboradores regulares do Bitcoin Core não têm ligação com o btc1, a implementação do Segwit2x, e o projeto rejeita as alegações de que se trata de uma atualização necessária, chamando-o de ruptura contenciosa com as regras da rede. O segwit, soft fork previsto para os próximos dias, não tem relação com esse hard fork e não exige nada da maioria dos usuários. O Segwit2x também não prevê proteção forte contra replay, alerta o comunicado.
Quem ativou o UPnP deve instalar sem demora o Bitcoin Core 0.14.2: um erro de sinal de inteiro no miniupnpc incluído, a CVE-2017-8798, permite que atacantes na rede local causem negação de serviço ou possivelmente outros danos. O UPnP continua desligado por padrão, então nós que nunca o ativaram não são afetados.
Mineradores sem segwit podem continuar usando getblocktemplate depois da ativação, porque o Bitcoin Core 0.14.1 tira as transações segwit do modelo. O padrão de -dbcache passa a 450 MiB, e o limite agora se mantém nos picos de flush. Argumentos renomeados em createrawtransaction e disconnectnode quebram quem usa argumentos nomeados da 0.14.0.
A carteira de um nó novo poderia enviar e receber antes do fim da sincronização no modo híbrido SPV de blocos completos previsto no roteiro do Bitcoin Core, que busca primeiro os blocos a partir da chave mais antiga da carteira enquanto a validação completa continua em segundo plano. Os vazamentos de privacidade dos filtros Bloom desaparecem ao custo de mais banda, e os pagamentos devem esperar 6 ou mais confirmações.
Trocar o ECDSA por assinaturas Schnorr reduziria um multisig 50-de-50 ao tamanho de um gasto de chave única e esconderia sua política de quem observa. O roteiro do Bitcoin Core aponta como principal obstáculo o cancelamento, em que um signatário malicioso subtrai a chave de outro usuário. A delinearização responde a esse ataque, embora sua prova de segurança ainda esteja em revisão por pares.
Cache de assinaturas no Bitcoin-Qt 0.7.0, Ultraprune com LevelDB na 0.8.0 e sincronização headers-first no Bitcoin Core 0.10 aparecem na parte 1 de uma retrospectiva dos ganhos de velocidade do software de referência. Só a verificação paralela de scripts rendeu de 35% a 100% nos benchmarks dos desenvolvedores.
O download inicial de blocos em nós novos ficou 5,7 vezes mais rápido no Bitcoin Core 0.14.0 do que na 0.13.2, em um teste no Amazon EC2 com configurações padrão: 6 horas e 24 minutos contra 1 dia, 12 horas e 40 minutos. Blocos assumidos como válidos e a memória compartilhada entre a mempool e o cache de UTXO explicam o ganho. As carteiras também ganham aumento de taxa opcional, desligado por padrão.
Envios da carteira que batem no limite de cadeias não confirmadas não devolvem mais erro de RPC no Bitcoin Core 0.13.2. Eles reportam sucesso, e a inserção na mempool é tentada de novo na retransmissão, sem precisar reiniciar. As estimativas de taxa para um alvo de 1 bloco foram desativadas, e o tratamento de blocos compactos inválidos foi corrigido.
Encapsular o segwit em P2SH tem o maior custo em bytes: 19% a mais para P2WSH/P2SH e 11% para P2WPKH/P2SH em uma transação de 180 bytes, pelas contas do Bitcoin Core sobre o que o BIP141 traria. A validação pede cerca de cinco hashes SHA256 a mais por transação. Bugs, blocos maiores e taxas menores entram como riscos, e os autores não tomam posição sobre a ativação.
Os mineradores recebem o código para sinalizar o soft fork do segwit no Bitcoin Core 0.13.1, com a sinalização aberta a partir de 15 de novembro de 2016, no início do próximo período de ajuste. O lock-in exige 95% dos blocos em um período de 2.016 blocos, e a ativação vem um período depois. As carteiras continuam compatíveis, de modo que só os mineradores talvez precisem agir.
O segwit precisa de dois grupos a bordo: mineradores sinalizando o bit 1 em 95% dos blocos de um período de ajuste e full nodes suficientes rodando o Bitcoin Core 0.13.1 ou uma implementação compatível. A sinalização começa no primeiro ajuste que cair em 15 de novembro de 2016 ou depois. Há passos separados para mineradores, operadores de nós, usuários de carteira e desenvolvedores, incluindo quem decidir não atualizar.
O código do segwit entra no Bitcoin Core 0.13.0, mas fica inativo na mainnet; usá-lo ali vai exigir uma versão posterior, que deve ser a 0.13.1. A retransmissão de blocos compactos (BIP152) atenua os picos de banda, e as carteiras novas usam chaves HD do BIP32, de modo que um único backup cobre todas as chaves privadas futuras. Builds para Linux ARM também entram nos downloads oficiais.