Eltoo - Revision history

NotATether: Add Update and settlement and Deployment sections

2026-09-13T07:28:50Z

Add Update and settlement and Deployment sections

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

	Today's Lightning channels use Poon–Dryja revocation. Each state update exchanges revocation secrets for the prior commitment. If an old commitment is broadcast, the other party can sweep the cheater's funds after a delay. Eltoo replaces punishment-as-primary-security with a latest-state-wins rule. Publishing an old update is mainly a fee cost if the honest party can still put a newer update on chain before settlement finalizes. Both parties can hold identical transaction sets. Without a soft fork, Bitcoin Script cannot express that rebinding behavior for Taproot spends in the form eltoo needs. Until such a rule activates on mainnet, eltoo channels remain limited to signet, regtest, and research implementations. Related [[Channel factory\|channel factory]] and multiparty designs often assume eltoo or an equivalent covenant because revocation trees scale poorly with the number of participants.		Today's Lightning channels use Poon–Dryja revocation. Each state update exchanges revocation secrets for the prior commitment. If an old commitment is broadcast, the other party can sweep the cheater's funds after a delay. Eltoo replaces punishment-as-primary-security with a latest-state-wins rule. Publishing an old update is mainly a fee cost if the honest party can still put a newer update on chain before settlement finalizes. Both parties can hold identical transaction sets. Without a soft fork, Bitcoin Script cannot express that rebinding behavior for Taproot spends in the form eltoo needs. Until such a rule activates on mainnet, eltoo channels remain limited to signet, regtest, and research implementations. Related [[Channel factory\|channel factory]] and multiparty designs often assume eltoo or an equivalent covenant because revocation trees scale poorly with the number of participants.

			== Update and settlement ==

	An eltoo update transaction spends the previous update output and creates a new one controlled by both parties. A settlement transaction spends the latest update output after a relative delay and pays the agreed balances. Because every update can rebind to any earlier update output under ANYPREVOUT-style sighashes, the on-chain race favors the highest state number the honest party can still broadcast. Factories and multiparty channels benefit because participants do not need a growing tree of pairwise revocation secrets for every historical state.		An eltoo update transaction spends the previous update output and creates a new one controlled by both parties. A settlement transaction spends the latest update output after a relative delay and pays the agreed balances. Because every update can rebind to any earlier update output under ANYPREVOUT-style sighashes, the on-chain race favors the highest state number the honest party can still broadcast. Factories and multiparty channels benefit because participants do not need a growing tree of pairwise revocation secrets for every historical state.

			State numbers and relative delays must be agreed in the channel parameters so both parties can recognize a strictly later update without interactive revocation secrets.

			== Deployment ==

	Until BIP 118 or an equivalent rebindable signature rule activates, implementations can only emulate the protocol on networks that already enable those opcodes. Research clients on signet demonstrate the state machine. Mainnet Lightning continues to use Poon–Dryja revocation and [[Watchtower\|watchtowers]] for offline defense.		Until BIP 118 or an equivalent rebindable signature rule activates, implementations can only emulate the protocol on networks that already enable those opcodes. Research clients on signet demonstrate the state machine. Mainnet Lightning continues to use Poon–Dryja revocation and [[Watchtower\|watchtowers]] for offline defense.

			AnyPREVOUT remains a soft-fork discussion. Until it or BIP 448-style rebindable signatures activate, eltoo stays a design target for factories and research networks rather than a default Lightning channel type.


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

NotATether: Expand See also links

2026-09-12T21:13:01Z

Expand See also links

← Older revision		Revision as of 21:13, 12 September 2026
Line 12:		Line 12:
	* [[Payment channels]]		* [[Payment channels]]
	* [[Channel factory]]		* [[Channel factory]]
	* [[~~Hashed Timelock~~ Contracts]]		* [[Watchtower]]
			* [[Hash Time Locked Contracts]]

	== External links ==		== External links ==

NotATether: Add deployment status versus Poon-Dryja

2026-09-12T21:12:59Z

