Revocation 撤銷機制

Revocation Key Derivation Structure

Each party maintains two base points:
• revocation_basepoint: Own revocation base point
• per_commitment_point: Unique point for each commitment tx

Revocation Public Key Calculation:
revocation_pubkey =
  revocation_basepoint * SHA256(
    revocation_basepoint || per_commitment_point
  )
  +
  per_commitment_point * SHA256(
    per_commitment_point || revocation_basepoint
  )

Design rationale:
• Two keys needed to generate revocation private key
• revocation_basepoint_secret (held by counterparty)
• per_commitment_secret (held by self, given to counterparty later)

Revocation Private Key (can only be calculated after revocation):
revocation_privkey =
  revocation_basepoint_secret * SHA256(
    revocation_basepoint || per_commitment_point
  )
  +
  per_commitment_secret * SHA256(
    per_commitment_point || revocation_basepoint
  )

Key points:
• Before revocation, neither party can calculate revocation privkey
• When revoking, send per_commitment_secret to counterparty
• Counterparty can then calculate revocation private key

State Update and Revocation

State N -> State N+1 Update Flow:

Alice                                 Bob
  |                                    |
  | [Current: Commitment tx N]         |
  |                                    |
  |---- commitment_signed ------------>|  Alice signs new commitment N+1
  |     (signature for N+1)            |
  |                                    |
  |<--- revoke_and_ack ----------------|  Bob revokes old commitment N
  |     (per_commitment_secret_N)      |  and confirms receipt of N+1
  |     (next_per_commitment_point)    |
  |                                    |
  |<--- commitment_signed -------------|  Bob signs new commitment N+1
  |     (signature for N+1)            |
  |                                    |
  |---- revoke_and_ack --------------->|  Alice revokes old commitment N
  |     (per_commitment_secret_N)      |  and confirms receipt of N+1
  |     (next_per_commitment_point)    |
  |                                    |
  | [Current: Commitment tx N+1]       |
  | [Commitment tx N revoked by both]  |
  |                                    |

revoke_and_ack message contents:
• channel_id: 32 bytes
• per_commitment_secret: 32 bytes (the revoked key)
• next_per_commitment_point: 33 bytes (point for next use)

to_local Output Script (revocable):

OP_IF
    # Revocation path: counterparty can spend immediately
    <revocation_pubkey>
OP_ELSE
    # Normal path: self must wait to_self_delay
    <to_self_delay>
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <local_delayed_pubkey>
OP_ENDIF
OP_CHECKSIG

Usage Scenarios:

Case 1: Normal Close (publishing latest state)
• Alice publishes latest commitment tx
• to_local output requires waiting to_self_delay
• Bob doesn't have revocation key (this is latest state)
• After waiting, Alice normally retrieves funds

Case 2: Fraud Attempt (publishing old state)
• Alice publishes already-revoked old commitment tx
• Bob detects old transaction
• Bob has per_commitment_secret for this tx
• Bob calculates revocation_privkey
• Bob immediately spends to_local (Alice's money) with revocation key
• Alice loses all funds

Shachain: Efficient Key Storage Structure

Problem:
• A long-term channel may have millions of state updates
• Each update produces a per_commitment_secret
• Need to store all old keys for potential penalties

Solution: Shachain
Uses hash chain structure, only needs to store O(log n) seeds
Can derive all n keys

Structure diagram:
           seed
          /         H(0||s)  H(1||s)
      /       /      ...      ...

Derivation rule:
Binary representation of index determines derivation path

Storage efficiency:
• 2^48 keys only need 48 seeds
• Each seed is 32 bytes
• Total only needs 1.5 KB

Key Verification on Receipt:
1. Receive per_commitment_secret
2. Verify it can derive previous keys
3. If verification fails, counterparty may be cheating
4. Insert new key into Shachain structure

HTLC Outputs Also Have Revocation Paths

Offered HTLC (HTLC I sent):
# Revocation path
OP_DUP OP_HASH160 <revocation_hash> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    # Normal path...
OP_ENDIF

If old state is published, counterparty can claim HTLC with revocation key

Received HTLC (HTLC I received):
• Also contains revocation path
• Prevents attempting to claim already-settled HTLC after publishing old state

How Watchtowers Use Revocation Data

Preparation Phase:
1. You revoke old state N
2. Calculate txid prefix of old commitment tx as hint
3. Build penalty transaction (using revocation key)
4. Encrypt penalty tx with commitment tx txid
5. Send (hint, encrypted_blob) to watchtower

Monitoring Phase:
1. Watchtower monitors blockchain
2. When seeing a transaction, match txid against hints
3. If match found, decrypt blob with txid
4. Broadcast penalty transaction
5. Your funds are protected

Eltoo's Different Approach

Current LN-Penalty Mechanism:
• Publishing old state = lose all funds
• Need to store all old keys
• Punishment may be too severe

Eltoo (requires SIGHASH_ANYPREVOUT):
Does not use revocation mechanism
New state can "replace" old state

Advantages:
• No need to store old keys
• Publishing old state only gets updated, not punished
• Better suited for multi-party channels (Channel Factories)
• Simpler implementation

Disadvantages:
• Requires Bitcoin soft fork (ANYPREVOUT)
• No punishment may reduce deterrence
• Not yet activated