Bitcoin Optech Newsletter Nr. 430

Der Newsletter dieser Woche fasst die anhaltende Diskussion über die Verwendung von TCP-Hole-Punching zusammen, um Knoten hinter Heimroutern erreichbar zu machen, und beschreibt einen Entwurf eines BIP zur Standardisierung der Ausgaberichtlinien, die Mitunterzeichner bei der Emulation von Covenants durchsetzen. Ebenfalls enthalten sind unsere regelmäßigen Rubriken, in denen Vorschläge und Diskussionen zur Änderung der Konsensregeln von Bitcoin zusammengefasst, neue Versionen und Release-Kandidaten angekündigt sowie bemerkenswerte Änderungen an beliebter Bitcoin-Infrastruktursoftware beschrieben werden.

Nachrichten

● Fortgesetzte Diskussion über TCP-Hole-Punching für Heimknoten: Im Anschluss an

unsere Zusammenfassung vom Mai zum „Delving Bitcoin“-Thread von 0xB10C über die Verwendung von Hole Punching, damit Knoten hinter Heimroutern Verbindungen untereinander akzeptieren können, teilte 0xB10C mit, dass die Arbeit an einer Spezifikation und einer experimentellen Bitcoin-Core-Implementierung wieder aufgenommen wurde. Heimknoten können in der Regel nur ausgehende Verbindungen herstellen, und die standardmäßige Aktivierung der NAT-PMP-Portzuordnung in Bitcoin Core 30.0 führte nicht dazu, dass deutlich mehr von ihnen wie erhofft erreichbar wurden. „Hole Punching“, bei dem zwei Heimknoten gleichzeitig Verbindungen zueinander herstellen, sodass jeder Router den Datenverkehr des anderen durchlässt, wäre eine „Best-Effort“-Ergänzung zur Portweiterleitung. Mehr erreichbare ehrliche Knoten würden es Angreifern, deren Knoten leichter zu erreichen sind, erschweren, die Slots für ausgehende Verbindungen eines Knotens zu füllen.

0xB10C fasste die vier bisher diskutierten Entwürfe zusammen und schlug eine neue Option vor, die keinen Koordinator benötigt: Ein Knoten gibt seine „punchable“ Adresse und einen temporären öffentlichen Schlüssel in einem neuen addr v2-Typ bekannt, und jedes Knotenpaar leitet aus seinem gemeinsamen Geheimnis und jedem neuen Block dieselbe Kandidatenliste und denselben „Punch“-Zeitpunkt ab. Als Reaktion auf Anthony Towns’ Einwand, dass ein Angreifer das System mit echten Adressen überfluten könnte, und nachdem er später feststellte, dass unerreichbare Knoten solche Ankündigungen weitaus weniger zuverlässig empfangen als lauschende Knoten, skizzierte er eine „Message-Board“- Alternative, bei der lauschende Knoten die verifizierten Adressen von Heimat- Knoten speichern, die nach einem Peer suchen.

Towns stellte in Frage, ob zufällige eingehende Verbindungen den Heimatknoten überhaupt helfen, und argumentierte, dass „Hole Punching“ es einem Angreifer erleichtert, ehrliche Knoten direkt zu erreichen, während es kaum dazu beiträgt, eine Verbindung zu einem ehrlichen Knoten zu gewährleisten. Er schätzte, dass ein Angreifer, der etwa 10.000 Adressen ankündigt, für die meisten ehrlichen Knoten schon früh als Übereinstimmung identifiziert würde, und schlug kurzlebige Verbindungen zu zufälligen Peers als risikoärmere Alternative vor. Jonathan Harvey-Buschel führte Daten an, die zeigen, dass ehrliche Knoten schwerer erreichbar sind als von Angreifern kontrollierte, und sprach sich für eine Koordination über den eigenen Tor-Dienst eines Knotens aus. Towns fragte später, ob die jüngsten TCP- und Protokollschwachstellen dazu führen, dass das Nichtakzeptieren eingehender Verbindungen die sicherere Standardeinstellung für Privatanwender sei. Die Diskussion dauert an.

● BIP-Entwurf für standardisierte Ausgaberichtlinien für Mitunterzeichner: Luke Carriere

