Eltoo
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 BIP 118 SIGHASH_ANYPREVOUT or later Taproot-native covenant bundles such as BIP 448.
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 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.
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 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.