O Bitcoin Core incorporou em 22 de outubro uma mudança nas regras que abre uma via mais rápida para corrigir vulnerabilidades: uma falha considerada fácil de ser encontrada novamente por atacantes agora pode ser corrigida de uma só vez em todas as linhas de versões ainda mantidas, com um comunicado publicado à medida que cada correção é disponibilizada. A mudança ocorre quando um retrato da rede feito pelo Instituto de Tecnologia de Karlsruhe (KIT) mostra que 43,6% dos pares públicos do Bitcoin Core incluídos na amostra estão executando versões que já não recebem correções.
Pela nova regra, os desenvolvedores podem classificar uma falha durante a triagem, avaliando com que facilidade ela pode ser descoberta novamente, inclusive com a ajuda de grandes modelos de linguagem. O desenvolvedor do Bitcoin Core Antoine Poinsot anunciou a mudança na lista de discussão bitcoindev, na solicitação de incorporação que atualiza a política de segurança do projeto. Ele argumentou que o antigo período de embargo pouco acrescenta, ao mesmo tempo que atrasa a disponibilidade de uma versão corrigida. A desvantagem que apontou é que as medidas de mitigação terão menos tempo para demonstrar sua eficácia nas ramificações de desenvolvimento. Em 23 de outubro, a nova categoria ainda não havia sido aplicada publicamente a nenhuma falha específica.
A mudança encerra uma política que mantinha em sigilo os detalhes de bugs de gravidade média e alta até duas semanas após o fim da vida útil da última versão afetada, um período que podia se estender por quase um ano. O embargo — período durante o qual os detalhes de uma vulnerabilidade permanecem em sigilo até que versões corrigidas sejam amplamente implantadas — dependia de que fosse difícil redescobrir os bugs. As ferramentas de IA enfraquecem essa premissa, então longos períodos de silêncio agora atrasam as correções mais do que protegem os operadores.
Como a política antiga funcionava na prática
A prática do projeto fica evidente na divulgação da CVE-2024-52911. O bug de alta gravidade de uso após liberação na validação de blocos, que afetava versões posteriores à 0.14.0 e anteriores à 29.0 e permitia que um bloco inválido especialmente criado derrubasse um nó, foi relatado em novembro de 2024, corrigido na versão 29.0 em abril de 2025 e divulgado em 5 de maio de 2026, cerca de 388 dias após a correção. O padrão continua: as notas de lançamento da versão 32.0 afirmam que três falhas de gravidade média ou alta corrigidas na versão 30.0 permanecerão em sigilo até duas semanas após o lançamento da nova versão.
A parcela sem suporte
O Bitcoin Core mantém apenas suas três linhas de versões principais mais recentes, atualmente 29.x, 30.x e 31.x. O levantamento do KIT de 18 de outubro contabilizou 3.671 dos 8.422 pares do Bitcoin Core que se identificaram como executando linhas que já haviam chegado ao fim da vida útil; os demais estavam nas versões 31.x (3.243), 30.x (712) e 29.x (635). A contagem abrange apenas pares públicos IPv4 e IPv6, portanto nós que usam somente Tor, nós que não aceitam conexões e infraestruturas privadas operadas por corretoras, custodiantes e mineradores não estão incluídos. Quem quiser entender os conceitos básicos pode começar por o que são nós de cripto e como funcionam.
A parcela deve crescer. Quando a versão 32.0 for lançada, a 29.x sairá da janela de manutenção, e uma projeção baseada no levantamento indica que 4.306 dos 8.422 pares, ou 51,1%, estarão em linhas sem suporte se a amostra permanecer inalterada. Em 24 de outubro, a página do ciclo de vida do projeto ainda indicava a data de lançamento da versão 32.0 como a definir, e o diretório de downloads continha apenas versões candidatas.
O Core 32.0 também muda o formato padrão de transação Bitcoin parcialmente assinada da versão 0 para a versão 2, o que é relevante para configurações multisig que combinam nós antigos e novos. Como o Bitcoin não tem uma autoridade central que possa impor atualizações, a segurança da rede depende da decisão dos operadores de atualizar.