Bitcoin Script 實戰教學（三）：SegWit 與 Taproot 深入解析

系列導言

這是「Bitcoin Script 實戰教學」系列的第三篇。本篇將深入探討 SegWit 和 Taproot 這兩個重要升級如何改變了比特幣腳本的執行方式。這兩個升級代表了比特幣協議歷史上最重要的技術革新，不僅解決了長期存在的技術問題，更為比特幣的未來發展奠定了基礎。

系列文章：

基礎概念與操作碼
標準腳本類型詳解
SegWit 與 Taproot 深入解析（本篇）
多重簽名實現
時間鎖機制
進階應用與智能合約

一、SegWit 深入解析

1.1 什麼是 SegWit？

SegWit 是 Segregated Witness（隔離見證）的縮寫，於 2017 年 8 月透過軟分叉方式在比特幣主網啟動。這個升級的核心思想非常簡單但影響深遠：將交易的簽名數據（witness）從交易主體中分離出來。

「見證」在密碼學和法律用語中都指的是「證明某事為真的證據」。在比特幣交易中，見證就是數位簽名——它證明交易發起者確實擁有花費這些比特幣的權限。在 SegWit 之前，這些簽名數據和交易的其他部分混合在一起；SegWit 則將它們「隔離」到一個獨立的區域。

這個看似簡單的架構改變，解決了困擾比特幣多年的幾個關鍵問題。

1.2 交易延展性問題

交易延展性（Transaction Malleability）是 SegWit 解決的最重要問題之一。要理解這個問題，我們需要先了解比特幣如何識別交易。

每筆比特幣交易都有一個唯一識別碼，稱為交易 ID（txid）。這個 ID 是透過對整個交易進行雙重 SHA-256 雜湊運算得到的。問題在於，在傳統交易格式中，簽名數據也包含在這個雜湊計算中。

ECDSA 簽名有一個數學特性：對於同一個訊息，存在多個數學上等價的有效簽名。具體來說，如果 (r, s) 是一個有效簽名，那麼 (r, -s mod n) 也是有效的。這意味著任何人（不需要私鑰）都可以修改交易中的簽名，產生一個不同的 txid，但交易仍然有效。

這個問題對於一般的單筆交易影響不大，但對於依賴未確認交易 txid 的應用來說是災難性的。最典型的例子是閃電網路：它需要建立一連串相互依賴的交易，如果其中一筆交易的 txid 被修改，整個交易鏈就會斷裂。2014 年，Mt. Gox 交易所的部分損失就與交易延展性攻擊有關。

SegWit 的解決方案非常優雅：既然問題出在簽名會影響 txid，那就把簽名移到 txid 計算範圍之外。交易的核心數據（發送者、接收者、金額）用來計算 txid，而簽名則存放在獨立的 witness 區域。這樣，無論簽名如何被修改，txid 都保持不變。

1.3 區塊容量提升

比特幣區塊大小限制為 1MB，這個限制源自中本聰早期為防止垃圾交易攻擊所設置的參數。隨著比特幣使用量增加，這個限制開始制約交易處理能力，導致交易費用上升和確認時間延長。

直接增加區塊大小需要硬分叉，這意味著所有節點必須同時升級，否則網路會分裂。這在社區中引發了激烈爭論，最終導致了 2017 年的分叉事件。

SegWit 採用了一個巧妙的方法：引入「區塊權重」的概念來代替固定的區塊大小限制。新的規則規定區塊的最大權重為 4,000,000 權重單位（WU）。傳統交易數據的每個位元組計算為 4 WU，而 witness 數據的每個位元組只計算為 1 WU。

這個設計有幾個重要含義。首先，舊節點只看到傳統區塊數據，對它們來說區塊仍然在 1MB 限制內，保持了向後相容性。其次，由於 witness 數據佔用權重較少，使用 SegWit 的用戶可以享受較低的交易費用。實際上，這創造了一個經濟誘因，鼓勵用戶和錢包採用 SegWit。

