Transações não padrão forjadas podiam ocupar um nó do Bitcoin Core por alguns segundos cada uma sem que o remetente fosse desconectado, o que abria caminho para atrasar a propagação de blocos. A CVE-2025-46598, de gravidade Baixa, foi relatada por Antoine Poinsot e mitigada na v30.0 com a redução do tempo de validação no pior caso.
Blocos acima de 1 GB podiam estourar uma verificação de tamanho em nós do Bitcoin Core de 32 bits e derrubá-los na gravação em disco, mas só como bloco compacto e só contra uma vítima com -maxmempool acima de 3 GB e 1 GB de transações lá dentro. Pieter Wuille encontrou a CVE-2025-46597, de gravidade Baixa; limitar o -maxmempool em sistemas de 32 bits resolveu o problema na 29.1 e na 30.0.
Caem as taxas mínimas padrão no Bitcoin Core 28.3: -blockmintxfee para 1 satoshi por kvB, -minrelaytxfee e -incrementalrelayfee para 100 satoshis por kvB. As taxas da carteira não mudam, e transações mais baratas podem não se propagar a menos que os novos padrões se espalhem pela rede. As permissões de whitelist também deixam de valer para conexões de entrada via onion (#33395).
O FillBlock recebe duas correções de P2P no Bitcoin Core 29.2: uma verificação de mutação de witness (#32646) e outra de cabeçalho vazio antes da chamada (#33296). As checagens TRUC deixam de ser aplicadas em reorganizações (#33504), e getblock e getblockheader não retornam mais o target da ponta (#33446).
Os limites de OP_RETURN praticamente desaparecem no Bitcoin Core 30.0: o -datacarriersize passa a 100.000 por padrão e uma transação pode levar várias saídas de dados, embora -datacarriersize=83 restaure o teto antigo. As taxas de retransmissão padrão caem para 0,1 satoshi por vB, as operações de assinatura legadas ficam limitadas a 2500 por transação padrão, e um novo comando bitcoin engloba os executáveis existentes.
No Bitcoin Core 29.1, o log incondicional em disco fica limitado a 1 MiB por hora para cada ponto do código (#32604), e transações padrão podem ter no máximo 2500 operações de assinatura legadas potencialmente executadas. As taxas de retransmissão padrão caem para 100 satoshis por kvB, enquanto builds de 32 bits limitam -maxmempool a 500 MB e -dbcache a 1 GiB.
Pouco mais da metade das mudanças do Bitcoin Core 28.2 é trabalho de build. O Guix agora notariza o pacote do app para macOS e assina todos os binários de macOS e Windows (#31407), e o depends recebe correções de compilação para libevent no NetBSD (#31500) e freetype com cmake (#32693).
Trinta e um colaboradores do Bitcoin Core assinaram uma carta defendendo que o software de nó não deve se recusar a retransmitir transações com demanda econômica sustentada que chegam de forma confiável aos blocos, já que usuários e mineradores conseguem contornar esses filtros. Eles frisam que isso não endossa o uso não financeiro de dados e que só os usuários escolhem qual software e quais políticas rodar.
Anos de spam ininterrupto de addr podiam estourar o identificador de 32 bits do gerenciador de endereços do Bitcoin Core e derrubar o nó; era o que restava de um ataque já atenuado pelo limite de frequência na v22.0. A versão 29.0 adota um identificador de 64 bits e fecha a CVE-2024-52919, de gravidade Baixa. Eugene Siegel encontrou o problema; Martin Zumsande fez a mudança.
Acabou o suporte a UPnP no Bitcoin Core 29.0; o -natpmp agora roda sobre uma implementação própria de PCP e NAT-PMP, sem o libnatpmp. O dust efêmero chega como nova política, uma correção para o peso de bloco reservado em dobro acrescenta o -blockreservedweight, e os nós pedem os pais que faltam a todos os pares que anunciaram um órfão. As versões 26.x e anteriores chegam ao fim da manutenção.
Com -port definido, o Bitcoin Core 28.1 calcula a porta onion padrão como essa porta mais um, em vez de fixá-la em 8334 na mainnet, o que volta a permitir vários nós locais lado a lado sem colisão na inicialização. Linhas HiddenServicePort manuais no torrc podem precisar de ajuste. Dados secretos também passam a ser limpos em DecodeExtKey (#31166).
Um par que anuncia um bloco e depois empaca podia deixar um nó do Bitcoin Core esperando até 10 minutos antes de tentar em outro lugar, e atacantes podiam repetir o truque. A CVE-2024-52922, de gravidade Média, relatada e corrigida por Greg Sanders, é mitigada na v25.1 e na v26.0, que podem pedir um bloco de imediato a até 3 pares de bloco compacto de alta largura de banda.
A versão 27.2 do Bitcoin Core fecha uma condição de corrida na detecção de autoconexão (#30394) e corrige chamadas a FillPSBT que retornavam complete=true indevidamente (#30357). A thread de carregamento de blocos e o scheduler agora encerram em outra ordem (#30435), e o código compila com miniupnpc 2.2.8 e GCC 15.
Blocos mutados de um único par podiam apagar o estado de download de outros pares que anunciavam o mesmo bloco no Bitcoin Core anterior à v25.0, fazendo o nó esquecer um bloco compacto que ainda estava reconstruindo. Suhas Daftuar percebeu o problema, e o #27608 restringe cada par ao próprio estado. A CVE-2024-52921 tem gravidade Média.
Antes da v25.0, nós do Bitcoin Core podiam ser derrubados remotamente com uma mensagem blocktxn repetida para um mesmo bloco, que disparava uma asserção segundo a qual o FillBlock só roda uma vez. Não era preciso colisão de short-id: incluir transações ausentes da raiz de Merkle do bloco levava ao mesmo caminho. Niklas Gögge encontrou e corrigiu o bug de gravidade Alta, CVE-2024-35202.
Um pico de atividade na rede no início de maio de 2023, agravado por nós espiões, atrasou a propagação de blocos e transações porque ordenar conjuntos inv-to-send gigantes consumia quase todo o tempo da thread P2P. De gravidade Média, o problema foi corrigido no Bitcoin Core v25.0 pelo #27610, que descarta antes as transações que já saíram da mempool e esvazia os conjuntos mais depressa à medida que crescem.
A testnet4 (BIP94) estreia no Bitcoin Core 28.0, junto com retransmissão limitada de pacotes para duplas de 1 pai e 1 filho, transações TRUC padrão sob o BIP 431 e um novo tipo de saída Pay To Anchor. O -mempoolfullrbf agora é 1 por padrão, e o libbitcoinconsensus some depois de ter sido descontinuado na 27.0.
Cadeias de cabeçalhos de baixa dificuldade podiam derrubar remotamente nós do Bitcoin Core anteriores à v24.0.1, e uma única cadeia forjada servia contra qualquer nó da rede. A correção no #25717 faz o nó verificar se a cadeia tem trabalho suficiente antes de armazená-la, o que também encerrou a dependência de checkpoints contra ataques conhecidos. Gravidade: Alta.
O spam de mensagens addr podia derrubar um nó do Bitcoin Core: 2^32 inserções no addrman estouravam um contador de ID de 32 bits e disparavam uma asserção. Eugene Siegel relatou o bug de gravidade Alta em 2021, e a v22.0 traz a correção de Pieter Wuille.
Fazendo-se passar por um dispositivo UPnP na rede local, um atacante podia alimentar um nó do Bitcoin Core com respostas M-SEARCH inchadas até esgotar a memória. Só ficavam expostos os nós iniciados com -miniupnp, já que a biblioteca vem desligada por padrão nos demais casos. O bug, de gravidade Baixa, foi corrigido na v22.0.