Ein Lightning-Kanal hat zwei Guthaben, deren Summe durch die Kanalkapazität begrenzt ist. Nutzbares lokales Guthaben bildet ausgehende Liquidität, nutzbares entferntes Guthaben eingehende Liquidität. Reserven, Gebühren der Commitment-Transaktion, ausstehende HTLCs, Kanalregeln und die nutzbare Kapazität jedes Wegabschnitts bestimmen, ob ein bestimmter Betrag eine Route tatsächlich durchlaufen kann.
Kanalkapazität ist das im Finanzierungsoutput gebundene Bitcoin-Guthaben. Liquidität ist nur der derzeit in einer Richtung nutzbare Anteil. Ein Kanal mit 1.000.000 sats Kapazität kann daher fast alles auf einer Seite halten und eine große Zahlung in Gegenrichtung nicht übertragen. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Ausgehende Liquidität ist der Betrag, den der lokale Knoten nach Abzug von Protokollreserven, Gebührenpflichten der Commitment-Transaktion und ausstehenden HTLCs durch den Kanal senden kann. Sie sinkt bei ausgehenden Zahlungen oder Weiterleitungen und steigt, wenn Wert vom Gegenüber eintrifft. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Eingehende Liquidität ist der Betrag, den das Gegenüber zum lokalen Knoten senden kann. Sie ist für den Empfang über diesen Kanal erforderlich, entsteht aber nicht durch Änderung einer Zahlungsanforderung. Sie muss im entfernten Guthaben vorhanden sein oder durch eine Maßnahme zur Liquiditätssteuerung bereitgestellt werden. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Eine geroutete Zahlung gelingt nur, wenn jeder gewählte Abschnitt genügend nutzbare Liquidität in der richtigen Richtung hat und den HTLC gemäß Gebührenregeln, Mindest- und Höchstbeträgen sowie CLTV-Zeitgrenze akzeptiert. Ein erschöpfter Kanal kann eine sonst gut verbundene Route blockieren. [BOLT #2 — Peer Protocol for Channel Management] [BOLT #7 — P2P Node and Channel Discovery]
channel_reserve_satoshis, Gebühren der Commitment-Transaktion, anchor outputs, Dust-Regeln, max_htlc_value_in_flight_msat, max_accepted_htlcs und bereits ausstehende HTLCs können den für eine neue Zahlung verfügbaren Betrag verringern. Wallet-Guthaben, Kanalkapazität und sofort routbarer Betrag sind deshalb drei verschiedene Größen. [BOLT #2 — Peer Protocol for Channel Management]
BOLT #7 ermöglicht die Bekanntgabe eines Kanals und seiner Weiterleitungsregeln. Seine Kapazität lässt sich aus dem auf der Blockchain identifizierten Finanzierungsoutput ermitteln; die private Guthabenaufteilung wird dadurch nicht offengelegt. Der Sender schätzt eine Route anhand eigener Informationen, früherer Ergebnisse und Zahlungsversuche. Ein öffentlicher Explorer kann nicht bestätigen, dass eine gewählte Route genau jetzt einen bestimmten Betrag überträgt. [BOLT #7 — P2P Node and Channel Discovery]
Eine abgewickelte Zahlung verschiebt Guthaben in jedem verwendeten Kanal: Auf der sendenden Seite sinkt ausgehende und steigt eingehende Liquidität, am anderen Ende umgekehrt. Die Zahlung verteilt vorhandene Kapazität neu, ohne die Gesamtkapazität zu erhöhen. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Ein weiterleitender Knoten braucht für denselben HTLC eingehende Liquidität in einem Kanal und ausgehende im nächsten. Eine hohe Gesamtsumme an sats reicht nicht, wenn sie in den falschen Kanälen oder auf den falschen Seiten liegt. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Empfangene Zahlungen, kreisförmiger Ausgleich, Öffnen oder Schließen von Kanälen, Swaps und Splicing können Liquidität verschieben. Sie unterscheiden sich bei Gebühren, Spuren auf der Blockchain, Zeitbedarf, Vertrauen in Gegenparteien und Ausfallrisiko; keine Methode erzeugt kostenlose Liquidität. Eine mehrteilige Zahlung kann Routen kombinieren, benötigt aber weiterhin genügend gesamte Kapazität in der jeweiligen Richtung. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Managing Liquidity]
Prüfen Sie am eigenen Knoten lokale und entfernte Guthaben jedes Kanals, Reserven, ausstehende HTLCs und Gebührenpuffer. Testen Sie danach den beabsichtigten Betrag. Notieren Sie Richtung, Höhe, Zeitpunkt und Implementierung: Liquidität ändert sich nach jeder Zahlung und ist kein dauerhafter Gesamtwert für das Netzwerk. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity] [Lightning Labs — Managing Liquidity]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Lightning Network, Payment Channel, Lightning Routing, Inbound Liquidity, Bitcoin, HTLC. Auf diesen Eintrag verweisen außerdem Payment Channel, Lightning Routing, Volatilität, Marktkapitalisierung.