在實踐中，完全使用 SegWit 交易的區塊可以達到約 2MB 到 2.3MB 的實際大小，有效地將區塊容量提升了一倍以上。

1.4 二次雜湊問題

在傳統比特幣交易中，簽名雜湊的計算方式存在一個效能問題。對於一筆有 n 個輸入的交易，每個輸入的簽名都需要對整個交易進行雜湊，這導致總的計算量與 n² 成正比——這就是所謂的二次雜湊問題。

對於普通交易來說，這個問題不太明顯。但對於輸入數量很多的大型交易，計算成本會急劇上升。惡意攻擊者可以構造特殊的交易，讓節點花費大量時間驗證，這被稱為「交易驗證拒絕服務攻擊」。

SegWit 透過 BIP 143 重新設計了簽名雜湊演算法。新演算法預先計算可複用的中間值，使得簽名驗證的複雜度從 O(n²) 降低到 O(n)。這不僅提高了效能，也消除了一類潛在的攻擊向量。

1.5 Witness 程式結構

SegWit 引入了一種新的輸出類型，稱為 witness program（見證程式）。這種輸出的 ScriptPubKey 格式非常簡潔：

<version> <witness program>

版本位元組表示 witness 程式的類型。版本 0 是目前最常用的，支援兩種標準腳本。當 witness program 的長度為 20 位元組時，它被解釋為 P2WPKH（Pay to Witness Public Key Hash），這是 SegWit 版本的 P2PKH。當長度為 32 位元組時，則是 P2WSH（Pay to Witness Script Hash），這是 SegWit 版本的 P2SH。

版本 1 是為 Taproot 保留的，使用 32 位元組的 witness program。版本 2 到 16 保留給未來的升級使用。這種版本化的設計確保了比特幣可以持續演進，同時保持向後相容性。

1.6 SegWit 交易結構

傳統比特幣交易的結構相對簡單：版本號、輸入列表（包含 ScriptSig）、輸出列表、鎖定時間。SegWit 交易則在此基礎上增加了標記位元組和 witness 區域。

SegWit 交易在版本號之後插入兩個特殊位元組：標記（marker，值為 0x00）和旗標（flag，值為 0x01）。這兩個位元組告訴支援 SegWit 的節點，這是一筆 SegWit 交易。對於不支援 SegWit 的舊節點，這些位元組會被誤解為空的輸入列表，導致交易被視為無效而忽略——這正是軟分叉的巧妙之處。

witness 區域位於輸出列表和鎖定時間之間。每個輸入都有對應的 witness 堆疊，包含簽名和其他必要的驗證數據。這些數據不參與 txid 的計算，但會被驗證節點用來確認交易的有效性。

二、Taproot 升級概述

2.1 Taproot 的歷史背景

Taproot 於 2021 年 11 月在區塊高度 709,632 啟動，是自 SegWit 以來比特幣最重要的協議升級。這個升級由三個相互關聯的 BIP 組成：BIP 340 定義了 Schnorr 簽名方案，BIP 341 定義了 Taproot 的輸出和花費規則，BIP 342 定義了 Tapscript——一個改進版的腳本語言。

Taproot 的設計理念可以追溯到 2018 年，由比特幣核心開發者 Greg Maxwell 提出。他的洞見在於：大多數複雜的比特幣合約最終都會以所有參與方達成共識的方式結算，只有在出現爭議時才需要執行複雜的腳本邏輯。因此，如果我們能讓共識結算看起來像普通的單簽名交易，就能大幅提升隱私性和效率。

這個觀察引導了 Taproot 的核心設計：每個 Taproot 輸出都有兩種花費方式。Key path（密鑰路徑）允許透過一個聚合簽名直接花費，就像普通的單簽名交易一樣。Script path（腳本路徑）則允許揭示並執行預先承諾的腳本，用於處理非共識情況。

