LN-Symmetry (Eltoo)

What Is LN-Symmetry?

LN-Symmetry is a proposed upgrade to the Lightning Network's channel update mechanism that replaces the current penalty-based enforcement (called LN-Penalty) with a simpler symmetric design. Originally published in 2018 as eltoo by Christian Decker, Rusty Russell, and Olaoluwa Osuntokun, the protocol was renamed "LN-Symmetry" by Greg Sanders during his proof-of-concept implementation to highlight its defining property: both channel participants hold identical transaction data and have identical capabilities.

In the current LN-Penalty system, publishing an outdated channel state triggers a penalty transaction that allows the counterparty to claim all channel funds. This creates asymmetric information (each party holds different revocation data) and generates "toxic waste" in the form of old revocation keys that must be stored indefinitely. LN-Symmetry eliminates both problems by allowing any later state to simply override any earlier state on-chain, with no punishment involved.

The trade-off is clear: LN-Symmetry requires a Bitcoin soft fork to deploy, specifically SIGHASH_ANYPREVOUT (BIP-118) or an equivalent covenant mechanism. No activation timeline currently exists.

How It Works

LN-Symmetry uses three transaction types that work together to enforce the "latest state wins" rule. Understanding these transactions and how they interact reveals why the protocol is both simpler and more flexible than LN-Penalty.

Funding Transaction

Like current Lightning channels, an LN-Symmetry channel begins with a funding transaction that locks bitcoin into a 2-of-2 multisig output. This output has two spending paths:

• An update path with no timelock, allowing either party to attach a new update transaction immediately
• A settlement path with a relative timelock (enforced via OP_CSV), allowing final balance distribution after a configurable delay

Update Transactions

Each channel state produces a new update transaction carrying an incrementing state number encoded in the nLockTime field. The state number creates strict ordering: update transaction number 50 can spend the output of update transaction number 10 (or any earlier update), but not vice versa. This ordering is enforced on-chain via OP_CHECKLOCKTIMEVERIFY.

The critical innovation is that update transactions are "floating": they can spend any prior update output or the original funding output without needing separate signatures for each case. This is what requires SIGHASH_ANYPREVOUT: a signature type that commits to the spending script but not to the specific UTXO being spent.

Settlement Transactions

Each update transaction has a corresponding settlement transaction that distributes funds according to the agreed balance. Settlement transactions include a relative timelock (typically hours to days), creating a window during which the counterparty can respond with a newer update if the published state is outdated.

Dispute Resolution

When a party broadcasts an old state, the resolution process is straightforward:

1. Party A broadcasts update transaction with state number 5 (an outdated state)
2. Party B detects this and broadcasts their update transaction with state number 100
3. The newer update "rebinds" to spend the old update's output, skipping all intermediate states
4. After the settlement timelock expires, Party B's settlement transaction distributes funds correctly

The worst-case on-chain footprint is three transactions: funding, final update, and settlement. Compare this with LN-Penalty, where a dispute involving HTLCs may require multiple justice transactions to resolve.

Transaction Structure

The simplified structure of an LN-Symmetry update and settlement pair:

// Update Transaction (state N)
Input:  funding_output OR any prior update_output
        (SIGHASH_ANYPREVOUT signature)
Output: shared_update_script
        nLockTime: 500_000_000 + N  (state number)

// Settlement Transaction (for state N)
Input:  update_N_output (after CSV delay)
Output: alice_balance, bob_balance
        (plus any pending HTLCs)

LN-Symmetry vs. LN-Penalty

The differences between LN-Symmetry and the current LN-Penalty mechanism extend across security model, storage, operational complexity, and extensibility.

Why It Matters

LN-Symmetry addresses several fundamental friction points in the current Lightning Network that affect both operators and end users.

Eliminating Toxic Waste

In LN-Penalty, every revoked channel state is a liability. If a node crashes and restores from an outdated backup, it risks broadcasting a revoked commitment transaction and losing its entire channel balance. This has caused real fund losses and makes Lightning node operation inherently fragile for less sophisticated users.

LN-Symmetry removes this class of failure entirely. Broadcasting an old state is harmless: the counterparty simply publishes the correct state, and funds are distributed according to the latest agreed balance. The operator who broadcast the old state loses only the on-chain transaction fees.

Simplified Watchtowers

Current watchtowers must store revocation data for every prior state of every channel they monitor. For a watchtower serving thousands of active channels, each with thousands of state updates, this storage grows rapidly.

With LN-Symmetry, a watchtower needs only the latest update and settlement transaction per channel. This reduces storage to a few kilobytes per channel regardless of channel lifetime, making watchtower services dramatically cheaper and more scalable. For a deeper analysis, see the watchtower architecture deep dive.

Enabling Multiparty Channels

