PTLCs 點時間鎖定合約

HTLC 隱私問題：

Alice ──HTLC(H)──> Bob ──HTLC(H)──> Carol ──HTLC(H)──> Dave
                         │
                         │ 相同的 H = SHA256(preimage)
                         ▼
問題 1：路徑關聯
  - 如果 Bob 和 Dave 合謀，他們可以發現這是同一筆支付
  - 他們可以推斷 Alice 是發送者，Dave 是接收者

問題 2：Wormhole 攻擊
  - 惡意節點可以「跳過」中間節點
  - 收取路由費卻不提供服務

問題 3：鏈上可追蹤
  - 如果 HTLC 超時需要上鏈結算
  - 相同的 hash 在區塊鏈上可見
  - 可以關聯多個通道的關閉

PTLC 基本概念：

設定：
  - s = 秘密標量（只有 Dave 知道）
  - S = s·G = 對應的公開點

支付路徑：
  Alice ──PTLC(S+a)──> Bob ──PTLC(S+b)──> Carol ──PTLC(S)──> Dave
              │               │                │
              │               │                └─ Dave 用 s 解鎖
              │               └─ Carol 學到 s，用 s+b 解鎖給 Bob
              └─ Bob 學到 s+b，但不知道 s，用 s+a+b 解鎖給 Alice

關鍵：
  - 每一跳的「點」都不同：S, S+b·G, S+(a+b)·G
  - 即使 Bob 和 Dave 合謀，他們看到的是不同的點
  - 無法確定這些點是否來自同一筆支付

適配器簽名機制：

標準 Schnorr 簽名：
  sig = (R, s) where s = k + e·x
  驗證：s·G = R + e·P

適配器簽名：
  設 T = t·G 是「適配點」

  1. 簽名者創建「不完整簽名」：
     s' = k + e·x  (但使用 R' = R + T)
     發送 (R', s')

  2. 驗證者檢查：
     s'·G = R' + e·P - T
     這證明：如果知道 t，就能得到有效簽名

  3. 當秘密 t 被揭露時：
     s = s' + t
     (R, s) 是有效的 Schnorr 簽名

  4. 反向：看到完整簽名可以推導 t：
     t = s - s'

關鍵屬性：
  - 知道 t → 可以完成簽名
  - 看到完成的簽名 → 可以學到 t

PTLC 詳細流程（Alice → Bob → Carol → Dave）：

1. 設定階段
   Dave 生成秘密 s，公開 S = s·G
   Alice 選擇路由，生成隨機數 a, b

2. 轉發階段（洋蔥路由中攜帶 adaptor 資訊）

   Alice → Bob:
   - PTLC 鎖定點：S + (a+b)·G
   - 包含 Bob 的 adaptor：b·G

   Bob → Carol:
   - PTLC 鎖定點：S + b·G
   - 包含 Carol 的 adaptor：（無需額外）

   Carol → Dave:
   - PTLC 鎖定點：S
   - Dave 用 s 解鎖

3. 結算階段（逆向揭示秘密）

   Dave → Carol:
   - Dave 用 s 創建完整簽名花費 PTLC
   - Carol 從簽名中提取 s

   Carol → Bob:
   - Carol 用 s + b 創建簽名（她知道 s，Alice 告訴她 b）
   - 實際上：Carol 只需要用 s 解鎖，然後
   - Bob 從簽名中提取 s + b（但不知道 s 和 b 分別是什麼）

   Bob → Alice:
   - Bob 用 s + a + b 解鎖
   - Alice 從簽名中可以驗證支付完成

MuSig2 + PTLC 通道：

傳統 HTLC 通道關閉（鏈上可見）：
┌─────────────────────────────────────┐
│ IF                                  │
│   <revocation_pubkey>               │
│ ELSE                                │
│   <local_delayed> CHECKSEQUENCEVERIFY │
│   <local_pubkey>                    │
│ ENDIF                               │
│ CHECKSIG                            │
└─────────────────────────────────────┘
  看起來明顯是 Lightning 通道

MuSig2 + PTLC + Taproot 通道關閉：
┌─────────────────────────────────────┐
│ <aggregated_pubkey> CHECKSIG        │
└─────────────────────────────────────┘
  看起來就像普通的單簽支付！

隱私改進：
- 合作關閉：無法區分是 2-of-2 還是 1-of-1
- 強制關閉：使用 Tapscript，但主要路徑是 keypath
- PTLC 結算：與普通交易無異