Channel Backup 通道備份

Dynamic Nature of Channel State:

Problem: Channel state keeps changing

Timeline:
T0: Open channel, state 0
    Alice: 1 BTC, Bob: 0 BTC

T1: Backup state 0

T2: Pay 0.3 BTC to Bob, state 1
    Alice: 0.7 BTC, Bob: 0.3 BTC

T3: Pay 0.2 BTC to Bob, state 2
    Alice: 0.5 BTC, Bob: 0.5 BTC

T4: Disk failure!

What happens when restoring backup (state 0)?

Alice tries to broadcast commitment tx 0
-> Bob detects this is an old state
-> Bob broadcasts penalty transaction
-> Alice loses entire 1 BTC!

This is worse than losing the backup entirely!

Static Channel Backup (SCB) Principle:

SCB does NOT contain channel state!

SCB Contents:
  version: backup format version
  channels: [
    {
      channel_point: funding txid:vout
      remote_pubkey: peer node public key
      capacity: channel capacity
      addresses: peer node addresses
    },
    ...
  ]

Recovery Flow:
1. Restore wallet using seed words
2. Import SCB file
3. Node connects to each channel peer
4. Request peer to initiate cooperative close
5. Peer uses latest state to close
6. Funds return on-chain

Key Points:
• Does not attempt to restore state (avoids toxic backup)
• Relies on peer's honest cooperation
• Funds will return, but must wait for on-chain confirmation

option_data_loss_protect (BOLT feature):

Detects data loss when nodes reconnect:

Normal case:
  Alice ---channel_reestablish---> Bob
         my_current_per_commitment_point
         your_last_per_commitment_secret
  Alice <------------------------- Bob

If Alice loses data:
  Alice (after recovery) sends outdated commitment point
       ----------------------------------> Bob
                                           Bob detects mismatch!
  Alice <-- sends latest per_commitment_secret
            + suggests closing channel

Bob's options:
1. Initiate cooperative close (friendly)
2. Force close (using latest state)

Alice can verify if Bob's state is newer than hers,
ensuring Bob isn't maliciously using an old state.

Feature bit: option_data_loss_protect (bit 0/1)

option_static_remotekey:

Traditional mode:
  to_remote output uses derived keys
  Key differs with each state update
  Recovery requires knowing exact state number

static_remotekey mode:
  to_remote output uses fixed payment_basepoint
  Regardless of which state is broadcast, output is same address

Benefits:
Even if peer unilaterally closes channel,
you only need seed words to spend to_remote output!

Not required:
• Knowing current state number
• Saving any channel data
• Peer cooperation

Note: to_local and HTLCs still need extra data for recovery

Feature bit: option_static_remotekey (bit 12/13)

Watchtower as Backup Supplement:

Scenario: You lose data, peer maliciously broadcasts old state

Without Watchtower:
• You cannot penalize (no revocation key)
• Can only accept peer's claimed state
• May lose funds

With Watchtower:
• Watchtower has penalty transactions stored
• Even if you're offline/lost data
• Watchtower can protect you

However:
• Watchtower needs new data uploaded on each update
• Storage requirements can be large
• Must trust Watchtower is online and reliable