Lightning service provider - Revision history

NotATether: Add LSPS protocols and Counterparty role sections

2026-09-13T07:28:54Z

Add LSPS protocols and Counterparty role sections

← Older revision		Revision as of 07:28, 13 September 2026
Line 2:		Line 2:

	A Lightning payment can only be received on a channel that already has bitcoin on the remote side (inbound capacity). A new wallet has no channels until some peer opens toward it or the wallet opens outbound and later receives. LSPs perform that operational work (on-chain fees, UTXO management, and staying online). Early providers each exposed a proprietary API. A common specification effort (originally LSPS) was later published as Bitcoin Lightning Improvement Proposals (bLIPs) in the lightning/blips repository.		A Lightning payment can only be received on a channel that already has bitcoin on the remote side (inbound capacity). A new wallet has no channels until some peer opens toward it or the wallet opens outbound and later receives. LSPs perform that operational work (on-chain fees, UTXO management, and staying online). Early providers each exposed a proprietary API. A common specification effort (originally LSPS) was later published as Bitcoin Lightning Improvement Proposals (bLIPs) in the lightning/blips repository.

			== LSPS protocols ==

	The LSP and the wallet are ordinary Lightning peers. Service requests ride on the encrypted BOLT 8 transport as JSON-RPC 2.0 payloads (message type 37913), defined as LSPS0 / bLIP 50. LSPS1 / bLIP 51 standardizes purchasing a channel (order, payment, open, refund on failure). LSPS2 / bLIP 52 standardizes [[Just-in-time channel]] opens: the LSP intercepts an incoming HTLC, opens toward the wallet (often zero-conf), and forwards the payment minus an opening fee. LSPS5 / bLIP 55 registers HTTPS webhooks so a usually offline mobile wallet can be notified of activity. Related tools for channel capacity include [[Dual funding]] and [[Splicing]]. An LSP is a liquidity counterparty, not a custodian of the wallet's channel keys when the wallet holds them. Receiving still depends on the LSP's willingness to extend inbound capacity and on the LSP's own outbound routes. [[Watchtower]] services are a separate always-on watcher role; some hosts combine both functions.		The LSP and the wallet are ordinary Lightning peers. Service requests ride on the encrypted BOLT 8 transport as JSON-RPC 2.0 payloads (message type 37913), defined as LSPS0 / bLIP 50. LSPS1 / bLIP 51 standardizes purchasing a channel (order, payment, open, refund on failure). LSPS2 / bLIP 52 standardizes [[Just-in-time channel]] opens: the LSP intercepts an incoming HTLC, opens toward the wallet (often zero-conf), and forwards the payment minus an opening fee. LSPS5 / bLIP 55 registers HTTPS webhooks so a usually offline mobile wallet can be notified of activity. Related tools for channel capacity include [[Dual funding]] and [[Splicing]]. An LSP is a liquidity counterparty, not a custodian of the wallet's channel keys when the wallet holds them. Receiving still depends on the LSP's willingness to extend inbound capacity and on the LSP's own outbound routes. [[Watchtower]] services are a separate always-on watcher role; some hosts combine both functions.

	Wallets typically discover an LSP through an application default, a QR or deep link, or a manual node id. After LSPS0 negotiation the wallet can buy a channel with LSPS1, request JIT receives with LSPS2, or register push notifications with LSPS5. Fees may be quoted as a flat opening charge, a basis-point cut of the first payment, or a recurring liquidity lease, depending on the provider and the bLIP used.		Wallets typically discover an LSP through an application default, a QR or deep link, or a manual node id. After LSPS0 negotiation the wallet can buy a channel with LSPS1, request JIT receives with LSPS2, or register push notifications with LSPS5. Fees may be quoted as a flat opening charge, a basis-point cut of the first payment, or a recurring liquidity lease, depending on the provider and the bLIP used.

			bLIP documents evolve independently of BOLTs. Wallets should treat unknown LSPS methods as optional and fall back to manual channel opens when negotiation fails.

			== Counterparty role ==

	An LSP that also routes payments for other users is still subject to ordinary Lightning channel risk, including jamming and unbalanced liquidity. Choosing among multiple LSPs can reduce dependence on a single inbound peer. Specifications do not require the LSP to custody the client's long-term keys. Custody products that hold keys for the user are a different trust model even when they market Lightning receive services.		An LSP that also routes payments for other users is still subject to ordinary Lightning channel risk, including jamming and unbalanced liquidity. Choosing among multiple LSPs can reduce dependence on a single inbound peer. Specifications do not require the LSP to custody the client's long-term keys. Custody products that hold keys for the user are a different trust model even when they market Lightning receive services.

			Marketing that calls an LSP a bank or custodian is describing a different product. A non-custodial LSP still chooses whether to sell inbound liquidity and can close or refuse channels like any other peer.


	== See also ==		== See also ==