2.2 為什麼選擇 Schnorr 簽名？

在深入 Taproot 之前，我們需要理解 Schnorr 簽名為什麼是這個升級的基石。比特幣從創始之初就使用 ECDSA（橢圓曲線數位簽名演算法），這是一個成熟且廣泛使用的簽名方案。然而，ECDSA 有一些固有的限制。

Schnorr 簽名由德國密碼學家 Claus Schnorr 在 1989 年發明，實際上比 ECDSA 更早。它沒有被比特幣最初採用的原因很簡單：當時 Schnorr 簽名受專利保護，而 ECDSA 是自由使用的。Schnorr 專利在 2008 年過期，但比特幣已經在 2009 年初以 ECDSA 的形式誕生了。

Schnorr 簽名相比 ECDSA 有幾個重要優勢。首先是數學結構的簡潔性。ECDSA 的安全性證明相當複雜，而 Schnorr 簽名有著優雅的數學證明，基於離散對數問題的困難性。這種簡潔性不僅便於分析，也使得實現更不容易出錯。

其次是線性特性。Schnorr 簽名具有加法同態性，這意味著多個簽名可以數學上相加成一個聚合簽名。對於多重簽名場景，這帶來了革命性的改進：n-of-n 多簽只需要一個 64 位元組的簽名，而不是 n 個獨立簽名。

第三是批量驗證效率。當需要驗證多個 Schnorr 簽名時，可以將它們合併成一個運算，大幅減少計算量。這對於區塊驗證特別有價值，因為每個區塊可能包含數千個簽名。

三、Schnorr 簽名詳解

3.1 數學基礎

要理解 Schnorr 簽名的工作原理，我們需要一些橢圓曲線密碼學的基礎知識。比特幣使用的是 secp256k1 曲線，這是一個定義在有限域上的橢圓曲線。曲線上有一個特殊的點 G，稱為生成點，任何私鑰 d 對應的公鑰都是 P = d × G（這裡的乘法是橢圓曲線上的純量乘法）。

Schnorr 簽名的安全性基於離散對數問題的困難性：給定 P 和 G，在計算上不可能推導出 d。這與 ECDSA 使用相同的數學難題，但 Schnorr 的構造方式更為直接。

簽名過程如下。簽名者首先選擇一個隨機數 k（稱為 nonce），計算 R = k × G。然後計算 e = H(R

m)，其中 H 是雜湊函數，m 是要簽名的訊息，

表示連接。最後計算 s = k + e × d。簽名就是 (R, s) 這對值。

驗證同樣簡潔：檢查 s × G 是否等於 R + e × P。這個等式成立的原因可以這樣理解：s × G = (k + e × d) × G = k × G + e × d × G = R + e × P。只有知道私鑰 d 的人才能計算出正確的 s 值。

3.2 與 ECDSA 的具體差異

在比特幣的實際應用中，Schnorr 和 ECDSA 簽名有幾個具體的差異。

首先是簽名格式。ECDSA 簽名使用 DER 編碼，長度通常在 71 到 72 位元組之間（取決於 r 和 s 值的具體位元數）。Schnorr 簽名固定為 64 位元組：R 點的 x 座標佔 32 位元組，s 值佔 32 位元組。

其次是公鑰格式。傳統比特幣使用壓縮公鑰（33 位元組，包含一個前綴位元組表示 y 座標的奇偶性）或非壓縮公鑰（65 位元組）。BIP 340 引入了「x-only」公鑰——只有 32 位元組的 x 座標。這種格式是可行的，因為對於任何 x 座標，最多只有兩個有效的 y 座標，而 BIP 340 規定永遠選擇「偶數」的那個。

這種簡化節省了空間，但也意味著私鑰可能需要「翻轉」。如果計算出的公鑰 y 座標是奇數，就需要用曲線的階減去私鑰，使得對應的公鑰 y 座標變為偶數。這是 Taproot 實現中的一個微妙細節。

