Eltoo / LN-Symmetry

LN-Penalty (Current Mechanism) Problems:

1. Asymmetric State
   Alice's commitment tx != Bob's commitment tx
   Each update produces two different transactions
   Increases complexity and potential errors

2. State Storage Burden
   Each channel update requires storing:
   • New commitment tx
   • Peer's revocation key
   • All HTLC timeout/success transactions

   10,000 updates ~ several GB of data!

3. Penalty Mechanism Risks
   • Must store all old states
   • Lost old states = cannot penalize cheater
   • Watchtower needs massive storage

4. Toxic State
   • Accidentally broadcasting old state may cause total loss
   • Hardware failure can cause disaster
   • Complex backup requirements

Eltoo Core Concept:

Symmetric State:
Alice and Bob use the same update tx and settle tx

         Funding TX
         (2-of-2 multisig)
              |
              v
         Update TX (state n)
         Can be overwritten by state n+1
              |
              v
         Settlement TX
         Final balance distribution to Alice and Bob

Key Features:
• Anyone can "overwrite" old state with newer state
• No penalty mechanism needed
• Only need to store latest state

SIGHASH_ANYPREVOUT Explained:

Traditional signature (SIGHASH_ALL):
  Signature commits to = Hash(
    all inputs (including txid and vout) +
    all outputs
  )
  -> Signature bound to specific input UTXO

ANYPREVOUT:
  Signature commits to = Hash(
    input's scriptPubKey (not txid/vout) +
    all outputs
  )
  -> Signature not bound to specific UTXO, can attach to any compatible output

This means:
  Update TX n+1 signature can spend:
  • Funding TX output
  • Or Update TX n output
  • Or any earlier Update TX output

  As long as output script is compatible!

Eltoo State Transitions:

Initial state:
Funding TX --[state 0]--> Update TX 0 --> Settlement TX 0
                          Alice: 5 BTC
                          Bob:   5 BTC

Alice pays 1 BTC to Bob:
Funding TX --[state 1]--> Update TX 1 --> Settlement TX 1
                          Alice: 4 BTC
                          Bob:   6 BTC

Bob pays 2 BTC to Alice:
Funding TX --[state 2]--> Update TX 2 --> Settlement TX 2
                          Alice: 6 BTC
                          Bob:   4 BTC

Close channel (normal):
1. Both parties agree to use latest state
2. Broadcast Update TX 2
3. Wait for timelock
4. Broadcast Settlement TX 2

Close channel (someone cheats):
1. Alice broadcasts old Update TX 0
2. Bob notices, broadcasts Update TX 2
3. Update TX 2 "overwrites" Update TX 0
4. Settlement uses Settlement TX 2

No penalty! Just restores to correct state.

Eltoo Transaction Structure:

Funding TX:
  Output:
    2-of-2 MuSig (Alice + Bob)
    or Taproot output

Update TX (state n):
  Input:
    Signed with SIGHASH_ANYPREVOUT
    Can spend Funding TX or any earlier Update TX

  Output:
    <state_n+1 pubkey> CHECKSIG
    or after CSV timelock:
    <settlement pubkey> CHECKSIG

  nLockTime: state number (ensures ordering)

Settlement TX:
  Input:
    Spends Update TX output (after CSV)

  Outputs:
    Alice: X BTC
    Bob:   Y BTC
    (distributed according to latest state)

Channel Factory Concept:

Traditional mode: Each channel needs one on-chain tx
  Alice--Bob: 1 tx
  Alice--Carol: 1 tx
  Bob--Carol: 1 tx
  Total 3 on-chain transactions

Channel Factory:

      Factory Funding TX
      (N-of-N multisig)
      Alice + Bob + Carol + ...
              |
      +-------+-------+
      |               |
  Alice-Bob      Bob-Carol
   Channel        Channel

  Only 1 on-chain tx to open multiple channels!

Eltoo advantages:
• Multi-party coordination simpler (symmetric state)
• Anyone going offline doesn't cause penalty risk
• Can dynamically adjust channels within Factory