veröffentlichte auf „Delving Bitcoin“ seinen Vorschlag zur Standardisierung der Ausgaberichtlinien, die von Mitunterzeichnern bei der Emulation von Covenants durchgesetzt werden. Mehrere aktuelle Entwürfe, darunter Johan Halseths Blinded Co-Signers und die Chain Code-Delegation, definieren jeweils ihre eigenen Richtlinien, sodass eine Wallet, die für das eine Konzept entwickelt wurde, keinen Mitunterzeichner oder kein Orakel verwenden kann, das für ein anderes Konzept entwickelt wurde. Carriere beantragt keine BIP-Nummer für den Entwurf und fragte, ob dies die richtige Ebene für eine Standardisierung sei.

Der Entwurf folgt mehreren Designprinzipien:

Alles, was durch Bitcoin-Skript durchgesetzt werden kann, muss dort durchgesetzt werden, wobei die Richtlinien für Mitunterzeichner nur das definieren, was das Skript nicht leisten kann.

Es muss immer mindestens ein Ausgabepfad verfügbar sein,

der keinen Mitunterzeichner benötigt.

Wie ein Mitunterzeichner eine Ausgabe verifiziert und was seine Ehrlichkeit gewährleistet, sind

einstellbare Profile, die je nach Richtlinie ausgewählt werden.

Mitunterzeichner müssen Orakel-Bescheinigungen im

DLC-Format akzeptieren, damit bereits verfügbare Orakel ohne Änderungen wiederverwendet werden können.

Eine Richtlinie besteht aus fünf Teilen. Der Output definiert den Taproot-Deskriptor, der die Mittel enthält; die Mitunterzeichner-Gruppe Gruppe gibt an, welche Mitunterzeichner beteiligt sind und wie viele unterschreiben müssen, Vorlagen listen die Transaktionen auf, die die Mitunterzeichner mit ihren genauen Ausgängen unterschreiben dürfen, Bedingungen legen fest, was erfüllt sein muss, bevor jede Vorlage unterschrieben werden kann, und Profile benennen den Verifizierungsmodus, die Nachweisformate und etwaige Rechenschaftssysteme. Einige Punkte sind noch offen, beispielsweise ob JSON oder TLV für die Serialisierung verwendet werden soll, ob eine „Blinded Verification“ bereits jetzt festgelegt werden sollte oder ob man weitere Erfahrungen mit der Implementierung abwarten sollte, ob das Format für die Bescheinigung von Aussagen im Vorschlag oder in den DLC-Spezifikationen festgelegt werden soll und ob der Fallback-Pfad zeitlich gesperrt sein muss.

In der anschließenden Diskussion wies PREDGE darauf hin, dass einem der Nachweisprofile, genannt `statement-v0`, kein Finalitätsflag aufweist, was bedeutet, dass ein Mitunterzeichner auf eine vorläufige Bescheinigung reagieren könnte, die später korrigiert wird. Darüber hinaus erklärte tehiyadu, dass der Policy-Hash sich an die exakte Semantik des Verifizierers halten sollte, um zu verhindern, dass verschiedene Implementierungen dieselben Bytes akzeptieren, während sie unterschiedliche Bedingungen durchsetzen. Carriere stimmte beiden Punkten zu und sagte, er werde ein Finalitäts-Flag hinzufügen und die Verifizierer-Regeln festlegen.

Änderung des Konsensverfahrens

*Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zur Änderung der Konsensregeln von Bitcoin zusammenfasst.*

● Fortsetzung der Diskussion zu BIP54: Antoine Riard veröffentlichte auf

