Channel Jamming 通道堵塞

Liquidity Jamming Attack:

Attacker controls two nodes A and Z:

A ──> B ──> C ──> D ──> Z
│                       │
└── Attacker controls ──┘

Attack flow:
1. A sends payment to Z (via B-C-D route)
2. HTLC propagates all the way to Z
3. Z intentionally doesn't reveal preimage
4. All intermediate channel liquidity locked
5. Wait for HTLC timeout (hours to days)
6. Attacker loses no funds (payment fails)

Cost analysis:
• Attacker cost: only routing fees (few sats)
• Victim loss: liquidity locked, can't process payments
• Duration: up to HTLC timeout (~2 weeks max)

────────────────────────────────────────────

Slot Jamming Attack:

HTLC slot limit:
• Max 483 pending HTLCs per channel direction
• Required to keep commitment tx under
  Bitcoin's max transaction size limit

Attack flow:
1. Attacker creates 483+ small payments
2. Each payment only 1 sat
3. All HTLC slots filled
4. Normal payments can't go through

Cost: 483 sats x routing fee = few hundred sats

Upfront Fee Mechanism:

Current model (pay only on success):
  Payment success: routing node collects fee
  Payment failure: routing node gets nothing

Upfront fee model:
  When sending: immediately pay small "hold fee"
  Success: normal routing fee
  Failure: routing node keeps hold fee

Advantages:
• Increases attack cost
• Compensates routing nodes for resource use

Disadvantages:
• Increases cost for normal users
• Routing nodes might intentionally delay
• Complex implementation

Local Reputation System:

Each node maintains its own reputation database:

Peer     | Success Rate | Reputation
---------|--------------|------------
Node A   | 95%          | Good
Node B   | 30%          | Suspicious
Node C   | 5%           | Bad

Behavior:
• HTLCs from low-rep nodes: limit slots/amount
• HTLCs from high-rep nodes: process normally
• New nodes: gradually build reputation

Challenges:
• Attackers can build reputation first
• Reputation can't be shared (privacy issues)
• May cause network fragmentation

Circuit Breaker Plugin (CLN):

Per-peer limit settings:
  max_pending_htlcs_per_peer: 30
  max_htlc_value_per_peer: 100000 sat
  max_pending_duration: 1 hour

When limits reached:
• Reject new HTLCs
• Prioritize small fast payments
• Log suspicious behavior

Limitations:
• Only mitigation, not complete prevention
• May affect normal large payments

Reputation Credentials (research):

Concept:
1. Nodes buy "reputation tokens" (pay via LN)
2. Attach tokens when sending payment
3. Payment failure: tokens destroyed
4. Payment success: tokens can be recovered

Features:
• Purchase cost = attack cost
• Anonymous credentials (privacy protection)
• Transferable

Challenges:
• Increases normal payment complexity
• Token economics design
• Requires widespread adoption

Shorten HTLC Timeout:

Current default:
  Max HTLC timeout = 2016 blocks = ~2 weeks

Reduced timeout:
  Max HTLC timeout = 144 blocks = ~1 day

Benefits:
• Attack duration shortened
• Liquidity recovers faster

Problems:
• Long-path payments more likely to timeout
• Reduces tolerance for offline nodes
• Requires faster block monitoring