Splicing - Revision history

NotATether: Expand Fee bumps on disagreement path

2026-09-13T07:35:54Z

Expand Fee bumps on disagreement path

← Older revision		Revision as of 07:35, 13 September 2026
Line 12:		Line 12:
	== Fee bumps ==		== Fee bumps ==

	Because the splice spends the current funding outpoint, a stuck low-feerate splice blocks capacity changes until it confirms, is replaced, or is abandoned per peer policy. Peers repeat interactive construction with a higher feerate and exchange fresh signatures, using [[Replace by fee]] on the unconfirmed splice transaction. Anchor-style or TRUC fee-bumping on the splice itself depends on the channel's commitment format and on whether the splice transaction opts into version-3 policy.		Because the splice spends the current funding outpoint, a stuck low-feerate splice blocks capacity changes until it confirms, is replaced, or is abandoned per peer policy. Peers repeat interactive construction with a higher feerate and exchange fresh signatures, using [[Replace by fee]] on the unconfirmed splice transaction. Anchor-style or TRUC fee-bumping on the splice itself depends on the channel's commitment format and on whether the splice transaction opts into version-3 policy. If peers disagree on whether a replacement splice is valid, one side may need to force-close using the latest commitment that still spends a funding outpoint both sides acknowledge.

	== Pending state ==		== Pending state ==

NotATether: Add Fee bumps section and pending-state densify

2026-09-13T07:32:58Z

Add Fee bumps section and pending-state densify

← Older revision		Revision as of 07:32, 13 September 2026
Line 8:		Line 8:

	Quiescence prevents concurrent commitment updates from racing the interactive splice builder. Peers that cannot quiesce safely should refuse <code>option_splice</code> until both sides implement <code>stfu</code>.		Quiescence prevents concurrent commitment updates from racing the interactive splice builder. Peers that cannot quiesce safely should refuse <code>option_splice</code> until both sides implement <code>stfu</code>.


			== Fee bumps ==

			Because the splice spends the current funding outpoint, a stuck low-feerate splice blocks capacity changes until it confirms, is replaced, or is abandoned per peer policy. Peers repeat interactive construction with a higher feerate and exchange fresh signatures, using [[Replace by fee]] on the unconfirmed splice transaction. Anchor-style or TRUC fee-bumping on the splice itself depends on the channel's commitment format and on whether the splice transaction opts into version-3 policy.

	== Pending state ==		== Pending state ==
Line 16:		Line 21:

	A node that restarts mid-splice must reload every unfinished funding outpoint from durable storage before accepting new HTLCs, or it may sign commitments against a discarded txid.		A node that restarts mid-splice must reload every unfinished funding outpoint from durable storage before accepting new HTLCs, or it may sign commitments against a discarded txid.

			After <code>splice_locked</code>, nodes should forget superseded funding outpoints promptly so monitors do not keep watching dead txids. Public capacity advertisements that lag the locked splice can cause temporary routing failures toward the old short channel id.

NotATether: Add Negotiation and Pending state sections

2026-09-13T07:28:52Z

