Ao assinar, o Bitcoin Core 26.2 não presume mais que um TapMiniscript seja “sane” (#29853); o getnetworkhashps lança erro com parâmetros inválidos (#28554), e o setmocktime ganha um máximo obrigatório (#29869). Os builds também funcionam com miniupnpc 2.2.8.
Antes do Bitcoin Core 0.10.1, as mensagens recebidas podiam chegar a 32 MiB, então um atacante podia forçar a alocação dessa RAM por conexão e talvez derrubar o nó. O usuário Evil-Knievel, do Bitcointalk, relatou o problema; o #5843 reduziu o limite para 2 MiB, depois elevado a 4 MB por causa do Segwit. Uma divulgação anunciada para 2015 foi adiada, e os detalhes só vieram à tona em 2024.
O IPv6 barateou o inchaço da lista de banimentos do Bitcoin Core, que não tinha limite, e cada mensagem GETADDR obrigava a varrer essa lista para cada endereço devolvido, até 2500 deles. De gravidade Alta, a queda por memória e o dreno de CPU foram resolvidos pelo #19219, lançado na 0.20.1 e na 0.21.0.
Dois bugs no tratamento da mensagem version, um estouro de inteiro com sinal e um erro de lógica em abs64, permitiam a um atacante distorcer o horário ajustado da vítima até que ela rejeitasse novos blocos por datados longe demais no futuro. O atacante precisava estar entre os primeiros 200 pares a se conectar. De gravidade Média, a falha foi corrigida no Bitcoin Core 0.21.0.
Abrir um link de pagamento BIP72 malicioso podia derrubar o Bitcoin-Qt: o parâmetro r podia apontar para um arquivo enorme, e o programa tentava alocar memória para ele enquanto o download rodava em silêncio em segundo plano. O bug, de gravidade Média, sumiu quando o #17165 removeu o suporte ao BIP70, mudança que chegou na 0.20.0.
Transações órfãs forjadas, inválidas mas caras de validar, podiam paralisar um nó por horas, porque cada transação recém-aceita disparava uma busca quadrática no cache de órfãs. O #15644, de Pieter Wuille, interrompe esse trabalho para atender novas mensagens assim que surge uma correspondência. A correção do problema, de gravidade Alta, chegou aos usuários no Bitcoin Core 0.18.0.
Uma mensagem GETDATA malformada podia deixar a thread net_processing girando a 100% de CPU nas versões do Bitcoin Core anteriores à 0.20.0, com mais 1,5 MB de memória por par atacante. Os demais pares continuavam sendo atendidos, daí a classificação Baixa. John Newbery encontrou o bug e o corrigiu no #18808.
Cabeçalhos construídos diretamente sobre o bloco gênese, com dificuldade de apenas 1, escapavam da lógica de checkpoints do Bitcoin Core da 0.12.0 até a 0.15.0, o que permitia a um spammer inflar o mapBlockIndex sem limite e possivelmente derrubar o nó por falta de memória. Cory Fields relatou o bug de gravidade Média em 2017, e o #11028 o resolveu.
Uma só INV recheada com 50.000 itens de bloco podia fazer um nó enfileirar 50.000 respostas getheaders de cerca de 1 kB cada, e um par que se recusasse a lê-las mantinha cheio esse buffer de envio de 50 MB. O #18962, de John Newbery, apresentado como economia de banda, passou a enviar um GETHEADERS por INV e chegou na 0.20.0.
Ao segurar as respostas GETDATA e depois disparar anúncios falsos para tirar uma transação do mapa g_already_asked_for, de 50.000 entradas, o atacante podia reanunciá-la sem parar e impedir que a vítima a pedisse a qualquer outro par. John Newbery divulgou o bug, de gravidade Média; o #19988, de Pieter Wuille, o corrigiu no Bitcoin Core 0.21.0.
Um segundo estouro de buffer no miniupnpc, descoberto por Wladimir J. Van Der Laan, vazava dados e podia ser encadeado com a CVE-2015-6031 para execução remota de código, o que ele demonstrou contra o miniupnpc 1.6-precise do Ubuntu. O exploit não podia ser portado diretamente para o Bitcoin Core, e a versão 0.12 trouxe a correção em fevereiro de 2016.
Correções de bugs dominam o Bitcoin Core 27.1: o aumento de taxa da interface gráfica para transações não assinadas volta a funcionar, o campo de IP do proxy não aceita mais porta, e GetAddedNodeInfo() agora detecta pares CJDNS adicionados via addnode (#30085). O tratamento de TapMiniscript na assinatura também muda (#29853).
O transporte v2 do BIP324 passa a vir ligado por padrão no Bitcoin Core 27.0, e o novo algoritmo CoinGrinder busca o conjunto de inputs mais leve com taxas a partir de 30 sat/vB. O tempo ajustado pela rede sai do código de consenso em favor do horário do sistema, o que torna relógios precisos mais importantes para os operadores. O libbitcoinconsensus é descontinuado, com remoção prevista para a v28.
O Bitcoin Core 25.2 para de processar blocos mutados (#29412). A atualização também corrige um segfault em getrawtransaction (#29003), um use-after-free em WalletBatch::EraseRecords (#29176) e uma queda da interface gráfica ao selecionar “Mask values”.
Sessões I2P no Bitcoin Core 26.1 usam criptografia ECIES-X25519 e ElGamal (#29200), e o nó agora registra o progresso ao carregar a mempool. Entre as correções estão a recusa em processar blocos mutados (#29412) e uma carteira que pula a seleção de moedas BnB quando o SFFO está ativo (#28994).
Experimental e desligado por padrão, o transporte v2 do BIP324 estreia no Bitcoin Core 26.0 e é ativado com -v2transport. O novo RPC loadtxoutset carrega snapshots assumeutxo, entregando um nó utilizável em minutos enquanto o chainstate original termina de validar em segundo plano, e o submitpackage envia transações brutas à mempool como pacote.
Estimativas de taxa defasadas não são mais servidas pelo Bitcoin Core 24.2 (#27622), e o tratamento de endereços bech32 inválidos no RPC foi corrigido (#27727). A maior parte do restante mexe no sistema de build e na CI, incluindo um conserto para o build do pacote Qt no macOS com o linker do Xcode 15 (#28543).
Os downloads paralelos de blocos compactos chegam ao Bitcoin Core 25.1 (#27626). Outras correções tratam de uma queda do REST em /deploymentinfo (#27853), do desligamento do servidor após a desconexão de um cliente remoto (#28551) e da migração de carteiras, que agora recusa scripts inválidos (#28125).
Reescaneamentos de carteiras descriptor ficam mais rápidos no Bitcoin Core 25.0 quando há filtros de blocos compactos BIP158 disponíveis via -blockfilterindex=1, e o novo RPC scanblocks faz buscas nesses filtros. A política de retransmissão agora aceita transações a partir de 65 bytes não witness. Sob -blocksonly, a memória máxima da mempool cai de 300 MB para 5 MB.
Três mudanças de P2P sustentam o Bitcoin Core 23.2: fim da corrupção do peers.dat (#26909), nada de limpar antes da hora o estado de download de outros pares (#27608) e filas inv-to-send mais rápidas (#27610). O resto é trabalho de build e CI, como compilar o bdb com clang-16 em aarch64.