閃電網路 Taproot 通道規格勘誤：照舊文實作恐產生無效花費

發生什麼事

閃電網路規格儲存庫 lightning/bolts 於 2026 年 10 月 19 日（UTC）合併 PR #1352，由開發者 erickcestari 提出、Roasbeef 合併，修正 Simple Taproot Channels（簡易 Taproot 通道）擴充規格。該擴充是在 5 月由 BOLTs #995 正式納入規格庫，分配特性位元 80/81，定義以 MuSig2 聚合金鑰的 P2TR 注資輸出、taproot 化的承諾交易與 HTLC 腳本，以及交換 MuSig2 部分簽章與 nonce 的新 TLV 欄位。

Bitcoin Optech 第 428 期（10 月 23 日）摘要指出，規格中 taproot 輸出金鑰推導與控制區塊建構的錯誤「若照先前規格實作，可能產生無效花費」，同時強調這些修改是讓規格對齊既有的 LND 與 Eclair 實作，並未改變協定行為。合併紀錄顯示本次只改動 bolt-simple-taproot.md 一個檔案，新增 176 行、刪除 80 行。

修正了哪些錯誤

金鑰與控制區塊方面，PR 說明有五組輸出金鑰公式（錨定輸出、送出與接收的 HTLC、兩種第二層輸出）把 tweak 雜湊直接加到內部金鑰上，而 BIP 341 的正確寫法是 Q = P + int(hashTapTweak(...))G。規格也只在 NUMS 點處說明要用 32 位元組 x-only 形式，如今統一定義 x_only() 並套用到所有內部金鑰與控制區塊序列化。taproot_nums_point 在承諾交易章節被大量使用卻從未定義，to_remote 章節還自訂了一個與前文及測試向量都不一致的值；to_local 的控制區塊內容也有誤，延遲路徑需要附上兄弟葉雜湊，不是原文所稱的 33 位元組。

簽章與 nonce 方面，commitment_signed 原本沒有寫明 HTLC 簽章使用的 sighash 類型。修正後明訂為 SIGHASH_SINGLE|SIGHASH_ANYONECANPAY，接收方組見證時要在 64 位元組簽章後補上 0x83；由於 SIGHASH_SINGLE 綁定同索引的輸出，為了手續費加速而合併第二層交易時，每個 HTLC 輸入與對應輸出必須位於相同索引。PR 也更正 BIP 327 秘密 nonce 長度為 97 位元組，而不是兩個純量。

測試向量方面，accepted_htlc 系列把本地與遠端 HTLC 金鑰位置放反；*_remote_commit 系列與本地版本逐位元組相同，等於沒有測到任何東西，現改由遠端承諾點與本地撤銷基點重新推導；原本名為 combined_key 的欄位其實是 BIP 86 tweak 後的輸出金鑰，拆成 combined_funding_key 與 funding_key 兩項。

驗證方式與實作現況

作者表示，他從種子重新推導每一把金鑰、腳本、葉雜湊、tapscript 根與輸出金鑰，用 BIP 340、BIP 327 參考實作依 BIP 341 sighash 檢查所有簽章，包括重播每筆承諾簽章的 MuSig2 流程，並在 BIP 342 規則下執行每個見證。作者另提到曾請 AI 工具撰寫腳本，協助檢查新測試向量是否正確，並附上公開 gist。

對照實作的結果是：Eclair 的測試套件在不改程式碼的情況下直接通過新向量；LND 的測試則通過參數、三筆承諾交易、簽章驗證與 MuSig2 重播，以及 11 項腳本條目中的 5 項，其餘 6 項失敗被作者歸因於 LND 向量產生器本身與欄位更名，而非 LND 鏈上行為有誤。PR 說明未提及 Core Lightning 與 LDK 的對照結果，本文也未找到兩者的公開驗證資料。

同日合併的另一項規格收緊

同一天稍晚，BOLTs #1341 也被合併。該 PR 由 Eclair 開發者 t-bast 於 6 月提出，禁止在 utf8 欄位中放入 NULL 與其他控制字元，理由是沒有正當用途；並要求所有地方的特性位元都必須最小編碼，取消過去對 node_announcement 的寬鬆處理。這兩項加上同日合併、要求 BOLT11 發票只能有一個付款雜湊與付款秘密的 #1357，顯示規格維護者正密集把過去的模糊與寬鬆處清掉。