Ein LSP ist Gegenpartei und Dienstleister, kein Teil des Bitcoin-Konsenses; der Client kann seine Schlüssel selbst halten, muss aber Preis, Verfügbarkeit, Kanalbedingungen und das konkrete Trust Model des verwendeten LSPS-Protokolls prüfen.
Ein Lightning Service Provider setzt eigene oder beschaffte Liquidität für Clients ein. Meist öffnet er einen Kanal zu einer Non-custodial Wallet für Inbound Capacity oder verbindet On-chain- und Off-chain-Mittel per Swap; er berechnet Blockspace, Kapital, Betrieb und Risiko. [1]
Die Kapazität eines Lightning-Kanals ist fest und auf Local und Remote Balance verteilt. Eine neue Wallet ohne Kanal kann daher nicht allein durch eine Invoice empfangen; ein LSP liefert Inbound Liquidity, ohne dass der Nutzer Peer, UTXO und Parameter der Funding Transaction manuell wählen muss. [1]
LSPS0, nun bLIP 50, vereinheitlicht die Client-LSP-Kommunikation als JSON-RPC 2.0 über Lightning BOLT8 Peer-to-Peer-Transport. Jede LSPS-Nachricht nutzt Message ID 37913, und lsps0.list_protocols meldet die exakt unterstützten Erweiterungen; die Bezeichnung LSP garantiert also nicht jeden Dienst. [2]
LSPS1, also bLIP 51, standardisiert die direkte Kanalbestellung. Der Client liest das Angebot, erstellt eine Order, prüft Kapazität, Preis und Ablauf und zahlt On-chain oder per Lightning; laut Spezifikation ist der Kauf nicht atomar und der Client vertraut auf Lieferung des Kanals oder die vorgeschriebene Refund. [3]
LSPS2, also bLIP 52, behandelt einen Just-in-time Channel. Der Client erhält Parameter und setzt einen Route Hint mit Request-ID in die Invoice; erreicht die Zahlung den LSP, öffnet er einen Zero-confirmation Channel, zieht die Opening Fee ab und leitet den Rest weiter. Der Client muss dann verbunden sein. [4]
Ein Non-custodial LSP hält nicht die Private Keys des Clients und lässt ihm seine Kanalseite, dennoch bleibt betriebliche Abhängigkeit. Der Anbieter sieht die direkte Verbindung und einen Teil des Payment Flow, kann Liquidität ablehnen, Preise im Angebot ändern oder offline sein; Zero-confirmation Channel und vorausbezahlte Order haben verschiedene Risiken. [1]
Die Standards LSPS0, LSPS1 und LSPS2 wechselten aus dem ursprünglichen Repository in den bLIP-Prozess als aktive bLIP 50, 51 und 52. Die Referenzbibliothek lightning-liquidity implementiert LSPS1- und LSPS2-Client-Handler sowie einen LSPS2-Service-Handler, doch eine Wallet oder Node kann nur eine Teilmenge zu eigenen Bedingungen unterstützen. [5]
Vor Nutzung sind Node ID und Connection String des LSP, das Resultat von lsps0.list_protocols, genaue Kapazität und Balance-Aufteilung, Fee, Ablauf, Confirmations und Refund Policy zu prüfen. Danach müssen Funding Transaction, Channel State und reale Inbound Capacity stimmen; Logo oder erstellte Invoice beweisen das nicht. [2]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Lightning Network, Inbound Liquidity, Payment Channel, Submarine Swap, BOLT 11, Lightning Address. Auf diesen Eintrag verweisen außerdem Just-in-Time Channels, Trampoline Routing, Bitlifi.
01Ist ein Lightning Service Provider automatisch custodial?+
Nein. Ein LSP kann einen Kanal zu einer Wallet mit eigenen Schlüsseln öffnen und nur seine Kanalseite verwalten. Der Client hängt dennoch von Verfügbarkeit, Liquiditätsangebot und Erfüllung der Bestellung ab.
02Kann ein LSP die erste Zahlung ohne bestehenden Kanal empfangen?+
Ja, wenn Wallet und Anbieter LSPS2 unterstützen und die Zahlung die Opening Fee deckt. Der LSP öffnet beim Eingang einen JIT Channel und zieht die Gebühr ab; Inbound Capacity ist weder kostenlos noch bedingungslos.