Bitcoin Script 實戰教學（四）：多重簽名完全指南

系列導言

這是「Bitcoin Script 實戰教學」系列的第四篇。本篇將全面探討多重簽名的各種實現方式，從傳統的 OP_CHECKMULTISIG 到現代的 MuSig2。多重簽名是比特幣腳本系統最重要的應用之一，它將比特幣的安全性從單一密鑰提升到分散式信任模型，為個人資產保護、企業財務管理、以及複雜的智能合約奠定了基礎。

系列文章：

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

一、理解多重簽名

1.1 從單簽名到多重簽名

在傳統的比特幣交易中，一個私鑰對應一個地址，擁有私鑰就能完全控制該地址下的所有資金。這種模型簡單直接，但也有明顯的風險：私鑰一旦丟失或被盜，資金就永久無法恢復或被竊取。

多重簽名（Multisignature，簡稱 Multisig）是一種需要多個私鑰授權才能花費資金的機制。它通常用 m-of-n 的形式表示，其中 n 是參與的公鑰總數，m 是需要的最少簽名數量。例如，2-of-3 多重簽名意味著有三個人各持有一把私鑰，但只需要其中任意兩人簽名就能花費資金。

這個看似簡單的概念帶來了深遠的影響。它讓我們能夠設計出容錯性更強的資產保管方案，建立需要多方同意的企業財務系統，甚至構建去中心化的協議層應用。

1.2 為什麼需要多重簽名？

多重簽名解決了加密貨幣管理中的幾個核心問題。

首先是安全性問題。即使你的一把私鑰被盜，攻擊者也無法動用資金，因為他們還需要獲取其他密鑰。這種「冗餘安全」的概念與傳統銀行保險箱需要兩把鑰匙的原理類似，但在數位領域實現得更加優雅。

其次是可恢復性問題。在 2-of-3 配置中，即使你丟失了一把私鑰，仍然可以使用剩餘的兩把密鑰恢復對資金的控制。這大大降低了「因為忘記密碼而永久失去比特幣」這類悲劇發生的可能性。

第三是治理問題。對於企業或組織來說，重大財務決策不應該由單一個人控制。多重簽名可以確保資金的動用需要多個授權人的同意，這與傳統公司治理中的多人簽核流程相呼應。

最後是信任最小化。在涉及多方的交易場景中，例如託管服務或去中心化交易，多重簽名可以設計出不需要完全信任任何單一方的解決方案。經典的 2-of-3 託管就是一個例子：買家、賣家、仲裁者各持一把密鑰，正常情況下買賣雙方完成交易，只有發生爭議時才需要仲裁者介入。

1.3 多重簽名的歷史演進

比特幣的多重簽名經歷了三個主要的發展階段，每個階段都帶來了效率和隱私的顯著提升。

第一階段是 2012 年隨 BIP 16 引入的 P2SH 多重簽名。這是最早被廣泛採用的標準化多簽方案，使用 OP_CHECKMULTISIG 操作碼在腳本層面驗證多個簽名。雖然這種方法功能完善，但它需要在鏈上暴露所有公鑰和所需的所有簽名，導致較大的交易體積和較高的費用。

第二階段是 2017 年 SegWit 帶來的 P2WSH 多重簽名。這種方式在功能上與 P2SH 類似，但由於簽名數據被放入 witness 區域並享受費用折扣，實際成本下降了約 35%。同時，使用 SHA256 替代 HASH160 也提升了密碼學安全性。

第三階段是 2021 年 Taproot 啟動後帶來的革命性變化。透過 Schnorr 簽名的線性特性，多個簽名現在可以被聚合成一個單一簽名，在鏈上看起來與普通的單簽名交易完全相同。這不僅大幅降低了費用，更重要的是提供了前所未有的隱私保護——外部觀察者無法判斷一筆交易是單人控制還是需要多方授權。

二、傳統多重簽名詳解

2.1 OP_CHECKMULTISIG 的工作原理

OP_CHECKMULTISIG 是比特幣最早支援多重簽名的操作碼。它的設計相當直接：從堆疊中取出一組公鑰和一組簽名，然後驗證是否有足夠數量的有效簽名。

一個 2-of-3 多重簽名的贖回腳本（Redeem Script）看起來像這樣：

OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG

這個腳本的含義是：這裡有三個公鑰，需要其中兩個對應的有效簽名才能花費這筆資金。OP_2 指定需要的簽名數量，OP_3 指定公鑰的總數，而 OP_CHECKMULTISIG 執行實際的驗證邏輯。