Add deployment status versus Poon-Dryja

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

	An eltoo update transaction spends the previous update output and creates a new one controlled by both parties. A settlement transaction spends the latest update output after a relative delay and pays the agreed balances. Because every update can rebind to any earlier update output under ANYPREVOUT-style sighashes, the on-chain race favors the highest state number the honest party can still broadcast. Factories and multiparty channels benefit because participants do not need a growing tree of pairwise revocation secrets for every historical state.		An eltoo update transaction spends the previous update output and creates a new one controlled by both parties. A settlement transaction spends the latest update output after a relative delay and pays the agreed balances. Because every update can rebind to any earlier update output under ANYPREVOUT-style sighashes, the on-chain race favors the highest state number the honest party can still broadcast. Factories and multiparty channels benefit because participants do not need a growing tree of pairwise revocation secrets for every historical state.

			Until BIP 118 or an equivalent rebindable signature rule activates, implementations can only emulate the protocol on networks that already enable those opcodes. Research clients on signet demonstrate the state machine. Mainnet Lightning continues to use Poon–Dryja revocation and [[Watchtower\|watchtowers]] for offline defense.

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

NotATether: Add mechanism: update and settlement transactions

2026-09-12T21:12:57Z

Add mechanism: update and settlement transactions

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

	Today's Lightning channels use Poon–Dryja revocation. Each state update exchanges revocation secrets for the prior commitment. If an old commitment is broadcast, the other party can sweep the cheater's funds after a delay. Eltoo replaces punishment-as-primary-security with a latest-state-wins rule. Publishing an old update is mainly a fee cost if the honest party can still put a newer update on chain before settlement finalizes. Both parties can hold identical transaction sets. Without a soft fork, Bitcoin Script cannot express that rebinding behavior for Taproot spends in the form eltoo needs. Until such a rule activates on mainnet, eltoo channels remain limited to signet, regtest, and research implementations. Related [[Channel factory\|channel factory]] and multiparty designs often assume eltoo or an equivalent covenant because revocation trees scale poorly with the number of participants.		Today's Lightning channels use Poon–Dryja revocation. Each state update exchanges revocation secrets for the prior commitment. If an old commitment is broadcast, the other party can sweep the cheater's funds after a delay. Eltoo replaces punishment-as-primary-security with a latest-state-wins rule. Publishing an old update is mainly a fee cost if the honest party can still put a newer update on chain before settlement finalizes. Both parties can hold identical transaction sets. Without a soft fork, Bitcoin Script cannot express that rebinding behavior for Taproot spends in the form eltoo needs. Until such a rule activates on mainnet, eltoo channels remain limited to signet, regtest, and research implementations. Related [[Channel factory\|channel factory]] and multiparty designs often assume eltoo or an equivalent covenant because revocation trees scale poorly with the number of participants.

			An eltoo update transaction spends the previous update output and creates a new one controlled by both parties. A settlement transaction spends the latest update output after a relative delay and pays the agreed balances. Because every update can rebind to any earlier update output under ANYPREVOUT-style sighashes, the on-chain race favors the highest state number the honest party can still broadcast. Factories and multiparty channels benefit because participants do not need a growing tree of pairwise revocation secrets for every historical state.

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

NotATether: fix PoonDryja en-dash (restore approved wording)

2026-09-06T07:53:15Z

fix PoonDryja en-dash (restore approved wording)

