Bitcoin Core corrige falha que revelava o IP do usuário nas transações

　　A equipe do Bitcoin Core lançou nesta semana a versão 31.1 do software com uma correção para uma falha de privacidade que poderia revelar o endereço IP do nó responsável pelo envio de uma transação. O problema afetava o recurso -privatebroadcast, criado justamente para impedir que o destinatário identificasse o IP e a localização aproximada do remetente.

　　A vulnerabilidade não afetava todas as transações realizadas pelo Bitcoin Core. Segundo o próprio projeto, o problema atingia usuários da versão 31.0 que haviam ativado manualmente o -privatebroadcast e utilizavam a função sendrawtransaction para transmitir transações. As funções padrão da carteira, como sendtoaddress e sendall, não usavam o mecanismo e, portanto, não foram afetadas.

　　O Bitcoin Core introduziu o recurso de transmissão privada na versão 31.0, lançada em 19 de abril de 2026. A ferramenta deveria encaminhar transações exclusivamente por redes de privacidade como Tor ou I2P, utilizando conexões separadas e temporárias para dificultar tanto a identificação do IP do remetente quanto a associação entre diferentes transações originadas pelo mesmo usuário.

• Julho começa com tokenização captando quase R$ 9 milhões no Brasil

　　No entanto, uma condição específica quebrava essa proteção. Quando o Bitcoin Core tentava estabelecer uma conexão utilizando o transporte v2 do BIP324 por meio do Tor e a negociação falhava, o software podia tentar novamente pelo protocolo v1. Essa segunda tentativa, em determinados cenários, ocorria diretamente pela internet aberta, conhecida como clearnet, expondo o endereço IP do nó ao par que recebia a conexão.

　　A equipe do Bitcoin Core alertou que uma falha legítima durante a negociação do transporte v2 seria improvável quando o outro nó realmente suportasse o protocolo. Entretanto, um nó malicioso poderia encerrar deliberadamente a conexão v2 para forçar a nova tentativa pelo protocolo v1 e, assim, tentar descobrir o IP do remetente. Conexões com nós Onion e I2P não foram afetadas pelo problema.

　　Falha quebrava promessa de privacidade do Bitcoin Core

　　O próprio projeto reconheceu publicamente o problema em 6 de junho e afirmou que a vulnerabilidade contrariava diretamente uma das garantias apresentadas no lançamento do Bitcoin Core 31.0: impedir que o endereço IP e, consequentemente, a localização geográfica aproximada do remetente fossem conhecidos pelos destinatários das transações.

• Gráficos apontam risco de nova queda do Bitcoin, mas dados da Binance podem salvar o BTC

　　Até a chegada da versão 31.1, os desenvolvedores recomendavam duas soluções temporárias aos usuários afetados. A primeira consistia em desativar completamente o -privatebroadcast. A segunda envolvia desligar o transporte v2, embora essa alternativa trouxesse desvantagens, como maior facilidade para identificar e censurar conexões realizadas pela internet aberta.

　　A correção ganhou relevância devido à ampla presença do Bitcoin Core entre os nós públicos conhecidos da rede Bitcoin. Segundo o retrato da Coin Dance, 18.374 dos 23.795 nós públicos contabilizados utilizavam o Bitcoin Core, o equivalente a aproximadamente 77,2% do total. Os números, contudo, representam nós públicos detectados pelo serviço e não necessariamente todos os nós existentes na rede.

　　Bitcoin Core 31.1 também corrige problemas em carteira, disco e MuSig2

　　Além da falha de privacidade, o Bitcoin Core 31.1 trouxe mudanças de estabilidade, armazenamento, carteira e processamento de transações. Entre as principais alterações está a desativação de um mecanismo de seek compaction no LevelDB, banco de dados usado pelo software. Discussões técnicas do projeto apontaram que esse processo podia provocar um efeito em cascata e regravar grandes partes do banco de dados do estado da blockchain aproximadamente a cada hora.

• Google anuncia que vai banir Polymarket, Kalshi e mercados preditivos do Chorme

　　A atualização também adicionou uma verificação extra durante a migração de carteiras baseadas no formato Berkeley DB, com o objetivo de conferir a página final do banco de dados durante o processo. Outra mudança alterou a forma como o software estima o tamanho das entradas de uma transação, um elemento que influencia o cálculo do espaço ocupado e das taxas necessárias para transmitir fundos.

　　Os desenvolvedores também corrigiram um problema relacionado ao MuSig2, protocolo que permite agregar várias chaves públicas e produzir assinaturas conjuntas. Anteriormente, uma função podia receber uma lista vazia de chaves públicas, embora o BIP327, que especifica o MuSig2, exija pelo menos uma chave. A versão 31.1 passou a rejeitar explicitamente essa configuração inválida.