Just-in-time channel - Revision history

NotATether: Add Trust models and Risks sections

2026-09-13T07:28:48Z

Add Trust models and Risks sections

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

	In outline: the client gets JIT parameters from an LSP and embeds a reserved SCID in invoice routing hints. When a matching payment arrives, the LSP holds the HTLC, opens an often-unannounced channel with the client, funds it (crediting the payment minus any opening fee), and forwards the HTLC so the client can settle with the preimage. Without extra on-chain contracts, the first open typically requires trusting the LSP for that handshake. After a channel exists, later capacity changes are often done with [[Splicing]] rather than more JIT opens. Related liquidity tooling includes [[Dual funding]].		In outline: the client gets JIT parameters from an LSP and embeds a reserved SCID in invoice routing hints. When a matching payment arrives, the LSP holds the HTLC, opens an often-unannounced channel with the client, funds it (crediting the payment minus any opening fee), and forwards the HTLC so the client can settle with the preimage. Without extra on-chain contracts, the first open typically requires trusting the LSP for that handshake. After a channel exists, later capacity changes are often done with [[Splicing]] rather than more JIT opens. Related liquidity tooling includes [[Dual funding]].

			== Trust models ==

	LSPS2 describes two trust models for that handshake. In one model the LSP trusts the client to claim the forwarded payment after the channel is open. In the other the client trusts the LSP, and the LSP may withhold broadcasting the funding transaction until it learns the payment preimage. Opening fees are typically deducted from the first received amount rather than paid as a separate on-chain invoice. Channels opened this way are often private. Public announcement is optional and usually deferred until the funding transaction has enough confirmations.		LSPS2 describes two trust models for that handshake. In one model the LSP trusts the client to claim the forwarded payment after the channel is open. In the other the client trusts the LSP, and the LSP may withhold broadcasting the funding transaction until it learns the payment preimage. Opening fees are typically deducted from the first received amount rather than paid as a separate on-chain invoice. Channels opened this way are often private. Public announcement is optional and usually deferred until the funding transaction has enough confirmations.

			LSP fee schedules and channel announcement policy remain application choices outside BOLT consensus. Wallets should surface which trust model an LSP uses before the first receive, because the funding broadcast timing differs.

			== Risks ==

	A risk specific to JIT opens is that a prepayment probe reaching the client's reserved route hint can cause an LSP to open a channel before a real payment arrives. Payers that probe only through the last public hop reduce that failure mode. After the first channel exists, the wallet usually buys more inbound capacity with LSPS1 channel orders or adjusts size with [[Splicing]] instead of repeating JIT opens for every payment.		A risk specific to JIT opens is that a prepayment probe reaching the client's reserved route hint can cause an LSP to open a channel before a real payment arrives. Payers that probe only through the last public hop reduce that failure mode. After the first channel exists, the wallet usually buys more inbound capacity with LSPS1 channel orders or adjusts size with [[Splicing]] instead of repeating JIT opens for every payment.

			Private JIT channels do not appear in public gossip, so pathfinding beyond the LSP depends on the LSP's own outbound graph. That concentration is intentional for onboarding and is a reason many wallets later splice or buy additional peers.


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

NotATether: Expand See also links

2026-09-12T21:12:55Z

Expand See also links

← Older revision		Revision as of 21:12, 12 September 2026
Line 13:		Line 13:
	== See also ==		== See also ==
	* [[Lightning Network]]		* [[Lightning Network]]
			* [[Lightning service provider]]
	* [[Dual funding]]		* [[Dual funding]]
	* [[Splicing]]		* [[Splicing]]

NotATether: Add probe risk and post-open liquidity path

2026-09-12T21:12:53Z

Add probe risk and post-open liquidity path

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

	LSPS2 describes two trust models for that handshake. In one model the LSP trusts the client to claim the forwarded payment after the channel is open. In the other the client trusts the LSP, and the LSP may withhold broadcasting the funding transaction until it learns the payment preimage. Opening fees are typically deducted from the first received amount rather than paid as a separate on-chain invoice. Channels opened this way are often private. Public announcement is optional and usually deferred until the funding transaction has enough confirmations.		LSPS2 describes two trust models for that handshake. In one model the LSP trusts the client to claim the forwarded payment after the channel is open. In the other the client trusts the LSP, and the LSP may withhold broadcasting the funding transaction until it learns the payment preimage. Opening fees are typically deducted from the first received amount rather than paid as a separate on-chain invoice. Channels opened this way are often private. Public announcement is optional and usually deferred until the funding transaction has enough confirmations.

			A risk specific to JIT opens is that a prepayment probe reaching the client's reserved route hint can cause an LSP to open a channel before a real payment arrives. Payers that probe only through the last public hop reduce that failure mode. After the first channel exists, the wallet usually buys more inbound capacity with LSPS1 channel orders or adjusts size with [[Splicing]] instead of repeating JIT opens for every payment.

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