← Older revision		Revision as of 07:53, 6 September 2026
Line 1:		Line 1:
	'''Eltoo''' (also called '''LN-Symmetry''') is a proposed [[Lightning Network]] channel update mechanism in which any later channel state can replace any earlier state on chain without a punitive justice transaction. The paper ''eltoo: A Simple Layer2 Protocol for Bitcoin'' by Christian Decker, Rusty Russell, and Olaoluwa Osuntokun described update and settlement transactions that rebind to prior outputs. Deploying that pattern on Bitcoin requires a consensus change that makes signatures rebindable across different prevouts, commonly discussed as [https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki BIP 118] <code>SIGHASH_ANYPREVOUT</code> or later Taproot-native covenant bundles such as BIP 448.		'''Eltoo''' (also called '''LN-Symmetry''') is a proposed [[Lightning Network]] channel update mechanism in which any later channel state can replace any earlier state on chain without a punitive justice transaction. The paper ''eltoo: A Simple Layer2 Protocol for Bitcoin'' by Christian Decker, Rusty Russell, and Olaoluwa Osuntokun described update and settlement transactions that rebind to prior outputs. Deploying that pattern on Bitcoin requires a consensus change that makes signatures rebindable across different prevouts, commonly discussed as [https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki BIP 118] <code>SIGHASH_ANYPREVOUT</code> or later Taproot-native covenant bundles such as BIP 448.

	Today's Lightning channels use ~~PoonDryja~~ revocation. Each state update exchanges revocation secrets for the prior commitment. If an old commitment is broadcast, the other party can sweep the cheater's funds after a delay. Eltoo replaces punishment-as-primary-security with a latest-state-wins rule. Publishing an old update is mainly a fee cost if the honest party can still put a newer update on chain before settlement finalizes. Both parties can hold identical transaction sets. Without a soft fork, Bitcoin Script cannot express that rebinding behavior for Taproot spends in the form eltoo needs. Until such a rule activates on mainnet, eltoo channels remain limited to signet, regtest, and research implementations. Related [[Channel factory\|channel factory]] and multiparty designs often assume eltoo or an equivalent covenant because revocation trees scale poorly with the number of participants.		Today's Lightning channels use Poon–Dryja revocation. Each state update exchanges revocation secrets for the prior commitment. If an old commitment is broadcast, the other party can sweep the cheater's funds after a delay. Eltoo replaces punishment-as-primary-security with a latest-state-wins rule. Publishing an old update is mainly a fee cost if the honest party can still put a newer update on chain before settlement finalizes. Both parties can hold identical transaction sets. Without a soft fork, Bitcoin Script cannot express that rebinding behavior for Taproot spends in the form eltoo needs. Until such a rule activates on mainnet, eltoo channels remain limited to signet, regtest, and research implementations. Related [[Channel factory\|channel factory]] and multiparty designs often assume eltoo or an equivalent covenant because revocation trees scale poorly with the number of participants.

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

NotATether: create Eltoo stub (LN-Symmetry, BIP 118 ANYPREVOUT, not activated)

2026-09-06T07:50:00Z

create Eltoo stub (LN-Symmetry, BIP 118 ANYPREVOUT, not activated)

New page

'''Eltoo''' (also called '''LN-Symmetry''') is a proposed [[Lightning Network]] channel update mechanism in which any later channel state can replace any earlier state on chain without a punitive justice transaction. The paper ''eltoo: A Simple Layer2 Protocol for Bitcoin'' by Christian Decker, Rusty Russell, and Olaoluwa Osuntokun described update and settlement transactions that rebind to prior outputs. Deploying that pattern on Bitcoin requires a consensus change that makes signatures rebindable across different prevouts, commonly discussed as [https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki BIP 118] <code>SIGHASH_ANYPREVOUT</code> or later Taproot-native covenant bundles such as BIP 448.

Today's Lightning channels use PoonDryja revocation. Each state update exchanges revocation secrets for the prior commitment. If an old commitment is broadcast, the other party can sweep the cheater's funds after a delay. Eltoo replaces punishment-as-primary-security with a latest-state-wins rule. Publishing an old update is mainly a fee cost if the honest party can still put a newer update on chain before settlement finalizes. Both parties can hold identical transaction sets. Without a soft fork, Bitcoin Script cannot express that rebinding behavior for Taproot spends in the form eltoo needs. Until such a rule activates on mainnet, eltoo channels remain limited to signet, regtest, and research implementations. Related [[Channel factory|channel factory]] and multiparty designs often assume eltoo or an equivalent covenant because revocation trees scale poorly with the number of participants.

== See also ==

* [[Lightning Network]]
* [[Payment channels]]
* [[Channel factory]]
* [[Hashed Timelock Contracts]]

== External links ==

* [https://blockstream.com/eltoo.pdf eltoo: A Simple Layer2 Protocol for Bitcoin]
* [https://bitcoinops.org/en/topics/eltoo/ Bitcoin Optech: Eltoo]
* [https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki BIP 118: SIGHASH_ANYPREVOUT for Taproot Scripts]
* [https://github.com/bitcoin/bips/blob/master/bip-0448.md BIP 448: Taproot-native (Re)bindable Transactions]

[[Category:Technical]]