Continua a discussão sobre TCP hole punching para tornar acessíveis os nós domésticos atrás de roteadores. A edição também aborda um rascunho de BIP para padronizar as políticas de gasto aplicadas por co-signatários ao emular covenants.
Greg Sanders, Antoine Poinsot, Elias Rohrer, Oleksandr Kurbatov e Nishant Bansal participam, com os apresentadores da Optech, da recapitulação da edição #429, que abre com Bitcoin Core #36665, #36667 e #36669 antes de passar à política de segurança atualizada. Silent payments multipartes, a divulgação de um DoS no Core Lightning e o Eclair 0.14.6 vêm depois; a transcrição ainda não saiu.
Um anúncio de canal com o mesmo nó nas duas pontas podia derrubar o Core Lightning, das versões 25.02 a 26.04, a cada reinício, e o atacante só gastava taxas on-chain; a correção veio na 26.04.1. A newsletter #429 traz essa divulgação ao lado do protocolo de Oleksandr Kurbatov para inputs multipartes em silent payments e das versões pontuais mais rápidas do Bitcoin Core para bugs fáceis de descobrir.
Ao fingir que não suporta os pings do BIP 31, um par malicioso escapava da desconexão de 20 minutos e lia devagar, inflando a fila de envio do nó em até 2 MB por hora para cada par de entrada e 5 MB para cada par de saída. A CVE-2026-117349, de gravidade Média, foi corrigida pelo #36667 no Bitcoin Core 32.1, 31.2, 30.4 e 29.5; nós em -blocksonly estavam bem menos expostos.
O monitoramento de exceções de socket agora é igual entre poll() e select() no Bitcoin Core 29.5 (#36665), e pares com envio pausado passam a ter timeout obrigatório (#36667). Posições de flatfile migram para inteiros de 64 bits (#36669), os nós assumem v2transport para endereços vindos de seeds, e um seed de DNS sai da lista.
Um minerador conseguiria levar um arquivo undo do Bitcoin Core além de 4 GiB, fazendo as posições de 32 bits darem a volta e corrompendo dados, e os nós desligam se vier a reorganização certa; no Windows e em sistemas de 32 bits a falha ocorre em 2 GiB, sem reorganização. A CVE-2026-117346 tem gravidade Baixa e exigiria cerca de um mês de todos os blocos da rede. As versões 32.1, 31.2, 30.4 e 29.5 resolvem em sistemas de 64 bits; nós de 32 bits e armazenamento de blocos em FAT32 continuam afetados.
Em Windows, macOS e BSD, os nós podiam cair quando um par conectado enviava dados urgentes TCP, que passavam pelas leituras pausadas no backend select() e acumulavam memória sem limite (CVE-2026-117350). No Linux, o nó usa poll() e não é afetado. A falha, de gravidade Média, apareceu em uma varredura com LLM do Project Loupe e está corrigida no Bitcoin Core 32.1, 31.2, 30.4 e 29.5.
O Bitcoin Core 30.4 deixa de tratar os bits 5 a 28 do BIP 9 como sinal de soft fork, em linha com o BIP 323, e blocos que os ativam não disparam mais avisos de implantação desconhecida (#34779). Na rede, pares com envio pausado agora têm um timeout obrigatório (#36667), e as posições de flatfile passam a usar inteiros de 64 bits (#36669).
A transmissão privada ganha um teto no Bitcoin Core 31.2: a fila de transações que ainda não voltaram da rede para em 10.000 entradas e, cheia, recusa novos envios, cabendo a quem chama limpá-la com abortprivatebroadcast (#35406). Os bits de versão 5 a 28 deixam de contar como sinal de soft fork, conforme o BIP 323.
A transmissão privada do Bitcoin Core 32.1 não corre mais o risco de expor o IP do remetente, vazamento possível quando uma conexão v2 falhava e a nova tentativa em v1 saía direto, sem passar pelo Tor. O padrão de -maxconnections sobe de 125 para 200, e a retransmissão de saída de transações passa a ser limitada por um backlog global, não mais por par.