der Bitcoin-Dev-Mailingliste seine Sichtweise zum Stand des „Consensus Cleanup“-Soft-Forks (BIP54). Das Verbot von Transaktionen, deren Größe ohne Witness genau 64 Bytes beträgt, ist nach wie vor die umstrittenste Regel. Eine Bitcoin-Core-Implementierung wird derzeit geprüft und getestet und ist die Referenzimplementierung, auf die im BIP verwiesen wird (Bitcoin Core #35793). Der PR aktiviert die neuen Regeln im regtest-Modus, ohne dass eine Aktivierung im Mainnet erfolgt. Er wies außerdem auf Interoperabilitätsarbeiten in btcd (btcd #2537) hin und erklärte, ihm sei keine libbitcoin-Implementierung bekannt. Seiner Ansicht nach sind nun weitere Überprüfungen und Tests sowie eine Dokumentation erforderlich, damit Wallets über die vorgeschlagene Begrenzung auf 2.500 Signaturvorgänge im Pre-Segwit-Skript und über die 64-Byte-Regel informiert sind – und erst später die Aktivierungslogik. Er sprach nur für sich selbst und hielt es für realistisch, in der zweiten Hälfte des Jahres 2027 über eine Aktivierung nachzudenken, sofern sich die Community bis dahin darauf einigt.

Pieter Wuille aktualisierte seinen „Delving Bitcoin“-Thread darüber, wie die beiden BIP54-Zeitstempelregeln die Kettenlänge begrenzen (siehe Newsletter Nr. 425). Der oberste Beitrag enthält nun die genaue Formel für die Untergrenze der Arbeit, und sowohl diese Formel als auch die dezimale Näherung sind nun im verlinkten Lean-Code bewiesen.

Riard ging auf einen Einwand ein, der während der Entwicklung von BIP54 vorgebracht wurde: dass die Behebung des Time-Warp-Fehlers eine Konsensänderung im Stil von Mark Friedenbachs Forward Blocks für den Rest der zukünftigen Geschichte von Bitcoin unmöglich machen würde. Da die Korrektur die Manipulation von Zeitstempeln lediglich einschränkt, anstatt sie zu beseitigen, könnte ein weitaus begrenzterer Vorschlag für „Forward Blocks“ dennoch umgesetzt werden. Er schätzte, dass das durch die Korrektur weiterhin zulässige 7.200-Sekunden-Fenster die Schwierigkeit pro Retarget-Periode um etwa 0,60 % senken und die Blockrate um etwa denselben Betrag erhöhen könnte – was weit hinter der Kapazitätssteigerung des ursprünglichen Vorschlags zurückbleibt. Riard argumentierte zudem, dass die Idee selbst unter den alten Regeln unhaltbar sei: Validatoren würden Transaktionen einmal in der Forward-Chain und erneut bei der Synchronisierung mit der Kompatibilitätskette verarbeiten – und zwar gegen dieselben Gebühren, es sei denn, die Nutzer würden doppelt zahlen; außerdem müssten Knoten, die kein Upgrade durchgeführt hätten, weiterhin die zusätzlichen Daten herunterladen. Riard wird eine kurze Fußnote zu BIP54 vorschlagen, in der er diese Argumente darlegt, und Friedenbach um Gegenargumente bitten.

Prototyp für einen Opt-in-Replay-Schutz : Sjors Provoost knüpfte an den „Delving Bitcoin“-Thread über einen Opt-in- Replay-Schutz für eine Kettenteilung (siehe Newsletter Nr. 420 ) mit einem Prototyp an, der eine neue Witness-Version verwendet. Ein Anhang , dessen Nutzdaten mit dem Byte 0x01 beginnen, benennt einen Block anhand einer 4-Byte-Höhe, und jede Signatur auf diesem Input verpflichtet sich zum Hash des Blocks auf der gewünschten Kette. Der Hash selbst ist in der Transaktion nicht enthalten. Er bezifferte die zusätzlichen Kosten auf 1,75 vBytes. Der benannte Block muss mindestens 100 Blöcke alt sein, was dem Zeithorizont der Coinbase-Fälligkeit entspricht. Er erklärte, dass bei einer gleichmäßigen Aufteilung der Hashrate die Wartezeit bis zur Aufteilung der Coins im schlimmsten Fall zwei Tage betragen würde, da die Regel nur auf einer Seite gelten muss. Er schlug vor, die Witness-Version zusammen mit einem anderen Vorschlag zu veröffentlichen, der eine solche benötigt, wie beispielsweise CISA (BIP460), BIP360 oder einen Output im P2TRv2-Stil

mit einem Keypath, der später deaktiviert werden kann.

Anthony Towns entgegnete, dass eine neue Witness-Version unnötig sei und dass eine neue Public-Key-Kodierung für eine Taproot-Signaturprüfung im Stil von BIP118 ausreichen würde. Provoost antwortete, dass er diese Kodierung in Betracht gezogen habe und sie für einen „Hack“ halte; nach seinem Verständnis würde sie bei einer Keypath-Ausgabe nicht funktionieren.

Moonsettler stellte in Frage, ob die Forderung nach 100 Blöcken in der Spaltung, in der diese Funktion am wichtigsten wäre, wünschenswert sei, und schlug vor, diese Verzögerung als Richtlinienregel beizubehalten, die gelockert werden könnte. Provoost antwortete, dass, sobald Coins auf die schnellere Seite wechseln und Bestätigungen sammeln, die langsamere Seite den Schutz nicht mehr benötige. Provoost schrieb außerdem, dass er davon ausgeht, dass die Regel vor einer umstrittenen Hard Fork eingeführt wird, sodass beide Seiten sie übernehmen und keine der beiden Seiten sie einfach wieder aufheben kann: Der Block-Hash befindet sich nur in der Signaturnachricht, daher bedeutet das Entfernen der Regel eine Änderung der Transaktionsserialisierung, um den Hash zu übertragen.

● QSAVE für nicht migrierte Coins: James Tagg veröffentlichte auf der

Bitcoin-Dev-Mailingliste fünf BIP-Entwürfe für QSAVE (Quantum Secure Asset Verification and Escrow), einen postquanten Übergang, bei dem keine Coins verbrannt werden . Er beschrieb diese als Alternative zu BIP361 und zu Hourglass. Aus Sicht der Durchsetzung, die jederzeit als Soft Fork aktiviert werden könnte, würde jeder Input, der nicht in einem Verzeichnis bekannter postquanten sicherer Typen aufgeführt ist, als nicht migriert behandelt werden, einschließlich unbekannter und zukünftiger Skripttypen. Ein nicht migrierter Input müsste weiterhin seinem Sperrskript entsprechen und zudem einen zweiten Faktor erfüllen: entweder einen Zero-Knowledge-Proof, dass ein Seed sowohl das Ausgabeskript als auch einen postquanten Schlüssel ableitet, oder eine vor einem Stichtag festgelegte postquanten Bindung. Fehlt bei einem nicht migrierten Input in einer Transaktion dieser zweite Faktor, muss jede ausgabebare Ausgabe eine Wiederherstellungsausgabe sein. In QSAVE gibt es keine Auslaufphase, daher führt ein fehlender zweiter Faktor nicht zur Vernichtung der Coin. Ein On-Chain-Nachweis kann sie jederzeit direkt ausgeben, ohne dass ein Dritter erforderlich ist. Ansonsten beschrieb er einen Off-Chain-Prozess für verlorene Vermögenswerte, dessen rechtliche und wirtschaftliche Behandlung er außerhalb des Konsenses ansiedelte, bei dem eine Gruppe dezentraler Verwahrer die Wiederherstellungs-Outputs verwahren würde, mit einem Backup-Verwahrer und einem Veto-Kontrolleur, und die Gelder könnten eine konservative Rendite von 0,5 % erzielen, die an wohltätige Zwecke geht. Die Entwürfe spezifizieren außerdem Pre-Cutoff-Wasserzeichen, einen optionalen ML-DSA-87-Schlüssel, den er QD5 nannte, sowie ein zk-STARK-Ausgabeblatt für BIP360 (P2MR)- Ausgänge.

● Proof-of-Decay für nicht migrierte Ausgänge: bitKingAE

veröffentlichte auf Delving Bitcoin einen Entwurf zur Reduzierung von postquantenanfälligen Ausgängen, wie beispielsweise frühen P2PK- Coins, die innerhalb einer Karenzfrist nicht bewegt werden. Nach Ablauf der Karenzfrist würde der Wert des Ausgangs entsprechend der Blockhöhe planmäßig sinken. Die verlorenen Satoshis würden verbrannt oder als Mining-Belohnungen ausgezahlt, anstatt dass die Coins eingefroren oder demjenigen überlassen würden, der eine Signatur vorweisen kann. Das Beispiel im Beitrag sah einen kleinen Prozentsatz des Guthabens alle 50.000 Blöcke vor. Vinicius Cestari erwiderte mit drei Einwänden: Ein Quantenangreifer kann warten, bis die Karenzzeit endet, und exponierte Ausgänge abräumen, bevor der Wertverlust nennenswert ist; eine plötzliche Verbesserung bei Quantenangriffen könnte diese sogar noch früher leeren; und der Zeitplan verringert den Kontostand eines passiven Besitzers, einschließlich eines, dessen Schlüssel bereits gestohlen wurden.

● BIP300-Bundle-Zensur: Ori Newman argumentierte auf der

Bitcoin-Dev-Mailingliste, dass ein Miner mit 26 % der Hashrate ein gültiges Auszahlungs-Bundle im Drivechains-Vorschlag (BIP300) auf unbestimmte Zeit zensieren kann. Er schrieb, dass, wenn der Miner mit 26 % in jedem von ihm geschürften Block einen ALARM sendet, jeder dieser Blöcke die Punktzahl jedes ausstehenden Bundles um 1 senkt. Wenn die anderen 74 % der Hashrate in jedem Block für ein Bündel stimmen, würde dessen erwartete Punktzahl am Ende des 26.300-Block- Fensters bei 12.624 liegen und damit unter den erforderlichen 13.150. Er schlug vor, „ALARM“ und jegliche anderen Downvotes zu verbieten, was die Annahme einer ehrlichen Mehrheit wiederherstellen würde: Ein Bundle, das von 51 % der Hashrate unterstützt wird, würde mit ziemlicher Sicherheit angenommen, und eines, das von 49 % unterstützt wird, würde mit ziemlicher Sicherheit abgelehnt. Falls die aktuelle Regel beabsichtigt ist, forderte er, dass der BIP stattdessen eine Annahme einer ehrlichen Mehrheit von 75 % festlegt. Er bezeichnete dies als starke Abweichung vom Sicherheitsmodell von Bitcoin und sagte, ein Argument dafür sei, dass es für einen Angreifer mit weniger als 75 % der Hashrate schwieriger wäre, Gelder zu stehlen.

Veröffentlichungen und Release-Kandidaten

*Neue Versionen und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf die neuen Versionen oder helfen Sie beim Testen der Release-Kandidaten.*

● LND v0.21.6-beta und v0.20.7-beta sind Sicherheits-

Veröffentlichungen für die Zweige 0.21 und 0.20 dieser beliebten LN-Knoten- Implementierung. Beide enthalten die Abhilfe für die Linux-Kernel- Sicherheitslücke CVE-2026-98432, die weiter unten unter LND #11456 beschrieben wird. Linux- Betreiber sollten ein Upgrade durchführen, MPTCP auf dem Host deaktivieren, um andere Dienste zu schützen, und einen gepatchten Kernel installieren, da die LND- Abhilfemaßnahme die zugrunde liegende Sicherheitslücke nicht behebt.

● Core Lightning 26.06.10 ist eine Sicherheitsversion dieser beliebten LN-Knoten-

Implementierung. Sie behebt Sicherheitslücken in den Bereichen Dual Funding, Splicing, On-Chain-HTLC-Auflösung, Zugriffskontrollen und anderen Komponenten. Der Quellcode für die Sicherheitskorrekturen ist verfügbar, während die zugehörigen Tests vorübergehend zurückgehalten werden, um den Nutzern mehr Zeit für das Upgrade zu geben. Das Projekt empfiehlt dringend ein Upgrade.

● BTCPay Server 2.4.7 ist ein Sicherheitsupdate für diesen selbst gehosteten Zahlungsabwickler . Es behebt 85 Sicherheitsprobleme, die vom OSS-Scanner-Programm von Anthropic gemeldet wurden OSS-Scanner-Programms von Anthropic gemeldet wurden, darunter Probleme im Zusammenhang mit Auszahlungslimits, dem Zugriff auf Daten anderer Shops, der Authentifizierung und der Ressourcenerschöpfung. Außerdem werden Probleme bei der Zahlungsabrechnung und der Zuverlässigkeit behoben. Ein Update wird dringend empfohlen, insbesondere für Server, die von mehreren Händlern gemeinsam genutzt werden.

Wichtige Änderungen am Code und in der Dokumentation

*Bemerkenswerte aktuelle Änderungen in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition und BINANAs.*

● Bitcoin Core #36539 stellt das PSBTv0-Format für nicht signierte Transaktionen

und Gebührenerhöhungen wieder her, die aus der GUI exportiert wurden. Bitcoin Core 32.1 exportierte diese PSBTs unter Verwendung von Version 2, wodurch Nutzer daran gehindert wurden, sie mit Tools zu signieren, die nur Version 0 unterstützen. Der separate Workflow für externe Signierer, der mit `-signer` (siehe Newsletter Nr. 138) konfiguriert wurde, verwendet weiterhin PSBTv2, sodass diese Nutzer einen externen Signierer benötigen, der dies unterstützt, wie beispielsweise HWI 2.1.0 oder höher.

● Bitcoin Core #35714 behebt einen Fehler, bei dem der Knoten seinen Blockindex

und seine UTXO-Datenbank aktualisieren konnte, nachdem das Schreiben von Block- oder Undo-Daten auf die Festplatte fehlgeschlagen war. Obwohl der Fehler den Knoten zum Herunterfahren veranlasste, konnte der Code, der diese Schreibvorgänge verarbeitete, die Datenbanken noch aktualisieren, bevor der Knoten stoppte. Wenn diese Aktualisierungen erfolgreich waren, konnten die Datenbanken einen Zustand aufzeichnen, für den die zugehörigen Block- oder Undo-Daten noch nicht sicher gespeichert worden waren. Dies könnte den lokalen Zustand des Knotens inkonsistent machen und die Wiederherstellung erschweren. Der Code überspringt nun diese Datenbank-Schreibvorgänge während des fehlgeschlagenen Flush-Versuchs. Dies ergänzt frühere Schutzmaßnahmen zur Flush-Reihenfolge für optionale Indizes, die im Newsletter Nr. 414 behandelt wurden.

● Bitcoin Core #35492 behebt einen Fehler, bei dem `bitcoin-wallet dump` (siehe

Newsletter Nr. 130) nach dem Schreiben eines unvollständigen Wallet-Exports einen Erfolg melden konnte. Bisher prüfte der Befehl, ob er die Zieldatei öffnen konnte, erkannte jedoch nachfolgende Schreibfehler nicht, wie z. B. mangelnden Speicherplatz. Folglich konnten Nutzer fälschlicherweise annehmen, dass der Export abgeschlossen war, nur um beim Versuch, die Wallet wiederherzustellen, fehlende Daten festzustellen. Nun überprüft der Befehl das Schreiben, das Flushen und das Schließen der Datei. Er meldet Fehler und entfernt unvollständige Dump-Dateien.