NotATether: Expand See also links

2026-09-12T21:13:27Z

Expand See also links

← Older revision		Revision as of 21:13, 12 September 2026
Line 15:		Line 15:
	* [[Splicing]]		* [[Splicing]]
	* [[Watchtower]]		* [[Watchtower]]
			* [[Channel jamming]]
	* [[LNURL]]		* [[LNURL]]

NotATether: Add operational risks and non-custody boundary

2026-09-12T21:13:25Z

Add operational risks and non-custody boundary

← Older revision		Revision as of 21:13, 12 September 2026
Line 6:		Line 6:

	Wallets typically discover an LSP through an application default, a QR or deep link, or a manual node id. After LSPS0 negotiation the wallet can buy a channel with LSPS1, request JIT receives with LSPS2, or register push notifications with LSPS5. Fees may be quoted as a flat opening charge, a basis-point cut of the first payment, or a recurring liquidity lease, depending on the provider and the bLIP used.		Wallets typically discover an LSP through an application default, a QR or deep link, or a manual node id. After LSPS0 negotiation the wallet can buy a channel with LSPS1, request JIT receives with LSPS2, or register push notifications with LSPS5. Fees may be quoted as a flat opening charge, a basis-point cut of the first payment, or a recurring liquidity lease, depending on the provider and the bLIP used.

			An LSP that also routes payments for other users is still subject to ordinary Lightning channel risk, including jamming and unbalanced liquidity. Choosing among multiple LSPs can reduce dependence on a single inbound peer. Specifications do not require the LSP to custody the client's long-term keys. Custody products that hold keys for the user are a different trust model even when they market Lightning receive services.

	== See also ==		== See also ==

NotATether: Add discovery, LSPS flow, and fee forms

2026-09-12T21:13:23Z

Add discovery, LSPS flow, and fee forms

