O Bitcoin Core 32.0 entrou no ciclo final de testes após a marcação da versão v32.0rc1, em 14 de setembro. A edição altera o cálculo de taxas, melhora o desempenho da validação de blocos e inclui correções de segurança. Atualmente, a equipe prevê marcar a versão final v32.0 em 10 de outubro, embora novos testes possam alterar o cronograma.

O repositório oficial registrou a v32.0rc1 no commit d0231bb. Um mantenedor assinou o código às 12h58 UTC de 14 de setembro, com verificação confirmada. No entanto, as notas preliminares não indicam mudanças nas regras de consenso do Bitcoin.

Assim, a atualização não redefine quais transações ou blocos a rede considera válidos. O software também não instala novas versões automaticamente. Portanto, cada operador decide quando atualizar, enquanto versões antigas podem continuar em funcionamento.

Versão 32 entra na etapa final de testes

Os desenvolvedores iniciaram o congelamento de recursos em 20 de agosto. Desde então, o trabalho ficou limitado às correções necessárias antes do lançamento. Em 14 de setembro, a equipe separou o ramo 32.x do principal, enquanto o desenvolvimento da versão 33 continuou em paralelo.

A primeira candidata atende operadores de nós, desenvolvedores de carteiras e outros usuários interessados em testar o software. Em seguida, os responsáveis avaliarão se o código está pronto para uma versão estável. O projeto abriu, em 15 de setembro, uma discussão para receber comentários sobre os testes.

Os responsáveis orientam os participantes a seguir o guia de verificação da candidata. Eventuais falhas devem ser registradas em issues separadas no GitHub. Até 16 de setembro, o projeto ainda não havia publicado os arquivos binários da versão final.

Esse modelo de atualização manual ganhou relevância em divulgações anteriores de segurança. Em maio, o projeto revelou a CVE-2024-52911 após o fim do suporte ao ramo vulnerável 28.x. Contudo, o Bitcoin Core 29.0 já havia corrigido a falha antes da publicação dos detalhes técnicos.

Novo cálculo combina mempool e blocos anteriores

Uma das principais mudanças afeta o estimatesmartfee, RPC usado por carteiras e aplicações para calcular taxas de transação. Até agora, o estimador principal analisava confirmações de transações incluídas em blocos anteriores. A versão 32 acrescenta um estimador separado, baseado nas transações que aguardam no mempool do nó.

O novo mecanismo produz estimativas econômicas e conservadoras conforme as condições atuais das transações pendentes. Antes de usá-lo, o software verifica a atividade recente dos blocos. Dessa forma, pode rejeitar a estimativa quando o mempool estiver esparso ou apresentar condições inadequadas.

Quando os dois sistemas apresentam resultados válidos, o estimatesmartfee retorna a menor taxa. Logo, o modo combinado padrão não eleva a recomendação baseada na política de blocos. Seu objetivo consiste em reduzir a sugestão quando as condições atuais do mempool permitirem.

Com isso, o cálculo pode responder mais rapidamente após o fim de um período de taxas elevadas. O estimador histórico ainda pode refletir transações recentes que pagaram valores maiores. Enquanto isso, o mempool pode indicar que a concorrência por espaço já diminuiu.

A opção fee_rate_estimator permite solicitar block_policy, mempool_policy ou o comportamento combinado. Além disso, o software salva as estatísticas do novo estimador em um arquivo separado para recuperá-las após reinicializações. As carteiras usarão o modo combinado por padrão, e a resposta poderá identificar qual estimador definiu a taxa.

Validação paralela busca reduzir leituras em disco

O Bitcoin Core 32 também altera a recuperação de dados de transações durante a conexão de blocos. Agora, o software pode pré-carregar saídas anteriores, chamadas de prevouts, enquanto a validação prossegue. Por padrão, oito threads executam essa tarefa, mas operadores podem configurar até 16 ou desativar o recurso.

As prevouts identificam os valores e as condições das saídas gastas pelas entradas de uma transação. Os nós precisam desses dados para verificar se as entradas existem e não foram gastas. Nesse contexto, a mudança busca reduzir esperas por leituras em disco quando o cache não contém as informações necessárias.

O impacto dependerá do armazenamento, do comportamento do cache e da configuração de cada nó. A opção -prevoutfetchthreads=<n> controla a quantidade de threads, enquanto o valor zero desativa a busca paralela. Também será possível acompanhar pelo getblockchaininfo o progresso da validação histórica em segundo plano do AssumeUTXO.

Carteira e servidor HTTP recebem correções

A atualização corrige uma falha de notificação de carteira em sistemas diferentes do Windows. Um usuário RPC autenticado e autorizado a criar carteiras poderia explorar caracteres especiais no nome delas. Sob uma configuração com -walletnotify, o problema poderia executar comandos com os privilégios do processo do Bitcoin Core.

Agora, o software trata os nomes das carteiras como texto literal durante a substituição de marcadores das notificações. Também rejeita determinados caminhos relativos com os elementos de ponto simples ou triplo. Por outro lado, a revisão do servidor HTTP reescrito identificou uma rota capaz de esgotar a memória.

Durante uma solicitação, o servidor podia continuar lendo e enfileirando dados da mesma conexão sem um limite efetivo. Testes posteriores mostraram que o tráfego REST sem autenticação gerava um problema semelhante. Em uma simulação, 16 conexões elevaram o consumo de 46 MB para cerca de 3 GB em aproximadamente um minuto.

Após a correção revisada, o mesmo teste aumentou o uso de memória em cerca de 3 MB durante 90 segundos. Antes do patch, a elevação chegava a 3,2 GB no mesmo cenário. A equipe incorporou a solução ao código em 5 de setembro, antes da marcação da candidata.

Como o servidor HTTP reescrito estreia na versão 32, a falha não alcançou uma versão estável. Uma auditoria com o modelo Kimi K3, da Moonshot AI, identificou o problema inicial. Ainda assim, possíveis achados de inteligência artificial exigem verificação humana antes da confirmação de uma vulnerabilidade.

PSBT versão 2 torna-se padrão em quatro RPCs

O Bitcoin Core 32 passa a criar PSBT versão 2 por padrão em quatro comandos. Os RPCs createpsbt, walletcreatepsbt, converttopsbt e psbtbumpfee adotarão o formato. Entretanto, aplicações poderão usar o argumento opcional psbt_version para solicitar outra versão compatível.

As PSBTs permitem que carteiras, aplicações e dispositivos de assinatura troquem dados antes da transmissão de uma transação de Bitcoin. Por isso, softwares que presumem o formato antigo precisam testar a compatibilidade com a versão 2. A atualização mantém a possibilidade de solicitar o padrão anterior.

A edição também adiciona o RPC exportwatchonlywallet. Ele cria um arquivo de carteira descriptor com descritores públicos, histórico de transações e catálogo de endereços, mas sem chaves privadas. Já o tutorial de assinatura offline passa a usar esse comando para criar uma carteira watch-only online.

O comando derivehdkey permite derivar uma chave pública ou privada estendida por um caminho com ao menos uma etapa hardened. Adicionalmente, o addhdkey permite incluir uma chave estendida BIP32 sem usá-la imediatamente para gerar scripts de saída. A versão ainda incorpora mudanças em RPCs do PrivateBroadcast e na retransmissão de transações.

	Receba nossas últimas notícias em primeira mão.  Adicione-nos como sua fonte preferida no Google  e toque em “Favorito” para priorizar nossas atualizações.