3.3 多重簽名聚合

Schnorr 簽名最引人注目的特性是支援簽名聚合。考慮一個 2-of-2 多簽場景，Alice 和 Bob 共同控制一筆資金。

在 ECDSA 世界中，這需要一個 P2SH 腳本，包含兩個公鑰和 OP_CHECKMULTISIG。花費時需要提供兩個完整的簽名，總共約 144 位元組的簽名數據。

使用 Schnorr 簽名的 MuSig2 協議，Alice 和 Bob 首先各自選擇隨機數並交換 R 值的承諾，然後交換實際的 R 值並計算聚合 R = R_A + R_B。接著，雙方獨立計算各自的部分簽名 s_A 和 s_B，最終聚合簽名就是 (R, s_A + s_B)。

這個聚合簽名只有 64 位元組，與單一簽名完全相同。更重要的是，從鏈上觀察者的角度來看，這與普通的單簽名交易沒有任何區別。沒有人知道這筆交易實際上需要兩個人的授權。

MuSig2 是 MuSig 協議的改進版本，將互動輪次從三輪減少到兩輪，大幅提升了實用性。然而，它的實現仍然比普通簽名複雜得多，特別是在確保 nonce 安全性方面需要特別小心。

四、P2TR（Pay to Taproot）詳解

4.1 Taproot 輸出的結構

Taproot 輸出的 ScriptPubKey 格式非常簡潔：

OP_1 <32-byte x-only pubkey>

這裡的 OP_1（0x51）表示 witness 版本 1，後面跟著 32 位元組的 x-only 公鑰。這個公鑰不是普通的公鑰，而是經過「調整」（tweaked）的輸出公鑰，蘊含著豐富的資訊。

Taproot 地址使用 Bech32m 編碼（BIP 350 定義），主網地址以 bc1p 開頭，測試網地址以 tb1p 開頭。這裡的 p 代表版本 1（版本 0 使用 q，因為在 Bech32 編碼中 0 對應 q，1 對應 p）。

4.2 公鑰調整機制

Taproot 的核心創新在於公鑰調整（key tweaking）機制。假設我們有一個內部公鑰 P（可能是單一公鑰，也可能是多方聚合公鑰），以及一個可選的腳本樹。我們需要構造一個輸出公鑰 Q。

如果沒有腳本樹，調整值 t 計算為：t = H_TapTweak(P)。如果有腳本樹，則先計算樹的 Merkle 根 m，調整值為：t = H_TapTweak(P

m)。這裡的 H_TapTweak 是一個標籤雜湊函數，其定義確保了不同用途的雜湊不會碰撞。

輸出公鑰 Q = P + t × G。這個 Q 就是存放在 ScriptPubKey 中的值。

這個設計的巧妙之處在於承諾方式。如果 Q = P + t × G，那麼知道 P 和 t 的人可以驗證 Q 確實是由 P 調整而來的。而 t 本身包含了腳本樹的 Merkle 根（如果有的話），所以 Q 實際上承諾了整個腳本樹的內容，但除非需要使用腳本路徑，否則這些腳本永遠不會暴露。

4.3 Key Path 花費

Key path 是 Taproot 輸出最常見的花費方式，也是最高效的方式。要透過 key path 花費，簽名者需要知道內部私鑰 d，然後計算調整後的私鑰 d’ = d + t。使用 d’ 對交易進行 Schnorr 簽名，這個簽名就可以通過 Q 的驗證。

witness 只包含一個元素：64 位元組的 Schnorr 簽名。沒有腳本，沒有公鑰揭示，沒有任何其他數據。這意味著無論背後的腳本有多複雜，只要所有參與方達成共識，花費的方式就和最簡單的單簽名交易一樣。

這對隱私有巨大的意義。一個複雜的多方合約——比如閃電網路通道的開設和關閉——在鏈上看起來與普通的個人轉帳沒有區別。觀察者無法知道這筆交易背後是一個人還是一百個人，是否有任何備用腳本存在。

