Multi-Path Payments 多路徑支付

Single-Path Payment Problem:

Scenario: Alice wants to pay 1 BTC to Dave

Network state:
Alice --[0.3]--> Bob --[0.8]--> Carol --[0.5]--> Dave
      |                                           ^
      +--[0.4]--> Eve --[0.6]--> Frank --[0.3]---+

Path 1: Alice -> Bob -> Carol -> Dave
        Bottleneck: 0.3 BTC (Alice-Bob channel)

Path 2: Alice -> Eve -> Frank -> Dave
        Bottleneck: 0.3 BTC (Frank-Dave channel)

Problem:
• No single path can support 1 BTC
• Payment fails!

Solution:
• Split 1 BTC
• Path 1 sends 0.3 BTC
• Path 2 sends 0.3 BTC
• Other paths send remaining 0.4 BTC

Basic MPP Flow:

1. Receiver generates invoice
   Invoice:
     payment_hash: H = SHA256(preimage)
     payment_secret: S (32 bytes random)
     amount: 1,000,000 sats
     features: basic_mpp

2. Sender splits payment
   Total 1,000,000 sats -> 3 shards:
   - Shard 1: 400,000 sats, path A
   - Shard 2: 350,000 sats, path B
   - Shard 3: 250,000 sats, path C

3. Each shard's HTLC payload
   Final hop payload:
     amt_to_forward: 400000
     outgoing_cltv_value: ...
     payment_secret: S
     total_msat: 1000000000

4. Receiver processing
   • Collect all HTLCs with same H and S
   • Verify total_msat matches
   • Wait for all shards to arrive
   • Reveal preimage to settle all shards at once

5. Atomicity guarantee
   • All shards succeed -> payment complete
   • Any shard fails -> all shards timeout and return

Payment Secret Importance:

Problem: MPP without payment_secret

Attack scenario (Wormhole Attack):
1. Alice sends shard 1 (500k sats) to Bob
2. Malicious routing node Eve intercepts
3. Eve sends her own 500k sats fake shard
4. Receiver gets 1M sats, reveals preimage
5. Eve uses preimage to settle Alice's shard
6. Eve stole 500k sats!

Solution: Payment Secret
• Only invoice holder knows payment_secret
• Receiver only accepts HTLCs with correct secret
• Eve cannot forge shards (doesn't know secret)

Feature bits:
• var_onion_optin (bit 8/9): required
• payment_secret (bit 14/15): required for MPP

AMP Mechanism:

Differences from Basic MPP:

Basic MPP:
• All shards use same payment_hash H
• May be correlated by routing nodes

AMP:
• Each shard has different payment_hash H_i
• Final preimage derived from shared secret
• Routing nodes cannot correlate shards

AMP secret derivation:
1. Sender chooses random root_share
2. For n shards:
   share_i = HMAC("share", root_share, i)
   preimage_i = share_1 XOR share_2 XOR ... XOR share_i
   hash_i = SHA256(preimage_i)

3. Receiver needs all shares to calculate final preimage
4. Ensures atomicity: can only settle after collecting all shards

Advantages:
• Each HTLC looks like independent payment
• Stronger privacy protection
• Supports spontaneous payments (Keysend + AMP)

MPP Timeout Scenarios:

Scenario 1: Partial shard failure
  Shard 1: Successfully reaches receiver
  Shard 2: Routing failure

  Handling:
  • Receiver waits reasonable time
  • After timeout, let all HTLCs expire
  • Sender can retry (different paths or split)

Scenario 2: Receiver offline
  All shards arrive, but receiver doesn't reveal preimage

  Handling:
  • All HTLCs timeout
  • Funds return to sender

Receiver MPP timeout setting:
  mpp_timeout: 60 seconds (typical)
  Timer starts after receiving first shard
  If not complete before timeout -> abandon, wait for HTLC expiry

Best practices:
• Sender should send all shards in parallel
• Avoid delays from sequential sending
• Monitor partial failures and retry quickly