Bitcoin Core 32.1 lançado em 27 de outubro de 2026: por que a 32.0 foi retirada, os três bugs divulgados e o novo estimador de tarifas

1. O que é o Bitcoin Core 32.1, e por que não existe uma 32.0?

O Bitcoin Core é a implementação de referência do Bitcoin, o software que valida blocos, retransmite transações e roda a carteira por trás de muitos serviços. Ele lança uma versão principal mais ou menos a cada seis meses e mantém as três mais recentes. A versão 32.1, publicada em 27 de outubro de 2026, é a primeira release pública da linha 32.x, com um novo estimador de tarifas, padrões de conexão mais altos, um índice de transações menor, PSBT versão 2 como padrão nos RPCs da carteira e um lote de correções de segurança. Ela não muda nenhuma regra de consenso: blocos e transações válidos antes continuam válidos depois.

A 32.0 existe apenas como tag. O mantenedor fanquake criou a tag em 21 de outubro e escreveu na issue do cronograma de release, em 26 de outubro, que, por problemas de última hora, a 32.0 não seria anunciada nem lançada e nenhum binário seria publicado; a 32.1 viria com o mesmo conteúdo mais correções adicionais. O pull request que finalizou a 32.1, mesclado naquela tarde, faz o backport de exatamente três mudanças de Antoine Poinsot: o monitoramento de exceções de socket alinhado entre os backends poll e select, um timeout de 20 minutos para peers cujo buffer de envio nunca esvazia e posições de 64 bits nos arquivos de blocos e de undo. São as correções das três vulnerabilidades divulgadas dois dias depois, descritas na seção 3. O projeto não disse mais sobre os motivos do que isso.

2. Quando foi lançado? Datas-chave

As datas vêm da issue do cronograma de release do Bitcoin Core, do servidor de downloads do bitcoincore.org e dos posts de divulgação. Status em 2 de novembro de 2026.

3. Quais vulnerabilidades foram corrigidas e divulgadas?

Três, todas publicadas em 28 de outubro de 2026 e todas encontradas pelo mesmo caminho: uma varredura automatizada do código por um modelo de linguagem de grande porte, conduzida como Project Loupe por Elias Rohrer, da Spiral, com Gregory Sanders validando cada achado e reportando-o à equipe de segurança do Bitcoin Core. Duas foram redescobertas de forma independente por outros pesquisadores antes de as correções saírem. A política do Bitcoin Core é divulgar os bugs que classifica como fáceis de descobrir assim que existem releases corrigidas para toda linha mantida, e é por isso que os relatórios saíram um dia depois da 32.1.

CVE-2026-117349, gravidade média: um peer que diz não suportar os pings da BIP 31 nunca é desconectado por ignorá-los, e se ele também lê mensagens muito devagar, o nó continua enfileirando anúncios de transações para ele sem limite. O post estima o crescimento em até cerca de 2 MB por hora para um peer de entrada e 5 MB por hora para um de saída; nós rodando com blocksonly estão muito menos expostos. Reportada em 15 de setembro, corrigida pelo pull request #36667, que desconecta um peer pausado que não esvaziou o buffer de envio em 20 minutos.

CVE-2026-117350, gravidade média, afeta apenas Windows, macOS e BSD: o código de sockets baseado em select verificava condições excepcionais mesmo com as leituras pausadas por backpressure, então um peer enviando dados urgentes de TCP podia forçar leituras que contornam o limite de memória por peer até o nó ficar sem memória. O Linux usa poll e não é afetado. Reportada em 23 de outubro, três dias antes de as correções serem mescladas, e corrigida pelo pull request #36665.

CVE-2026-117346, gravidade baixa: as posições nos arquivos de blocos e de undo eram de 32 bits, então, quando um arquivo de undo passava de 4 GiB, dados novos sobrescreviam dados antigos, e um reorg posterior que precisasse desses dados derrubava o nó até uma reindexação em uma versão corrigida. No Windows e em sistemas de 32 bits, as gravações falham a partir de 2 GiB. O post chama a exploração em sistemas de 64 bits de impraticável: um minerador precisaria de vários milhares de blocos com transações não padrão, cerca de um mês de blocos, posicionados com precisão, mais um reorg específico de dois blocos. Reportada pela primeira vez em 8 de julho, corrigida pelo pull request #36669, que armazena as posições como inteiros de 64 bits sem mudar o formato em disco; sistemas de 32 bits continuam afetados.

