Lightning Async Payments

Moderne mobile Betriebssysteme wie Android und iOS verschärfen dieses Problem, da sie die CPU-Zeit für Hintergrundanwendungen massiv einschränken. Sofern eine App nicht zu privilegierten Kategorien wie VoIP gehört, wird ihr im Standby kaum Rechenleistung zugestanden. Eine mobile Wallet kann daher oft nicht „aufwachen“, um einen eingehenden HTLC selbstständig zu claimen. 

Die Magie der „statischen Rechnung“ ohne Hash

Ein zentraler Baustein der Async Payments sind BOLT 12 Rechnungen, die im Oktober 2025 in die Spezifikation aufgenommen wurden. Diese Rechnungen verzichten bewusst auf einen Payment-Hash. Das Fehlen des Hashes dient dem Sender als Signal: Der Empfänger nutzt einen Lightning Service Provider (LSP) und ist vermutlich offline, weshalb der „Async Flow“ eingeleitet werden muss.

Technisch gesehen ist dieser Verzicht eine kritische Sicherheitsmaßnahme. Er verhindert, dass ein böswilliger LSP dieselbe Rechnung mehrfach verwendet („Double-Use“), um Zahlungen abzufangen. Zudem nutzt BOLT 12 sogenannte „Blinded Paths“, um die Identität des Empfängers gegenüber dem Intermediär zu schützen, während der Onion Payload sicherstellt, dass der Empfänger die Zahlung später verifizieren kann.

Der LSP als vertrauensloser „Briefkasten“

In diesem neuen Protokoll fungiert der LSP als Vermittler, der jedoch niemals die Kontrolle über die Gelder erlangt. Der Clou: Nicht nur der Empfänger, sondern auch der Sender profitiert von neuer Freiheit.

1. Der Sender sperrt die Mittel (HTLC) mit einer langen Laufzeit bei seinem eigenen LSP.
2. Er sendet eine Onion Message an den LSP des Empfängers.
3. Sobald diese Nachricht übermittelt ist, kann der Sender sofort offline gehen – die Zahlung ist im System „eingeloggt“.

Wichtig ist die Abgrenzung zu „Custodial Services“: Der LSP ist kein Treuhänder. Da er das Preimage nicht kennt, kann er das Geld nicht stehlen. Er hält lediglich die verschlüsselte Nachricht in einem virtuellen Briefkasten, bis der Empfänger sich wieder verbindet.

Trampoline Routing als Kapazitäts-Retter

Bisherige Versuche für Offline-Zahlungen scheiterten oft an der massiven Blockierung von Netzwerkliquidität. Async Payments lösen dies durch „Trampoline Routing“. Hierbei wird die Zahlung an einen Trampoline-Knoten delegiert, der die Pfadfindung übernimmt. Das entscheidende Detail für die Netzwerkeffizienz: Die Upstream-Route wird normal gesettelt; lediglich auf dem „Last Hop“ (beim LSP des Empfängers) bleibt das Kapital gesperrt.

Dieses Verhalten ist deutlich „sozialer“ gegenüber dem restlichen Netzwerk, da es Kanäle auf den Zwischenstationen nicht unnötig verstopft.

Trotz der technischen Eleganz unterliegen Async Payments physikalischen Grenzen durch das CLTV-Timeout (Expiry). Jede Lightning-Zahlung hat ein Ablaufdatum, das in Bitcoin-Blöcken gemessen wird.

In der Praxis bedeutet dies: Bleibt der Empfänger zu lange offline, läuft die Zeitspanne der gesperrten HTLCs ab. Während die Theorie oft von Tagen spricht, liegt das reale Zeitfenster bei typischen CLTV-Deltas von 40 bis 144 Blöcken aktuell eher bei 7 bis 24 Stunden. Erscheint der Empfänger innerhalb dieser Frist nicht online, wird die Zahlung an den Sender zurückgebucht.

Die Entwicklung von Async Payments, vorangetrieben durch das Lightning Development Kit (LDK v0.7.0+), markiert das Ende der „Always-on“-Pflicht. Dennoch bleibt eine Herausforderung: der „Specification Gap“. Während LDK bereits produktiv nutzbare Features liefert, ist die zugrundeliegende Standardisierung im BOLT-Protokoll (PR #1149) noch in der Abstimmungsphase. Dies bedeutet, dass die Interoperabilität zwischen verschiedenen Wallets aktuell noch eingeschränkt ist.