De discussie over TCP hole punching om thuisnodes achter routers bereikbaar te maken, gaat door. De nieuwsbrief behandelt ook een BIP-concept voor het standaardiseren van bestedingsbeleid dat cosigners afdwingen bij het emuleren van covenants.
Bij de bespreking van #429 schuiven Greg Sanders, Antoine Poinsot, Elias Rohrer, Oleksandr Kurbatov en Nishant Bansal aan bij de presentatoren van Optech. Eerst komen Bitcoin Core #36665, #36667 en #36669 aan bod, daarna het bijgewerkte beveiligingsbeleid. Later volgen multiparty silent payments, een DoS-melding over Core Lightning en Eclair 0.14.6; het transcript laat nog op zich wachten.
Een kanaalaankondiging met aan beide kanten dezelfde node kon Core Lightning 25.02 tot en met 26.04 bij elke herstart laten crashen, en de aanvaller betaalde daarvoor alleen on-chain transactiekosten; 26.04.1 bevat de oplossing. Daarnaast staan in nieuwsbrief #429 het protocol van Oleksandr Kurbatov voor silent payment-inputs van meerdere partijen en de snellere puntreleases van Bitcoin Core voor bugs die makkelijk te ontdekken zijn.
Door te doen alsof hij BIP 31-pings niet ondersteunt, kon een kwaadwillende peer de verbreking na 20 minuten ontlopen en traag blijven lezen. De verzendwachtrij van een node zwol zo op met maximaal 2 MB per uur per inkomende peer en 5 MB per uitgaande. CVE-2026-117349, ingeschaald als Medium, is met #36667 verholpen in Bitcoin Core 32.1, 31.2, 30.4 en 29.5; -blocksonly-nodes waren veel minder kwetsbaar.
In Bitcoin Core 29.5 bewaken poll() en select() socketuitzonderingen voortaan op dezelfde manier (#36665), en voor gepauzeerde send-peers geldt nu een harde time-out (#36667). Flatfile-posities stappen over op 64-bits integers (#36669), nodes gaan bij adressen uit seeds uit van v2transport en er verdwijnt één DNS-seed.
Een miner kon een undo-bestand van Bitcoin Core voorbij 4 GiB duwen, waarna de 32-bits posities omsloegen en data beschadigd raakte; volgt dan de juiste reorg, dan sluiten nodes af. Op Windows en 32-bits systemen gaat het al zonder reorg mis bij 2 GiB. CVE-2026-117346 heeft de classificatie Low en zou ongeveer een maand aan alle blokken van het netwerk vergen. Versies 32.1, 31.2, 30.4 en 29.5 lossen het op voor 64-bits systemen; 32-bits nodes en blokopslag op FAT32 blijven kwetsbaar.
Een verbonden peer kon nodes op Windows, macOS en BSD laten crashen met TCP urgent data: die glipte in de select()-backend langs gepauzeerde leesacties en stapelde zich onbeperkt op in het geheugen (CVE-2026-117350). Linux-nodes gebruiken poll() en lopen geen risico. Bitcoin Core 32.1, 31.2, 30.4 en 29.5 dichten de bug, die als Medium is geclassificeerd en bij een LLM-scan binnen Project Loupe aan het licht kwam.
Bitcoin Core 30.4 ziet BIP 9-bits 5 tot en met 28 niet langer als soft-fork-signalen, in lijn met BIP 323. Blokken die deze bits zetten, leiden dus niet meer tot waarschuwingen over onbekende deployments (#34779). Op netwerkgebied geldt nu een time-out voor gepauzeerde send-peers (#36667) en flatfile-posities gebruiken voortaan 64-bits integers (#36669).
Private broadcast krijgt in Bitcoin Core 31.2 een bovengrens: de wachtrij van transacties die nog niet door het netwerk zijn teruggekaatst, stopt bij 10.000 stuks. Is hij vol, dan worden nieuwe inzendingen geweigerd en moeten aanroepers hem leegmaken met abortprivatebroadcast (#35406). Versiebits 5 tot en met 28 tellen, conform BIP 323, niet meer als soft-fork-signalen.
Private broadcast in Bitcoin Core 32.1 kan het IP-adres van de verzender niet meer prijsgeven. Dat lek kon optreden als een mislukte v2-verbinding het opnieuw probeerde over v1, rechtstreeks in plaats van via Tor. De standaardwaarde van -maxconnections gaat van 125 naar 200, en uitgaande transactie-relay wordt begrensd via een globale backlog in plaats van per peer.