As notas de release da própria 32.1 listam outras correções que não são CVEs: uma nova tentativa de private broadcast que podia vazar o IP do remetente ao contornar o proxy do Tor, um caminho de execução de comandos por meio de nomes de carteira forjados com walletnotify em sistemas que não são Windows, e limites de 10.000 transações de private broadcast na fila e 1.000 tentativas de envio para cada uma. As notas também dizem que em duas semanas o projeto vai divulgar três vulnerabilidades de gravidade média e alta corrigidas na 30.0 (e nenhuma de gravidade baixa na 32.1), então outro post de divulgação é esperado por volta de 10 de novembro.

4. Como o novo estimador de tarifas muda as taxas que você paga?

Se você usa uma carteira ou serviço que pede a tarifa a um nó Bitcoin Core pelo estimatesmartfee, a 32.1 muda o que ele ouve. Até agora o Core só usava seu estimador de política de blocos (block policy), que olha para trás, para as tarifas das transações que foram confirmadas dentro de um número-alvo de blocos. Ele é conservador e demora a baixar: depois de um pico de congestionamento, continua propondo tarifas altas por um tempo, porque o histórico ainda diz que estão altas. A 32.1 adiciona um estimador de política de mempool (mempool policy), que olha o que está esperando agora, e o estimatesmartfee devolve o menor dos dois. O estimador da mempool só pode baixar o resultado, nunca elevá-lo, então uma carteira baseada no Core deixa de pagar a mais logo que os blocos esvaziam, e se comporta como antes quando a mempool está cheia.

A mesma ideia move as tarifas que a maioria dos explorers mostra. Em 2 de novembro de 2026 o mempool.space, que estima só a partir da mempool, coloca a meta de meia hora em 3 sat/vB, $0.33 para uma transferência típica com o BTC a US$ 77.853:

Tarifas do Bitcoin neste momento (mempool.space)

Para desenvolvedores, o RPC ganha um objeto de opções: fee_rate_estimator aceita auto (o padrão, combinado), block_policy (o comportamento antigo) ou mempool_policy, valores desconhecidos são rejeitados, verbosity 2 adiciona mempool_health_statistics, e no modo auto a resposta informa qual estimador foi usado. Os dados da política de blocos passam para fees/block_policy_estimates.dat e são migrados na primeira inicialização. A seleção de moedas da própria carteira usa a estimativa combinada. O que isso não muda: a tarifa continua sendo escolha sua, replace-by-fee e child-pays-for-parent continuam resgatando uma transação que pagou pouco demais, e os níveis de sat/vB do nosso guia de tarifas se atualizam a cada minuto a partir da mempool.

5. O que muda para operadores de nós?

Atualize, e confira em que linha você está. A 29.x chegou ao fim de vida em 27 de outubro de 2026 e a 29.5, de 28 de outubro, é sua release final, então um nó na 29.x não receberá mais correções; a 30.x segue mantida até a 33.0 sair, a 31.x até a 34.0 e a 32.x até a 35.0. Atualizar de uma versão em fim de vida direto para a 32.1 é suportado, embora a migração do diretório de dados possa levar tempo. As plataformas suportadas são kernel Linux 3.17 ou mais recente, macOS 14 ou mais recente e Windows 10 versão 1903 ou mais recente.

Dois padrões mudam o consumo do seu nó. O maxconnections padrão sobe de 125 para 200, e uma nova opção inboundrelaypercent (padrão 50) limita a fatia de slots de entrada dada a peers que retransmitem transações; para manter o comportamento antigo, rode com maxconnections=125 e inboundrelaypercent=100. A retransmissão de transações para fora agora tem limite de vazão com um backlog global (txsendrate, padrão de 14 transações por segundo, 2,5 vezes isso para peers de saída, mais um teto de banda de 12 MB por 10 minutos). Serviços ocultos do Tor criados automaticamente ganham defesas de proof-of-work quando o daemon do Tor as suporta. O servidor RPC não usa mais libevent, e uma nova opção rpcmaxconnections (padrão 16) limita os clientes HTTP simultâneos.

