AMP 原子多路徑支付

Two Multi-Path Payment Types Compared

Basic MPP (Multi-Path Payments):
• Requires invoice: Yes
• Preimage source: Receiver generates
• All parts use: Same payment_hash
• Settlement: Receiver reveals preimage for all parts

Problems:
• Intermediate nodes see the same payment_hash
• Can identify different parts of the same payment
• Poor privacy

AMP (Atomic Multi-Path Payments):
• Requires invoice: No (spontaneous payment)
• Preimage source: Sender generates and splits
• Each part uses: Different payment_hash
• Settlement: Receiver reconstructs preimage then settles all parts

Advantages:
• Each part has different payment_hash
• Intermediate nodes cannot correlate parts
• Stronger privacy protection
• No need to pre-request invoice

AMP Key Splitting Mechanism

Sender (Alice) generates:
1. Generate root key (root_share)
   root_share = random_bytes(32)

2. Generate child key for each part
   child_share[i] = HMAC(root_share, i)

3. Calculate payment_hash for each part
   preimage[i] = child_share[i] XOR (sum of child_share[j])
   payment_hash[i] = SHA256(preimage[i])

4. Pass child_share to receiver via onion

Three-Part Payment Example:
root_share = R

Part 1: child_share[1] = HMAC(R, 1) = S1
Part 2: child_share[2] = HMAC(R, 2) = S2
Part 3: child_share[3] = HMAC(R, 3) = S3

After receiver gets all parts:
• Reconstruct: root = S1 XOR S2 XOR S3
• Verify all child_shares are from same root
• Calculate all preimages
• Settle all HTLCs

AMP Onion TLV Fields

Final Hop TLV Payload:

TLV Type 8: amp_record
• root_share: 32 bytes (child key shard)
• set_id: 32 bytes (identifies this payment set)
• child_index: 4 bytes (which part number)

TLV Type 16: payment_metadata (optional)
• Extra payment data

set_id Purpose:
• Identifies all parts belonging to the same AMP payment
• Receiver uses it to collect and match all parts
• Randomly generated by sender
• Invisible to intermediate nodes (inside onion encryption)

AMP Atomicity

Why is it atomic?
Receiver can only calculate preimage after receiving all parts.

If 3-part payment, only 2 parts received:
• Have S1, S2
• Cannot calculate root = S1 XOR S2 XOR S3
• Cannot calculate any preimage
• Cannot claim any part

When all 3 parts received:
• Have S1, S2, S3
• Calculate root = S1 XOR S2 XOR S3
• Calculate all preimages
• Claim all parts simultaneously

Failure Handling:
• If a part fails to route: sender can retry that part
• Or abandon entire payment
• Receiver cannot partially claim
• All unclaimed HTLCs eventually timeout and refund

發送 AMP 支付命令：

LND：
# 發送 AMP 支付（自發支付到節點）
lncli sendpayment --dest <pubkey> \
  --amt 100000 \           # 金額（satoshis）
  --amp                     # 啟用 AMP

# 指定分割數量
lncli sendpayment --dest <pubkey> \
  --amt 100000 \
  --amp \
  --max_parts 5             # 最多分成 5 個部分

# 帶消息的 AMP 支付（keysend 風格）
lncli sendpayment --dest <pubkey> \
  --amt 100000 \
  --amp \
  --data 7629168=<hex_message>

接收 AMP 支付：
# 查看收到的 AMP 支付
lncli listinvoices

# AMP 支付會顯示多個 HTLC
# 但屬於同一個 set_id

AMP Invoices (Optional)

Although AMP doesn't require invoices, you can create AMP invoices:

# Create AMP invoice
lncli addinvoice --amt 100000 --amp

Features:
• Invoice doesn't contain payment_hash (receiver doesn't pre-generate)
• Contains AMP feature flag
• Sender generates payment_hash
• Can be paid multiple times (reusable)

AMP Invoice Feature Bits:
• BOLT 11 invoice's '9' tag contains AMP feature bits
• Sender sees this and uses AMP protocol

AMP Security

Advantages:
1. Unlinkability
   • Each part has different payment_hash
   • Routing nodes cannot identify different parts of same payment

2. No interaction required
   • Sender doesn't need to wait for receiver to generate invoice
   • Reduces privacy leakage opportunities

3. Atomicity
   • Mathematically guarantees all parts settle simultaneously
   • No partial payment success scenarios

Considerations:
1. Receiver must support AMP (feature bits 30/31)

2. No traditional proof of payment
   • Sender generates preimage, cannot prove receiver received
   • Suitable for scenarios not requiring receipts

3. Timeout handling
   • If parts don't arrive, must wait for all HTLCs to timeout
   • May lock funds for extended time