當花費這筆資金時，ScriptSig（解鎖腳本）需要提供簽名和原始的贖回腳本：

OP_0 <signature1> <signature2> <redeemScript>

這裡的 OP_0 是一個看起來奇怪但必需的元素，稍後我們會解釋它的存在原因。

2.2 臭名昭著的 off-by-one Bug

OP_CHECKMULTISIG 有一個從比特幣誕生之初就存在的程式錯誤：它會從堆疊中多彈出一個元素。這個被稱為「off-by-one bug」的問題源於原始程式碼中的一個索引錯誤。

具體來說，在驗證完所有簽名之後，操作碼會嘗試彈出一個額外的元素。如果堆疊中沒有這個元素，腳本就會失敗。更糟糕的是，彈出的這個元素被完全忽略——它不參與任何驗證邏輯。

為了讓腳本正確執行，使用者必須在簽名之前放置一個「啞」元素。這個元素可以是任何值，因為它反正會被忽略。慣例上使用 OP_0（空位元組），這就是為什麼你會在所有多簽 ScriptSig 的開頭看到這個看似莫名其妙的零值。

為什麼這個 bug 沒有被修復？因為比特幣的共識規則是神聖不可侵犯的。任何改變腳本驗證行為的修改都可能導致原本有效的交易變得無效，從而引發網路分裂。這個 bug 作為「歷史遺產」被永久保留了下來。

不過，BIP 147 引入了一個軟分叉規則（NULLDUMMY），要求這個啞元素必須是空位元組 OP_0。這防止了一類潛在的交易延展性攻擊，因為在此之前，這個被忽略的元素可以被第三方任意修改而不影響交易有效性。

2.3 簽名順序的限制

OP_CHECKMULTISIG 還有一個重要的限制：簽名必須按照公鑰在腳本中出現的順序排列。這意味著如果你有公鑰 A、B、C，而且只有 A 和 C 簽名了，你不能提供簽名順序為 C、A——必須是 A、C。

這個設計選擇是為了簡化驗證邏輯。操作碼按順序遍歷公鑰，對每個簽名嘗試用下一個未匹配的公鑰驗證。一旦匹配成功就移動到下一個簽名，如果到達公鑰列表末尾而還有未驗證的簽名，則整個驗證失敗。

這個約束給實際應用帶來了一些不便。在收集簽名時，你需要知道每個簽名者對應哪個公鑰，並按正確順序排列。這也是為什麼後來的 Tapscript 採用了不同的設計。

2.4 建立 P2SH 多重簽名地址

讓我們看一個完整的建立 2-of-3 P2SH 多重簽名地址的過程。

首先，需要收集所有參與者的公鑰。在實踐中，這通常意味著每個參與者用自己的錢包軟體或硬體錢包生成一個公鑰並分享給協調者。重要的是只分享公鑰，絕不分享私鑰。

接下來，按照字典序對公鑰進行排序。這一步確保無論誰來建立地址，使用相同的公鑰集合都會得到相同的地址。沒有這個標準化步驟，不同的排序會產生不同的地址，造成混亂。

然後，構建贖回腳本並計算其 HASH160 雜湊值。這個 20 位元組的雜湊值就是 P2SH 地址的核心部分。最後，加上版本前綴（主網為 0x05）並進行 Base58Check 編碼，就得到了一個以「3」開頭的 P2SH 地址。

每個參與者都需要保存完整的贖回腳本，因為花費時需要揭示它。實際上，大多數多簽錢包會同時記錄所有公鑰，並在需要時重新生成腳本，以確保一致性。

三、SegWit 多重簽名

3.1 P2WSH 的優勢

SegWit 為多重簽名帶來了實質性的改進，主要體現在三個方面。

費用節省是最直觀的好處。在 SegWit 中，witness 數據（包括簽名）只計算四分之一的區塊權重。對於簽名佔據大部分體積的多簽交易來說，這意味著顯著的成本下降。一個 2-of-3 的 P2WSH 交易相比等價的 P2SH 交易，可以節省約 35% 的費用。隨著簽名數量增加，節省的比例還會更高。

安全性也得到了提升。P2SH 使用 HASH160（RIPEMD160(SHA256(x))），產生 20 位元組的雜湊值，提供約 80 位元的碰撞抵抗。P2WSH 則直接使用 SHA256，產生 32 位元組的雜湊值，提供 128 位元的碰撞抵抗。雖然 80 位元在目前看來已經足夠安全，但對於可能存在數十年的大額資產來說，更高的安全邊際是值得的。

