Inbound Liquidity

Petr betreibt ein Café und nimmt Zahlungen im Lightning Network an. Sein Knoten, die Software für die Zahlungen, zeigt Guthaben an, trotzdem kann ein Kunde nicht bezahlen. Fehlende eingehende Liquidität kann der Grund sein. Ein Zahlungskanal ist eine Vereinbarung zweier Knoten über die Aufteilung hinterlegter Bitcoin. Petrs Anteil heißt local balance, der Anteil des Partners remote balance. Beim Empfang wechselt Wert von der Partnerseite zu Petr. Dafür muss auf der Partnerseite etwas zum Übertragen liegen. Die remote balance gehört weiterhin dem Partner: Empfangsmöglichkeiten zu erwerben ist weder ein Bitcoin-Geschenk noch bereits erzielter Umsatz. [1] [6]

Nehmen wir einen Kanal mit 1000000 sat Kapazität. Sat ist die Abkürzung von satoshi, einer kleinen Bitcoin-Einheit. Petr hat eine local balance von 800000 sat, sein Partner eine remote balance von 200000 sat. Der grobe Empfangsspielraum beträgt damit 200000 sat. Empfängt Petr 100000 sat, steigt seine Seite auf 900000 sat und dem Partner bleiben 100000 sat. Petr hat die Zahlung hinzugewonnen, aber sein weiterer Empfangsspielraum ist geschrumpft. Das Beispiel lässt Reserven, Gebühren und ausstehende HTLC-Zahlungen der Übersicht halber weg; diese werden unten erklärt. Finanziert Petr einen neuen Kanal allein, ohne anfängliche Übertragung an den Partner, erhält er vor allem Sendemöglichkeiten. Die Bestätigung der Kanaleröffnung kehrt diese Richtung nicht um. [1] [2]

An einem erfolgreichen Tag wächst das Geld auf Petrs Seite, während der Empfangsspielraum der verwendeten Kanäle abnimmt. Mehr Guthaben kann somit bedeuten, dass die nächste Zahlung schwerer ankommt. Bei eigener Infrastruktur gilt es, nutzbare Kanäle, erwartete Beträge, laufende Zahlungen und Kosten für neue Liquidität zu beobachten. Manche Wallets übernehmen einen Teil davon, am Mechanismus ändert das nichts. Petr bemerkt einen gescheiterten Versuch möglicherweise gar nicht, weil die Zahlung schon vor seinem Knoten scheitert. Eine ausgestellte Rechnung oder eine ältere Kapazitätsanzeige bestätigt keine Zahlung. [6]

Bezahlt Petr einen Lieferanten über Lightning, sinkt die local balance der verwendeten Kanäle und deren remote balance wächst. Das kann Platz für spätere Eingänge schaffen. Ähnlich funktioniert Loop Out: Über einen Swap, einen Tausch zwischen Zahlungsebenen, sendet er Wert aus Lightning und erhält Bitcoin an einer On-Chain-Adresse. Die Kanäle müssen dafür nicht geschlossen werden. Loop In geht umgekehrt vor und wandelt On-Chain-Mittel in ausgebbares Lightning-Guthaben um. Dabei entstehen keine neuen Bitcoin. Zum Vergleich des Ergebnisses gehören Routing-, Swap- und On-Chain-Gebühren sowie die Prüfung, ob der Vorgang tatsächlich abgeschlossen wurde. [1] [4]

Ein Partner kann auch einen Kanal zu Petr finanzieren. Petr gewinnt dadurch Empfangsspielraum, ohne das Geld des Partners geschenkt zu bekommen. Die Lightning Pool-Dokumentation beschreibt einen Markt solcher Vereinbarungen: bid bezeichnet die Nachfrage nach Liquidität, ask das Angebot. Die Laufzeit wird in Blöcken gemessen; hinzu kommen eine Prämie und weitere Gebühren. Ein Block ist eine Gruppe von Transaktionen, die zur Blockchain, Bitcoins öffentlicher Transaktionshistorie, hinzugefügt wird. Die Laufzeit richtet sich somit nach neuen Blöcken, nicht nach einer exakt festgelegten Stundenzahl. Der gesamte entfernte Saldo wird damit nicht gekauft. Auch bedeutet die Laufzeit nicht, dass stets derselbe Betrag empfangbar bleibt, denn Zahlungen ändern die Verteilung. Eine dauerhafte Verfügbarkeit nach Vertragsende darf ebenfalls nicht vorausgesetzt werden. [1] [5]

Petr kann mehrere Kanäle haben und den Spielraum gerade bei einem anderen Partner benötigen. Circular rebalancing, kreisförmiges Ausgleichen, schickt seine Zahlung über einen Kanal ins Netz und bringt sie über einen anderen eigenen Kanal zurück. Der sendende Kanal gewinnt Empfangsspielraum, der empfangende verbraucht ihn. Es wird Guthaben zwischen Petrs Kanalseiten verschoben, kein neues Kapital geschaffen; das Routing kostet Gebühren. Dafür braucht es eine nutzbare Route. Fehlen auf allen entfernten Seiten seiner Kanäle Mittel, kann die Zahlung nirgendwo zurückkommen. Kreisförmiges Ausgleichen allein löst das nicht. [1]

Ein Teil der Mittel muss als Reserve für einen sicheren Kanalbetrieb verbleiben. Weitere Mittel können vorübergehend durch HTLCs gebunden sein, bedingte Zahlungszusagen. Der Empfänger kann sie einlösen, indem er einen geheimen Wert offenlegt, aus dem sich der vereinbarte Zahlungshash, ein Prüfwert, berechnen lässt. Scheitert die Zahlung, hat die sendende Seite nach Fristablauf eine Möglichkeit, die Mittel zurückzuerhalten. BOLT 2, die Spezifikation zur Kanalverwaltung, begrenzt außerdem Mindestbetrag, Anzahl gleichzeitiger HTLCs und ihren Gesamtwert. Die volle remote balance steht daher nicht unbedingt für eine weitere Zahlung bereit. Alle entfernten Salden zu addieren und eine pauschale Reserve abzuziehen reicht nicht; die einzelnen Kanäle und ihr aktueller Zustand zählen. [2]

Eine Zahlung läuft meist über mehrere Knoten. Selbst wenn Petr Empfangsspielraum hat, kann ein früherer Streckenabschnitt offline sein oder zu wenig Mittel haben. BOLT 7 beschreibt channel_update-Nachrichten, mit denen Knoten Routingbedingungen für eine Kanalrichtung bekannt geben. Dazu zählen Gebühren und htlc_maximum_msat, die Obergrenze einer einzelnen bedingten Zahlung in msat, Tausendsteln eines satoshi. Das ist keine Zusage über aktuelle Guthaben entlang der gesamten Route. Auch die Summe von Petrs Empfangsspielraum garantiert daher nicht, dass jeder einzelne Sender ihm diesen Betrag zahlen kann. Empfangsliquidität ist ein notwendiger Teil der Lösung, nicht der einzige. [3]