Payment Secret 支付密鑰

Payment Secret 解決的問題：

問題 1：前向劫持攻擊

沒有 payment_secret 的情況：

  Alice --> Bob --> Carol --> 收款人

攻擊：Carol 是惡意中繼節點
1. Carol 看到 payment_hash
2. Carol 向收款人發起另一筆同 hash 的支付
3. Carol 獲得 preimage
4. Carol 使用 preimage 領取 Alice 的支付
5. Carol 不轉發 Alice 的原始支付

結果：Carol 獲得免費的服務/商品

有 payment_secret 的保護：

  Alice --> Bob --> Carol --> 收款人

1. 收款人生成發票，包含：
   • payment_hash
   • payment_secret（只有 Alice 知道）

2. Alice 在最終 HTLC payload 中包含 payment_secret

3. Carol 無法看到 payment_secret（洋蔥加密）

4. 即使 Carol 知道 payment_hash，
   也無法創建有效的支付請求

5. 收款人驗證 payment_secret 才會揭露 preimage

探測攻擊：

沒有 payment_secret 時：

攻擊者可以：
1. 生成隨機 payment_hash
2. 向目標節點發送探測支付
3. 觀察錯誤訊息：
   • "unknown payment hash" -> 路由可達
   • "channel exhausted" -> 通道餘額不足

這允許攻擊者：
• 發現私有通道
• 估計通道餘額
• 追蹤支付模式

有 payment_secret 的保護：

節點行為改變：

沒有正確 payment_secret 的支付：
-> 直接拒絕，返回 "incorrect_or_unknown_payment_details"

這使得探測更困難：
• 無法區分「hash 錯誤」和「secret 錯誤」
• 無法確認路由可達性
• 大大降低探測效率

多路徑支付（MPP）與 payment_secret：

payment_secret 的關鍵作用：

MPP 將大額支付拆分成多個 HTLC：

發票：100,000 sats

拆分：
• HTLC 1: 40,000 sats（路徑 A）
• HTLC 2: 35,000 sats（路徑 B）
• HTLC 3: 25,000 sats（路徑 C）

所有 HTLC 共享：
• 相同的 payment_hash
• 相同的 payment_secret

收款人處理：

收到第一個 HTLC 時：
1. 驗證 payment_secret
2. 記錄 payment_hash + secret 組合
3. 累加金額
4. 等待更多 HTLC...

收到後續 HTLC 時：
1. 驗證 payment_secret 匹配
2. 驗證 payment_hash 匹配
3. 累加金額
4. 檢查是否達到 total_msat

達到總金額時：
1. 揭露 preimage 給所有 HTLC
2. 原子完成所有部分支付

安全保證：
• 沒有正確 secret，無法「搭便車」到 MPP 支付
• 每個部分都必須是同一個付款人
• 防止部分支付被劫持

Payment Secret 規範：

發票中的 payment_secret（BOLT 11）：

Tagged field 's'（type 16）：
• 長度：52 data 字符（32 bytes）
• 值：隨機生成的 256-bit 值

範例發票字段：
s = 0x1234567890abcdef...（32 bytes）

洋蔥 payload 中的 payment_data（TLV type 8）：

只在最終節點的 payload 中：

payment_data:
• payment_secret: 32 bytes
• total_msat: 8 bytes（TU64）

total_msat 用於 MPP：
• 表示整個支付的總金額
• 不是當前 HTLC 的金額
• 收款人用來判斷是否收齊所有部分

功能位：

var_onion_optin (8/9)：
  支援 TLV 洋蔥 payload
  payment_secret 需要此功能

payment_secret (14/15)：
  明確表示支援 payment_secret
  現在是強制要求

basic_mpp (16/17)：
  支援基本 MPP
  需要 payment_secret