Dual funding - Revision history

NotATether: Add Interactive construction and Deployment sections

2026-09-13T07:30:18Z

Add Interactive construction and Deployment sections

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

	The original Lightning open is single-funded: one peer pays the entire funding output and on-chain fees, and the other starts with no outbound liquidity until it receives payments or later adjusts the channel. Dual funding lets each peer put coins into the same 2-of-2 or Taproot funding output in one on-chain transaction.		The original Lightning open is single-funded: one peer pays the entire funding output and on-chain fees, and the other starts with no outbound liquidity until it receives payments or later adjusts the channel. Dual funding lets each peer put coins into the same 2-of-2 or Taproot funding output in one on-chain transaction.

			== Interactive construction ==

	Peers that support the feature exchange <code>open_channel2</code> and <code>accept_channel2</code>, then build the funding transaction interactively with <code>tx_add_input</code>, <code>tx_add_output</code>, remove messages, and <code>tx_complete</code>, followed by commitment setup and <code>tx_signatures</code>. Because both sides may contribute inputs, the unconfirmed funding transaction can be fee-bumped with [[Replace by fee]] by repeating interactive construction at a higher feerate. Dual funding does not by itself change HTLC routing. Both peers need on-chain UTXOs. A peer with no coins cannot dual-fund.		Peers that support the feature exchange <code>open_channel2</code> and <code>accept_channel2</code>, then build the funding transaction interactively with <code>tx_add_input</code>, <code>tx_add_output</code>, remove messages, and <code>tx_complete</code>, followed by commitment setup and <code>tx_signatures</code>. Because both sides may contribute inputs, the unconfirmed funding transaction can be fee-bumped with [[Replace by fee]] by repeating interactive construction at a higher feerate. Dual funding does not by itself change HTLC routing. Both peers need on-chain UTXOs. A peer with no coins cannot dual-fund.

	Interactive construction is shared with later channel updates that also rebuild funding, notably [[Splicing]]. Either peer may abort before signatures if the other's proposed inputs, outputs, or fees are unacceptable. Commitment transactions for the dual-funded channel still follow the ordinary Lightning penalty model after the funding outpoint is locked. Feature advertisement uses BOLT 9 bits 28 and 29. Implementations must agree on those bits before <code>open_channel2</code> is useful.		Interactive construction is shared with later channel updates that also rebuild funding, notably [[Splicing]]. Either peer may abort before signatures if the other's proposed inputs, outputs, or fees are unacceptable. Commitment transactions for the dual-funded channel still follow the ordinary Lightning penalty model after the funding outpoint is locked. Feature advertisement uses BOLT 9 bits 28 and 29. Implementations must agree on those bits before <code>open_channel2</code> is useful.

			== Deployment ==

	Some implementations combine dual funding with zero-confirmation acceptance of the funding transaction among trusting peers. That speeds first receive but reintroduces [[Zero-confirmation transaction\|0-conf]] risk on the channel capacity itself until the funding outpoint confirms. Public dual-funded channels still need gossip announcement rules and reserve balances like any other public channel.		Some implementations combine dual funding with zero-confirmation acceptance of the funding transaction among trusting peers. That speeds first receive but reintroduces [[Zero-confirmation transaction\|0-conf]] risk on the channel capacity itself until the funding outpoint confirms. Public dual-funded channels still need gossip announcement rules and reserve balances like any other public channel.

	Core Lightning was an early production adopter of interactive funding and <code>option_dual_fund</code>. Other implementations expose subsets of the v2 open messages or prefer single-fund opens plus later [[Splicing]]. Interoperability failures usually show up as peers advertising mismatched feature bits or aborting interactive construction when input ownership proofs disagree.		Core Lightning was an early production adopter of interactive funding and <code>option_dual_fund</code>. Other implementations expose subsets of the v2 open messages or prefer single-fund opens plus later [[Splicing]]. Interoperability failures usually show up as peers advertising mismatched feature bits or aborting interactive construction when input ownership proofs disagree.

			Peers that only implement single-funded opens can still connect. Dual funding activates only when both advertise <code>option_dual_fund</code> and complete the v2 handshake.


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

NotATether: Add implementation notes

2026-09-13T07:27:07Z

Add implementation notes

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

	Some implementations combine dual funding with zero-confirmation acceptance of the funding transaction among trusting peers. That speeds first receive but reintroduces [[Zero-confirmation transaction\|0-conf]] risk on the channel capacity itself until the funding outpoint confirms. Public dual-funded channels still need gossip announcement rules and reserve balances like any other public channel.		Some implementations combine dual funding with zero-confirmation acceptance of the funding transaction among trusting peers. That speeds first receive but reintroduces [[Zero-confirmation transaction\|0-conf]] risk on the channel capacity itself until the funding outpoint confirms. Public dual-funded channels still need gossip announcement rules and reserve balances like any other public channel.

			Core Lightning was an early production adopter of interactive funding and <code>option_dual_fund</code>. Other implementations expose subsets of the v2 open messages or prefer single-fund opens plus later [[Splicing]]. Interoperability failures usually show up as peers advertising mismatched feature bits or aborting interactive construction when input ownership proofs disagree.

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

NotATether: Add zeroconf funding caveat and public channels

2026-09-13T07:27:06Z

