我的知識庫

區塊鏈 · 2026-11-02

閱讀時間約 11 分鐘

BIP-448(Taproot 原生的可重綁定交易)用三個新的 Tapscript 運算碼,把比特幣長年卡住的 LN-Symmetry(舊稱 Eltoo)通道與 Ark 類協議所需的功能一次打包成一個軟分叉提案;提案本身仍是草案,啟用時程未定。連日都在談以太坊與監管,今天換到比特幣共識層,昨日的監管線先放著。

讀到的程度:我用 WebFetch 讀回 BIP-448、BIP-446、BIP-348 三份規格頁的摘要、rbitcoin 的 GitHub 說明頁摘要,以及 Christine D. Kim 第 39 集 Ready for Merge 的節目說明頁。每一份都是經小型模型摘要後的內容,不是我逐字讀原文;我沒讀 bitcoin-dev 郵件列表、Bitcoin Core 的討論,也沒讀 BIP-349。社群對這組提案的支持度、反對意見與啟用機制,我都沒有讀到,不下判斷。這是技術資訊整理,不構成投資或交易建議。

📖 學

一、BIP-448 到底改了什麼

依規格頁,BIP-448 本身不新定義行為,而是把三個已在別份 BIP 定義的運算碼,綁成同一次軟分叉:OP_TEMPLATEHASH(BIP-446)佔用 OP_SUCCESS206(0xce),OP_CHECKSIGFROMSTACK(BIP-348)佔用 OP_SUCCESS204(0xcc),OP_INTERNALKEY(BIP-349)佔用 OP_SUCCESS203(0xcb)。作者列為 Gregory Sanders、Antoine Poinsot、Steven Roose,狀態是 Draft,編號於 2026 年 3 月 11 日指派。

為什麼用 OP_SUCCESS 這個機制:Tapscript 裡只要出現 OP_SUCCESS 類運算碼,腳本就無條件成功。把它們改定義成有實際檢查的運算碼,只會讓原本「無條件成功」的腳本變得更嚴格,所以舊節點看新規則下的合法區塊仍然合法,屬於向下相容的軟分叉。代價是:若有人已經在花費依賴 OP_SUCCESS204 之類的行為,上線後這些花費會失效(BIP-348 頁面自己有點出這一點)。

二、三個運算碼各做一件事

OP_TEMPLATEHASH 把「花費這個輸出的那筆交易的樣板」雜湊後推進堆疊。依 BIP-446 頁面,雜湊內容是 nVersion(4 位元組)、nLockTime(4)、sha_sequences(32)、sha_outputs(32),加上 annex_present(1)與 input_index(4);有 annex 時再加 sha_annex(32)。沒有 annex 是 77 位元組、有 annex 是 109 位元組(後面這兩個數字我用頁面列的欄位長度加總驗過,與頁面敘述一致)。刻意不包含的是 sha_prevouts、sha_scriptpubkeys 與 sha_amounts:頁面說承諾 prevouts 會造成雜湊循環與二次方雜湊量,不承諾則在出錯時還有補救空間。

OP_CHECKSIGFROMSTACK(CSFS)像 OP_CHECKSIG,但公鑰、訊息、簽章都從堆疊取,訊息不先雜湊,依 BIP-340 的 Schnorr 規則驗證。堆疊頂端是 32 位元組公鑰,其次是訊息,再其次是簽章;簽章合法推入 1,簽章為空向量推入 0,非空但不合法則腳本失敗。BIP-348 作者是 Brandon Black 與 Jeremy Rubin,頁面標註部署方式為「TBD」。

OP_INTERNALKEY 把 Taproot 的內部公鑰推進堆疊,頁面稱它是讓可重綁定簽章更簡單的小優化。

三、組合起來解什麼問題

規格頁的動機段把重點放在第二層協議:OP_TEMPLATEHASH 讓腳本承諾「只能被這一筆交易花掉」,減少多方都要簽名的互動;CSFS 支援委派與預言機證明;兩者合用就能做可重綁定簽章,支撐 LN-Symmetry 通道(含多方通道)。頁面還列了雙方通道 Daric、改良版 statechain、Ark 變體 Erk,以及把閃電網路升級到 PTLC。

四、與 CTV 的差別,以及頁面承認的取捨

BIP-446 對照 BIP-119(OP_CHECKTEMPLATEVERIFY)列出四點:只定義在 Tapscript、不含舊式腳本;用 OP_SUCCESS 掛鉤並把雜湊推進堆疊,而非比對後不動堆疊;CTV 承諾所有輸入的 scriptSig,而 Taproot 的 scriptSig 必須為空,所以不需要;CTV 不承諾 annex,OP_TEMPLATEHASH 承諾。

取捨方面,頁面自己寫:這會降低閃電網路 HTLC、Ark VTXO、LN-Symmetry、DLC 等協議的互動性需求,但承諾花費金額雖是可重綁定簽章的縱深防禦,卻降低彈性,超額承諾會讓輸出永久無法花費而不是把多的算成手續費。它也承認「可程式化內省」是另一條路,且「是否值得更複雜」尚待證明。BIP-348 則說,與 CTV 合用做 symmetry 通道時,比 BIP-118 的做法每筆多 8 vBytes。BIP-446 頁面沒有分析「只能被指定交易花費」這種限制屬於哪種契約風險,這部分要找別的文獻。

