Core Lightning hielt einen betrügerischen Abschluss für kooperativ
Der Newsletter von Bitcoin Optech vom 25. September erklärt eine Korrektur in Core Lightning (CLN), einer der wichtigsten Knoten-Implementierungen des Lightning Network, die einem Kanalpartner einen Weg verschließt, ohne Strafe zu betrügen.
Lightning-Kanäle werden durch den Austausch neuer Commitment-Transaktionen aktualisiert; alte werden widerrufen. Sendet ein Partner eine widerrufene Commitment, kann die Gegenseite normalerweise eine Strafe einfordern, die das Guthaben des Betrügers nimmt. Laut Optech konnte CLN einen erzwungenen Abschluss jedoch als kooperativen behandeln, wenn alle Outputs an bereits bekannte Shutdown-Skripte zahlten. Ein Partner, der beim Öffnen des Kanals kein vorab festgelegtes Shutdown-Skript angegeben hatte, konnte in einer Shutdown-Nachricht das Output-Skript einer alten, widerrufenen Commitment nennen, den kooperativen Abschluss abbrechen und diese Commitment dann ohne Strafe senden. CLN erkennt Commitment-Transaktionen jetzt an Locktime und Sequence-Kodierung, bevor es prüft, ob die Outputs wie ein gemeinsamer Abschluss aussehen. Dieselbe Änderung startet die On-Chain-Überwachung nach bestimmten Reorganisationen neu und behebt mehrere Abstürze.
Die Korrektur kam mit v26.06.7 am 28. August unter einem zweiwöchigen Embargo; der Quellcode folgte am 11. September. Die Release-Notizen ergänzen eine betriebliche Warnung: Zwischen dem 28. August und dem 1. September meldeten Docker-Images mit den Tags v26.06.7 und latest beim Start die neue Version, enthielten die Korrekturen aber nicht, weil die CI sie von einem Platzhalter-Tag veröffentlicht hatte. Wer in dieser Zeit gezogen hat, sollte den Image-Digest mit der Tabelle in den Notizen vergleichen und neu ziehen. CLN 26.06.8 vom 22. September mit weiteren Sicherheitskorrekturen ist die Version, die das Projekt dringend empfiehlt; ihr Quellcode ist sofort verfügbar, einige Tests werden vorerst zurückgehalten.

Was das bedeutet
Das Sicherheitsmodell von Lightning beruht auf der Strafe für das Senden alter Zustände; lässt sich ein Knoten so täuschen, dass er eine widerrufene Commitment nicht erkennt, fällt die Abschreckung für diesen Kanal weg. Die Bedingung war eng - ein Partner ohne vorab festgelegtes Shutdown-Skript und ein Knoten mit älterer Version -, eine verwundbare Version heißt also nicht, dass jeder Kanal gefährdet war.
Die Docker-Episode ist die allgemeinere Lehre. Ein Versionsstring beweist nicht, welcher Code in einem Image steckt; der Digest tut es. Für Knotenbetreiber verhindert das Festlegen von Images per Digest statt per Tag genau diesen Fehler.