Duas opções economizam disco e tempo. O índice de transações guarda menos dados: um txindex reconstruído ocupa menos da metade do espaço, mas a economia só vem se você apagar indexes/txindex no diretório de dados e reiniciar, o que pode levar horas; o txospenderindex encolhe do mesmo jeito. A validação de blocos pré-carrega as saídas anteriores em paralelo com prevoutfetchthreads, padrão 8, máximo 16, 0 para desativar. As sessões legadas ElGamal do I2P serão removidas até a v34 e o suporte a CJDNS está em revisão, então operadores que dependem de um dos dois devem acompanhar as próximas notas de release.

6. O que muda para desenvolvedores e carteiras?

A mudança incompatível é a PSBT versão 2. createpsbt, walletcreatefundedpsbt, converttopsbt e psbtbumpfee agora produzem PSBTs versão 2 por padrão; um novo argumento psbt_version seleciona a versão 0 para ferramentas que ainda não conseguem interpretar a v2. Se um dispositivo de assinatura, coordenador ou script do seu fluxo não foi testado com PSBTv2, passe o argumento antes de atualizar o nó com que ele fala.

Vários campos e opções ficam obsoletos: vsize nos RPCs da mempool e em getrawtransaction (use vsize_adjusted, ou vsize_bip141 para o tamanho bruto da BIP 141), a opção de inicialização walletrbf e a chave bip125-replaceable (os nós retransmitem substituições de qualquer transação desde o Core 28) e o RPC removeprunedfunds, que agora exige deprecatedrpc=removeprunedfunds. Nomes de carteira com elementos de caminho feitos só de pontos, ou uma carteira chamada apenas de uma barra, são rejeitados.

Novidades na superfície de RPC: exportwatchonlywallet, addhdkey e derivehdkey; send e sendall deixam de ser marcados como experimentais; getblockchaininfo informa o progresso da validação em segundo plano do assumeutxo; getbalances ganha um saldo nonmempool; getnetworkinfo informa a versão do asmap; exportasmap e getopenrpcinfo; um comando bitcoin-util getchainparams. O servidor HTTP próprio é mais rigoroso com os headers, então verifique qualquer cliente que envie headers incomuns. Nada disso toca na forma como uma transação é construída ou transmitida, então SDKs que falam com um nó por RPC padrão, incluindo o ChainGate, continuam funcionando.

7. Usuários de Bitcoin precisam fazer algo?

Não. A 32.1 não muda nenhuma regra de consenso, então não há fork, não há moeda nova e nada para migrar; suas chaves, endereços e saldos são os mesmos. Se você usa uma carteira leve ou mantém moedas em uma exchange, a atualização acontece nas máquinas de outras pessoas.

O que você pode notar é uma carteira conectada a um nó Core propondo tarifas menores nas horas seguintes a um período movimentado, já que o estimador agora lê a mempool. Se você roda seu próprio nó, atualize; se está na 29.x, está em uma linha sem manutenção desde 27 de outubro. Quem disser para você mover ou "atualizar" seus bitcoins por causa de uma release do Core está aplicando um golpe.

8. O que está confirmado e o que segue em aberto?

9. O que vem a seguir?

O próximo item com data é a divulgação das três vulnerabilidades corrigidas na 30.0, que as notas de release prometem para duas semanas depois da release, ou seja, por volta de 10 de novembro de 2026. Vamos adicioná-la aqui, junto com qualquer release de manutenção da 32.x. O registro de atualizações abaixo mostra o que mudou e quando.

Enquanto isso, o guia de tarifas do Bitcoin mostra os níveis de sat/vB ao vivo que o novo estimador está alcançando, o guia sobre hash da transação explica como acompanhar uma transação que está esperando, e a notícia sobre o encerramento da Binance Pool cobre o que acontece com transações travadas quando esse acelerador fechar em 10 de novembro.

Atualizações deste artigo

• 31 de outubro de 2026: primeira publicação. Datas retiradas da issue do cronograma de release do Bitcoin Core, do servidor de downloads e das páginas de release do bitcoincore.org; detalhes das vulnerabilidades dos três posts de divulgação de 28 de outubro; conteúdo da release das notas de release da 32.1 e da página de ciclo de vida.

Perguntas frequentes