Add Negotiation and Pending state sections

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

	Without splicing, changing capacity usually means a close and a new open, which is slower, costs more on-chain fees, and drops the channel from the public graph while it is down. A splice-in adds funds. A splice-out withdraws to an on-chain address. Moving value into another of the same node's channels is sometimes called a cross-splice.		Without splicing, changing capacity usually means a close and a new open, which is slower, costs more on-chain fees, and drops the channel from the public graph while it is down. A splice-in adds funds. A splice-out withdraws to an on-chain address. Moving value into another of the same node's channels is sometimes called a cross-splice.

			== Negotiation ==

	Peers first quiesce the channel (BOLT 2 <code>option_quiesce</code> / <code>stfu</code>) so both sides share the same committed state with no in-flight updates. They then negotiate amounts and feerate, build a transaction that spends the current funding output (plus any extra inputs) into a new funding output and optional splice-out outputs, and exchange signatures for that splice and for commitments that spend the new outpoint. Commitments that still spend the old outpoint are kept until the splice confirms. After un-quiescing, new HTLCs must remain valid against every pending funding outpoint so a late confirmation cannot strand a payment. The splice may be fee-bumped with [[Replace by fee]] by repeating construction. When a splice reaches the required depth, peers exchange <code>splice_locked</code>, drop competing pending splices and the old funding outpoint, and advertise the new short channel id.		Peers first quiesce the channel (BOLT 2 <code>option_quiesce</code> / <code>stfu</code>) so both sides share the same committed state with no in-flight updates. They then negotiate amounts and feerate, build a transaction that spends the current funding output (plus any extra inputs) into a new funding output and optional splice-out outputs, and exchange signatures for that splice and for commitments that spend the new outpoint. Commitments that still spend the old outpoint are kept until the splice confirms. After un-quiescing, new HTLCs must remain valid against every pending funding outpoint so a late confirmation cannot strand a payment. The splice may be fee-bumped with [[Replace by fee]] by repeating construction. When a splice reaches the required depth, peers exchange <code>splice_locked</code>, drop competing pending splices and the old funding outpoint, and advertise the new short channel id.

			Quiescence prevents concurrent commitment updates from racing the interactive splice builder. Peers that cannot quiesce safely should refuse <code>option_splice</code> until both sides implement <code>stfu</code>.

			== Pending state ==

	Splicing needs no consensus change. Taproot channels splice into a new P2TR funding output. Legacy channels splice into a new P2WSH 2-of-2. Until <code>splice_locked</code>, watchers must track every pending funding outpoint.		Splicing needs no consensus change. Taproot channels splice into a new P2TR funding output. Legacy channels splice into a new P2WSH 2-of-2. Until <code>splice_locked</code>, watchers must track every pending funding outpoint.
Line 9:		Line 15:
	While a splice is pending, the channel may keep serving HTLCs, but both peers must be prepared to settle those HTLCs against either the old or the new funding outpoint. Public channels update gossip after <code>splice_locked</code> so the network learns the new capacity and short channel id. Until then, routers may still advertise the pre-splice capacity. Failed or replaced splices must not leave orphan commitment signatures that spend a discarded outpoint.		While a splice is pending, the channel may keep serving HTLCs, but both peers must be prepared to settle those HTLCs against either the old or the new funding outpoint. Public channels update gossip after <code>splice_locked</code> so the network learns the new capacity and short channel id. Until then, routers may still advertise the pre-splice capacity. Failed or replaced splices must not leave orphan commitment signatures that spend a discarded outpoint.

	~~Interactive construction lets either peer add inputs for a splice~~-~~in or claim a splice-out output to an address it controls. Feerate agreement matters because the~~ splice ~~transaction competes for confirmation like any other on-chain spend. [[Watchtower\|Watchtowers]] and local channel monitors need~~ every ~~pending~~ funding ~~txid. Otherwise a revoked commitment that still spends an old~~ outpoint ~~could be missed after~~ a ~~capacity change~~.		A node that restarts mid-splice must reload every unfinished funding outpoint from durable storage before accepting new HTLCs, or it may sign commitments against a discarded txid.


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

NotATether: Expand See also links

2026-09-12T21:13:21Z

Expand See also links

← Older revision		Revision as of 21:13, 12 September 2026
Line 14:		Line 14:
	* [[Dual funding]]		* [[Dual funding]]
	* [[Lightning Network]]		* [[Lightning Network]]
			* [[Just-in-time channel]]
			* [[Watchtower]]
	* [[Replace by fee]]		* [[Replace by fee]]

NotATether: Add inputs, feerate, and watcher requirements

2026-09-12T21:13:19Z