● Die BIPs #2205, #2210 und #2212 fügen drei Entwürfe

für Spezifikationen zur Signaturaggregation über mehrere Eingaben hinweg hinzu. BIP458 spezifiziert die nicht-interaktive Halbaggregation, bei der `n` bestehende BIP-340-Signaturen zu `32 × (n + 1)` Bytes anstelle von `64 × n` Bytes. BIP459 spezifiziert DahLIAS, ein interaktives Protokoll, das eine einzige 64-Byte-Aggregatsignatur für mehrere Schlüssel und Nachrichten erzeugt. BIP460 schlägt vor, diese Verfahren für Keypath-Ausgaben von neuen Witness-Version-2- Ausgängen, wobei individuelle Signaturen für „Scriptpath“-Ausgaben beibehalten werden und „Keypath“-Eingaben die Möglichkeit haben, sich davon auszuschließen. Seit der Berichterstattung über den Vorschlag im Newsletter Nr. 417 wurden die ausgeschlossenen Eingaben so geändert, dass sie gewöhnliche BIP341-Signaturen ohne spezielle Markierung verwenden, wodurch Wallets den neuen Ausgabetyp übernehmen und gleichzeitig ihre bestehende Signaturlogik weiterverwenden können. Dies würde das Transaktionsgewicht und die Gebühren für Transaktionen mit mehreren beteiligten Eingaben reduzieren, einschließlich Coinjoins und Payjoins . Die Einführung der vorgeschlagenen Transaktionsaggregation würde einen Soft Fork erfordern. BIP460 lässt den Aktivierungsmechanismus und die Parameter offen.

