Die Lightning-Fehlerbehebungen dieser Woche haben eine Form: ein Knoten, der einer ungeprüften Angabe vertraut
Victoria Shinder2 Min. LesezeitLiest man den Bitcoin-Optech-Newsletter vom 23. Oktober als Liste von Patches, ist es eine fade Woche aus Punktreleases. Liest man ihn nach der Form der Fehler, ist es eine Lektion, viermal erzählt: Ein Lightning-Knoten verlor Gelder oder hätte sie verlieren können, weil er nach einem von der Gegenseite gelieferten Wert handelte, ohne diesen gegen etwas zu prüfen, das er selbst kontrolliert.
Nehmen wir die Eclair-Splicing-Korrektur. Beim Splicen eines einfachen Taproot-Kanals darf ein Peer nur Betrag und Skript des vorherigen Outputs eines Inputs liefern statt der ganzen Transaktion. Eclair vertraute diesen beiden Feldern. Ein Peer konnte bei beiden lügen und Eclair dazu bringen, einen Splice zu signieren, der nie bestätigt werden kann — weil eine Taproot-Signatur sich auf die echten Beträge und Skripte der verausgabten Inputs festlegt —, während Eclair diesen ungültigen Splice als jüngsten Funding-Zustand behandelte. Von dort konnte der Peer eine ältere Commitment veröffentlichen und ein ausgehendes HTLC einfordern, nachdem Eclairs eingehendes abgelaufen war. Die Korrektur ist ein einziger Grundsatz: Prüfe die behaupteten Outputs gegen dein eigenes Bitcoin-Backend, bevor du signierst. Aus dem vertrauten Feld wird ein geprüftes Feld.
Die Trampolin-Routing-Korrektur ist dieselbe Krankheit in einem anderen Organ. Eclair lockerte seine Grenzen für Routenlänge und Ablauf, wenn die Pfadsuche scheiterte, was einem Zahler erlaubte, verdeckte Pfade mit übermäßigen Ablaufdeltas zu liefern, die Ordnung zu brechen, die sichert, dass das ausgehende HTLC vor dem eingehenden abläuft, und Gelder on-chain zurückzuholen. Die Korrektur lockert das Ablauflimit nicht mehr — sie vertraut der Geometrie des Zahlers nicht mehr. Und die BOLT11-Änderung ist die reinste Form: Eine Rechnung muss nun genau einen Zahlungshash und ein Zahlungsgeheimnis tragen, denn ein Parser, der still den ersten wählte, während ein Knoten den letzten nahm, ließ einen Angreifer beide auf verschiedene Hashes zeigen und Doppelzahlungen kassieren — ein Exploit, der tatsächlich gegen einen Bot gefahren wurde. Die Mehrdeutigkeit war die Schwachstelle; die Wahl zu entfernen entfernt sie.
Dass dieses Muster gerade in Lightning wiederkehrt, ist strukturell, nicht nachlässig. Lightning ist ein Protokoll, um mit Menschen zu handeln, denen man nicht vertraut, über Kanäle, deren aktuellen Zustand nur die beiden Parteien halten, und jede Optimierung, die einen Peer weniger senden lässt — ein Betrag statt der vollen Transaktion, ein Routing-Hinweis statt eines validierten Pfades —, ist eine Einladung, über den nicht gesendeten Teil zu lügen. Die technische Antwort ist nicht abstrakt "weniger vertrauen"; es ist die konkrete Disziplin dieser Korrekturen: Ein Wert, den eine Gegenseite wählen kann, muss gegen einen geprüft werden, den sie nicht wählen kann — die Kette, eine festgelegte Signatur, ein Backend, das man selbst betreibt. Jede Korrektur dieser Woche ist diese Regel, angewandt auf eine Stelle, an der sie übersprungen war. Die noch übersprungenen sind der Newsletter der nächsten Woche.