LSP jest kontrahentem i service provider, nie częścią Bitcoin consensus; klient może trzymać własne keys, lecz musi ocenić cenę, dostępność, warunki kanału i konkretny trust model używanego LSPS protocol.
Lightning Service Provider przeznacza własną lub pozyskaną liquidity dla klientów. Najczęściej otwiera channel do non-custodial wallet, zapewniając inbound capacity, albo łączy on-chain i off-chain funds przez swap; pobiera opłatę za block space, capital, operation i risk. [1]
Capacity kanału Lightning jest stała i dzieli się na local oraz remote balance. Nowa wallet bez channel nie odbierze zwykłej płatności tylko tworząc invoice; LSP daje inbound liquidity bez ręcznego wybierania peer, UTXO i funding transaction parameters. [1]
LSPS0, obecnie bLIP 50, ujednolica client-LSP communication jako JSON-RPC 2.0 przez Lightning BOLT8 peer-to-peer transport. Wszystkie LSPS messages używają message ID 37913, a lsps0.list_protocols podaje dokładne extensions; sama etykieta LSP nie gwarantuje każdej service. [2]
LSPS1, czyli bLIP 51, standaryzuje bezpośrednią order kanału. Client pobiera offer, tworzy order, sprawdza capacity, price i expiry, a następnie płaci on-chain lub przez Lightning; specification mówi wprost, że purchase nie jest atomic i klient ufa LSP, że dostarczy channel albo wykona wymagany refund. [3]
LSPS2, czyli bLIP 52, obsługuje just-in-time channel. Client pobiera parameters i umieszcza w invoice route hint z request identifier; gdy incoming payment dotrze do LSP, provider otwiera zero-confirmation channel, potrąca opening fee i przekazuje resztę. Client musi być wtedy połączony. [4]
Non-custodial LSP nie trzyma private keys klienta i pozostawia mu jego stronę channel, lecz zależność operacyjna trwa. Provider widzi direct connection i część payment flow, może odmówić liquidity, zmienić price w granicach offer lub być offline; zero-confirmation channel i prepaid order mają inne risks. [1]
Standardy LSPS0, LSPS1 i LSPS2 przeniesiono z pierwotnego repository do procesu bLIP jako aktywne bLIP 50, 51 i 52. Reference library lightning-liquidity implementuje client handlers LSPS1 i LSPS2 oraz service handler LSPS2, ale konkretna wallet lub node może wspierać tylko subset na własnych warunkach. [5]
Przed użyciem trzeba sprawdzić node ID i connection string LSP, wynik lsps0.list_protocols, dokładną capacity i balance split, fee, expiry, confirmations oraz refund policy. Po otwarciu sprawdza się funding transaction, channel state i rzeczywistą inbound capacity; logo ani utworzona invoice tego nie dowodzą. [2]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Lightning Network, Inbound Liquidity, Payment Channel, Submarine Swap, BOLT 11, Lightning Address. Do tego hasła prowadzą również odsyłacze z Just-in-Time Channels, Trampoline Routing, Bitlifi.
01Czy Lightning Service Provider jest automatycznie custodial?+
Nie. LSP może otworzyć kanał do wallet trzymającej własne keys i zarządzać tylko swoją stroną. Client nadal zależy od availability, liquidity offer i wykonania konkretnej order.
02Czy LSP pozwala odebrać pierwszy payment bez wcześniejszego channel?+
Tak, jeśli wallet i provider wspierają LSPS2, a payment pokrywa opening fee. LSP otwiera JIT channel po nadejściu i potrąca fee; inbound capacity nie jest darmowa ani bezwarunkowa.