● Core Lightning #9419 fügt ein optionales `failure_reason` Feld zum

`listforwards` RPC und `forward_event` Benachrichtigungen für lokal fehlgeschlagene Weiterleitungsversuche hinzu. Bisher wurde für mehrere unterschiedliche Probleme derselbe Protokollfehlercode verwendet, was es für Betreiber schwierig machte, festzustellen, warum die Weiterleitung fehlgeschlagen war. Das neue Feld unterscheidet zwischen Ursachen wie unzureichender ausgehender Liquidität, einem offline befindlichen ausgehenden Peer und Beschränkungen hinsichtlich der Anzahl oder des Gesamtwerts ausstehender HTLCs.

● Core Lightning #9592 aktualisiert `xpay` (siehe Newsletter Nr. 330)

, um einen Weiterleitungsknoten für den Rest einer Zahlung zu meiden, nachdem dieser zweimal eine Rückmeldung `unknown_next_peer`. Bisher schloss jeder Fehler nur den gemeldeten Kanal aus, sodass bei aufeinanderfolgenden Versuchen weiterhin andere Kanäle über denselben Knoten ausgewählt werden konnten, bis die Wiederholungszeit der Zahlung abgelaufen war. Nach dem zweiten Fehler desselben Knotens `xpay` wird dieser über die private `askrene` Routing-Ebene der Zahlung ausgeschlossen. Diese Heuristik kann zwar nutzbare Kanäle ausschließen, schränkt jedoch wiederholte Versuche über denselben Knoten ein.