LN-Penalty struggles with more than two participants because the penalty mechanism creates an "innocent bystander" problem: if three parties share a channel and one cheats, the first honest party to detect the fraud could claim penalty funds while the other honest party loses out.

LN-Symmetry's "latest state wins" rule works identically regardless of participant count. This enables channel factories where a single on-chain UTXO supports multiple sub-channels that can be dynamically rebalanced. For more on how channel factories could transform Lightning scalability, see the channel factories research article.

Hardware Wallet Compatibility

The constant storage requirement makes LN-Symmetry viable for devices with limited persistent storage, including hardware wallets and embedded systems. Current LN-Penalty channels are impractical for these devices because they cannot reliably store the growing set of revocation data.

Use Cases

• Long-lived payment channels: channels that remain open for months or years accumulate thousands of states under LN-Penalty, each requiring storage. LN-Symmetry keeps storage constant regardless of channel age.
• Channel factories and multiparty constructions: groups of users can share a single on-chain UTXO and create, resize, or close sub-channels among themselves without additional on-chain transactions.
• Mobile Lightning wallets: phones and tablets with unreliable connectivity benefit from safe backup restoration. An LN-Symmetry wallet can restore from any prior state without risking fund loss.
• Lightweight watchtower networks: service providers can monitor channels at minimal cost, reducing the barrier to entry for watchtower operation and improving network-wide security.
• Layer 2 protocols beyond Lightning: the symmetric update mechanism can serve as a building block for other off-chain protocols, including virtual channels and timeout trees.

Implementation Progress

While LN-Symmetry cannot be deployed on Bitcoin mainnet without a soft fork, significant implementation work has been completed on test networks.

Proof-of-Concept on Signet

Greg Sanders built a working LN-Symmetry implementation using a modified version of Core Lightning running against Bitcoin Inquisition (a signet fork for testing proposed consensus changes). The implementation successfully demonstrated channel opening and closing, payment routing with "fast-forwards," unilateral closes, and reconnection logic.

Key findings from the proof-of-concept included that eltoo-style channels require approximately twice the HTLC expiry delta compared to LN-Penalty channels, because the settlement timelock must expire before HTLC timelocks can begin counting down. This "2x delay problem" means LN-Symmetry channels need longer timelock windows, which increases capital lockup during routing.

BIP-446 and BIP-448

In early 2026, BIP-446 (OP_TEMPLATEHASH) and BIP-448 (Taproot-native Re-bindable Transactions) reached draft status as formal Bitcoin Improvement Proposals. Co-authored by Greg Sanders, Antoine Poinsot, and Steven Roose, these proposals bundle OP_TEMPLATEHASH with OP_CHECKSIGFROMSTACK to provide an alternative path to enabling LN-Symmetry without requiring SIGHASH_ANYPREVOUT. This represents the first complete Taproot-native covenant bundle to reach the official Bitcoin standards track.

Risks and Considerations

Reduced Cheating Deterrent

LN-Penalty punishes cheaters by confiscating their entire channel balance. LN-Symmetry imposes no such penalty: a party broadcasting an old state loses only the transaction fees paid. While cheating still fails (the counterparty publishes the correct state), the absence of harsh punishment may reduce the disincentive to attempt fraud. Researchers have proposed optional penalty extensions that could be layered on top of the base LN-Symmetry protocol.

Soft Fork Dependency

LN-Symmetry requires changes to Bitcoin's consensus rules. Whether through BIP-118 (SIGHASH_ANYPREVOUT) or the BIP-446/BIP-448 covenant bundle, a soft fork must be activated before LN-Symmetry can reach mainnet. Bitcoin soft forks intentionally require broad community consensus and have no guaranteed timeline. For context on how OP_CHECKTEMPLATEVERIFY and other covenant proposals relate, see the covenants research article.

Doubled HTLC Expiry Deltas

The proof-of-concept revealed that LN-Symmetry channels need roughly twice the HTLC expiry delta of LN-Penalty channels. This happens because the settlement transaction's relative timelock must expire before any HTLC timeouts can begin counting down. Longer deltas mean more capital locked for longer during payment routing, which could affect routing economics and channel competitiveness.

Transaction Pinning

During proof-of-concept development, preventing transaction pinning attacks consumed approximately one-third of engineering effort. Pinning attacks exploit mempool policy rules to prevent legitimate transactions from confirming. While solutions exist (including v3 transactions and ephemeral anchors), they add protocol complexity.

Migration Complexity

Adopting LN-Symmetry would require Lightning implementations to rewrite their channel update logic, transaction structures, and cooperative close procedures. Existing channels would need to be closed and reopened (or migrated via splicing), and the network would likely run both LN-Penalty and LN-Symmetry channels in parallel during a transition period.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.