Tudo o que foi reunido de fontes oficiais.
141 publicações
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.
Bitcoin Optech
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.
Bitcoin Optech
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.
Bitcoin Optech
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.
Bitcoin Core
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.
Bitcoin Core
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.
Bitcoin Core
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.
Bitcoin Core
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).
Bitcoin Core
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.
Bitcoin Core
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.
Bitcoin Core
Adam Gibson explica o Lichen, sua camada 2 de emissor único com saídas unilaterais validadas por BitVM, na recapitulação da edição #428. João Dias e Vincenzo Palazzo são os outros convidados de Gustavo Flores Echaiz e Brandon Black; sintaxe de descriptors para pré-imagens de hash, rbitcoin 0.8.0 e LND v0.21.5-beta.rc1 também entram na conversa.
Bitcoin Optech
Desenhado por Adam Gibson, o Lichen permite que usuários de uma camada 2 de emissor único resgatem bitcoin on-chain quando o hub se recusa ou sai do ar, com disputas resolvidas por provas Groth16 e transações BitVMX pré-assinadas. Outro tema da newsletter #428 é a proposta de João Dias para uma forma privada de pré-imagem nos fragmentos de hash do miniscript; Ibis Wallet v5.0-beta e rbitcoin 0.8.0 aparecem entre as atualizações de software.
Bitcoin Optech
Dois bugs de memória do Eclair no handshake de abertura de canal são o assunto de Erick Cestari na recapitulação da #427: um apareceu no fuzzer de Matt Morehouse, o outro com um LLM. Em seguida, Adam Gibson apresenta o LN-GAP, que tem como exemplo uma partida de xadrez jogada dentro de um canal Lightning. Bitcoin Core 32.0rc4 e um lote de correções do Eclair ficam para a parte final do programa.
Bitcoin Optech
O Eclair v0.14.0 e anteriores podiam ficar sem memória durante a abertura de canal: um bug vazava cerca de 1 MB por segundo, e outro consumia 4 GB em uns 48 minutos por uma única conexão, sem custo on-chain. Ambos foram corrigidos na v0.14.1. A newsletter #427 os coloca ao lado do LN-GAP, esquema de Adam Gibson para contratos de várias rodadas dentro de canais Lightning, que depende de um comitê de maioria honesta.
Bitcoin Optech
Clara Shikhelman abre a recapitulação da #426 com o Shielded Bitcoin, proposta da qual é coautora para movimentar bitcoin sem divulgar remetente, destinatário ou valores, sem mudanças de consenso nem operadores. Depois, Elias Rohrer, da Spiral, comenta as versões LDK v0.3-rc3 e v0.2.7 e mudanças no código do LDK, com Gustavo Flores Echaiz na apresentação.
Bitcoin Optech
Metaprotocolo para transferências on-chain privadas, o Shielded Bitcoin, de Misha Komarov com Clara Shikhelman e Aleksei Moskvin, dispensa mudança de consenso, mas exige uma cerimônia de configuração única e deixa rastro na entrada e na saída. Anthony Towns rascunha um BIP que deixa os pares escolherem seus próprios IDs de mensagem de um byte no transporte BIP324, e Fabian Jahr pergunta se as tags de tagged hash devem trazer números de BIP.
Bitcoin Optech
O parser de bits de recurso do Eclair alocava mais de 300 MB ao lidar com uma única mensagem de tamanho máximo, conta Matt Morehouse na recapitulação da #425, e a correção reduziu isso para cerca de 200 KB. Gustavo Flores Echaiz e Brandon Black seguem com sincronização de rótulos de carteira, tipos de saída PQC, limites de time warp do BIP54 e propostas de covenant para vaults.
Bitcoin Optech
Uma consulta de gossip de 64 kB podia inflar até 64 MB no Eclair v0.13.1 e anteriores, e uma mensagem init de tamanho máximo movimentava cerca de 300 MB; Matt Morehouse divulgou os dois bugs de DoS, corrigidos na v0.14.0. Jakub sonda o interesse em sincronizar rótulos de carteira BIP329 por meio de um armazenamento não confiável, e a seção de consenso da newsletter #425 volta aos tipos de saída pós-quânticos.
Bitcoin Optech
O PQLN, segurança pós-quântica para as superfícies off-chain da Lightning, é explicado por Ahmet Kurt no primeiro trecho pré-gravado do programa da Optech. Jan B, colaborador do Bitcoin Core que revisa PRs e trabalha no código do kernel, junta-se a Gustavo Flores Echaiz e Mike Schmidt na parte ao vivo, com o Bitcoin Core 32.0rc2 e seu guia de testes na pauta.
Bitcoin Optech
De Ahmet Kurt e colaboradores, o PQLN deixa o gossip, o transporte, as invoices, as offers e o onion da Lightning seguros contra computação quântica, mas não mexe nas operações on-chain, que exigiriam mudança de consenso. A conta vem em banda: um nó baixa 10 vezes e armazena 9 vezes mais dados, enquanto a assinatura ML-DSA leva só 0,33 ms. Já dá para testar uma implementação funcional em rust-lightning.
Bitcoin Optech
