Route Blinding 路徑盲化

Traditional Invoice Privacy Leakage:

BOLT 11 invoice contents:
lnbc100u1p...
  amount: 100,000 sats
  destination: 03abc123...def (receiver pubkey)
  expiry: 3600 seconds
  route hints:
    pubkey: 02xyz...
    scid: 123x456x0
    fee: 1 sat
    cltv: 40

Problems:
1. Destination pubkey exposes receiver identity
2. Route hints expose receiver's direct connections
3. Can track specific node's payment activity
4. Can analyze receiver's channel structure

Attack scenarios:
• Competitors monitoring merchant payments
• Tracking user spending habits
• Targeted attacks on high-value nodes

Blinded Path Structure:

Receiver Bob creates blinded path:

Real path:
  Node E --> Node F --> Node G --> Bob
  (entry)                          (receiver)

After blinding:

Blinded Path:
  introduction_node: E (public entry point)
  blinding_point: B = b*G
  blinded_hops:
    blinded_node_id: E' = HMAC(E, B)
      encrypted_data: [to F, encrypted]
    blinded_node_id: F' = HMAC(F, B')
      encrypted_data: [to G, encrypted]
    blinded_node_id: G' = HMAC(G, B'')
      encrypted_data: [to Bob, encrypted]
    blinded_node_id: Bob' = HMAC(Bob, B''')
      encrypted_data: [final payload]

Sender only knows:
• Entry node E's real ID
• A series of meaningless blinded_node_ids
• Cannot deduce identities of F, G, Bob

Blinding Cryptography:

1. Receiver chooses random blinding secret: b
   Calculates blinding point: B = b*G

2. For each node N_i, calculate:

   Shared secret:
   ss_i = SHA256(b * N_i)  // ECDH with node pubkey

   Blinded node ID:
   N_i' = N_i + SHA256("blinded_node_id", ss_i)*G

   Encryption key:
   key_i = SHA256("encrypted_data", ss_i)

   Next hop blinding point:
   B_{i+1} = SHA256("blinding", ss_i) * B

3. When each node receives payment:
   • Use own private key and B to calculate ss
   • Decrypt encrypted_data
   • Calculate next hop's B'
   • Forward to next blinded_node_id

Key points:
• Each node can only decrypt its own data
• Cannot deduce other nodes' identities
• Sender knows nothing about path details

Payment Using Blinded Path:

1. Bob creates Offer/Invoice with blinded path
   Offer:
     amount: 100,000 sats
     paths:
       - introduction_node: 02abc...
         blinding_point: 03xyz...
         blinded_hops: [...]

2. Alice calculates route
   Alice -> ... -> entry node E -> [blinded path] -> Bob

   Alice builds onion:
   • Normal hops: path from Alice to E
   • Blinded hops: use blinded_hops directly

3. E receives payment
   • Recognizes this is blinded path
   • Decrypts using blinding_point
   • Finds next hop is F (from encrypted_data)
   • Calculates new blinding_point
   • Forwards

4. F, G process similarly

5. Bob receives payment
   • Decrypts final payload
   • Verifies and accepts payment

Reply Path Use Cases:

BOLT 12 Offers flow:
1. Bob publishes Offer (with blinded reply path)
2. Alice requests invoice using Onion Message
3. Bob returns invoice through reply path
4. Alice pays invoice

Reply Path structure:

alice_offer_request:
  offer_id: ...
  amount: 100000
  reply_path:
    introduction_node: node near Alice
    blinding_point: ...
    blinded_hops: [... -> Alice]

Benefits:
• Alice can protect her privacy when sending requests
• Bob can reply without knowing who Alice is
• Bidirectional privacy protection

Onion Messages vs HTLC:

HTLC (traditional):
• Used for payments
• Requires locking funds
• Has time limits
• Requires channel

Onion Messages:
• Used for communication
• No funds locked
• No time limits
• No direct channel needed

Use cases:
• BOLT 12 invoice requests
• BOLT 12 invoice replies
• Future: payment proofs, chat, etc.

Message type: 513 (onion_message)
Feature bits: 38/39 (option_onion_messages)