4.4 Script Path 花費

當需要使用備用腳本時，就需要透過 script path 花費。這種情況下，witness 需要包含三部分：腳本的輸入數據（如簽名）、要執行的腳本本身，以及控制區塊（control block）。

控制區塊的結構包含：一個版本位元組（其中包含葉子版本和 Q 的 y 座標奇偶性）、32 位元組的內部公鑰 P，以及 Merkle 證明路徑（每個節點 32 位元組）。

Merkle 證明路徑允許驗證者確認所揭示的腳本確實是輸出承諾的腳本樹的一部分。驗證過程是：首先用腳本和葉子版本計算葉子雜湊，然後沿著證明路徑向上計算直到得到 Merkle 根，最後驗證 Q = P + H_TapTweak(P

root) × G。

這個機制的優美之處在於，只需要揭示你實際使用的腳本和它的證明路徑，而不需要揭示整個腳本樹。如果樹中有 128 個腳本，使用其中一個只需要 7 層的證明（log₂(128) = 7），其他 127 個腳本保持完全保密。

4.5 MAST 的實現

Taproot 實際上實現了一個叫做 MAST（Merkle Abstract Syntax Tree，默克爾抽象語法樹）的概念。這個概念在比特幣社區討論多年，而 Taproot 終於將它變成了現實。

傳統的 P2SH 需要在花費時揭示整個贖回腳本，無論其中有多少分支。如果你有一個「Alice 可以隨時花費，或者 Bob 在一年後可以花費」的腳本，即使 Alice 花費，也需要揭示 Bob 的備用條件存在。

使用 Taproot，Alice 和 Bob 可以構建一個腳本樹：根節點下有兩個葉子，分別是 Alice 的條件和 Bob 的時間鎖條件。更好的是，他們可以用聚合公鑰作為 key path——如果雙方合作，完全不需要揭示任何腳本。只有當他們無法合作（比如 Alice 失聯）時，Bob 才需要使用 script path，此時只揭示自己的分支，Alice 的腳本保持私密。

這種架構對於閃電網路等複雜協議特別有價值。閃電網路通道的承諾交易包含多個可能的花費路徑，使用 Taproot 可以大幅簡化這些交易的結構並提升隱私性。

五、Tapscript 新規則

5.1 Tapscript 的設計目標

Tapscript 是 Taproot 腳本路徑中使用的腳本規則，由 BIP 342 定義。它基於 SegWit 的腳本規則，但做了幾個重要的修改和改進。

設計 Tapscript 的主要目標是：適配 Schnorr 簽名、改進多簽效率、放寬某些限制、以及為未來升級預留空間。

5.2 OP_CHECKSIGADD

Tapscript 最重要的新操作碼是 OP_CHECKSIGADD（0xba）。這個操作碼專門為 Schnorr 簽名的批量驗證優化設計，用來取代傳統的 OP_CHECKMULTISIG。

OP_CHECKMULTISIG 有一個著名的「off-by-one」bug：它會多從堆疊中彈出一個未使用的元素。這個 bug 從比特幣誕生之初就存在，由於共識規則無法輕易修改，一直保留至今。OP_CHECKSIGADD 避免了這個問題。

OP_CHECKSIGADD 的語義很簡單：它從堆疊取三個元素——簽名、計數器 n、公鑰。如果簽名有效，將 n+1 推回堆疊；如果簽名無效（空簽名），將 n 推回堆疊。這允許用簡單的累加邏輯實現 k-of-n 多簽：

<pk1> OP_CHECKSIG
<pk2> OP_CHECKSIGADD
<pk3> OP_CHECKSIGADD
2 OP_NUMEQUAL

這個腳本檢查三個公鑰中是否至少有兩個對應有效簽名。與 OP_CHECKMULTISIG 不同，簽名的順序不需要與公鑰順序匹配——未簽名的公鑰對應空簽名即可。

