lnd 0.21.4 eröffnet keine Lightning-Kanäle des alten Commitment-Typs mehr

Victoria Shinder03 October 2026, 13:002 Min. Lesezeit

Lightning Labs hat am 1. Oktober lnd 0.21.4-beta veröffentlicht, dazu 0.20.5-beta für die Vorgängerlinie. Datenbankmigrationen enthält das Release nicht, und die Notes nennen eine inkompatible Änderung, die Node-Betreiber vor dem Update verstehen sollten.

Keine neuen Legacy-Kanäle mehr. lnd eröffnet und akzeptiert keine neuen Kanäle des alten Commitment-Typs mehr, der 2024 aus der Lightning-Spezifikation entfernt wurde. Die Notes erklären, warum das zählt: In diesem Format ist der to_remote-Ausgang verändert („tweaked“), sodass ein Node nach Datenverlust die Mittel eines solchen Kanals nicht allein zurückholen kann, sondern den passenden Commitment-Punkt vom Peer braucht. Außerdem beschreiben sie eine Lücke, die nun geschlossen wird. Ein leerer channel_type in einer open_channel-Nachricht verlangt genau diesen alten Typ, und lnd akzeptierte das bisher ohne jede Prüfung der Features – ein Peer konnte also einen Legacy-Kanal bekommen, egal was beide Seiten signalisiert hatten. Neue Kanäle fallen jetzt auf den Static-Remote-Key-Typ zurück, und der RPC OpenChannel lehnt commitment_type LEGACY ab. Bestehende Legacy-Kanäle sind nicht betroffen: Sie lassen sich weiter nutzen, zwangsweise oder kooperativ schließen.

Korrekturen, die man kennen sollte.

• Ein Fehler, der HTLCs beim Übergang eines Kanals zwischen Lebenszyklusphasen hängen lassen konnte – mit möglichen unnötigen Zwangsschließungen und On-Chain-Gebühren –, ist behoben.
• Der Interceptor für weitergeleitete HTLCs gleicht Wiederholungen vom eingehenden Link nach der Freigabe einer Weiterleitung nun ab, sodass eine Wiederholung nicht mehr als zweite Abfangung gilt, solange das ursprüngliche ausgehende HTLC aktiv ist.
• Scheitert die Rekonstruktion eines AMP-Zahlungssatzes, werden nur dessen HTLCs storniert. Bisher wurde die ganze Rechnung storniert, was wiederverwendbare statische AMP-Rechnungen unbrauchbar machte.
• Peers beantworten jetzt jeden gültigen eingehenden Ping, wie BOLT 1 es verlangt; das bestehende Flood-Limit bleibt die Grenze für den Verbindungsabbau.
• Die Dekodierung nach BOLT 11 lehnt Rechnungen mit mehr als einem Payment-Hash-Feld ab. Die Notes weisen darauf hin, dass das strenger ist als der aktuelle BOLT-11-Text, der das erste Feld zu verwenden empfiehlt – Wallets, die solche Rechnungen erzeugen, werden also abgewiesen.
• Die Migration auf den nativen SQL-Graphspeicher scheitert nicht mehr an alten Kanaldatensätzen mit leeren Features.

Für Wallet-Entwickler gibt es eine Ergänzung: Output-Leases im WalletKit-RPC können nun aktiv bleiben, bis die ausgebende Transaktion eine gewählte Zahl von Bestätigungen erreicht, statt nach einer Zeit abzulaufen.

Was das bedeutet

Die Änderung bei Legacy-Kanälen ist die, die man prüfen sollte. Wer auf Peers oder Software setzt, die Kanäle mit leerem channel_type öffnen, bekommt nun Static-Remote-Key-Kanäle – die sicherere Voreinstellung für die Wiederherstellung nach Datenverlust. Wallet-Entwickler sollten außerdem prüfen, dass ihre Rechnungen nie zwei Payment-Hashes enthalten.