Channel Reserve 通道儲備金

Risk Without Channel Reserve:

Scenario: Alice and Bob open channel, Alice contributes 1 BTC

Initial state:
  Alice: 1.0 BTC    Bob: 0 BTC        State #0

Alice pays Bob 0.5 BTC:
  Alice: 0.5 BTC    Bob: 0.5 BTC      State #1

Alice pays another 0.5 BTC:
  Alice: 0 BTC      Bob: 1.0 BTC      State #2

Problem: Alice now has 0 balance
• Alice broadcasts State #1 (cheating)
• Even if penalized, Alice had 0 anyway
• Alice loses nothing!
• Might even grab 0.5 BTC

With Channel Reserve:
  Alice: 0.01 BTC   Bob: 0.99 BTC     State #2
  (reserve)

• Alice cannot spend to 0
• If Alice cheats, she loses 0.01 BTC
• Economic deterrence works!

Reserve Calculation Rules (BOLT 2):

channel_reserve = max(dust_limit, 1% of channel_capacity)

Example: 1 BTC channel
• Channel capacity: 100,000,000 sats
• 1% reserve: 1,000,000 sats (0.01 BTC)
• Minimum each party must keep: 1,000,000 sats

Actual usable capacity:

1 BTC Channel Layout:
[Alice reserve] [   Usable capacity   ] [Bob reserve]
     1%                  98%                  1%
  0.01 BTC            0.98 BTC            0.01 BTC

Parameter Negotiation (open_channel message):
• channel_reserve_satoshis: minimum balance peer must keep
• dust_limit_satoshis: minimum valid output (~546 sats)

Constraints:
channel_reserve >= dust_limit
channel_reserve >= 1% of funding_satoshis (recommended)
to_local + to_remote >= 2 * channel_reserve

Payment Limit Example:

Channel state:
• Channel capacity: 1 BTC
• Alice balance: 0.6 BTC
• Bob balance: 0.4 BTC
• Reserve requirement: 0.01 BTC (each party)
• Alice max sendable: 0.6 - 0.01 = 0.59 BTC

Payment Flow Check:

Alice wants to send 0.55 BTC to Bob:
  Before     Alice: 0.6   Bob: 0.4
  After      Alice: 0.05  Bob: 0.95
  Reserve    0.05 >= 0.01  PASS

Alice wants to send 0.595 BTC to Bob:
  Before     Alice: 0.6   Bob: 0.4
  After      Alice: 0.005 Bob: 0.995
  Reserve    0.005 < 0.01  REJECTED

Error message:
  insufficient_balance or
  amount_below_minimum

Single-Funded Channel Reserve:

Alice single-funds 1 BTC channel:
  Alice: 1.0 BTC    Bob: 0 BTC
  Reserve requirement:
  Alice: 0.01 BTC   Bob: 0.01 BTC

Problem: Bob balance is 0, below reserve!

Solution:
1. Reserve is "must keep once you have funds"
2. Bob starting at 0 is allowed
3. Once Bob receives any funds, must maintain reserve

Flow:
State 0: Alice 1.0, Bob 0      <- Bob exempt (no funds)
State 1: Alice 0.9, Bob 0.1    <- Bob must now keep 0.01
State 2: Alice 0.89, Bob 0.11  <- Bob cannot spend below 0.01

Bob max spendable: 0.11 - 0.01 = 0.1 BTC

BOLT 2 states:
"If to_local_msat < channel_reserve_satoshis*1000
 AND to_local_msat != 0"
then reserve requirement is violated.

HTLC and Reserve Interaction:

Scenario:
• Alice balance: 0.05 BTC
• Reserve: 0.01 BTC
• Available balance: 0.04 BTC
• Alice wants to route a 0.03 BTC HTLC

Step 1: Add HTLC
  Alice balance: 0.05 -> 0.02 + 0.03 (HTLC)
  Remaining 0.02 >= reserve 0.01  PASS

Step 2a: HTLC success (Bob gets funds)
  Alice: 0.02    Bob: +0.03
  Alice 0.02 >= 0.01  PASS

Step 2b: HTLC fails (funds return to Alice)
  Alice: 0.02 + 0.03 = 0.05
  Alice 0.05 >= 0.01  PASS

Notes:
• During HTLC, reserve must still be satisfied
• Cannot use reserve to "front" HTLC
• Large HTLCs may fail due to reserve limits

Dynamic Reserve (some implementations support):

Problem: Fixed 1% reserve may be too high or too low

Small channel: 10,000 sats
• 1% = 100 sats (may be below dust limit)
• Actually uses dust limit (546 sats)

Large channel: 10 BTC
• 1% = 0.1 BTC (may be too high)
• Locks up too much liquidity

Solutions:
1. Set reasonable value during negotiation
2. Use option_channel_reserve (if supported)
3. Accept peer's reserve requirement or reject channel

channel_update message (BOLT 1.1 proposal):
• Allows adjusting reserve during channel lifetime
• Increase: improves security
• Decrease: releases liquidity
• Requires mutual agreement

Reserve and Penalty Mechanism:

Security Mechanism Layers:

1. Channel Reserve
   Ensures cheater has funds that can be seized

2. Revocation Keys
   Allows victim to identify and penalize old states

3. Penalty Transaction
   Actually seizes cheater's entire channel funds

4. Watchtower
   Monitors and executes penalties even when offline

Under Eltoo:
• No penalty mechanism used
• Reserve importance reduced
• May still be used for other purposes (e.g., fee guarantee)