Lightning Routing bedeutet, einen Weg für eine Zahlung durch das Lightning-Netzwerk zu finden und zu nutzen. Dieser Weg besteht aus Zahlungskanälen: Deren Teilnehmer sperren gemeinsam Mittel in Bitcoin und aktualisieren, welcher Anteil jeweils wem gehört. Programme, sogenannte Nodes, verwalten diese Kanäle. Der Sender plant die Route meist anhand öffentlicher Informationen, Angaben des Empfängers und früherer Versuche. Da er nicht alle aktuellen Guthaben kennt, muss er die Nutzbarkeit eines Weges abschätzen und manchmal einen anderen ausprobieren.
Anna möchte einen Kaffee bezahlen, hat aber keinen Kanal mit dem Café. Sie hat einen mit Pavel, der wiederum einen Kanal mit dem Café betreibt. Die Zahlung kann deshalb über ihn laufen: Im ersten Kanal verschiebt sich Guthaben von Anna zu Pavel, im zweiten von Pavel zum Café. Dabei wandert nicht dieselbe Münze von Kanal zu Kanal; vielmehr ändern sich die Guthaben in miteinander verknüpften Schritten. Pavel braucht daher eigene verfügbare Mittel auf der Seite, von der aus er das Café bezahlt. Wallet oder Node des Senders wählt den Weg zum Empfänger und bereitet Anweisungen für jeden Schritt vor. Der Empfänger liefert benötigte Daten und unterstützte Funktionen, gegebenenfalls auch Angaben zu einem privaten Schlussabschnitt. Die Nodes unterwegs leiten entsprechend weiter. Sie suchen nicht jeweils selbst den gesamten Weg zum Ziel. [1] [4]
Gossip bezeichnet den Informationsaustausch zwischen Nodes. BOLT #7 beschreibt Kanalankündigungen und gerichtete Aktualisierungen: Grund- und anteilige Gebühr, CLTV-Ablaufdifferenz, Mindest- und Höchstbetrag sowie Verfügbarkeitskennzeichen. Die veröffentlichten Bedingungen beweisen weder, dass der Nachbar gerade online ist, noch dass genügend Mittel verfügbar sind. CLTV bezeichnet hier eine Frist, die als Bitcoin-Blockhöhe, also als Position eines Blocks in der Kette, angegeben wird, nicht als genaue Uhrzeit. Der Abstand zwischen den Fristen gibt einem Vermittler Zeit zu reagieren, falls die Weiterleitung stockt. [2]
Die Gesamtkapazität eines Kanals zeigt nicht, wie viel jede Seite gerade senden kann. Der Sender kennt seine eigenen Kanäle; andernorts verwendet er Schätzungen und frühere Erfolge und Fehler. Software bewertet deshalb Gebühren und Erfolgswahrscheinlichkeit. Eine andere Zahlung kann inzwischen die Liquidität verändern, also die in der benötigten Richtung versendbaren Mittel. [4] [5]
Die Schritte sind durch HTLCs verknüpft, also bedingte Zahlungen: Ihr Abschluss erfordert die Offenlegung des zugehörigen Geheimnisses. Bleibt eine Zahlung unvollendet, lassen sich die Mittel nach Ablauf ihrer Frist zurückfordern. Die Berechnung beginnt beim Betrag für den Empfänger und geht zurück. Jeder Vermittler benötigt den Betrag für den nächsten Node plus seine Gebühr. Sein eingehender HTLC muss gemäß der geforderten CLTV-Differenz ausreichend später ablaufen als der ausgehende. Eine längere Route kann dadurch Kosten und die Bindungsdauer der Mittel bei Problemen erhöhen. [1] [2]
Onion Routing nach BOLT #4 verwendet die Sphinx-Konstruktion: Jeder Schritt erhält separat verschlüsselte Anweisungen. Ein Vermittler kennt seinen vorherigen und nächsten Partner sowie die eigenen Anweisungen. Das Paket allein verrät weder die ganze Route noch ihre Länge oder seine genaue Position. Verkehrsanalyse oder Zusammenarbeit mehrerer Nodes können die Privatsphäre dennoch schwächen. [1]
Ein Kanal kann vorübergehend ausfallen, die Gebühr zu niedrig, das CLTV falsch oder der nächste Partner unerreichbar beziehungsweise unbekannt sein. Der Sender erhält nur begrenzte Fehlerinformationen. Seine Software kann eine Route schlechter bewerten, neu berechnen und erneut versuchen. Das ist keine Geldstrafe an einen Node; ein Ergebnis ist auch kein dauerhaftes Zuverlässigkeitsurteil. [1] [4]
Verbindungen allein reichen nicht: Jeder Schritt muss den HTLC annehmen und in der benötigten Richtung genügend verfügbare Mittel haben. Ein Teil des Guthabens kann als Reserve oder in noch nicht abgeschlossenen Zahlungen gebunden sein. Die technischen Felder htlc_minimum_msat und htlc_maximum_msat legen außerdem den Mindest- und Höchstbetrag eines einzelnen HTLC in dieser Richtung fest. Die Einheit msat entspricht einem Tausendstel Satoshi; ein Satoshi ist die kleinste Werteinheit auf der Bitcoin-Blockchain. Auch ein hohes veröffentlichtes Limit beweist nicht, dass die benötigte Liquidität gerade verfügbar ist. Ein einziger ungeeigneter Kanal kann deshalb die gesamte Route blockieren. [2]
Unterstützt der Empfänger basic MPP, also eine in mehrere Teile aufgeteilte Zahlung, kann der Sender den im Protokoll als total_msat bezeichneten Gesamtbetrag auf mehrere Wege verteilen. Der Empfänger wartet auf die nötigen Teile und rechnet sie gemeinsam ab. So lässt sich verteilte Liquidität nutzen, neue Liquidität entsteht durch MPP aber nicht. Es kommen HTLCs, Versuche und möglicherweise Gebühren hinzu. [1]
Route Hints in BOLT #11 können Angaben zu den letzten unangekündigten Schritten liefern. Route Blinding in BOLT #12 stellt stattdessen einen verschlüsselten Schlussabschnitt über einen Einstiegsknoten, den Introduction Point, bereit. Der Sender muss diesen Punkt weiterhin erreichen und die zusammengefassten Gebühren- und CLTV-Bedingungen erfüllen. Mehr Privatsphäre garantiert keine Zustellung. [3] [6] [1]
Beim gewöhnlichen Bezahlen übernimmt die Wallet die Wegsuche. Die folgenden Angaben helfen vor allem Node-Betreibern und bei der Untersuchung wiederkehrender Probleme. Dokumentieren Sie Software und Version, Betrag, maximale Gebühr und CLTV-Limit, Anzahl der Versuche, verwendete Wege, Abschlussdauer und genaue Fehlerursache. Vergleichen Sie dasselbe Node-Paar zu ähnlichen Zeitpunkten. Erfolg beschreibt eine bestimmte Zahlung bei einem bestimmten Netzzustand, keinen dauerhaften globalen Wert. [4] [5]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Lightning Network, HTLC, Lightning-Liquidität, Payment Channel, Bitcoin, Inbound Liquidity. Auf diesen Eintrag verweisen außerdem HTLC, Lightning-Liquidität, BOLT 12, Inbound Liquidity.