此外，SegWit 重新設計的簽名雜湊演算法（BIP 143）解決了傳統交易的二次雜湊問題，使得驗證大型多簽交易的計算成本更加可控。

3.2 P2WSH 的結構

P2WSH 多重簽名在概念上與 P2SH 類似，但結構有所不同。

ScriptPubKey 變成了標準的 SegWit v0 格式：

OP_0 <32-byte-SHA256-of-witnessScript>

ScriptSig 現在是空的——所有解鎖數據都移到了 witness 區域。

witness 結構與 P2SH 的 ScriptSig 類似：

<empty-dummy>
<signature1>
<signature2>
<witnessScript>

witnessScript 的內容與傳統的 redeemScript 完全相同：

OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG

這種設計讓從 P2SH 遷移到 P2WSH 變得相對簡單：核心邏輯不變，只是封裝方式改變了。

3.3 巢狀 SegWit（P2SH-P2WSH）

在 SegWit 早期採用階段，許多交易所和服務商尚未支援原生 SegWit 地址。為了兼容這些服務，出現了一種過渡方案：將 P2WSH 包裝在 P2SH 內部。

這種巢狀結構的 ScriptPubKey 是標準的 P2SH 格式（地址以「3」開頭），但 redeemScript 只包含一個 SegWit witness program：

OP_0 <32-byte-SHA256-of-witnessScript>

花費時，ScriptSig 只包含這個 redeemScript，而實際的簽名數據仍然放在 witness 區域。

這種方案提供了部分 SegWit 的費用優惠（因為簽名仍在 witness 中），同時保持了與舊系統的兼容性。隨著原生 SegWit 支援越來越普及，這種過渡格式的使用正在減少。

四、Taproot 革新多重簽名

4.1 兩種路徑的設計哲學

Taproot 為多重簽名提供了兩種截然不同的實現方式，每種都有其獨特的優勢和適用場景。

Key Path 使用 Schnorr 簽名的聚合特性，將多個簽名者的公鑰和簽名合併成一個。在鏈上，這看起來就像普通的單簽名交易——只有 64 位元組的簽名，沒有公鑰列表，沒有任何多簽的痕跡。這提供了最佳的效率和隱私，但要求所有簽名者都必須參與（n-of-n）。

Script Path 使用 Tapscript 中的 OP_CHECKSIGADD 操作碼，允許 m-of-n 的任意閾值配置。雖然這種方式需要揭示腳本並在鏈上可見多個公鑰和簽名，但它提供了更大的靈活性——不需要所有人都在線，只需要達到閾值即可。

在實踐中，這兩種方式通常會結合使用。Key Path 設置為所有參與者的聚合公鑰，作為最常見情況（共識達成）的高效路徑。Script Path 中包含各種備用方案，例如子集閾值簽名、時間鎖保護的緊急恢復等，作為異常情況的處理機制。

4.2 MuSig2：聚合簽名的實現

MuSig2 是目前比特幣採用的 Schnorr 多簽聚合協議，由 BIP 327 標準化。它允許 n 個參與者共同產生一個看起來像單簽名的聚合簽名。

協議分為兩個主要階段。第一階段是密鑰聚合：每個參與者提供自己的公鑰，這些公鑰通過特定的演算法組合成一個聚合公鑰。這個聚合公鑰就是 Taproot 輸出的內部公鑰（或經過調整後的輸出公鑰）。

密鑰聚合不是簡單的相加。為了防止一類稱為「流氓密鑰攻擊」的安全問題，每個公鑰在相加前會乘以一個基於所有公鑰的係數。這確保了沒有任何一方可以惡意選擇自己的公鑰來操控聚合結果。

第二階段是簽名生成。MuSig2 需要兩輪通訊。在第一輪，每個簽名者生成一對隨機 nonce 並分享公開部分。在第二輪，每個簽名者計算自己的部分簽名並分享。最終，這些部分簽名被聚合成一個完整的 Schnorr 簽名。

MuSig2 相比其前身 MuSig 的主要改進是將互動輪次從三輪減少到兩輪，並且允許 nonce 預生成，這大大提升了實用性，特別是對於硬體錢包等離線簽名設備。

4.3 Nonce 安全性的關鍵性

