Um minerador conseguiria levar um arquivo undo do Bitcoin Core além de 4 GiB, fazendo as posições de 32 bits darem a volta e corrompendo dados, e os nós desligam se vier a reorganização certa; no Windows e em sistemas de 32 bits a falha ocorre em 2 GiB, sem reorganização. A CVE-2026-117346 tem gravidade Baixa e exigiria cerca de um mês de todos os blocos da rede. As versões 32.1, 31.2, 30.4 e 29.5 resolvem em sistemas de 64 bits; nós de 32 bits e armazenamento de blocos em FAT32 continuam afetados.
O monitoramento de exceções de socket agora é igual entre poll() e select() no Bitcoin Core 29.5 (#36665), e pares com envio pausado passam a ter timeout obrigatório (#36667). Posições de flatfile migram para inteiros de 64 bits (#36669), os nós assumem v2transport para endereços vindos de seeds, e um seed de DNS sai da lista.
Ao fingir que não suporta os pings do BIP 31, um par malicioso escapava da desconexão de 20 minutos e lia devagar, inflando a fila de envio do nó em até 2 MB por hora para cada par de entrada e 5 MB para cada par de saída. A CVE-2026-117349, de gravidade Média, foi corrigida pelo #36667 no Bitcoin Core 32.1, 31.2, 30.4 e 29.5; nós em -blocksonly estavam bem menos expostos.
Em Windows, macOS e BSD, os nós podiam cair quando um par conectado enviava dados urgentes TCP, que passavam pelas leituras pausadas no backend select() e acumulavam memória sem limite (CVE-2026-117350). No Linux, o nó usa poll() e não é afetado. A falha, de gravidade Média, apareceu em uma varredura com LLM do Project Loupe e está corrigida no Bitcoin Core 32.1, 31.2, 30.4 e 29.5.
O Bitcoin Core 30.4 deixa de tratar os bits 5 a 28 do BIP 9 como sinal de soft fork, em linha com o BIP 323, e blocos que os ativam não disparam mais avisos de implantação desconhecida (#34779). Na rede, pares com envio pausado agora têm um timeout obrigatório (#36667), e as posições de flatfile passam a usar inteiros de 64 bits (#36669).
A transmissão privada ganha um teto no Bitcoin Core 31.2: a fila de transações que ainda não voltaram da rede para em 10.000 entradas e, cheia, recusa novos envios, cabendo a quem chama limpá-la com abortprivatebroadcast (#35406). Os bits de versão 5 a 28 deixam de contar como sinal de soft fork, conforme o BIP 323.
A transmissão privada do Bitcoin Core 32.1 não corre mais o risco de expor o IP do remetente, vazamento possível quando uma conexão v2 falhava e a nova tentativa em v1 saía direto, sem passar pelo Tor. O padrão de -maxconnections sobe de 125 para 200, e a retransmissão de saída de transações passa a ser limitada por um backlog global, não mais por par.
O excesso de leitura e escrita em disco durante a operação normal vem de um bug corrigido no Bitcoin Core 29.4: o banco de dados chainstate vivia reescrevendo grandes partes de si mesmo. A solução desativa a seek compaction do LevelDB e compacta o chainstate regularmente (#35465).
Acaba o vaivém de disco do chainstate no Bitcoin Core 30.3, que também conserta uma queda do feebumper quando a taxa combinada de aumento não está disponível (#34870) e um bug de seleção de moedas que calculava um valor como booleano (#34888). Em PSBT, as chaves públicas MuSig2 agora são validadas na desserialização de pubnonce e de assinatura parcial (#34219).
Fechado no Bitcoin Core 31.1 um vazamento de IP no -privatebroadcast: algumas conexões saíam pela clearnet em vez da rede de privacidade ativada. A atualização também acaba com as reescritas do chainstate por trás da atividade excessiva de disco e rejeita lista vazia de chaves públicas na agregação de chaves MuSig2 (#35316).
Uma falha no handshake v2 pode expor o IP do remetente no Bitcoin Core 31.0: com -privatebroadcast ativo, a nova tentativa em v1 ignora o proxy Tor e conecta direto ao par. O gatilho provável é um par malicioso encerrando o handshake de propósito. Até a chegada da 31.1, dá para desligar o recurso, definir -v2transport=0 ou mandar o tráfego de saída IPv4/IPv6 pelo Tor.
Versões do Bitcoin Core posteriores à 0.14.0 e anteriores à 29.0 podiam ler memória já liberada ao validar um bloco inválido forjado, o que derrubava o nó. A CVE-2024-52911 tem gravidade Alta, embora o atacante precise gastar prova de trabalho válida na ponta da cadeia, e a execução remota de código é considerada improvável. Cory Fields relatou o problema; a 29.0 traz a correção.
O cluster mempool substitui o desenho antigo no Bitcoin Core 31.0: os limites de ancestrais e descendentes dão lugar a clusters de até 64 transações e 101 kB, e o CPFP carveout sai de cena. O -dbcache padrão sobe para 1024 MiB em máquinas com pelo menos 4096 MiB de RAM, e a nova opção -privatebroadcast envia as transmissões de sendrawtransaction apenas por Tor ou I2P.
Duas falhas ligadas a carteiras sem nome têm conserto no Bitcoin Core 28.4: a migração de carteiras legadas (#34156) e o createfromdump, cujo caminho de erro apagava o diretório de carteiras (#34215). Um seed de DNS também sai do chainparams (#33723).
O Bitcoin Core 29.3 para de punir pares que enviam transações inválidas pelo consenso (#33050). A validação ganha um cache de midstate de sighash por input para scripts legados, P2SH e segwit v0 (#32473) e detecta witness stripping sem rodar de novo as verificações de Script (#33105), enquanto o addPackageTxs do minerador se livra de um estouro de inteiro sem sinal (#33475).
Com o Bitcoin Core 30.2, some a falha de migração em carteiras legadas sem nome (#34156), e o createfromdump não apaga mais o diretório de carteiras quando falha em uma delas (#34215). Apertar Ctrl-C também deixa de travar durante chamadas de espera IPC (#33511).
Em condições raras, uma migração malsucedida de wallet.dat no Bitcoin Core 30.0 ou 30.1 pode apagar todos os arquivos do diretório de carteiras, colocando fundos em risco. Os desenvolvedores retiraram esses binários e pedem que ninguém migre pela interface gráfica ou por RPC até a 30.2. O bug exige um wallet.dat padrão, sem nome, que não consiga migrar ou carregar; os demais usuários não são afetados.
Carteiras no Bitcoin Core 30.1 deixam de considerar moedas TRUC não confirmadas que têm ancestrais (#33528). Em IPC, as opções não exigem mais o argumento -m (#33229), o registro de mensagens pesa menos (#33517) e chamadas waitNext em andamento podem ser canceladas (#33676).
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.
