路由與尋路

Lightning Network Graph Structure:

Nodes:
• Each entity running LN software
• Identified by 33-byte public key
• Broadcast via node_announcement

Channels (Edges):
• Payment channel between two nodes
• Identified by short_channel_id
• Two directions, each with independent fees and limits

┌───────┐   Channel A   ┌───────┐   Channel B   ┌───────┐
│ Alice │ ───────────── │  Bob  │ ───────────── │ Carol │
└───────┘               └───────┘               └───────┘
    │                                               │
    │               Channel C                       │
    └───────────────────────────────────────────────┘

Gossip Message Types:

1. channel_announcement
   • New channel online
   • Contains both node IDs and Bitcoin pubkeys
   • Requires on-chain funding tx verification

2. channel_update
   • Channel parameter changes
   • Fee rate, CLTV delta, min/max HTLC
   • Can mark channel as disabled

3. node_announcement
   • Node info update
   • Alias, color, addresses, features

Gossip Propagation:
• Node forwards new messages to all peers
• Uses timestamp to prevent old messages overwriting new
• Too old messages are ignored

Pathfinding Process:

1. Start reverse search from destination
   • Why reverse? Need to know final CLTV to calculate each hop

2. Calculate edge "cost"
   cost = base_fee + (amount * fee_rate) + risk_factor

3. Select path with lowest total cost

4. Validate path feasibility
   • Each hop amount <= channel capacity
   • HTLC count limit
   • CLTV within reasonable range

Cost factors:
• Fees (most important)
• Success probability (based on history)
• Timelock risk (longer CLTV = higher risk)
• Channel age (newer may be unstable)

Success Probability Estimation:

Problem: Public info is channel capacity, not current balance

Assumption: Uniform balance distribution
For channel capacity C, forwarding amount A:
Success probability = (C - A) / C

More precise estimation (history-based):
• Record success/failure for each channel
• Use Bayesian methods to update balance estimate
• Consider time decay (balances change)

LND Mission Control:
• Maintains success probability per channel
• Lowers probability after failure
• Gradually recovers over time

MPP (Multi-Path Payments):

Paying 1 BTC:
  Path 1: Alice -> X -> Y -> Carol (0.4 BTC)
  Path 2: Alice -> M -> N -> Carol (0.3 BTC)
  Path 3: Alice -> P -> Carol (0.3 BTC)

All parts use same payment_hash
Receiver waits for all parts, then reveals preimage

Advantages:
• Break single channel capacity limit
• Increase large payment success rate
• Better utilization of network liquidity

Requirements:
• Receiver supports MPP (feature bit 16/17)
• Sender intelligently splits amount
• All parts must use same payment_secret

Common Failure Reasons and Handling:

1. TEMPORARY_CHANNEL_FAILURE
   • Channel temporarily can't forward
   • Avoid temporarily, retry later

2. FEE_INSUFFICIENT
   • Fee too low
   • Retry after updating channel_update

3. UNKNOWN_NEXT_PEER
   • Next hop node offline
   • Choose different path

4. AMOUNT_BELOW_MINIMUM
   • Amount below channel minimum
   • Choose different channel

5. EXPIRY_TOO_SOON
   • CLTV too close
   • Increase CLTV or choose other path

Retry strategy:
• Exclude failed edges
• Recalculate path
• Retry up to N times

每一跳的手續費：

fee = base_fee_msat + (amount_msat × fee_rate / 1000000)

範例路徑手續費：
Alice → Bob → Carol → Dave

Carol → Dave: 1000 sat, fee = 0
Bob → Carol:  1001 sat, fee = 1 sat
Alice → Bob:  1003 sat, fee = 2 sat

總手續費 = 3 sat (0.3%)

計算方向：從終點反向計算
每一跳金額 = 下一跳金額 + 下一跳手續費

Routing Optimization Tips:

1. Pre-compute Routes
   • Calculate paths to common destinations ahead
   • Reduce payment latency

2. Route Caching
   • Remember successful paths
   • Prioritize for same destination

3. Local Channel Priority
   • Try direct channels first
   • Reduce fees and hop count

4. Parallel Attempts
   • Try multiple paths simultaneously
   • Use first one that succeeds

5. Smart Splitting (MPP)
   • Decide splits based on channel capacity
   • Balance success rate and fees