Multi-Signature
單簽名和 2-of-3 多簽名主根輸入的大小是多少？
在 Twitter 上討論了輸入的大小，然後 Taproot 出現了。Taproot 輸入的輸入大小是多少？
請同時涵蓋關鍵路徑支出（單籤或預設支出）和 2-of-3 多簽腳本路徑支出。
Taproot一般有兩種消費方式。預設方式是使用密鑰路徑花費輸出：pay-to-taproot 然後表現得像 p2pk 輸出，除了它使用 schnorr 簽名和使用 bech32 編碼的相應地址。
另一種方法是通過 Merkle 樹的根、到其中一個葉子的 Merkle 路徑以及葉子中包含的任意 segwit v1 腳本來揭示內部密鑰，然後滿足該腳本的支出條件。
在下文中，2-of-3 支出條件分為三個 2-of-2 條件：
2-of-{A, B, C} = (A && B) || (A && C) || (B && C)假設其中兩個密鑰是熱的，而第三個是用於恢復的備份密鑰。使用 MuSig 將使用兩個熱鍵支出的預設情況聚合到根路徑 pubkey 中。使用備份密鑰的其他兩個支出條件儲存在樹的葉子中。探索了兩種變體：一種是備份密鑰能夠參與 MuSig 簽名，另一種是回退到更簡單的多重簽名方案，其中籤名是非互動式的，例如，因為備份密鑰是氣隙的，並且 MuSig 所需的多次往返不方便。
關鍵路徑支出成本
* outpoint (txid:vout): 32+4vB * scriptSig size: 1vB * nSequence: 4vB * num witness items: 1WU * witness item size: 1WU * signature: 64WU 32+4+1+4+(1+1+64)/4 = 57.5vB控制塊
控制塊用於顯示腳本路徑並證明包含腳本。對於單個葉子，根等於葉子，並且樹的深度為 0 附加層。兩片葉子需要深度為 1。
深度 0 控制塊：
* Length of control block: 1WU * Header byte (script version, sign of output key): 1WU * Inner key of root key: 32WU = 34WU深度 1 控制塊：
* Length of control block: 1WU * Header byte: 1WU * Inner key of root key: 32WU * Hashing partner in tree: 32WU = 66WU腳本路徑支出成本以及關鍵路徑支出成本
腳本路徑花費假設 2-of-2 MuSig 葉
* script size: 1WU * script "<pk> OP_CHECKSIG": 33+1WU * Depth 1 Control block: 66WU 57.5+(1+34+66)/4 = 82.75vBLeafs 不能做 MuSig，用 2-of-2 OP_CHECKSIG 建構：
* +2nd sig: 1+64WU * script size: 1WU * Script "<pk1> OP_CHECKSIGVERIFY <pk2> OP_CHECKSIG": 33+1+33+1=68WU * Depth 1 Control block: 66WU 57.5+(1+64+1+68+1+1+32+32)/4 = 107.5vB丟棄其他變種
2-of-2 OP_CHECKSIG 的建構效率較低
* +2nd sig: 1+64WU * Length of script: 1WU * Script "<pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD 2 OP_EQUAL": 33+1+33+1+1+1=70WU * Depth 1 Control block: 66WU 57.5+(1+64+1+70+66)/4 = 108vB使用單個 2-of-3 葉子代替兩個 2-of-2 葉子的私密性更低、成本更高的變體：
* +2nd sig: 1+64WU * +1 empty witness item: 2WU * Length of script: 1WU * Script "<pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD <pk3> OP_CHECKSIGADD 2 OP_EQUAL": 33+1+33+1+33+1+2=104WU * Depth 0 Control block: 57.5+(1+64+2+1+104+1+1+32)/4 = 109vB免責聲明：所有數據盡最大努力，不信任，驗證。另外，如果我在某個地方犯了錯誤，請糾正我。