Add inputs, feerate, and watcher requirements

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

	While a splice is pending, the channel may keep serving HTLCs, but both peers must be prepared to settle those HTLCs against either the old or the new funding outpoint. Public channels update gossip after <code>splice_locked</code> so the network learns the new capacity and short channel id. Until then, routers may still advertise the pre-splice capacity. Failed or replaced splices must not leave orphan commitment signatures that spend a discarded outpoint.		While a splice is pending, the channel may keep serving HTLCs, but both peers must be prepared to settle those HTLCs against either the old or the new funding outpoint. Public channels update gossip after <code>splice_locked</code> so the network learns the new capacity and short channel id. Until then, routers may still advertise the pre-splice capacity. Failed or replaced splices must not leave orphan commitment signatures that spend a discarded outpoint.

			Interactive construction lets either peer add inputs for a splice-in or claim a splice-out output to an address it controls. Feerate agreement matters because the splice transaction competes for confirmation like any other on-chain spend. [[Watchtower\|Watchtowers]] and local channel monitors need every pending funding txid. Otherwise a revoked commitment that still spends an old outpoint could be missed after a capacity change.

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

NotATether: Add mechanism: pending HTLCs and gossip timing

2026-09-12T21:13:18Z

Add mechanism: pending HTLCs and gossip timing

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

	Splicing needs no consensus change. Taproot channels splice into a new P2TR funding output. Legacy channels splice into a new P2WSH 2-of-2. Until <code>splice_locked</code>, watchers must track every pending funding outpoint.		Splicing needs no consensus change. Taproot channels splice into a new P2TR funding output. Legacy channels splice into a new P2WSH 2-of-2. Until <code>splice_locked</code>, watchers must track every pending funding outpoint.

			While a splice is pending, the channel may keep serving HTLCs, but both peers must be prepared to settle those HTLCs against either the old or the new funding outpoint. Public channels update gossip after <code>splice_locked</code> so the network learns the new capacity and short channel id. Until then, routers may still advertise the pre-splice capacity. Failed or replaced splices must not leave orphan commitment signatures that spend a discarded outpoint.

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

NotATether: Create Splicing stub (option_splice / interactive construction)

2026-09-12T03:10:19Z

Create Splicing stub (option_splice / interactive construction)

New page

'''Splicing''' is a [[Lightning Network]] protocol that spends a channel's current funding output into a new funding output with a different amount, so peers can add or remove on-chain funds without closing the channel. Feature bits 62/63 advertise <code>option_splice</code>. The construction reuses interactive transaction building from [[Dual funding]].

Without splicing, changing capacity usually means a close and a new open, which is slower, costs more on-chain fees, and drops the channel from the public graph while it is down. A splice-in adds funds. A splice-out withdraws to an on-chain address. Moving value into another of the same node's channels is sometimes called a cross-splice.

Peers first quiesce the channel (BOLT 2 <code>option_quiesce</code> / <code>stfu</code>) so both sides share the same committed state with no in-flight updates. They then negotiate amounts and feerate, build a transaction that spends the current funding output (plus any extra inputs) into a new funding output and optional splice-out outputs, and exchange signatures for that splice and for commitments that spend the new outpoint. Commitments that still spend the old outpoint are kept until the splice confirms. After un-quiescing, new HTLCs must remain valid against every pending funding outpoint so a late confirmation cannot strand a payment. The splice may be fee-bumped with [[Replace by fee]] by repeating construction. When a splice reaches the required depth, peers exchange <code>splice_locked</code>, drop competing pending splices and the old funding outpoint, and advertise the new short channel id.

Splicing needs no consensus change. Taproot channels splice into a new P2TR funding output. Legacy channels splice into a new P2WSH 2-of-2. Until <code>splice_locked</code>, watchers must track every pending funding outpoint.

== See also ==
* [[Dual funding]]
* [[Lightning Network]]
* [[Replace by fee]]

== External links ==
* [https://bitcoinops.org/en/topics/splicing/ Bitcoin Optech: Splicing]
* [https://github.com/lightning/bolts/blob/master/02-peer-protocol.md BOLT 2: Peer Protocol for Channel Management]
* [https://github.com/lightning/bolts/pull/1160 BOLTs PR 1160: Channel Splicing]

[[Category:Technical]]