● LDK #5089 aktualisiert die Gebührenerhöhung bei erzwungenen Schließungen von Kanälen mit

Anker-Ausgängen. Wenn LDK die erforderlichen Mittel für eine CPFP-Untertransaktion, die einen Anker- Ausgang ausgibt, nicht beschaffen kann, sendet es nun nur die Commitment-Transaktion. Zuvor konnte dieser Fehler dazu führen, dass beide Transaktionen ungesendet blieben, was die Wiederherstellung der Kanalmittel verzögerte. Die Commitment-Transaktion enthält bereits eine Gebühr, die möglicherweise noch für die Bestätigung ausreicht, wenn die Gebührenschätzung konservativ war oder die Netzwerknachfrage sinkt. Dieser Fallback schließt jedoch Commitment-Transaktionen ohne Gebühr aus, die eine gebührenpflichtige untergeordnete Transaktion zur Weiterleitung erfordern. Das Problem wurde von Project Loupe gemeldet.

● LND #11456 deaktiviert Multipath-TCP-Listener (MPTCP) standardmäßig, um

CVE-2026-98432 zu beheben, eine Schwachstelle im Linux-Kernel, bei der die Ausführung von Remote-Code mithilfe von MPTCP demonstriert wurde. Go 1.24 und höher aktivieren diese Listener standardmäßig auf unterstützten Linux-Systemen, was LND-Betreiber gefährden könnte, selbst wenn sie MPTCP nicht explizit konfigurieren. Die Änderung legt `multipathtcp=0` in den Go-Standardwerten von LND. Dies blockiert den nachgewiesenen Exploit-Pfad über die LND-Listener, behebt jedoch nicht den zugrundeliegenden Kernel-Fehler. Betroffene Systeme benötigen weiterhin einen gepatchten Kernel. Betreiber, die bestehende Binärdateien verwenden, können die gleiche Abhilfemaßnahme anwenden, indem sie LND mit der Umgebungsvariablen `GODEBUG=multipathtcp=0`.

