Penalty Transactions 懲罰交易

Fraud Attempt Example:

Channel History:
State #0: Alice 1.0 BTC, Bob 0 BTC      (channel open)
State #1: Alice 0.8 BTC, Bob 0.2 BTC    (Alice pays Bob)
State #2: Alice 0.5 BTC, Bob 0.5 BTC    (Alice pays 0.3 more)
State #3: Alice 0.3 BTC, Bob 0.7 BTC    (current state)

Alice attempts to cheat:
• Alice broadcasts State #1 commitment tx
• Trying to get 0.8 BTC instead of current 0.3 BTC

Result:
• Bob detects old state
• Bob uses penalty tx to seize all of Alice's funds
• Alice loses entire 1.0 BTC channel capacity!

Lesson:
• Alice tried to gain 0.5 BTC (0.8 - 0.3)
• Alice instead loses all 1.0 BTC
• Expected return of cheating is negative!

How Revocation Keys Work:

On each state update:
1. Both parties create new commitment tx
2. Both parties exchange revocation keys for old state
3. Old state is "revoked", new state becomes valid

Revocation Key Generation (simplified):
Each party has:
• revocation_basepoint
• per_commitment_point

revocation_pubkey = f(revocation_basepoint,
                      per_commitment_point)

Only knowing the corresponding private key allows spending the revocation output

Key Exchange Flow (State N -> State N+1):

Alice                           Bob
  |                              |
  |---- commit_sig (N+1) ------->|
  |                              |
  |<--- revoke_and_ack (N) ------|  Bob revokes State N
  |                              |
  |<--- commit_sig (N+1) --------|
  |                              |
  |---- revoke_and_ack (N) ----->|  Alice revokes State N
  |                              |

After this, broadcasting State N can be penalized

Commitment tx to_local output script:

OP_IF
    <revocationpubkey>
OP_ELSE
    <to_self_delay>
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

Explanation:
• Path 1 (IF): Holder of revocation key can spend immediately
• Path 2 (ELSE): Owner must wait to_self_delay blocks

Penalty Transaction Construction:

After Alice broadcasts old commitment tx...

Old commitment tx outputs:
• to_local_alice (delayed)
• to_remote_bob (Bob can spend directly)
• HTLCs (if any)

Bob's penalty transaction:

Inputs:
  to_local_alice (using revocation key, no wait needed)

Outputs:
  Bob's address (minus fees)

Witness:
  <signature> <revocation_privkey> 1

Penalty Time Window:

to_self_delay parameter (e.g., 144 blocks ~ 1 day)

Timeline:
T0: Alice broadcasts old commitment tx
    |
    | Block confirmation
    v
T1: Commitment tx confirmed
    |
    | to_self_delay begins
    | (Bob has 144 blocks to execute penalty)
    |
    +-- Bob online: detects fraud, broadcasts penalty tx
    |   Result: Bob gets all of Alice's funds
    |
    |   OR
    |
    +-- Bob offline: but Watchtower monitoring
    |   Result: Watchtower broadcasts penalty tx
    |
    |   OR
    |
    +-- T1 + 144 blocks: delay ends
        Result: Alice can spend to_local output
                (If Bob doesn't respond, Alice succeeds)

Key Points:
• Victim must respond within delay period
• Longer delay = more secure but slower channel close
• Common settings: 144-2016 blocks (1 day to 2 weeks)

HTLC outputs can also be penalized:

HTLC output script in old commitment tx (simplified):

Offered HTLC (from Alice):
OP_IF
    # Revocation path
    <revocationpubkey>
OP_ELSE
    OP_IF
        # Success path (Bob provides preimage)
        <remote_htlcpubkey>
        OP_CHECKSIGVERIFY
        OP_HASH160 <payment_hash> OP_EQUALVERIFY
    OP_ELSE
        # Timeout path (Alice reclaims)
        <to_self_delay> OP_CSV OP_DROP
        <local_htlcpubkey>
    OP_ENDIF
OP_ENDIF
OP_CHECKSIG

All outputs from old commitment tx have revocation paths:

• to_local        -> can be penalized
• Offered HTLCs   -> can be penalized
• Received HTLCs  -> can be penalized
• to_remote       -> owned by Bob directly, no penalty needed

Bob needs to create multiple penalty transactions:
• Penalize to_local
• Penalize each Offered HTLC
• Penalize each Received HTLC (second-stage tx)

Watchtower Workflow:

Setup Phase:
1. User creates penalty tx for each old state
2. Encrypt penalty tx:
   encrypted_blob = encrypt(penalty_tx, breach_txid[:16])
3. Send to Watchtower:
   (breach_hint, encrypted_blob)
   breach_hint = sha256(breach_txid)[:16]

Monitoring Phase:
Watchtower monitors each new block:
for each tx in block:
    hint = sha256(tx.txid)[:16]
    if hint in stored_hints:
        # Potential fraud detected!
        key = tx.txid[:16]
        penalty_tx = decrypt(stored_blob, key)
        broadcast(penalty_tx)

Privacy Protection:
• Watchtower doesn't know user identity
• Watchtower doesn't know channel details
• Can only decrypt when fraud occurs
• Even if Watchtower is compromised, no info is leaked

Penalty Transaction Fee Considerations:

Problem: Pre-signed penalty tx fee rate may become outdated

Case 1: Fee rate too low
• Penalty tx may not confirm in time
• Cheater may win the time race
• Funds could be lost!

Case 2: Fee rate too high
• Deducts too much from penalty amount
• Small channels may not be worth penalizing
• Economically inefficient

Solutions:

1. CPFP (Child-Pays-For-Parent)
   Use additional UTXO to boost fee rate

2. Anchor Outputs
   Specifically designed for CPFP acceleration

3. Dynamic Fee Estimation
   Watchtower decides fee rate at broadcast time

4. Pre-sign Multiple Fee Versions
   Low/medium/high fee rate penalty transactions

Modern Implementation (with Anchor Outputs):
• Penalty tx fee rate = minimum fee rate
• Actual fee adjusted dynamically via CPFP
• Requires additional UTXO for CPFP

Eltoo (LN-Symmetry) Mode:

Uses state replacement instead of penalties:

Traditional Penalty Mode:
State N (old) -> broadcast -> penalty -> cheater loses all

Eltoo Mode:
State N (old) -> broadcast -> State N+1 overwrites -> correct settlement
                                 ^
                            No penalty needed

Advantages:
• Simpler, no need to store all revocation keys
• Accidentally broadcasting old state won't be penalized
• Better suited for multi-party channels
• More efficient state updates

Disadvantages:
• Requires SIGHASH_ANYPREVOUT (not yet activated)
• Cheater has no economic loss (except fees)
• May encourage more cheating attempts?

See: /tech/lightning/eltoo