更重要的是，這種結構允許有效的批量驗證。驗證者可以收集所有的 (公鑰, 訊息, 簽名) 三元組，使用 Schnorr 的批量驗證演算法一次性驗證所有簽名，這比逐個驗證快得多。

5.3 放寬的限制

Tapscript 移除了幾個傳統腳本的限制。

腳本大小限制：傳統腳本限制為 10,000 位元組，Tapscript 沒有這個限制（但仍受區塊權重限制）。這對於某些需要大量公鑰或複雜邏輯的應用來說是重要的改進。

操作碼數量限制：傳統腳本限制每個腳本最多 201 個操作碼，Tapscript 移除了這個限制。這對於需要大量條件分支的複雜腳本很有用。

堆疊元素大小：傳統腳本限制單個堆疊元素最大 520 位元組。Tapscript 仍然有這個限制，但由於 OP_SUCCESS 的存在，未來可以透過軟分叉放寬。

5.4 OP_SUCCESS 與未來升級

Tapscript 引入了一個創新的升級機制：OP_SUCCESS 操作碼。這些是一組目前未定義的操作碼（包括 0x50, 0x62, 0x89-0x8a 等），在 Tapscript 中被解釋為「立即成功」——遇到這些操作碼時，腳本驗證立即成功，不管其他條件。

這看起來像是一個安全漏洞——使用這些操作碼的腳本不就可以無條件被任何人花費嗎？確實如此。但關鍵在於，這允許未來透過軟分叉賦予這些操作碼實際意義。一旦一個 OP_SUCCESS 被重新定義，使用它的腳本就需要滿足新的條件才能被花費。

這種「先開放再收緊」的升級策略比傳統的「先禁用再啟用」更加靈活。傳統腳本中的禁用操作碼（如 OP_CAT）一旦被執行就會使腳本失敗，這意味著啟用它們需要複雜的版本控制機制。而 OP_SUCCESS 可以被簡單地重新定義，只要新的規則比「無條件成功」更嚴格，就是向後相容的軟分叉。

六、Bech32m 地址編碼

6.1 從 Bech32 到 Bech32m

SegWit v0 引入了 Bech32 地址編碼，這是一種專為人類可讀性設計的編碼格式，使用 32 個字元（qpzry9x8gf2tvdw0s3jn54khce6mua7l）來表示數據，並包含強大的錯誤檢測能力。

然而，Bech32 被發現存在一個弱點：在某些情況下，地址末尾的 q 字元可以被添加或刪除而不改變校驗和。這個問題對於 SegWit v0 地址影響較小（因為長度是固定的），但對於未來可能有不同長度的 witness 版本來說是個問題。

BIP 350 定義了 Bech32m 來解決這個問題。它使用了不同的校驗和常數，使得添加或刪除字元會被檢測到。規則是：SegWit v0 地址繼續使用原始 Bech32 編碼，而 SegWit v1 及更高版本使用 Bech32m。

這就是為什麼 P2WPKH 和 P2WSH 地址以 bc1q 開頭（q 是版本 0 在 Bech32 中的表示），而 P2TR 地址以 bc1p 開頭（p 是版本 1 在 Bech32 中的表示）。

6.2 地址類型識別

作為開發者，了解如何識別不同的比特幣地址類型很有用：

以 1 開頭的是傳統 P2PKH 地址，使用 Base58Check 編碼。以 3 開頭的是 P2SH 地址，可能包裝任何類型的腳本，包括 SegWit（P2SH-wrapped SegWit）。以 bc1q 開頭的是原生 SegWit v0 地址（P2WPKH 或 P2WSH）。以 bc1p 開頭的是 Taproot（P2TR）地址。

測試網使用不同的前綴：m 或 n 開頭是測試網 P2PKH，2 開頭是測試網 P2SH，tb1q 是測試網 SegWit v0，tb1p 是測試網 Taproot。

七、實際應用案例

