LSP є контрагентом і service provider, а не частиною Bitcoin consensus; клієнт може тримати власні keys, але має оцінити price, availability, channel terms і конкретний trust model використаного LSPS protocol.
Lightning Service Provider розгортає власну або залучену liquidity для клієнтів. Найчастіше він відкриває channel до non-custodial wallet заради inbound capacity або з’єднує on-chain та off-chain funds через swap; за block space, capital, operation і risk стягується fee. [1]
Capacity Lightning channel фіксована й ділиться між local та remote balance. Тому нова wallet без channel не може отримати звичайний Lightning payment лише створивши invoice; LSP дає inbound liquidity без ручного вибору peer, UTXO і funding transaction parameters. [1]
LSPS0, тепер bLIP 50, уніфікує client-LSP communication як JSON-RPC 2.0 через Lightning BOLT8 peer-to-peer transport. Усі LSPS messages мають message ID 37913, а lsps0.list_protocols повертає точний перелік extensions; сама назва LSP не гарантує кожну service. [2]
LSPS1, тобто bLIP 51, стандартизує пряму order каналу. Client читає offer, створює order, перевіряє capacity, price та expiry і платить on-chain або через Lightning; specification прямо каже, що purchase не atomic і client довіряє LSP доставити channel або виконати визначений refund. [3]
LSPS2, тобто bLIP 52, описує just-in-time channel. Client отримує parameters і додає до invoice route hint з request identifier; коли incoming payment доходить через LSP, provider відкриває zero-confirmation channel, віднімає opening fee і пересилає решту. Client мусить бути підключеним у цей момент. [4]
Non-custodial LSP не тримає private keys клієнта й залишає йому його сторону channel, але operational dependency лишається. Provider бачить direct connection і частину payment flow, може відмовити в liquidity, змінити price у межах offer або бути offline; zero-confirmation channel і prepaid order мають різні risks. [1]
Стандарти LSPS0, LSPS1 і LSPS2 перейшли з первинного repository до процесу bLIP як активні bLIP 50, 51 і 52. Reference library lightning-liquidity реалізує client handlers LSPS1 і LSPS2 та service handler LSPS2, але конкретна wallet чи node може підтримувати лише subset із власними commercial terms. [5]
Перед використанням треба перевірити node ID і connection string LSP, результат lsps0.list_protocols, точну capacity і balance split, fee, expiry, confirmations та refund policy. Після відкриття перевіряють funding transaction, channel state й реальну inbound capacity; logo чи створена invoice цього не доводять. [2]
Для повної картини прочитайте також Lightning Network, Inbound Liquidity, Payment Channel, Submarine Swap, BOLT 11, Lightning Address. На цю статтю також посилаються Just-in-Time Channels, Trampoline Routing, Bitlifi.
01Чи Lightning Service Provider автоматично custodial?+
Ні. LSP може відкрити канал до wallet, що тримає власні keys, і керувати лише своєю стороною. Client все одно залежить від availability, liquidity offer і виконання конкретної order.
02Чи можна через LSP отримати перший payment без попереднього channel?+
Так, якщо wallet і provider підтримують LSPS2, а payment покриває opening fee. LSP відкриває JIT channel при надходженні й віднімає fee; це не безкоштовна й не безумовна inbound capacity.