Add zeroconf funding caveat and public channels

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

	Interactive construction is shared with later channel updates that also rebuild funding, notably [[Splicing]]. Either peer may abort before signatures if the other's proposed inputs, outputs, or fees are unacceptable. Commitment transactions for the dual-funded channel still follow the ordinary Lightning penalty model after the funding outpoint is locked. Feature advertisement uses BOLT 9 bits 28 and 29. Implementations must agree on those bits before <code>open_channel2</code> is useful.		Interactive construction is shared with later channel updates that also rebuild funding, notably [[Splicing]]. Either peer may abort before signatures if the other's proposed inputs, outputs, or fees are unacceptable. Commitment transactions for the dual-funded channel still follow the ordinary Lightning penalty model after the funding outpoint is locked. Feature advertisement uses BOLT 9 bits 28 and 29. Implementations must agree on those bits before <code>open_channel2</code> is useful.

			Some implementations combine dual funding with zero-confirmation acceptance of the funding transaction among trusting peers. That speeds first receive but reintroduces [[Zero-confirmation transaction\|0-conf]] risk on the channel capacity itself until the funding outpoint confirms. Public dual-funded channels still need gossip announcement rules and reserve balances like any other public channel.

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

NotATether: Expand See also links

2026-09-12T21:10:45Z

Expand See also links

← Older revision		Revision as of 21:10, 12 September 2026
Line 9:		Line 9:
	== See also ==		== See also ==
	* [[Lightning Network]]		* [[Lightning Network]]
			* [[Splicing]]
			* [[Just-in-time channel]]
	* [[PSBT]]		* [[PSBT]]
	* [[Replace by fee]]		* [[Replace by fee]]

NotATether: Add mechanism: interactive abort and splicing relation

2026-09-12T21:10:43Z

Add mechanism: interactive abort and splicing relation

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

	Peers that support the feature exchange <code>open_channel2</code> and <code>accept_channel2</code>, then build the funding transaction interactively with <code>tx_add_input</code>, <code>tx_add_output</code>, remove messages, and <code>tx_complete</code>, followed by commitment setup and <code>tx_signatures</code>. Because both sides may contribute inputs, the unconfirmed funding transaction can be fee-bumped with [[Replace by fee]] by repeating interactive construction at a higher feerate. Dual funding does not by itself change HTLC routing. Both peers need on-chain UTXOs. A peer with no coins cannot dual-fund.		Peers that support the feature exchange <code>open_channel2</code> and <code>accept_channel2</code>, then build the funding transaction interactively with <code>tx_add_input</code>, <code>tx_add_output</code>, remove messages, and <code>tx_complete</code>, followed by commitment setup and <code>tx_signatures</code>. Because both sides may contribute inputs, the unconfirmed funding transaction can be fee-bumped with [[Replace by fee]] by repeating interactive construction at a higher feerate. Dual funding does not by itself change HTLC routing. Both peers need on-chain UTXOs. A peer with no coins cannot dual-fund.

			Interactive construction is shared with later channel updates that also rebuild funding, notably [[Splicing]]. Either peer may abort before signatures if the other's proposed inputs, outputs, or fees are unacceptable. Commitment transactions for the dual-funded channel still follow the ordinary Lightning penalty model after the funding outpoint is locked. Feature advertisement uses BOLT 9 bits 28 and 29. Implementations must agree on those bits before <code>open_channel2</code> is useful.

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

NotATether: Create Dual funding stub (BOLT 2 v2 open / option_dual_fund)

2026-09-12T02:51:06Z

Create Dual funding stub (BOLT 2 v2 open / option_dual_fund)

New page

'''Dual funding''' is a [[Lightning Network]] channel-opening protocol in which both peers can contribute inputs to the funding transaction, so the channel can open with a non-zero balance on both sides. It is the motivating use of the version 2 channel establishment flow in BOLT 2. Feature bits 28/29 advertise <code>option_dual_fund</code>.

The original Lightning open is single-funded: one peer pays the entire funding output and on-chain fees, and the other starts with no outbound liquidity until it receives payments or later adjusts the channel. Dual funding lets each peer put coins into the same 2-of-2 or Taproot funding output in one on-chain transaction.

Peers that support the feature exchange <code>open_channel2</code> and <code>accept_channel2</code>, then build the funding transaction interactively with <code>tx_add_input</code>, <code>tx_add_output</code>, remove messages, and <code>tx_complete</code>, followed by commitment setup and <code>tx_signatures</code>. Because both sides may contribute inputs, the unconfirmed funding transaction can be fee-bumped with [[Replace by fee]] by repeating interactive construction at a higher feerate. Dual funding does not by itself change HTLC routing. Both peers need on-chain UTXOs. A peer with no coins cannot dual-fund.

== See also ==
* [[Lightning Network]]
* [[PSBT]]
* [[Replace by fee]]
* [[Channel factory]]

== External links ==
* [https://bitcoinops.org/en/topics/dual-funding/ Bitcoin Optech: Dual funding]
* [https://github.com/lightning/bolts/blob/master/02-peer-protocol.md BOLT 2: Peer Protocol for Channel Management]
* [https://github.com/lightning/bolts/blob/master/09-features.md BOLT 9: Assigned Feature Flags]

[[Category:Technical]]