LSPS2, czyli bLIP 52, uzgadnia parameters, umieszcza specjalny identifier w payment data i przy przejściu przez LSP uruchamia otwarcie private zero-confirmation channel oraz przekazanie payment po potrąceniu opening fee.
Just-in-Time Channel powstaje dopiero w odpowiedzi na incoming payment docierającą z public Lightning Network przez LSP. Odbiorca nie musi wcześniej mieć channel, outbound capacity ani on-chain funds; koszt nowej inbound liquidity pokrywa wartość pierwszej otrzymanej payment. [1]
Client najpierw wywołuje lsps2.get_info i otrzymuje offers z min_fee_msat, proportional rate w ppm, valid_until, min_lifetime, max_client_to_self_delay oraz payment size limits. Wybraną offer wraz z utworzonym przez LSP promise przesyła w lsps2.buy; error może wystąpić po wygaśnięciu, przy zbyt małej payment lub braku liquidity. [2]
Udane lsps2.buy zwraca jit_channel_scid i lsp_cltv_expiry_delta. Client umieszcza LSP node ID i ten SCID jako jedyny hop route hint w BOLT11 invoice albo przekazuje te same dane przyszłym schematem, np. blinded path; expiry nie może przekroczyć valid_until, a client musi być połączony przy nadejściu payment. [1]
Gdy LSP rozpozna jit_channel_scid w incoming HTLC, rozpoczyna standardowy BOLT 2 channel establishment. Channel musi pomieścić payment_size_msat minus opening_fee i reserve, pozostaje unannounced, używa option_scid_alias i może przekazać payment jako zero-confirmation channel przed potwierdzeniem funding transaction. [4]
LSPS2 opisuje dwa trust models. W LSP trusts client provider najpierw publikuje valid funding transaction i ryzykuje, że client nie ujawni preimage; w client trusts LSP provider może wstrzymać broadcast, a client ujawnia preimage i ufa, że powstanie valid funding outpoint. [3]
JIT nie oznacza bezwarunkowej delivery. Payment musi pokryć opening fee, limits i minimum HTLC; rozłączenie przed funding_signed powoduje temporary_channel_failure, a naive prepayment probe w LSP trusts client może otworzyć channel, za który LSP ostatecznie nie dostanie payment. [1]
bLIP 52 jest active specification i wymaga LSPS0, czyli bLIP 50, jako transport. Reference crate lightning-liquidity zapewnia client i service handlers dla LSPS2, lecz documentation określa service-side support jako beta; obecność API nie dowodzi production readiness wallet ani LSP. [5]
Verification zaczyna się od lsps2.get_info i dokładnego max(min_fee_msat, proportional fee), wraz z valid_until, promise, payment limits, min_lifetime i max_client_to_self_delay. Po payment sprawdza się deducted fee, funding outpoint, channel parameters, channel_ready, alias i actual inbound capacity; sama invoice nie dowodzi open channel. [1]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Lightning Service Provider, Inbound Liquidity, Payment Channel, Price Channel, BOLT 11, BOLT 12.
01Czy Just-in-Time Channel jest bezpłatny?+
Nie. LSP potrąca opening fee z pierwszej incoming payment. Client musi wcześniej sprawdzić minimum i proportional składnik fee, payment limits oraz validity period parametrów.
02Czy Just-in-Time Channel jest potwierdzony on-chain przed odebraniem payment?+
Zwykle nie. LSPS2 otwiera zero-confirmation channel w reakcji na payment, a zależnie od trust model funding transaction może być tylko w mempool albo oczekiwać na broadcast. Client świadomie wybiera confirmation threshold i LSP risk.