● LND #11357 verschärft die BOLT11-Rechnungsvalidierung gemäß BOLTs

#1357 (siehe Newsletter #428). Anstatt das erste zu verwenden und den Rest zu ignorieren, werden nun doppelte Zahlungsgeheimnisfelder abgelehnt, wodurch Mehrdeutigkeiten zwischen Parsern verhindert werden, die unterschiedliche Vorkommen auswählen. Dies baut auf der früheren Ablehnung doppelter Zahlungs-Hashes auf (siehe Newsletter Nr. 425). Durch die mit der Spezifikationsaktualisierung hinzugefügten Tests wurde zudem festgestellt, dass bestehende Anforderungen nicht durchgesetzt wurden. Der Decoder lehnt nun falsche Längen beim Parsen des Zahlungs-Hashes, des Beschreibungs-Hashes, des Zahlungsgeheimnisses und des öffentlichen Schlüssels des Empfängers ab, anstatt diese Felder als fehlend zu behandeln. Zuvor konnte ein Feld für den öffentlichen Schlüssel des Empfängers mit falscher Länge dazu führen, dass LND darauf zurückgriff, den Schlüssel aus der Signatur wiederherzustellen. Für Rechnungen, die einen expliziten öffentlichen Schlüssel des Empfängers enthalten, ist zudem eine ECDSA-Signatur mit niedrigem S-Wert erforderlich. Diese Einschränkung gilt jedoch nicht, wenn der öffentliche Schlüssel aus der Signatur wiederhergestellt wird (siehe Newsletter Nr. 381).