← Older revision		Revision as of 21:13, 12 September 2026
Line 4:		Line 4:

	The LSP and the wallet are ordinary Lightning peers. Service requests ride on the encrypted BOLT 8 transport as JSON-RPC 2.0 payloads (message type 37913), defined as LSPS0 / bLIP 50. LSPS1 / bLIP 51 standardizes purchasing a channel (order, payment, open, refund on failure). LSPS2 / bLIP 52 standardizes [[Just-in-time channel]] opens: the LSP intercepts an incoming HTLC, opens toward the wallet (often zero-conf), and forwards the payment minus an opening fee. LSPS5 / bLIP 55 registers HTTPS webhooks so a usually offline mobile wallet can be notified of activity. Related tools for channel capacity include [[Dual funding]] and [[Splicing]]. An LSP is a liquidity counterparty, not a custodian of the wallet's channel keys when the wallet holds them. Receiving still depends on the LSP's willingness to extend inbound capacity and on the LSP's own outbound routes. [[Watchtower]] services are a separate always-on watcher role; some hosts combine both functions.		The LSP and the wallet are ordinary Lightning peers. Service requests ride on the encrypted BOLT 8 transport as JSON-RPC 2.0 payloads (message type 37913), defined as LSPS0 / bLIP 50. LSPS1 / bLIP 51 standardizes purchasing a channel (order, payment, open, refund on failure). LSPS2 / bLIP 52 standardizes [[Just-in-time channel]] opens: the LSP intercepts an incoming HTLC, opens toward the wallet (often zero-conf), and forwards the payment minus an opening fee. LSPS5 / bLIP 55 registers HTTPS webhooks so a usually offline mobile wallet can be notified of activity. Related tools for channel capacity include [[Dual funding]] and [[Splicing]]. An LSP is a liquidity counterparty, not a custodian of the wallet's channel keys when the wallet holds them. Receiving still depends on the LSP's willingness to extend inbound capacity and on the LSP's own outbound routes. [[Watchtower]] services are a separate always-on watcher role; some hosts combine both functions.

			Wallets typically discover an LSP through an application default, a QR or deep link, or a manual node id. After LSPS0 negotiation the wallet can buy a channel with LSPS1, request JIT receives with LSPS2, or register push notifications with LSPS5. Fees may be quoted as a flat opening charge, a basis-point cut of the first payment, or a recurring liquidity lease, depending on the provider and the bLIP used.

	== See also ==		== See also ==

NotATether: Create Lightning service provider stub (LSPS / bLIPs)

2026-09-12T03:38:59Z

Create Lightning service provider stub (LSPS / bLIPs)

New page

A '''Lightning service provider''' (LSP) is a [[Lightning Network]] node operator that sells inbound liquidity and related services to wallets, most commonly by opening channels toward the wallet so the wallet can receive payments. The role is an application-layer business on top of the Lightning peer protocol, not a consensus change.

A Lightning payment can only be received on a channel that already has bitcoin on the remote side (inbound capacity). A new wallet has no channels until some peer opens toward it or the wallet opens outbound and later receives. LSPs perform that operational work (on-chain fees, UTXO management, and staying online). Early providers each exposed a proprietary API. A common specification effort (originally LSPS) was later published as Bitcoin Lightning Improvement Proposals (bLIPs) in the lightning/blips repository.

The LSP and the wallet are ordinary Lightning peers. Service requests ride on the encrypted BOLT 8 transport as JSON-RPC 2.0 payloads (message type 37913), defined as LSPS0 / bLIP 50. LSPS1 / bLIP 51 standardizes purchasing a channel (order, payment, open, refund on failure). LSPS2 / bLIP 52 standardizes [[Just-in-time channel]] opens: the LSP intercepts an incoming HTLC, opens toward the wallet (often zero-conf), and forwards the payment minus an opening fee. LSPS5 / bLIP 55 registers HTTPS webhooks so a usually offline mobile wallet can be notified of activity. Related tools for channel capacity include [[Dual funding]] and [[Splicing]]. An LSP is a liquidity counterparty, not a custodian of the wallet's channel keys when the wallet holds them. Receiving still depends on the LSP's willingness to extend inbound capacity and on the LSP's own outbound routes. [[Watchtower]] services are a separate always-on watcher role; some hosts combine both functions.

== See also ==
* [[Lightning Network]]
* [[Just-in-time channel]]
* [[Dual funding]]
* [[Splicing]]
* [[Watchtower]]
* [[LNURL]]

== External links ==
* [https://github.com/lightning/blips Bitcoin Lightning Improvement Proposals (bLIPs)]
* [https://github.com/lightning/blips/blob/master/blip-0050.md bLIP 50 (LSPS0)]
* [https://github.com/lightning/blips/blob/master/blip-0051.md bLIP 51 (LSPS1)]
* [https://github.com/lightning/blips/blob/master/blip-0052.md bLIP 52 (LSPS2)]
* [https://bitcoinops.org/en/topics/jit-channels/ Bitcoin Optech: Just-In-Time (JIT) channels]

[[Category:Technical]]