NotATether: Add mechanism: LSPS2 trust models and fees

2026-09-12T21:12:52Z

Add mechanism: LSPS2 trust models and fees

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

	In outline: the client gets JIT parameters from an LSP and embeds a reserved SCID in invoice routing hints. When a matching payment arrives, the LSP holds the HTLC, opens an often-unannounced channel with the client, funds it (crediting the payment minus any opening fee), and forwards the HTLC so the client can settle with the preimage. Without extra on-chain contracts, the first open typically requires trusting the LSP for that handshake. After a channel exists, later capacity changes are often done with [[Splicing]] rather than more JIT opens. Related liquidity tooling includes [[Dual funding]].		In outline: the client gets JIT parameters from an LSP and embeds a reserved SCID in invoice routing hints. When a matching payment arrives, the LSP holds the HTLC, opens an often-unannounced channel with the client, funds it (crediting the payment minus any opening fee), and forwards the HTLC so the client can settle with the preimage. Without extra on-chain contracts, the first open typically requires trusting the LSP for that handshake. After a channel exists, later capacity changes are often done with [[Splicing]] rather than more JIT opens. Related liquidity tooling includes [[Dual funding]].

			LSPS2 describes two trust models for that handshake. In one model the LSP trusts the client to claim the forwarded payment after the channel is open. In the other the client trusts the LSP, and the LSP may withhold broadcasting the funding transaction until it learns the payment preimage. Opening fees are typically deducted from the first received amount rather than paid as a separate on-chain invoice. Channels opened this way are often private. Public announcement is optional and usually deferred until the funding transaction has enough confirmations.

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

NotATether: Create Just-in-time channel stub (LSP / LSPS2 JIT open)

2026-09-12T03:16:32Z

Create Just-in-time channel stub (LSP / LSPS2 JIT open)

New page

A '''just-in-time channel''' (JIT channel) is a [[Lightning Network]] channel that a Lightning service provider (LSP) opens in response to an incoming payment for a client that does not yet have inbound capacity. The LSP holds the first payment, funds a new channel, then forwards the HTLC into that channel so a new user can receive without first opening a channel or buying inbound liquidity.

JIT channels should not be confused with just-in-time routing, which rebalances existing channels so a payment that would otherwise fail for lack of local liquidity can be accepted.

Receiving on Lightning needs inbound capacity: a channel where the remote side holds enough balance (and a free HTLC slot) to carry the payment. A new wallet has neither. A JIT open treats the incoming payment as the event that creates the channel. Negotiation is commonly specified by LSPS2 (bLIP-52). The open usually depends on zero-confirmation channel features (<code>option_zeroconf</code> and <code>option_scid_alias</code>) so peers can use a short-channel-id alias before the funding transaction confirms. See also [[Zero-confirmation transaction]].

In outline: the client gets JIT parameters from an LSP and embeds a reserved SCID in invoice routing hints. When a matching payment arrives, the LSP holds the HTLC, opens an often-unannounced channel with the client, funds it (crediting the payment minus any opening fee), and forwards the HTLC so the client can settle with the preimage. Without extra on-chain contracts, the first open typically requires trusting the LSP for that handshake. After a channel exists, later capacity changes are often done with [[Splicing]] rather than more JIT opens. Related liquidity tooling includes [[Dual funding]].

== See also ==
* [[Lightning Network]]
* [[Dual funding]]
* [[Splicing]]
* [[Zero-confirmation transaction]]

== External links ==
* [https://bitcoinops.org/en/topics/jit-channels/ Bitcoin Optech: Just-In-Time (JIT) channels]
* [https://github.com/BitcoinAndLightningLayerSpecs/lsp Lightning Service Provider specifications (incl. LSPS2)]

[[Category:Technical]]