● LND #11413 beschleunigt die Bereinigung gespeicherter Ergebnisse ausgehender Zahlungen

beim Systemstart auf Knoten, die SQLite oder PostgreSQL verwenden. Im Normalbetrieb sammelt der Knoten für jeden abgewickelten, lokal initiierten HTLC-Versuch ein Ergebnis. Beim Systemstart entfernt er Ergebnisse, die nicht mehr benötigt werden. Bisher erforderte das individuelle Lesen und Löschen von Einträgen wiederholte Datenbank-Roundtrips, wodurch die Bereinigung auf einem stark ausgelasteten Knoten mit einem entfernten PostgreSQL-Server Stunden dauern konnte. Nun werden die Datenbankoperationen gebündelt, während die Ergebnisse beibehalten werden, die zur Wiederaufnahme ausstehender Zahlungen benötigt werden.

● LND #11151 fügt Prüfungen auf überhöhte Commitment-Gebühren und unzureichende

Anfangsguthaben bei der Annahme eingehender Kanäle hinzu. LND lehnt nun einen vorgeschlagenen Gebührensatz ab, der über dem höheren der folgenden Werte liegt: dem Zehnfachen seiner Schätzung für drei Blöcke oder 100 sat/vbyte. Außerdem setzt es die BOLT2-Regel zur Anfangsreserve durch und lehnt Kanäle separat ab, bei denen das Anfangsguthaben keiner der Parteien die Reserve übersteigt, die diese Partei vorhalten muss. Obwohl der Initiator die Commitment-Gebühr zahlt, kann eine überhöhte Gebühr sein nutzbares Guthaben aufbrauchen, wodurch die Kapazität des Empfängers für ausstehende Kanäle während der Eröffnung verschwendet wird und ein unbrauchbarer Kanal zurückbleibt, sobald die Finanzierungstransaktion bestätigt ist. Dies ergänzt die in Newsletter Nr. 429 behandelten Prüfungen der Mindestgebührensätze.

● Rust Bitcoin #7067 erweitert die Taproot-Signatur-Hash-

(sighash)-Helfer, sodass sie einen optionalen Anhang akzeptieren und bei Scriptpath-Ausgaben die Opcode-Position des letzten OP_CODESEPARATOR, der vor der Signaturprüfung ausgeführt wurde. Beides wirkt sich auf die Nachricht aus, auf die sich eine Signatur bezieht. Bisher gingen diese Komfortfunktionen davon aus, dass kein Anhang vorhanden und kein `OP_CODESEPARATOR`, sodass Aufrufer, die solche Ausgaben verarbeiten, die allgemeinere Sighash-Funktion verwenden mussten, um die Erzeugung eines falschen Digests zu vermeiden. Die Hilfsfunktionen akzeptieren diese Werte nun direkt, obwohl Aufrufer weiterhin die Position des Trennzeichens ermitteln müssen. Aufrufer, die Ausgaben ohne Anhang oder ohne ausgeführten `OP_CODESEPARATOR` , können `None` für die neuen Argumente übergeben, um das bisherige Verhalten beizubehalten. Siehe Newsletter Nr. 427 für zugehörige Änderungen an der `sighash`-API für Legacy- und SegWit-v0- Ausgaben.