Die Diskussion über TCP Hole Punching zur Erreichbarkeit von Heim-Nodes hinter Routern geht weiter. Zudem behandelt die Ausgabe einen BIP-Entwurf zur Standardisierung von Ausgaberegeln, die Cosigner bei der Emulation von Covenants durchsetzen.
Greg Sanders, Antoine Poinsot, Elias Rohrer, Oleksandr Kurbatov und Nishant Bansal sind in der Rückschau auf Ausgabe #429 bei den Optech-Moderatoren zu Gast. Los geht es mit Bitcoin Core #36665, #36667 und #36669, danach folgt die aktualisierte Sicherheitsrichtlinie. Später kommen Silent Payments mit mehreren Beteiligten, eine DoS-Offenlegung bei Core Lightning und Eclair 0.14.6 zur Sprache; das Transkript fehlt noch.
Eine Kanalankündigung, die an beiden Enden denselben Knoten nennt, konnte Core Lightning 25.02 bis 26.04 bei jedem Neustart zum Absturz bringen; den Angreifer kostete das nur Onchain-Gebühren. Behoben ist der Fehler in 26.04.1. Außerdem in Newsletter #429: das Protokoll von Oleksandr Kurbatov für Silent-Payment-Inputs mehrerer Parteien und schnellere Point-Releases von Bitcoin Core bei leicht auffindbaren Bugs.
Gab ein bösartiger Peer vor, BIP-31-Pings nicht zu beherrschen, entging er der Trennung nach 20 Minuten und konnte langsam lesen. Die Sendewarteschlange eines Knotens wuchs dadurch um bis zu 2 MB pro Stunde je eingehendem und 5 MB je ausgehendem Peer. Bitcoin Core 32.1, 31.2, 30.4 und 29.5 schließen die als mittelschwer eingestufte Lücke CVE-2026-117349 mit #36667; -blocksonly-Knoten waren deutlich weniger gefährdet.
poll() und select() überwachen Socket-Exceptions in Bitcoin Core 29.5 jetzt auf dieselbe Weise (#36665), für pausierte Send-Peers greift ein verbindliches Timeout (#36667). Flatfile-Positionen wechseln auf 64-Bit-Ganzzahlen (#36669), bei Adressen aus Seeds gehen Knoten von v2transport aus, und ein DNS-Seed fällt weg.
Ein Miner konnte eine Undo-Datei von Bitcoin Core über 4 GiB hinaus aufblähen. Ihre 32-Bit-Positionen laufen dann über, Daten werden beschädigt, und folgt ein passender Reorg, fahren Knoten herunter; unter Windows und auf 32-Bit-Systemen ist schon bei 2 GiB Schluss, ganz ohne Reorg. CVE-2026-117346 ist als niedrig eingestuft, der Angriff bräuchte rund einen Monat lang sämtliche Blöcke des Netzes. Auf 64-Bit-Systemen beheben 32.1, 31.2, 30.4 und 29.5 das Problem, 32-Bit-Knoten und Blockspeicher auf FAT32 bleiben betroffen.
Knoten unter Windows, macOS und BSD ließen sich von einem verbundenen Peer mit TCP-Urgent-Daten zum Absturz bringen: Die Daten umgingen im select()-Backend pausierte Lesevorgänge, der Speicher lief ohne Obergrenze voll (CVE-2026-117350). Linux-Knoten arbeiten mit poll() und bleiben verschont. Die als mittelschwer eingestufte Lücke, aufgespürt von einem LLM-Scan im Rahmen von Project Loupe, beheben Bitcoin Core 32.1, 31.2, 30.4 und 29.5.
Bitcoin Core 30.4 wertet die Bits 5 bis 28 aus BIP 9 gemäß BIP 323 nicht mehr als Soft-Fork-Signale, Blöcke mit diesen Bits lösen also keine Warnungen vor unbekannten Deployments mehr aus (#34779). Im Netzwerkteil gilt nun ein Timeout für pausierte Send-Peers (#36667), Flatfile-Positionen nutzen jetzt 64-Bit-Ganzzahlen (#36669).
Für Private Broadcast zieht Bitcoin Core 31.2 eine Obergrenze ein: Die Warteschlange der noch nicht vom Netz zurückgemeldeten Transaktionen endet bei 10.000 Einträgen. Ist sie voll, lehnt sie neue Einreichungen ab, und Aufrufer müssen sie mit abortprivatebroadcast leeren (#35406). Die Versionsbits 5 bis 28 gelten laut BIP 323 nicht länger als Soft-Fork-Signale.
Private Broadcast gefährdet in Bitcoin Core 32.1 nicht mehr die IP-Adresse des Absenders: Das Leck konnte entstehen, wenn eine gescheiterte v2-Verbindung den Neuversuch per v1 direkt statt über Tor startete. Der Standardwert von -maxconnections steigt von 125 auf 200, das Tempo ausgehender Transaktionen regelt nun ein globaler Backlog statt einer Grenze je Peer.