Bitcoin Optech #427: Eclair-DoS-Meldungen, ein Offchain-Vertragsvorschlag, Core 32.0rc4
Victoria Shinder2 Min. LesezeitDer Newsletter #427 von Bitcoin Optech vom 16. Oktober 2026 behandelt zwei gemeldete Denial-of-Service-Lücken in der Lightning-Implementierung Eclair, einen Vorschlag für komplexe Verträge innerhalb von Lightning-Kanälen sowie die üblichen Listen von Releases und bemerkenswerten Änderungen. Es ist ein wöchentlicher Überblick, daher sind die folgenden Punkte Verweise auf die zugrunde liegenden Meldungen und Diskussionen.
Zwei Eclair-DoS-Lücken, behoben in v0.14.1. Erick Cestari veröffentlichte die verantwortungsvolle Offenlegung auf Delving Bitcoin; beide Fehler wurden in Eclair #3324 behoben und im Juli in v0.14.1 veröffentlicht, wer eine ältere Version nutzt, sollte aktualisieren. Die erste, gefunden von Matt Morehouse mit seinem Smite-Fuzzer, ist eine Race Condition in der Prüfung doppelter temporary_channel_id: Eclair prüfte die ID, bevor der neue Kanal erfasst war, sodass schnelle identische open_channel-Nachrichten zwei an der Prüfung vorbeibrachten; der unerreichbare Kanalzustand belegte rund 25 kB bis zur Trennung — bei Wiederholung rund 1 MB pro Sekunde. Die zweite, von Cestari gefunden, umging Eclairs Grenze für unbestätigte offene Kanäle, indem die endgültige channel_id eines Kanals als nächste temporary_channel_id wiederverwendet wurde; mit einem einzelnen Feature-Bit an hoher Position, das jede Kopie auf rund 65 kB aufblähte, erschöpfte eine Verbindung einen 4-GB-Knoten in etwa 48 Minuten, und da offene Kanäle in die Datenbank geschrieben werden, stürzte der Knoten bei jedem Neustart erneut ab. Mobile Wallets, die einen Eclair-Knoten als LSP nutzen (etwa Phoenix), sind laut Morehouse nicht betroffen, weil ACINQ seine Knoten vor Monaten gepatcht hat.
LN-GAP: Offchain-Verträge im Kanal. Adam Gibson stellte auf der Bitcoin-Dev-Liste einen Vorschlag vor, komplexe, mehrrundige Zwei-Parteien-Verträge innerhalb eines Lightning-Kanals auszuführen und Streit onchain in einer konstanten Zahl von Transaktionen zu klären, mit einem Schachspiel als Beispiel (Repository und Paper liegen vor). Da Lightning keine Regeln durchsetzen kann, wenn eine Gegenpartei verstummt, fügt LN-GAP eine Venue hinzu — ein Gremium, das nur bezeugt, ob eine signierte Nachricht vor einer Frist veröffentlicht wurde, und nie Gelder hält — mit Ein-Bit-Signaturen je Mitglied, geprüft über OP_CHECKSIGADD, und Gebühren über Kanäle via Adaptoren. Es beruht auf einer Mehrheitsannahme: Kolludiert mehr als die Hälfte der Venue mit einer Partei, können Gelder gestohlen werden. (Der Newsletter ist der Verweis; dieser Punkt wird auf dem Analyse-Tisch vertieft.)
Releases und bemerkenswerte Änderungen. Bitcoin Core 32.0rc4 ist ein Release Candidate der nächsten Hauptversion. Der Newsletter listet zudem Korrekturen quer durch den Lightning-Stack, darunter mehrere Eclair-PRs zur Absicherung der Onchain-HTLC-Durchsetzung beim Splicing (#3396, #3397, #3400) und beim On-the-fly-Funding (#3399, #3394), einen LDK-Fix für HTLCs beim kooperativen Schließen (#5080) und einen LDK-Datenschutzfix für Onion-Nachrichten (#5087), eine LND-Prüfung für Hilfssignaturen von HTLCs auf Taproot-Assets-Kanälen (#11068), einen Rust-Bitcoin-Typ ScriptCode für die BIP143-Signaturberechnung (#6956) und einen BDK-Reorg-Fix (#2319).
Quelle: Bitcoin Optech, „Newsletter #427“ — https://bitcoinops.org/en/newsletters/2026/10/16