O Bitcoin Core 32.0 entrou em seu ciclo final de testes de candidato a lançamento depois que os desenvolvedores marcaram a v32.0rc1 em 14 de setembro, aproximando a estimativa de taxas, o desempenho de validação de blocos e correções de segurança de um lançamento planejado para 10 de outubro.
Resumo
- O Bitcoin Core 32.0 entrou em testes de candidato a lançamento em 14 de setembro, com a marcação final prevista para 10 de outubro.
- A nova estimativa de taxas combina o histórico de blocos com as condições atuais da mempool e pode recomendar taxas mais baixas.
- A validação de blocos agora pré-carrega saídas anteriores em oito threads de trabalho por padrão, reduzindo as esperas de disco.
- Uma falha de notificação da carteira poderia permitir que usuários autenticados executassem comandos em sistemas de nó afetados que não sejam Windows.
- Os testes descobriram que dezesseis conexões REST não autenticadas podiam levar o uso de memória a aproximadamente três gigabytes rapidamente.
O lançamento oficial no GitHub do projeto Bitcoin Core mostra a v32.0rc1 no commit d0231bb, assinada com uma assinatura verificada de mantenedor em 14 de setembro às 12:58 UTC. O cronograma de lançamento do projeto ainda tem como meta 10 de outubro para a tag final da v32.0, embora a data permaneça sujeita a testes e correções adicionais.
A versão 32 concentra-se no comportamento do software de nó, interfaces de carteira, cálculo de taxas, rede e desempenho. As notas de lançamento preliminares não listam uma mudança nas regras de consenso do Bitcoin, o que significa que a atualização não redefine quais transações ou blocos a rede considera válidos.
Bitcoin Core 32 tem como meta 10 de outubro após a tag RC1
Os desenvolvedores entraram em congelamento de recursos em 20 de agosto, limitando o trabalho a correções necessárias antes do lançamento. Em 14 de setembro, eles separaram o branch 32.x do branch principal de desenvolvimento e iniciaram o ciclo de candidato a lançamento, enquanto o trabalho de desenvolvimento para a versão 33 foi retomado separadamente.
O primeiro candidato destina-se a operadores de nós, desenvolvedores de carteiras e outros usuários testarem antes que os desenvolvedores decidam se o código está pronto para um lançamento estável. O Bitcoin Core abriu uma issue dedicada de feedback de testes do candidato a lançamento 32.0 em 15 de setembro, um dia após a marcação da RC1.
O projeto pede que os testadores usem o guia de testes para verificações específicas da RC e relatem problemas de software por meio de issues separadas no GitHub. Nenhum binário final da v32.0 foi lançado até 16 de setembro.
O Bitcoin Core não é atualizado automaticamente. Os operadores escolhem quando instalar novas versões, o que significa que lançamentos mais antigos podem permanecer ativos depois que um software mais novo se torna disponível.
Esse modelo de atualização manual foi importante em divulgações de segurança anteriores. Como o crypto.news relatou anteriormente, o Bitcoin Core divulgou a CVE-2024-52911 em maio depois que o branch vulnerável 28.x chegou ao fim de vida. O bug já havia sido corrigido no Bitcoin Core 29.0 antes que os detalhes técnicos se tornassem públicos.
Novo estimador de taxas combina mempool e histórico de blocos
Uma das mudanças mais visíveis voltadas ao usuário no Bitcoin Core 32 afeta o estimatesmartfee, o RPC usado por carteiras e aplicativos para calcular taxas de transação.
Até agora, o principal estimador do Bitcoin Core baseava-se no comportamento de confirmação observado de transações incluídas em blocos passados. A versão 32 adiciona um estimador separado baseado em transações atualmente aguardando dentro da mempool do nó.
O novo estimador de mempool produz estimativas econômicas e conservadoras a partir das condições atuais de transações pendentes. O Bitcoin Core verifica a atividade recente de blocos antes de usá-lo e pode rejeitar a estimativa quando a mempool parece muito esparsa ou não saudável.
Quando ambos os sistemas produzem resultados válidos, o estimatesmartfee retorna a estimativa de taxa mais baixa. O novo método, portanto, não pode elevar a recomendação existente de política de blocos por meio do modo padrão combinado; seu papel é reduzir a recomendação quando as condições atuais da mempool permitem fazê-lo.
Esse design pode responder mais rapidamente após o fim de um período de espaço de bloco caro. Um estimador de histórico de blocos pode continuar incorporando transações recentemente confirmadas com taxas altas, enquanto a mempool já pode mostrar menos transações competindo por confirmação.
O software preserva uma maneira de os aplicativos usarem o método anterior. Uma opção adicionada fee_rate_estimator permite aos usuários solicitar block_policy, mempool_policy ou o comportamento padrão combinado. O Bitcoin Core armazena as estatísticas do novo estimador de mempool em um arquivo de dados separado para que possam ser recarregadas após a reinicialização.
Os cálculos de taxa da carteira usarão o estimador padrão combinado. A resposta pode identificar qual estimador produziu a taxa selecionada, enquanto níveis mais altos de verbosidade expõem estatísticas de saúde da mempool para aplicativos que precisam de mais detalhes.
A validação de blocos ganha pré-busca paralela em disco
O Bitcoin Core 32 muda a forma como os nós recuperam dados de transações ao conectar blocos, particularmente quando as informações necessárias devem ser lidas do armazenamento.
O software agora pode pré-buscar saídas de transações anteriores, conhecidas como prevouts, do banco de dados chainstate em várias threads de trabalho enquanto a validação de blocos continua. O padrão é oito threads de pré-busca, com operadores podendo aumentar a configuração para 16 ou desabilitar a busca paralela definindo-a como zero.
Prevouts identificam as moedas sendo gastas pelas entradas de transação. Os nós precisam dessas informações para verificar se as entradas existem, não foram gastas anteriormente e satisfazem as regras de validação aplicáveis.
A melhoria visa reduzir o tempo gasto esperando por leituras de disco quando um nó processa blocos contendo entradas que ainda não estão disponíveis em caches de memória mais rápidos. O efeito variará com o hardware de armazenamento, o comportamento do cache e a configuração do nó.
O Bitcoin Core 32 expõe a configuração por meio de -prevoutfetchthreads=<n>, dando aos operadores controle sobre quantas threads participam. As notas do rascunho descrevem o recurso especificamente como uma melhoria de desempenho da validação de blocos.
Mudanças separadas no RPC dão aos operadores mais informações durante a validação em segundo plano do AssumeUTXO. Depois que um nó baseado em snapshot atinge a ponta da cadeia, o getblockchaininfo agora pode relatar o progresso da validação histórica da cadeia ainda em execução atrás do estado ativo do nó.
Correções de segurança fecham falhas de memória na carteira e no HTTP
O Bitcoin Core 32 corrige uma falha de notificação de carteira que afeta sistemas não Windows sob um conjunto restrito de condições.
As notas do rascunho afirmam que um usuário RPC autenticado com permissão para criar carteiras poderia elaborar um nome de carteira contendo caracteres de substituição especiais quando o nó fosse configurado com -walletnotify. Sob essas condições, o nome poderia fazer com que comandos arbitrários fossem executados com os privilégios do processo do Bitcoin Core.
A versão 32 altera a substituição de espaços reservados na notificação de carteira para que os nomes de carteira sejam tratados como texto literal. A versão também restringe a nomenclatura de carteiras ao rejeitar certos nomes de caminho relativo contendo elementos de caminho . ou ..
Um segundo problema surgiu durante a revisão do servidor HTTP reescrito do Bitcoin Core, que está substituindo o libevent na versão 32.
O desenvolvedor Matthew Zipkin enviou o pull request #36123 depois que uma auditoria usando o modelo Kimi K3 da Moonshot AI identificou um caminho de esgotamento de memória. Enquanto o servidor lidava com uma solicitação, ele podia continuar lendo e enfileirando dados enviados pela mesma conexão sem um limite efetivo de tamanho.
A primeira análise sugeriu que a condição exigia principalmente um cliente autenticado capaz de manter uma solicitação ocupada. Testes adicionais descobriram que o tráfego REST criava um problema semelhante sem autenticação.
Um revisor relatou que 16 conexões REST não autenticadas elevaram um processo de teste de 46 MB de memória para aproximadamente 3 GB em cerca de um minuto. Após a correção revisada, o mesmo teste aumentou o uso de memória em aproximadamente 3 MB ao longo de 90 segundos, em comparação com 3,2 GB antes do patch.
O patch foi mesclado em 5 de setembro, antes de v32.0rc1 ser marcado. Como o servidor HTTP reescrito é novo na versão 32, a falha específica foi detectada antes que o servidor aparecesse em uma versão estável do Bitcoin Core.
O uso do Kimi K3 se encaixa em um padrão recente de revisão de segurança assistida por IA em softwares Bitcoin. Como a crypto.news relatou em agosto, o Bitcoin Red Team havia registrado 7.958 possíveis achados após escanear centenas de projetos de código aberto relacionados ao Bitcoin, embora muitos exigissem verificação humana antes de poderem ser tratados como vulnerabilidades confirmadas.
Problemas de esgotamento de recursos apareceram em outros softwares Bitcoin este ano. Em cobertura relacionada, a crypto.news relatou que o Core Lightning confirmou falhas de segurança após revisar relatórios gerados por IA e alertou os operadores para atualizarem ou usarem temporariamente o modo offline.
PSBT versão 2 se torna o padrão para quatro RPCs
O Bitcoin Core 32 altera o formato padrão criado por quatro comandos usados com Transações Bitcoin Parcialmente Assinadas.
createpsbt, walletcreatepsbt, converttopsbt e psbtbumpfee produzirão PSBT versão 2 por padrão. Os desenvolvedores adicionaram um argumento opcional psbt_version para que os aplicativos possam solicitar explicitamente outra versão suportada quando necessário.
As PSBTs permitem que várias carteiras, aplicativos ou dispositivos de assinatura de hardware troquem informações de transação antes que a transação Bitcoin concluída seja transmitida. Mover o padrão para a versão 2 pode exigir testes por parte de softwares que assumem que a saída RPC do Core usará o formato mais antigo.
A atualização não remove a capacidade de solicitar a versão anterior. Aplicativos construídos em torno dos comandos RPC afetados podem definir o formato explicitamente enquanto testam a compatibilidade com a versão 2.
As ferramentas de carteira recebem outras mudanças na mesma versão. Um novo RPC exportwatchonlywallet cria um arquivo de carteira descritor contendo descritores públicos, histórico de transações e dados do catálogo de endereços sem chaves privadas. O tutorial de assinatura offline do Bitcoin Core agora usa esse comando para criar uma carteira online somente leitura.
Outro novo comando, derivehdkey, permite que uma carteira derive uma chave pública ou privada estendida através de um caminho contendo pelo menos uma etapa reforçada, enquanto addhdkey permite que uma chave estendida BIP32 seja adicionada sem usá-la imediatamente para gerar scripts de saída.
O PrivateBroadcast também recebe manutenção contínua. A Crypto.news relatou em junho que o Bitcoin Core 31.1rc1 corrigiu uma condição de rede que poderia expor um endereço IP de origem quando o PrivateBroadcast era usado. A versão 32 contém mais mudanças de RPC do PrivateBroadcast e de retransmissão de transações documentadas em suas notas de versão preliminares.
O cronograma atual do Bitcoin Core ainda lista 10 de outubro como a meta para marcar a v32.0. O tópico de feedback de testes do RC aberto em 15 de setembro permanece ativo, com os desenvolvedores direcionando os testadores que encontrarem defeitos reais do Bitcoin Core para abrir issues separadas antes do lançamento final.