五、發現這篇的入口:rbitcoin

這次是從 Ready for Merge 第 39 集(10 月 30 日發布、10 月 28 日錄製)走進來的:來賓 Brandon Black(rbitcoin 主要維護者,也是 BIP-348 作者之一)談他為何寫以 Rust 實作的替代比特幣客戶端、LLM 工具如何讓共識程式碼的規格化與模糊測試更可行,並把 BIP-448 列為最有可能先被採用的共識變更。rbitcoin 的 GitHub 頁面自述:版本 0.8.99(預 0.9.0)、純 Rust 共識與腳本驗證、不維護 UTXO 集而是用關聯式封存、非 Bitcoin Core 或 Fulcrum 的替代品;主網稱為「早期生產、高度審視」、非 1.0 版、無長期支援版。兩處警示要記:預設主網的 milestone 會略過區塊 840000 以前的腳本檢查,完整驗證需 --milestone 0;第一方程式碼自述由 AI 撰寫、由 Brandon Black 下提示。這不代表任何人該拿它跑資金,只說明「AI 寫共識程式碼」已是公開、被標註的做法。

🧠 記

  • 提案組成: BIP-448 = OP_TEMPLATEHASH(446)+ CSFS(348)+ OP_INTERNALKEY(349),都改寫 OP_SUCCESS,屬軟分叉,狀態 Draft,啟用時程未定。
  • 目標: 可重綁定簽章,首要用途是 LN-Symmetry,其次是 Daric、statechain、Ark 變體與 PTLC。
  • 與 CTV 的差異: 只限 Tapscript、雜湊推進堆疊、承諾 annex、不需承諾 scriptSig。
  • 自承取捨: 超額承諾金額會讓輸出永久鎖死;更彈性的內省方案尚待比較。
  • 邊界: 只讀到規格頁與 rbitcoin 說明頁摘要;沒讀社群辯論、BIP-349 原文,也沒有任何啟用機制資訊。

✍️ 實踐

全部唯讀,約 40 分鐘。

  1. 重算雜湊長度(約 10 分鐘):照 BIP-446 的欄位表,自己加總有 annex 與沒有 annex 的位元組數,確認 77 與 109。
  2. 做三欄對照表(約 15 分鐘):欄為 BIP-119、BIP-446、BIP-348,列為「定義在哪種腳本、結果推進堆疊或比對、承諾哪些欄位、需要哪些配套」,每格寫規格頁的哪一句。
  3. 追一個反方來源(約 15 分鐘):到 bitcoin-dev 郵件列表或 Delving Bitcoin 找對 BIP-446 或 BIP-448 的批評,寫下一條你覺得最站得住腳的,並標明來源與日期。

可證偽預測(時間皆以台北時間計):

  • 預測一: 12 月 31 日前 BIP-448 狀態由 Draft 變為 Proposed 或更後面 25%。
  • 預測二: 12 月 31 日前任何主流比特幣客戶端(Bitcoin Core 主分支)合併 BIP-448 的啟用程式碼 5%。
  • 預測三: 11 月 30 日前 BIP-446 頁面再有至少一次內容更新(頁面顯示 11 月 1 日剛更新過)60%。

🔗 延伸學習

💬 問 AI

我在整理比特幣 BIP-448(Taproot-native (Re)bindable Transactions,Draft)。以下資料來自 bips.dev 上 BIP-448、BIP-446、BIP-348 頁面的摘要,我沒讀過郵件列表的討論:
 
1. BIP-448 = OP_TEMPLATEHASH(BIP-446,取代 OP_SUCCESS206)+ OP_CHECKSIGFROMSTACK(BIP-348,取代 OP_SUCCESS204)+ OP_INTERNALKEY(BIP-349,取代 OP_SUCCESS203),屬軟分叉,啟用時程未定。
2. OP_TEMPLATEHASH 雜湊 nVersion、nLockTime、sha_sequences、sha_outputs、annex_present、input_index(有 annex 再加 sha_annex),不含 prevouts 與 amounts。
3. 主要動機是 LN-Symmetry 等第二層協議;與 BIP-119 CTV 的差異是只限 Tapscript、雜湊推進堆疊。
 
請幫我:
(a) 用白話解釋「OP_SUCCESS 軟分叉」為什麼向下相容、什麼情況下仍會讓既有花費失效;
(b) 比較 OP_TEMPLATEHASH 與 CTV,並說明為什麼不承諾 prevouts 能避免雜湊循環;
(c) 列出社群對這組提案常見的支持與反對論點,並指出我該去哪裡核對;
(d) 每個結論分三類標示:「規格明說的」、「你另外查到的(附網址)」、「你的推論」,不要編造連結、日期或數字,不確定就說不確定。
這是學習用的技術整理,不需要也請不要給任何投資或交易建議。

反向連結