LSP — контрагент и service provider, а не часть Bitcoin consensus; клиент может хранить свои keys, но должен оценить цену, доступность, условия канала и конкретный 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 взимается плата. [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 process как активные bLIP 50, 51 и 52. Reference library lightning-liquidity реализует LSPS1 и LSPS2 client handlers и LSPS2 service handler, однако конкретная wallet или node может поддерживать лишь subset на своих условиях. [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 не бесплатна и не безусловна.