MuSig2 實現中最需要謹慎處理的是 nonce（隨機數）的管理。nonce 重用可以導致私鑰洩露，這不是理論上的威脅——歷史上確實發生過因為 nonce 問題而損失大量比特幣的事件。

每次簽名必須使用全新的隨機 nonce。為了在這個要求和離線簽名的便利性之間取得平衡，MuSig2 允許預先生成一批 nonce 並安全存儲。但這帶來了狀態管理的複雜性：系統必須確保每個 nonce 只使用一次，即使在崩潰恢復的情況下也是如此。

對於硬體錢包這類安全敏感的環境，通常會採用確定性 nonce 生成方案，基於私鑰和訊息派生 nonce，從而避免狀態管理的問題。但這需要謹慎的密碼學設計，不正確的實現可能引入新的漏洞。

4.4 Tapscript 中的 OP_CHECKSIGADD

當 n-of-n 聚合不適用時（比如只需要 m-of-n 的子集），Taproot 提供了 Script Path 作為替代方案。Tapscript 引入了 OP_CHECKSIGADD 操作碼，這是傳統 OP_CHECKMULTISIG 的現代化替代品。

OP_CHECKSIGADD 的設計更加簡潔和靈活。它從堆疊取三個元素：一個簽名、一個累加器值、和一個公鑰。如果簽名有效，累加器加一；如果簽名為空（表示該簽名者沒有簽名），累加器不變。最後，累加器被推回堆疊。

一個 2-of-3 的 Tapscript 看起來像這樣：

<pubkey1> OP_CHECKSIG
<pubkey2> OP_CHECKSIGADD
<pubkey3> OP_CHECKSIGADD
2 OP_NUMEQUAL

執行時，堆疊上會累積有效簽名的數量，最後與所需閾值比較。

這種設計有幾個優點。首先，它沒有 off-by-one bug，不需要那個莫名其妙的啞元素。其次，簽名順序是靈活的——不需要按公鑰順序排列，未簽名的位置只需提供空值。第三，它支援高效的批量驗證，因為所有簽名可以被收集起來一次性驗證。

五、閾值簽名：更進一步

5.1 從多重簽名到閾值簽名

多重簽名和閾值簽名都解決「需要多方授權」的問題，但它們在技術實現上有根本區別。

傳統多重簽名（包括 OP_CHECKMULTISIG 和 OP_CHECKSIGADD）在腳本層面工作：每個參與者獨立產生自己的簽名，腳本驗證時檢查是否有足夠數量的有效簽名。這意味著每個簽名都是獨立存在的，鏈上可以看到有多少人參與、需要多少人簽名。

閾值簽名則在密碼學層面工作：多個參與者協作產生一個單一的聚合簽名，這個簽名與普通的單人簽名無法區分。沒有人（包括區塊鏈分析者）能夠知道這筆交易實際上需要多方授權。

MuSig2 可以看作是 n-of-n 的閾值簽名——所有人都必須參與才能產生有效簽名。但對於 m-of-n（其中 m < n）的情況，需要更複雜的協議。

5.2 FROST 協議

FROST（Flexible Round-Optimized Schnorr Threshold signatures）是目前最有前景的閾值簽名方案之一。它允許任意 t-of-n 配置，同時保持只需兩輪通訊的效率。

FROST 的工作分為兩個階段。密鑰生成階段（DKG，Distributed Key Generation）中，參與者協作生成一個共享的公鑰和各自的私鑰份額。這個過程使用密碼學技術（如 Feldman’s VSS）確保沒有任何人知道完整的私鑰，私鑰只存在於數學上的「虛擬」形式。

簽名階段中，任意 t 個參與者可以合作產生有效簽名。他們各自用私鑰份額計算簽名份額，這些份額被聚合成最終簽名。只需要 t 個人在線，其他人可以完全離線或甚至暫時失聯。

FROST 的優勢在於其靈活性。考慮一個 3-of-5 的企業金庫：五位高管各持有一份私鑰份額，任意三人可以授權支出。即使兩人長期出差或離職，公司仍然可以正常運營。而在鏈上，這與個人錢包的交易看起來完全一樣。

5.3 實際應用考量

閾值簽名雖然強大，但在實際部署中需要考慮幾個問題。

首先是密鑰生成的複雜性。DKG 協議需要參與者之間的同步通訊，這在跨時區、跨網路環境的場景中可能成為挑戰。一些實現選擇使用可信第三方來簡化這個過程，但這犧牲了部分去中心化特性。

