Zum Inhalt springen

Lightning-Dienstanbieter

Aus BitcoinWiki

Ein Lightning Service Provider (LSP; deutsch etwa „Lightning-Dienstanbieter“) ist ein Betreiber, der Nutzern des Lightning Network Kanalliquidität und Konnektivität bereitstellt. Ein LSP betreibt normalerweise einen oder mehrere Lightning-Knoten und öffnet oder verwaltet Zahlungskanäle für Kunden, die nicht jeden betrieblichen Schritt selbst ausführen. Der Begriff bezeichnet eine Dienstleistungsrolle, nicht das Lightning-Protokoll oder eine bestimmte Knotenimplementierung.[1]

LSPs sind häufig in Wallets integriert, doch LSP und Wallet müssen nicht dieselbe Stelle sein. Eine selbstverwahrende Wallet kann einen LSP nutzen, während der Nutzer die Schlüssel für seine Kanalseite behält. Auch eine verwahrende Wallet oder ein Zahlungsabwickler kann Lightning-Zugang anbieten; bei diesem Modell kontrolliert der Anbieter jedoch die Kundenguthaben. Die Bezeichnung LSP allein sagt deshalb nicht aus, ob ein Produkt verwahrend arbeitet.[2]

Rolle im Lightning Network

Lightning-Kanäle besitzen gerichtete Liquidität. Ein Nutzer kann nur das Guthaben auf seiner Kanalseite senden und nur dann empfangen, wenn auf der Gegenseite genügend Guthaben verfügbar ist. Eine neue Wallet kann daher Bitcoin besitzen, aber nicht über die zum Empfang einer Lightning-Zahlung nötige eingehende Liquidität verfügen.

Ein LSP kann dieses Problem lösen, indem er eigenes Kapital einem Kanal mit dem Kunden zuweist. Der Anbieter wird zum direkten Lightning-Peer des Kunden und stellt eingehende Kapazität bereit; Zahlungen benötigen weiterhin nutzbare Routen zwischen dem Anbieter und dem übrigen Netzwerk. Der Anbieter kann On-Chain-Finanzierungskosten, Kosten des gebundenen Kapitals und Betriebsausgaben über Kanalöffnungs-, Dienst- oder Routinggebühren decken. Ein LSP beseitigt die allgemeinen Liquiditäts- und Routingbeschränkungen des Lightning Network nicht.

LSPs sind von Lightning-Implementierungen zu unterscheiden. LND, Core Lightning, Eclair und das Lightning Development Kit sind Software zum Betrieb von Lightning-Knoten oder zum Bau von Wallets. Eine Organisation kann mit einer dieser Implementierungen einen LSP-Dienst anbieten, doch die Software selbst ist nicht zwangsläufig ein Dienstanbieter.

Dienstmodelle

Gekaufte Kanäle

Ein Kunde kann vor dem Empfang einer Zahlung einen Kanal kaufen. Die aktive LSPS1-Spezifikation, veröffentlicht als bLIP 51, definiert eine API, über die eine Wallet ein Angebot erhält, einen Auftrag erstellt und bezahlt und den LSP zur Kanaleröffnung auffordert. Die Spezifikation weist ausdrücklich darauf hin, dass der Kauf nicht atomar ist: Der Kunde muss darauf vertrauen, dass der Anbieter den zugesagten Kanal bereitstellt oder einen fehlgeschlagenen Auftrag erstattet.[3]

Just-in-time-Kanäle

Ein Just-in-time-Kanal (JIT-Kanal) wird als Reaktion auf eine eingehende Zahlung geöffnet. Bei LSPS2, veröffentlicht als bLIP 52, wird die Zahlung zum LSP geleitet. Dieser öffnet einen Kanal zum Empfänger und leitet die Zahlung nach Abzug der vereinbarten Eröffnungsgebühr weiter. Ein Kunde ohne bestehenden Kanal kann so Lightning-Zahlungen empfangen, ohne zuvor eingehende Kapazität zu kaufen.[4][5]

JIT-Kanäle können Zero-Confirmation-Verfahren nutzen, sodass die erste Zahlung möglicherweise zugestellt wird, bevor die Finanzierungstransaktion bestätigt ist. Dies beschleunigt die Einrichtung, schafft aber zusätzliche Vertrauens- und Finanzierungstransaktionsrisiken, die vom ausgehandelten Modell abhängen. Das LSPS2-Angebot enthält Gebührenobergrenzen, Gültigkeitszeiträume und eine zugesagte Mindestlebensdauer des Kanals.

Swaps und Liquiditätsverwaltung

Manche Anbieter tauschen On-Chain- und Off-Chain-Bitcoin mittels Submarine Swaps. Ein Swap kann ausgehende Liquidität hinzufügen, eingehende Liquidität freisetzen oder Mittel zwischen Lightning und der Bitcoin-Blockchain verschieben, ohne jeden betroffenen Kanal zu schließen. Diese Dienste lösen ein anderes Problem als der Kauf eines neuen Kanals und können unabhängig von einer LSP-Beziehung angeboten werden.

