Im Lightning Network konstruiert gewöhnlich der Sender die Route. Aus dem öffentlichen Gossip-Graphen, Empfängerdaten und eigenen Ergebnissen schätzt er einen Pfad zum Ziel; Betrag, Gebühr und CLTV werden pro Hop rückwärts berechnet, die Anweisungen in ein Onion-Paket verpackt und nach einem Fehler wird ein anderer Pfad versucht. Weil der öffentliche Graph keine aktuellen Saldoverteilungen zeigt, ist Routing eine Wahrscheinlichkeitsentscheidung mit unvollständigen, schnell veränderlichen Informationen.
Routing beginnt beim Zahler: Wallet oder Node wählt einen Kandidatenpfad und weist jedem Vermittler den nächsten Channel zu. Der Empfänger liefert Identität, Features und eventuell Route Hints oder Blinded Paths; den öffentlichen Teil berechnet meist der Sender.
BOLT #7 verbreitet Announcements und gerichtete Channel Updates mit Basisgebühr, proportionaler Gebühr, CLTV-Delta, Minima, Maxima und Verfügbarkeit. Sie beschreiben Policy und Topologie, beweisen aber weder Online-Status noch aktuelle Liquidität.
Öffentliches Gossip zeigt die Saldoverteilung nicht. Router kombinieren bekannte lokale Liquidität, Kapazität, frühere Erfolge und Fehler, Strafen und eigenes Scoring. Der billigste theoretische Pfad ist nicht zwingend der wahrscheinlichste.
Beträge und Expiries werden vom Payee zum Payer rückwärts aufgebaut. Jeder Hop erhält den Folgebetrag plus eigene Fee und ein um sein Delta höheres CLTV; mehr Hops erhöhen Gesamtgebühr und Zeitsperrenmarge.
BOLT #4 nutzt Onion Routing: Der Payer erstellt ein Sphinx-Paket mit getrennt verschlüsseltem Payload je Hop. Vermittler kennen Nachbarn und eigene Anweisung, nicht aber ganzen Pfad, Länge oder Position; Verkehrsanalyse und Kollusion bleiben Risiken.
Temporäre Channel-Fehler, zu geringe Fee, falsches CLTV oder ein unbekannter Next Peer liefern ein begrenztes Fehlersignal. Die Implementierung kann bestrafen, neu berechnen und wiederholen; ein Ergebnis beschreibt den Channel nicht dauerhaft.
Jeder Hop muss den HTLC annehmen und nach Reserven, Pending HTLCs sowie Mindest- und Höchstgrenzen genug gerichtete Liquidität haben. Hohe Gesamtkapazität oder viele Verbindungen beseitigen keinen schlecht balancierten Engpass.
Bei Basic MPP verteilt der Payer total_msat auf mehrere Pfade, die der Empfänger gemeinsam erfüllt. MPP nutzt verteilte Liquidität, fügt aber HTLCs, Versuche und Gebühren hinzu und erzeugt keine Kapazität.
BOLT-11-Route-Hints können letzte private Hops zeigen; BOLT 12 und Route Blinding liefern ein verschlüsseltes Ende über einen Introduction Point. Der Payer muss den ersten bekannten Punkt dennoch erreichen und aggregierte Gebühren sowie CLTV einhalten.
Dokumentieren Sie Implementierung, Version, Betrag, Gebühren- und CLTV-Limit, Versuche, Pfade, Dauer und exakten Fehler. Vergleichen Sie dasselbe Node-Paar zeitnah: Erfolg gilt für eine konkrete Zahlung und Netzlage, nicht als globaler Dauerwert. Quellen: BOLT #4 — Onion Routing Protocol; BOLT #7 — P2P Node and Channel Discovery; BOLT #11 — Lightning Payment Encoding; Lightning Labs — Pathfinding; LDK — Routing and Route Parameters.
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.