什么是Lightning Service Provider？定义、背景与来源

01什么是Lightning Service Provider？

LSP 是交易对手与服务提供者，并非 Bitcoin consensus 的组成部分；客户可以自持 keys，但必须评估价格、可用性、通道条款及所用 LSPS protocol 的具体 trust model。

02核心

Lightning Service Provider 为客户部署自有或取得的 liquidity。最常见的是向 non-custodial wallet 开设通道以提供 inbound capacity，或通过 swap 连接 on-chain 与 off-chain funds；block space、capital、operation 与 risk 都会计价。 [1]

03机制

Lightning channel capacity 固定，并分为 local 与 remote balance。因此，没有通道的新 wallet 仅创建 invoice 仍不能接收普通 Lightning payment；LSP 可提供 inbound liquidity，而无需用户手动选择 peer、UTXO 与 funding transaction parameters。 [1]

04要解决的问题

LSPS0 即现在的 bLIP 50，将 client-LSP communication 统一为经 Lightning BOLT8 peer-to-peer transport 传输的 JSON-RPC 2.0。所有 LSPS messages 使用 message ID 37913，lsps0.list_protocols 返回确切支持的 extensions；LSP 名称本身并不保证每项 service。 [2]

05安全模型

LSPS1 即 bLIP 51，标准化直接订购通道。Client 读取 offer、创建 order、核对 capacity、price 与 expiry，再通过 on-chain 或 Lightning 支付；specification 明确说明 purchase 并非 atomic，client 信任 LSP 会在付款后交付 channel 或执行规定 refund。 [3]

06部署状态

LSPS2 即 bLIP 52，处理 just-in-time channel。Client 取得 parameters，并在 invoice 中放入带 request identifier 的 route hint；incoming payment 到达 LSP 后，provider 开设 zero-confirmation channel、扣除 opening fee 并转发余款。Client 当时必须在线连接。 [4]

07限制

Non-custodial LSP 不持有客户 private keys，并把客户一侧 channel 留给客户，但仍存在 operational dependency。Provider 可见 direct connection 及部分 payment flow，可能拒绝 liquidity、在 offer 范围内改价或离线；zero-confirmation channel 与 prepaid order 的风险也不同。 [1]

08Atlas 中的关联

LSPS0、LSPS1 与 LSPS2 标准已从原 repository 转入 bLIP 流程，成为 active bLIP 50、51 与 52。Reference library lightning-liquidity 实现 LSPS1 和 LSPS2 client handlers 及 LSPS2 service handler，但特定 wallet 或 node 可能仅支持 subset，并有自己的 commercial terms。 [5]

09如何核验相关说法

使用前应核对 LSP node ID 与 connection string、lsps0.list_protocols 结果、准确 capacity 与 balance split、fee、expiry、confirmations 及 refund policy。开设后还要检查 funding transaction、channel state 与实际 inbound capacity；provider logo 或成功生成的 invoice 都不能证明这些属性。 [2]

Lightning Service Provider 为客户部署自有或取得的 liquidity。
Lightning channel capacity 固定，并分为 local 与 remote balance。
LSPS0 即现在的 bLIP 50，将 client-LSP communication 统一为经 Lightning BOLT8 peer-to-peer transport 传输的 JSON-RPC 2.0。
LSPS1 即 bLIP 51，标准化直接订购通道。
LSPS2 即 bLIP 52，处理 just-in-time channel。
Non-custodial LSP 不持有客户 private keys，并把客户一侧 channel 留给客户，但仍存在 operational dependency。
LSPS0、LSPS1 与 LSPS2 标准已从原 repository 转入 bLIP 流程，成为 active bLIP 50、51 与 52。
使用前应核对 LSP node ID 与 connection string、lsps0.list_protocols 结果、准确 capacity 与 balance split、fee、expiry、confirmations 及 refund policy。
LSP 是交易对手与服务提供者，并非 Bitcoin consensus 的组成部分；客户可以自持 keys，但必须评估价格、可用性、通道条款及所用 LSPS protocol 的具体 trust model。

结合上下文阅读

要获得更完整的理解，请将本词条与以下词条结合阅读： Lightning Network, Inbound Liquidity, Payment Channel, Submarine Swap, BOLT 11, Lightning Address. 反向关联还来自： Just-in-Time Channels, Trampoline Routing, Bitlifi.

?实用问题

01Lightning Service Provider 一定是 custodial 吗？

不是。LSP 可以向自持 keys 的 wallet 开设通道，并只管理自己一侧。Client 仍依赖其 availability、liquidity offer 与具体 order 的履行。

02没有预先通道，能通过 LSP 接收首笔 payment 吗？

可以，前提是 wallet 与 provider 支持 LSPS2，且 payment 足以覆盖 opening fee。LSP 在支付到达时开设 JIT channel 并扣费；这并非免费或无条件的 inbound capacity。