其次是門檻的選擇。門檻過低會降低安全性（攻擊者只需控制較少的份額），門檻過高會降低可用性（需要更多人同時在線）。不同場景需要根據具體的安全和可用性需求做出權衡。

最後是實現成熟度。相比經過十多年生產驗證的 OP_CHECKMULTISIG，閾值簽名協議相對較新。雖然密碼學原理已經被充分研究，但實現中的細節問題可能需要時間來發現和解決。

六、PSBT：多方協作的橋樑

6.1 為什麼需要 PSBT

在多重簽名的工作流程中，一個核心挑戰是如何在不同的簽名者之間傳遞交易資訊。每個簽名者可能使用不同的錢包軟體或硬體設備，可能處於離線狀態，甚至可能位於世界的不同角落。

PSBT（Partially Signed Bitcoin Transaction，部分簽名比特幣交易）是 BIP 174 定義的標準格式，專門解決這個問題。它是一種可以攜帶交易所有相關資訊的容器格式，包括未簽名的交易本身、每個輸入的詳細資訊（如 UTXO 數據、腳本、已收集的簽名等）、以及輸出資訊。

PSBT 的設計理念是讓不同的軟體和設備可以各自完成自己能做的部分，然後傳遞給下一個參與者。一個創建者可以構建基本交易結構，更新者可以添加輸入輸出的詳細資訊，多個簽名者可以獨立添加自己的簽名，組合者可以將不同來源的簽名合併，完成者可以構建最終的交易格式，提取者可以得到可廣播的原始交易。

6.2 PSBT 的結構

PSBT 使用鍵值對格式存儲資料，這種格式具有良好的擴展性——新的欄位類型可以被添加而不破壞舊實現的兼容性。

全局數據包含交易本身（未簽名形式）和 PSBT 版本資訊。每個輸入的數據可能包含：非 witness UTXO（完整的前序交易）、witness UTXO（只有相關輸出的資訊）、贖回腳本、witness 腳本、各種衍生路徑資訊、以及部分簽名的集合。每個輸出的數據通常包含金額和腳本資訊。

這種豐富的資訊結構讓簽名設備（特別是硬體錢包）可以驗證交易的所有關鍵方面：輸入是否存在、輸出是否正確、找零是否合理、費用是否過高。這些驗證對於防止簽名者被欺騙至關重要。

6.3 多簽工作流程

讓我們看一個使用 PSBT 的 2-of-3 多簽完整工作流程。

協調者首先創建一個 PSBT，包含要花費的 UTXO 和目標輸出。這個初始 PSBT 還沒有任何簽名，但包含了足夠的資訊讓簽名者理解這筆交易在做什麼。

PSBT 被發送給第一個簽名者（可能通過電子郵件、即時通訊、或任何檔案傳輸方式）。簽名者的錢包軟體或硬體解析 PSBT，顯示交易詳情供用戶確認，然後用自己的私鑰簽名並將部分簽名添加到 PSBT 中。

第一個簽名者返回更新後的 PSBT，然後發送給第二個簽名者。第二個簽名者重複同樣的過程，添加自己的簽名。

現在 PSBT 包含了足夠的簽名（2 個）。組合者（可能是協調者本人）驗證所有簽名的有效性，然後「完成」PSBT——將簽名和腳本組合成最終的 scriptSig 或 witness 格式。

最後，從完成的 PSBT 中提取原始交易並廣播到比特幣網路。

這個流程的優雅之處在於它的模組化：每個參與者只需要關心自己的步驟，不需要了解其他人使用什麼軟體或在哪裡簽名。

七、安全最佳實踐

7.1 密鑰分散原則

多重簽名的安全性建立在密鑰分散的基礎上。如果所有密鑰都存儲在同一個地方，那麼多簽就失去了意義——攻擊者只需要入侵一個位置就能獲得所有密鑰。

地理分散是第一道防線。不同的密鑰應該存儲在不同的物理位置，這樣即使一個位置被入侵、被沒收、或者遭受自然災害，其他密鑰仍然安全。

設備多樣化是另一個重要考量。使用不同品牌、不同型號的硬體錢包可以防止某個特定設備的漏洞影響整個系統的安全。如果所有密鑰都存儲在同一品牌的硬體錢包上，那麼該品牌的安全漏洞就可能成為致命弱點。

人員分離在企業場景中尤為重要。不同的密鑰應該由不同的人控制，這樣可以防止單個人的背叛或失職影響整體安全。同時，這也為組織提供了職責分離的保障。

