Lightning Service Provider

Lightning Service Provider는 clients를 위해 자체 또는 조달한 liquidity를 투입한다. 보통 non-custodial wallet에 inbound capacity를 주는 channel을 열거나 swap으로 on-chain과 off-chain funds를 연결하며, block space, capital, operation, risk에 가격을 매긴다. [1]

Lightning channel capacity는 고정되고 local과 remote balance로 나뉜다. 따라서 channel이 없는 새 wallet은 invoice만 만들어 일반 Lightning payment를 받을 수 없다. LSP는 사용자가 peer, UTXO, funding transaction parameters를 직접 고르지 않아도 inbound liquidity를 제공할 수 있다. [1]

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]

LSPS1, 즉 bLIP 51은 직접 channel 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를 받고 request identifier를 담은 route hint를 invoice에 넣는다. Incoming payment가 LSP에 도착하면 provider는 zero-confirmation channel을 열고 opening fee를 뺀 나머지를 전달한다. Client는 그 순간 연결돼 있어야 한다. [4]

Non-custodial LSP는 client의 private keys를 보유하지 않고 client 쪽 channel을 남기지만 operational dependency는 있다. Provider는 direct connection과 payment flow 일부를 보고, liquidity를 거절하거나 offer 범위에서 price를 바꾸거나 offline일 수 있다. Zero-confirmation channel과 prepaid order의 risk도 다르다. [1]

LSPS0, LSPS1, LSPS2 standards는 원래 repository에서 bLIP process로 옮겨 active bLIP 50, 51, 52가 됐다. Reference library lightning-liquidity는 LSPS1 및 LSPS2 client handlers와 LSPS2 service handler를 구현하지만, 특정 wallet이나 node는 자체 terms로 subset만 지원할 수 있다. [5]

사용 전 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]