Eltoo

What Is Eltoo?

Eltoo (pronounced "L2") is a proposed upgrade to Lightning Network payment channels that fundamentally redesigns how channel state updates work. Proposed by Christian Decker, Rusty Russell, and Olaoluwa Osuntokun in 2018, eltoo introduces symmetric state channels where either party can publish any state, and later states automatically supersede earlier ones.

The name "eltoo" is a phonetic play on "L2" (Layer 2), reflecting its purpose as an improved foundation for Bitcoin's second layer. More recently, the proposal has also been referred to as "LN-Symmetry" to emphasize its symmetric nature, where both channel parties have identical capabilities and transaction structures.

Unlike current Lightning channels that use a penalty-based system called LN-Penalty, eltoo achieves security through a simple rule: newer states can always replace older states on-chain. This elegance comes at the cost of requiring changes to Bitcoin itself, specifically a new signature hash type called SIGHASH_ANYPREVOUT.

The Problem Eltoo Solves

Current Lightning Network channels use what's called the LN-Penalty mechanism. When you update a channel state (say, after sending or receiving a payment), both parties create new commitment transactions and exchange revocation keys for the old state. If someone tries to cheat by broadcasting an old, favorable state, the other party can use the revocation key to claim all funds in the channel as punishment.

This penalty system works, but creates several problems:

Toxic Waste

Every revoked channel state becomes "toxic waste." If you accidentally broadcast an old state (perhaps from a corrupted backup), your counterparty can take all channel funds. This happens even if you had no malicious intent. Old states are dangerous to store, dangerous to lose track of, and create asymmetric risk based on who has more funds in the channel.

Complex State Management

Nodes must store every historical state and its associated revocation data for the lifetime of the channel. For active channels with thousands of updates, this becomes significant storage and management overhead. Losing this data can result in catastrophic fund loss.

Backup Fragility

Channel backups in the current system are inherently risky. A backup made at state N becomes dangerous once the channel advances to state N+1. Restoring from an old backup could accidentally broadcast a revoked state, triggering a penalty and total fund loss.

Watchtower Complexity

Watchtowers that monitor for cheating attempts must store data for every possible old state. For channels with many updates, this creates substantial data requirements and makes watchtower services more expensive to operate.

How Eltoo Works

Eltoo replaces the penalty mechanism with a simpler "latest state wins" approach. Here's how the update process works:

1. Funding transaction: Like current channels, eltoo channels start with a funding transaction that locks funds into a 2-of-2 multisig output.
2. Update transactions: Each state change creates a new update transaction. Crucially, these update transactions can spend either the funding output OR any previous update transaction's output. This is the key innovation.
3. Settlement transactions: Each update has an associated settlement transaction that distributes funds according to that state. Settlement transactions have a timelock, giving the other party time to respond.
4. State number ordering: Each update carries an incrementing state number. Only transactions with higher state numbers can replace those with lower numbers.

If someone broadcasts an old state, the process is straightforward:

1. Old update transaction appears on-chain with state number N
2. Other party broadcasts their update transaction with state number M (where M > N)
3. The newer transaction replaces the older one before settlement can finalize
4. Final settlement reflects the correct, latest state

There is no punishment. The party who broadcast the old state simply loses the opportunity to settle with that state. They do not lose any funds beyond what they legitimately owed in the correct state.

SIGHASH_ANYPREVOUT Explained

The magic enabling eltoo is SIGHASH_ANYPREVOUT (BIP-118), a proposed new signature hash type for Bitcoin transactions. To understand why it's necessary, consider how Bitcoin signatures normally work.

Normal Signatures

When you sign a Bitcoin transaction, the signature commits to specific inputs, including the transaction ID (txid) of the output being spent. This means a signature is only valid for spending one specific output. You cannot reuse the signature to spend a different output, even one with identical script conditions.

ANYPREVOUT Signatures

SIGHASH_ANYPREVOUT changes this. A signature using ANYPREVOUT commits to the spending conditions (the script) but not to the specific txid of the input. This means the same signature can spend any output that has matching script conditions.

For eltoo, this is essential. Update transaction N+1 needs to be able to spend either:

• The original funding output (if no updates have been published)
• Update transaction N's output (if state N was published)
• Any earlier update transaction's output (if an old state was published)

All these outputs use the same script structure, so with ANYPREVOUT, a single presigned transaction can spend any of them. Without ANYPREVOUT, you would need separate signatures for every possible input, making the system impractical.

Benefits of Eltoo

No Toxic Waste

Old states are not dangerous in eltoo. Broadcasting an outdated state does not result in fund loss; it simply gets replaced by the current state. This dramatically reduces operational risk and makes channel management less stressful.

Simple Backups

Since any state can be safely broadcast, backups become trivial. You only need to store your latest state. Even if you restore from an older backup, you just lose the opportunity to claim the latest state, not all your funds.

Efficient Watchtowers

Watchtowers only need to store the latest state for each channel, not every historical state. This reduces storage requirements from O(n) to O(1) where n is the number of state updates, making watchtower services much more scalable.

Multiparty Channels

Eltoo naturally extends to channels with more than two participants. The penalty system becomes exponentially complex with more parties, but eltoo's "latest wins" rule works the same regardless of participant count. This enables channel factories and other multi-party constructions.

Symmetric Roles

Both parties in an eltoo channel have identical transaction structures and capabilities. This symmetry simplifies implementation, reduces code complexity, and makes the protocol easier to reason about and audit.

Current Status and Timeline

Eltoo cannot be deployed today because SIGHASH_ANYPREVOUT requires a Bitcoin soft fork. The BIP-118 proposal has been under discussion since 2017, with various revisions and refinements.

BIP-118 Status

BIP-118 specifies two new signature hash types: SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT. The proposal is well-specified and has working implementations, but has not achieved the consensus needed for activation. Key considerations include:

• Technical readiness: The specification is mature and implementations exist in Bitcoin Core forks
• Safety analysis: Extensive review has not revealed critical issues, but soft forks receive intense scrutiny
• Ecosystem demand: While Lightning developers want ANYPREVOUT, broader community consensus is needed for activation

Alternative Proposals

Some researchers have explored ways to achieve eltoo-like benefits without ANYPREVOUT using existing opcodes or other proposed upgrades like OP_CHECKTEMPLATEVERIFY (CTV). These alternatives generally involve trade-offs in flexibility or efficiency compared to the full eltoo design.

Limitations and Trade-offs

Requires Soft Fork

The fundamental limitation is that eltoo cannot be deployed without changes to Bitcoin. Soft forks are intentionally difficult to activate, requiring broad community consensus. There is no certain timeline for SIGHASH_ANYPREVOUT activation.

No Punishment for Cheating

Unlike LN-Penalty where cheaters lose their entire channel balance, eltoo cheaters face no financial penalty. They simply fail to settle with the old state. Some argue this reduces the disincentive to attempt fraud, though the practical attack benefit is minimal.

On-Chain Footprint

If an old state is broadcast, correcting it requires an additional on-chain transaction. In high-fee environments, this correction cost could be significant. LN-Penalty settles in one transaction (the penalty), while eltoo might require multiple transactions if states are contested.

New Protocol Complexity

While eltoo simplifies state management, adopting it requires substantial changes to Lightning implementations. The entire channel update logic, transaction structure, and cooperative close procedures would need rewriting. This represents a significant engineering investment.

FAQ