7.1 閃電網路通道

閃電網路是 Taproot 最重要的受益者之一。傳統的閃電網路通道開設交易使用 2-of-2 P2WSH 多簽，在鏈上清晰可見。使用 Taproot，通道開設只需要一個普通的 P2TR 輸出，無法與普通支付區分。

通道承諾交易包含多個可能的花費路徑：合作關閉、單方面關閉、懲罰交易等。使用 MAST 結構，這些複雜的邏輯可以被隱藏在腳本樹中，只在必要時揭示。

7.2 多簽錢包

對於需要多方授權的企業或高價值錢包，Taproot 提供了顯著的隱私和成本優勢。一個 3-of-5 的多簽設置，使用 Schnorr 聚合可以讓所有簽名者共同產生一個單一簽名。在鏈上，這與個人錢包的交易看起來完全一樣。

如果某些簽名者無法參與，可以透過 script path 使用備用的閾值方案，只需要揭示需要的那個分支。

7.3 遺產規劃

Taproot 對於加密貨幣遺產規劃也很有用。假設 Alice 想設置一個輸出：正常情況下她自己可以花費，但如果她失聯超過一年，她的繼承人可以透過 2-of-3 多簽來花費。

使用 Taproot，Alice 的公鑰可以作為 key path——日常使用時就像普通錢包一樣。腳本樹中包含一個帶時間鎖的繼承人多簽腳本。只有當 Alice 真的無法使用 key path 時，繼承人才需要揭示這個腳本。

八、實作練習

練習 1：創建 Taproot 地址

嘗試用你熟悉的程式語言創建一個簡單的 Taproot 地址。步驟包括：生成一個隨機私鑰，計算對應的公鑰（注意轉換為 x-only 格式），計算無腳本的 tap tweak，調整公鑰，使用 Bech32m 編碼生成地址。

練習 2：設計腳本樹

設計一個 Taproot 輸出，支援以下場景：Alice 和 Bob 可以隨時共同簽名（key path），Alice 可以在 30 天後單獨花費，Carol 可以在 180 天後作為緊急恢復。畫出腳本樹結構，並考慮如何優化樹的深度以最小化未來可能的見證大小。

練習 3：比較效率

計算以下場景的 witness 大小：2-of-3 多簽使用傳統 P2SH、使用 P2WSH、使用 Taproot key path（假設 MuSig2 聚合）、使用 Taproot script path。分析不同方案的權衡。

九、小結

本篇我們深入探討了比特幣兩個最重要的升級：

SegWit 的貢獻包括：解決了交易延展性問題，使閃電網路等二層協議成為可能；提升了有效區塊容量；優化了簽名雜湊計算的效率；引入了版本化的 witness 程式，為未來升級奠定基礎。

Taproot 的創新包括：引入 Schnorr 簽名，提供更高效的簽名和批量驗證；實現 MAST，允許複雜腳本保持私密；透過 key path/script path 雙路徑設計，讓大多數交易看起來像簡單的單簽名；Tapscript 改進了腳本語言並為未來升級預留空間。

這些技術不僅提升了比特幣的效率和可擴展性，更重要的是大幅增強了隱私性——讓複雜的智能合約在鏈上看起來與普通交易無異。

下一篇預告

在下一篇文章中，我們將探討多重簽名的各種實現方式，包括傳統的 OP_CHECKMULTISIG、Tapscript 的 OP_CHECKSIGADD、以及 MuSig2 協議的細節。

參考資料

BIP 141: SegWit - SegWit 的原始規格
BIP 143: SegWit 簽名哈希 - 新的簽名雜湊演算法
BIP 340: Schnorr 簽名 - Schnorr 簽名的比特幣標準
BIP 341: Taproot - Taproot 的完整規格
BIP 342: Tapscript - Tapscript 腳本規則
BIP 350: Bech32m - 改進的地址編碼
Bitcoin Optech: Taproot - 深入的技術解說