Auch Wallet-Server-Funktionen wie verschlüsselte Backups, Zahlungsbenachrichtigungen, wiederverwendbare Zahlungskennungen, Verwaltung gehosteter Knoten und Watchtower-Überwachung sind verwandte Dienste. Sie machen einen Betreiber allein noch nicht zum LSP, auch wenn ein Anbieter mehrere Funktionen bündeln kann.[6]

Interoperabilität

Frühe LSP-Integrationen nutzten häufig anbieterspezifische APIs. Die Lightning Service Provider Specifications wurden entwickelt, damit Wallets und Dienstanbieter gemeinsame Anfrage- und Antwortformate verwenden können. Im Januar 2025 wurde die Entwicklung aus dem ursprünglichen LSP-Spezifikationsrepository in den Prozess der Bitcoin Lightning Improvement Proposals überführt.[7]

Zu den aktiven Spezifikationen gehören:

  • LSPS0 / bLIP 50, eine Transport- und Erkennungsschicht, die JSON-RPC-Nachrichten über den Lightning-Peer-to-Peer-Transport übermittelt;[8]
  • LSPS1 / bLIP 51 für den direkten Kauf eines Kanals; und
  • LSPS2 / bLIP 52 zur Aushandlung eines JIT-Kanals bei Eingang einer Zahlung.

Die Unterstützung einer Spezifikation bedeutet nicht, dass jeder LSP-Dienst unterstützt wird. Wallets und Anbieter können außerdem proprietäre APIs oder andere Liquiditätsmechanismen verwenden.

Vertrauen, Datenschutz und betriebliche Abwägungen

Bei einer nichtverwahrenden Vereinbarung kontrolliert der Kunde die Schlüssel zum Ausgeben seines Kanalguthabens, während der LSP seine eigene Kanalseite kontrolliert. Dies unterscheidet sich von der Einzahlung von Bitcoin bei einem Verwahrer. Dennoch kann der Kunde davon abhängig sein, dass der Anbieter einen passend bemessenen Kanal öffnet, angebotene Bedingungen einhält, erreichbar bleibt, Zahlungen weiterleitet und den Kanal nicht früher als erwartet schließt. Die genauen Pflichten unterscheiden sich je nach Dienstprotokoll und Implementierung.

Der LSP ist zugleich der unmittelbare Netzwerk-Peer des Kunden. Er kann die Knotenverbindung des Kunden und Angaben zu weitergeleiteten Zahlungen beobachten, obwohl das Onion-Routing von Lightning gewöhnlich verhindert, dass ein Zwischenknoten eine vollständige Route kennt. Forschung zur Lightning-Privatsphäre zeigt, dass öffentliche Netzwerkinformationen und Routingverhalten eigentlich private Informationen offenlegen können. Daher garantieren weder Lightning noch ein LSP Anonymität.[9]

Ein Dienst kann die Kanalverwaltung vereinfachen, zugleich aber Konnektivität oder Liquidität bei wenigen Betreibern konzentrieren. Wallets, mit denen Nutzer den Anbieter wechseln, mehrere Anbieter verwenden oder Kanäle direkt verwalten können, verringern die Abhängigkeit von einem einzelnen Dienst.[6]

Gebühren und Zuverlässigkeit hängen vom Anbieter und den aktuellen Netzwerkbedingungen ab. Zusätzlich zu Lightning-Routinggebühren und den On-Chain-Kosten einer Kanalöffnung oder -schließung kann eine Dienstgebühr anfallen. Ein vom LSP bereitgestellter Kanal garantiert weder eine vollständige Route zu jedem Empfänger noch dauerhafte Verfügbarkeit.

Siehe auch

Einzelnachweise

  1. ↑ Lightning Service Provider, Lightning Labs Builder's Guide, accessed 3 September 2026.
  2. ↑ Lightning services, Bitcoin Design Guide, accessed 3 September 2026.
  3. ↑ bLIP 51: LSPS1 Channel Requests, Lightning specifications repository, accessed 3 September 2026.
  4. ↑ bLIP 52: LSPS2 JIT Channel Negotiation, Lightning specifications repository, accessed 3 September 2026.
  5. ↑ Just-In-Time channels, Bitcoin Optech, accessed 3 September 2026.
  6. ↑ 6,0 6,1 Lightning services, Bitcoin Design Guide, accessed 3 September 2026.
  7. ↑ Lightning Service Provider Spec repository, archived 10 January 2025; accessed 3 September 2026.
  8. ↑ bLIP 50: LSPS0 LSP Spec Transport Layer, Lightning specifications repository, accessed 3 September 2026.
  9. ↑ An Empirical Analysis of Privacy in the Lightning Network, H. Yousaf et al., Financial Cryptography and Data Security, 2021.
Abgerufen von „https://bitcoinwiki.org/de/index.php?title=Lightning-Dienstanbieter&oldid=4434“