LSPS2 beziehungsweise bLIP 52 handelt Parameter aus, setzt eine besondere Kennung in die Zahlungsdaten und löst beim Durchlauf über den LSP die Öffnung eines privaten Zero-confirmation Channels sowie die Weitergabe nach Abzug der Opening Fee aus.
Ein Just-in-Time Channel entsteht erst als Reaktion auf eine eingehende Zahlung aus dem öffentlichen Lightning Network über einen LSP. Der Empfänger braucht vorher weder Kanal noch Outbound Capacity oder On-chain-Mittel; die neue Inbound Liquidity wird aus der ersten empfangenen Zahlung bezahlt. [1]
Der Client ruft zuerst lsps2.get_info auf und erhält Angebote mit min_fee_msat, proportional Rate in ppm, valid_until, min_lifetime, max_client_to_self_delay und Payment-Size-Grenzen. Das gewählte Angebot mit dem vom LSP erzeugten promise sendet er in lsps2.buy; bei Ablauf, zu kleiner Zahlung oder fehlender Liquidität kann ein Fehler folgen. [2]
Ein erfolgreiches lsps2.buy liefert jit_channel_scid und lsp_cltv_expiry_delta. Der Client setzt LSP Node ID und diesen SCID als einzigen Hop des Route Hints in eine BOLT11 Invoice oder übermittelt dieselben Angaben künftig etwa als Blinded Path; die Expiry darf valid_until nicht überschreiten und der Client muss bei Eingang verbunden sein. [1]
Erkennt der LSP jit_channel_scid in einem eingehenden HTLC, startet er den normalen BOLT 2 Channel Establishment. Der Kanal muss payment_size_msat minus opening_fee plus Reserve tragen, bleibt unangekündigt, nutzt option_scid_alias und kann die Zahlung als Zero-confirmation Channel vor Bestätigung der Funding Transaction weiterleiten. [4]
LSPS2 beschreibt zwei Trust Models. Bei LSP trusts client veröffentlicht der Anbieter zuerst eine gültige Funding Transaction und riskiert, dass der Client das Preimage nicht freigibt; bei client trusts LSP darf er den Broadcast zurückhalten, während der Client das Preimage freigibt und auf einen gültigen Funding Outpoint vertraut. [3]
JIT ist keine bedingungslose Zustellung. Die Zahlung muss Opening Fee, Limits und Mindest-HTLC decken; eine Trennung vor funding_signed führt zu temporary_channel_failure, und ein naiver Prepayment Probe kann bei LSP trusts client einen Kanal öffnen, für den der LSP am Ende nicht bezahlt wird. [1]
bLIP 52 ist als aktive Spezifikation geführt und verlangt LSPS0 beziehungsweise bLIP 50 als Transport. Der Referenz-Crate lightning-liquidity bietet Client- und Service-Handler für LSPS2, nennt die Service-Seite aber beta; eine vorhandene API belegt daher keine Produktionsreife einer Wallet oder eines LSP. [5]
Die Prüfung beginnt mit lsps2.get_info und der exakten Rechnung max(min_fee_msat, proportional fee) sowie valid_until, promise, Payment Limits, min_lifetime und max_client_to_self_delay. Danach sind abgezogene Fee, Funding Outpoint, Kanalparameter, channel_ready, Alias und reale Inbound Capacity zu prüfen; die Invoice allein beweist keinen offenen Kanal. [1]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Lightning Service Provider, Inbound Liquidity, Payment Channel, Price Channel, BOLT 11, BOLT 12.
01Ist ein Just-in-Time Channel kostenlos?+
Nein. Der LSP zieht eine Opening Fee von der ersten eingehenden Zahlung ab. Der Client muss vorher Mindest- und Proportionalanteil, Zahlungsgrenzen und Gültigkeitsdauer des Angebots prüfen.
02Ist ein Just-in-Time Channel vor Zahlungseingang bereits on-chain bestätigt?+
Meist nicht. LSPS2 öffnet als Reaktion einen Zero-confirmation Channel; je nach Trust Model liegt die Funding Transaction nur im Mempool oder wartet noch auf Broadcast. Der Client muss Bestätigungsschwelle und LSP-Risiko bewusst wählen.