A complete redesign of the Lightning Network's channel update mechanism. Instead of asymmetric punishment-based revocation, Eltoo uses SIGHASH_ANYPREVOUT to make any newer state replace any older state — elegantly and symmetrically.
The original Poon-Dryja payment channel protocol (2015) made Lightning possible, but at the cost of significant complexity. Understanding why it is complex explains exactly what Eltoo solves.
Every time Alice and Bob update their channel state (i.e., make a payment), the following happens:
The Poon-Dryja design prevents double-spending by making old states punishable. But punishment requires asymmetric transactions (each party signs a different version), which requires storing revocation data for every state ever created, which requires permanent watchtower monitoring. This cascade of complexity is structural, not accidental.
"eltoo: A Simple Layer2 Protocol for Bitcoin" — Christian Decker, Rusty Russell, Olaoluwa Osuntokun (2018)
The name "eltoo" is a play on "L2" (ell-too / Layer Two). Later renamed LN-Symmetry in the BIP process.
Instead of making old states punishable, make them replaceable. Any newer state can overwrite any older state on-chain — not by penalizing the cheater, but by the protocol structure itself.
The magic ingredient is a new Bitcoin signature hash flag: SIGHASH_ANYPREVOUT (APO), proposed in BIP118.
Because the signature for state #10 does not commit to which UTXO it spends — only to the script and value — it can spend any output with the same script and value.
This means: a signature created for state #10 can spend the output of state #7, state #8, OR state #9. The newer state can consume any older state's output!
Walk through the same scenario — Alice and Bob open a channel, make 5 payments, then close — in both protocols simultaneously.
Alice cheats by broadcasting old state #2 after the channel has reached state #5.
| Sighash Flag | Commits to Inputs | Commits to Outputs | Commits to UTXO | Notes |
|---|---|---|---|---|
SIGHASH_ALL |
✅ All | ✅ All | ✅ txid+vout | Current standard. Most restrictive. |
SIGHASH_SINGLE |
✅ All | ⚠️ Corresponding only | ✅ txid+vout | Allows adding outputs; UTXO still pinned. |
SIGHASH_NOINPUT |
❌ None | ✅ All | ❌ Not committed | Rejected — too dangerous (replay risk). |
SIGHASH_ANYPREVOUT BIP118 |
✅ Current input | ✅ All | ⚠️ Script + Value only | The Eltoo ingredient. Commits to script and amount, NOT to txid/vout. |
SIGHASH_ANYPREVOUTANYSCRIPT |
✅ Current input | ✅ All | ❌ Only value | Even more flexible variant; not committing to script either. |
Click on fields to see their role in the signature. Green = committed (signature binds to this). Red = not committed (flexible).
If a signature doesn't commit to the specific UTXO it spends, could an attacker take Alice's signature for her channel and use it to steal from a different channel?
No. The signature still commits to the scriptCode and value. A different channel has a different script (different public keys). The signature will not verify against a different channel's script.
Within the same channel: old states can be spent by later states — and this is precisely what Eltoo exploits by design. It's a feature, not a bug.
Eltoo uses three distinct transaction types. Understanding their structure reveals how replacement works at the Bitcoin protocol level.
Published on-chain once to open the channel. Identical to current Lightning.
Off-chain normally. Published on-chain during dispute. Uses APO signature.
The actual balance split. Published to close channel after update tx confirms.
The state number encoded in nLocktime is what makes replacement ordered. The update tx script verifies that the spending tx's locktime is at least as large as the current state. This means:
Lightning Network's routing relies on HTLCs. Eltoo must accommodate them within its symmetric update/settlement model.
In current LN, HTLC outputs are attached directly to commitment transactions. Each pending payment adds an output. In Eltoo, settlement transactions serve this role — but Eltoo replaces the entire update+settlement pair atomically when state changes.
Settlement transactions include HTLC outputs just like current LN. When a new state is needed (HTLC added, HTLC resolved), both the update tx and settlement tx are replaced together. Only the latest pair is relevant.
Click any row to expand for detailed explanation.
| Property | Current LN (Poon-Dryja) | Eltoo / LN-Symmetry |
|---|---|---|
| Transaction Symmetry | ❌ Asymmetric — Alice's tx ≠ Bob's tx. Each encodes whose perspective. | ✅ Symmetric — Alice and Bob sign the exact same update and settlement txs. |
| In Poon-Dryja, Alice holds Bob's commitment (pays Bob if Alice cheats) and vice versa. They're mirror-images with opposite HTLCs. Eltoo uses a shared settlement tx that both parties can publish, removing all asymmetry. | ||
| Revocation Keys | ❌ Required — O(N) revocation keys must be stored per channel. | ✅ Not needed — No revocation mechanism. Latest state wins by APO. |
| Current LN requires both parties to store a revocation preimage for EVERY prior state. After 10,000 payments, that's 10,000 keys. Eltoo eliminates this entirely — only the latest state matters, and it always wins due to the state number ordering. | ||
| Punishment / Penalty | ✅ Strong penalty — Cheat = lose ALL funds to the victim. | ⚠️ No penalty — Cheater loses nothing extra, but cheating fails. |
| This is philosophically significant. Poon-Dryja's penalty is a strong economic deterrent. Eltoo's argument: if cheating simply cannot succeed (latest state always replaces old state), why punish? The structural prevention is sufficient. The debate is whether the absence of punishment creates weaker incentives — see Section 7 philosophy cards below. | ||
| Watchtower Requirements | ❌ High — Must watch 24/7. Must store ALL revocation keys. Miss = lose all. | ✅ Low — Only needs latest state tx. Can respond anytime within update window. |
| Current LN watchtowers (PISA, Cerberus, etc.) must track a growing database of revocation keys per channel. If they lose a key, they cannot protect against that specific old state. Eltoo watchtowers just need the latest update tx — a constant-size payload — and can respond at any time during the update window (which can be set to days or weeks). | ||
| Storage per Channel | ❌ O(N) — Grows with number of payments. | ✅ O(1) — Only latest update + settlement tx needed. |
| For a channel with 1 million micro-payments (common in streaming sats scenarios), Poon-Dryja requires 1 million revocation secrets stored by each party. Eltoo requires storing exactly two transactions regardless of payment count: the latest update tx and the latest settlement tx. | ||
| Update Complexity | ❌ High — 2 txs created, 2 keys exchanged per payment. | ✅ Low — 1 symmetric tx pair, no key exchange. |
| The current update protocol is a carefully choreographed dance: Alice signs her commitment, Bob signs his, then revocation keys are exchanged in a specific order to prevent either party from using the old state. Eltoo reduces this to: both parties sign the same new settlement tx and update tx. | ||
| Bitcoin Soft Fork Needed | ✅ No — Already deployed (Taproot for latest features). | ❌ Yes — Requires BIP118 (SIGHASH_ANYPREVOUT) activation. |
| This is Eltoo's primary obstacle. BIP118 requires broad Bitcoin community consensus and miner activation signaling. The LNHANCE proposal bundles it with BIP119 (CTV) and BIP345, which some see as controversial. No activation timeline is currently confirmed. | ||
| Multi-Party Channels | ❌ Very Complex — Revocation grows combinatorially with N parties. | ✅ Feasible — Symmetric design scales to N parties naturally. |
| A 3-party channel in Poon-Dryja requires each pair of participants to maintain revocation keys for all historical states of the full channel — combinatorially explosive. Eltoo's symmetric structure means an N-party channel just needs all N parties to sign each new state update, with no extra revocation overhead. | ||
| Channel Factories | ❌ Complex — Revocation propagation across factory layers is hard. | ✅ Simpler — Replacement semantics compose cleanly with factory structure. |
| Channel factories allow multiple channels to be created from a single on-chain UTXO. In Poon-Dryja, the factory layer and channel layer each need revocation logic, creating complex interactions. Eltoo's "latest state always wins" property works recursively — factories become much more practical. | ||
| Implementation Complexity | ❌ High — Revocation key management, asymmetric tx construction, penalty logic. | ✅ Lower — No revocation module, symmetric construction, simpler dispute logic. |
| The current LN implementations (LND, CLN, Eclair) all contain significant complexity around revocation key derivation, storage, and penalty transaction construction. Eltoo eliminates this entire subsystem. The remaining complexity is in the APO signature construction and the update/settlement layering. | ||
Both approaches prevent successful cheating. The difference is in the consequences of attempting to cheat. Eltoo's approach enables simpler construction of channel factories and multi-party channels — arguably the bigger win for long-term Lightning scalability. For most users, the practical difference is that Eltoo makes Lightning safer: a lost backup or misconfigured wallet that accidentally broadcasts an old state won't result in total fund loss.
The protocol was renamed from "eltoo" (a play on "LToo" / "Layer Too") to LN-Symmetry in the BIP development process. The new name better describes the core property: symmetric channel update transactions that are identical for both parties.
BIP118 is being discussed alongside other Bitcoin script improvements under the LNHANCE proposal:
The combined LNHANCE proposal remains in active discussion as of 2026. Proponents argue bundling creates stronger activation pressure. Critics prefer evaluating each BIP independently. No activation mechanism (BIP9/BIP8) has been selected.
The entire revocation subsystem (key derivation, storage, breach detection, justice transactions) can be removed. LND, CLN, Eclair implementations become significantly simpler and safer.
Multi-party channel pools created from a single on-chain tx become practical. A group of 10 users can open channels with each other using 1 on-chain tx instead of 45 (all-pairs). Massive fee savings.
Watchtowers only need the latest update tx — a constant-size payload. No growing database of revocation keys. More parties can realistically offer watchtower services. Privacy: watchtower learns only current state, not history.
Accidental broadcast of old state (e.g., restoring an old backup) no longer catastrophically penalizes the user. The other party simply publishes the newer state — both get their correct balances.
N-party channel pools become feasible. Combined with Taproot's key aggregation (MuSig2), an N-party Eltoo channel looks like a single Taproot keypath spend on-chain — indistinguishable from a regular transaction.
The symmetric structure of Eltoo maps more cleanly onto post-quantum signature schemes (Dilithium, SPHINCS+) that were designed without the asymmetric revocation pattern in mind.
Eltoo / LN-Symmetry represents not just an incremental improvement but a fundamental architectural simplification of the Lightning Network. By replacing the punishment-based revocation mechanism with a structurally sound replacement mechanism, it eliminates an entire category of complexity — and enables channel factories that could scale Lightning to hundreds of millions of users.
The cost: a Bitcoin soft fork. The benefit: a simpler, safer, more scalable payment channel network that makes Lightning development easier and Lightning usage safer for everyone.