7.2 備份策略

多簽錢包的備份比單簽錢包更複雜，因為需要考慮多個組成部分。

每個私鑰（或助記詞）需要獨立備份，並且備份應該與原始存儲位置分開。備份的安全級別應該與原始密鑰相當——如果原始密鑰在硬體錢包中受到保護，備份也應該被妥善加密或物理保護。

除了私鑰本身，還需要備份多簽配置資訊：所有公鑰的列表、閾值設置（m-of-n）、腳本類型（P2SH/P2WSH/P2TR）、衍生路徑等。沒有這些資訊，即使擁有所有私鑰也無法重建錢包。

一個常見的做法是創建一個「設置描述符」，這是一種標準化格式，完整描述了多簽錢包的結構。這個描述符不包含私鑰資訊，可以相對安全地存儲在多個位置。

7.3 測試恢復流程

備份的價值只有在恢復時才能體現。因此，定期測試恢復流程是安全實踐的重要組成部分。

在小額測試資金的情況下，嘗試完整的恢復過程：使用備份恢復每個密鑰、重建多簽錢包配置、創建並簽名測試交易。這個過程可以發現備份中的問題，也讓相關人員熟悉緊急情況下的操作流程。

對於大額資產，應該定期（例如每年一次）驗證所有備份的完整性和可訪問性，但不需要每次都實際恢復——只需確認備份存在、可讀、且內容正確即可。

八、實作練習

練習 1：建立 2-of-3 P2WSH 多簽地址

給定三個公鑰，手動計算 2-of-3 P2WSH 多簽地址。步驟包括：按字典序對公鑰排序、構建 witness script、計算 SHA256 雜湊、用 Bech32 編碼生成地址。嘗試用你熟悉的程式語言實現這個過程。

練習 2：模擬 PSBT 工作流程

設計一個簡單的多簽交易場景，包括：創建初始 PSBT、第一個簽名者添加簽名、第二個簽名者添加簽名、組合並完成 PSBT、提取最終交易。可以使用 Bitcoin Core 的 RPC 命令或任何支援 PSBT 的程式庫。

練習 3：比較不同多簽方案的效率

計算相同 2-of-3 配置在不同方案下的交易大小：P2SH、P2WSH、Taproot Script Path、Taproot Key Path（假設使用 MuSig2）。分析每種方案的空間效率和隱私特性。

九、小結

本篇我們深入探討了比特幣多重簽名的各個層面：

傳統多簽使用 OP_CHECKMULTISIG，是最早的標準化方案。雖然有 off-by-one bug 和簽名順序限制等歷史包袱，但它經過了十多年的生產驗證，仍然是可靠的選擇。

SegWit 多簽（P2WSH）提供了約 35% 的費用節省和更強的雜湊安全性，是目前企業應用的主流選擇。

Taproot 多簽帶來了革命性的改進。透過 MuSig2 的 Key Path，n-of-n 多簽可以達到與單簽名相同的效率和隱私；透過 Tapscript 的 OP_CHECKSIGADD，m-of-n 配置獲得了更好的靈活性和批量驗證支援。

閾值簽名如 FROST 代表了下一代多方安全技術，可以在密碼學層面實現對外完全隱藏的多方授權。

PSBT 作為多簽工作流程的標準化格式，解決了不同軟體和設備之間的互操作性問題。

選擇哪種多簽方案取決於具體需求：需要最高隱私和效率，選擇 Taproot Key Path；需要靈活的閾值配置，選擇 Taproot Script Path 或傳統方案；需要與舊系統兼容，選擇 P2WSH 或 P2SH。

下一篇預告

在下一篇文章中，我們將探討時間鎖機制——比特幣腳本中控制「何時」可以花費資金的強大工具。我們會深入了解絕對時間鎖（nLocktime、OP_CHECKLOCKTIMEVERIFY）和相對時間鎖（nSequence、OP_CHECKSEQUENCEVERIFY），並探討它們在閃電網路、原子交換、遺產規劃等場景中的應用。

參考資料

BIP 11: M-of-N 標準交易 - 最早的多簽標準
BIP 16: P2SH - Pay to Script Hash 規範
BIP 147: NULLDUMMY - 修復多簽延展性
BIP 174: PSBT - 部分簽名交易格式
BIP 327: MuSig2 - Schnorr 多簽聚合協議
Bitcoin Optech: Multisig - 多簽主題深入解析
FROST 論文 - 閾值簽名的學術基礎