隔離見證版本 1 與版本 0 的鏈上成本
與正在提議的版本 1 相比，隔離見證版本 0 的總區塊鏈成本如何？我對單個使用者交易特別感興趣——支付公鑰（或 pk 雜湊）和腳本（主要是詢問沒有分支的腳本，因為我知道在具有更多分支的更複雜的腳本中可以節省）。區塊鏈總成本是指輸出以及花費這些輸出的輸入中的字節數、vbytes 和權重。換句話說，我要問的是，與可以在版本 0 上完成的事務相比，版本 1 腳本是否會節省任何費用。
一般來說，Segwit v1 的花費比 segwit v0 便宜，但創建成本略高。
由提議的主根 BIP定義的 Segwit v1 輸出腳本的長度將始終為 35 個字節。然而，Segwit v0 輸出腳本是 22 字節（對於單個密鑰情況）或 34 字節（腳本雜湊情況）。這意味著發送到 segwit v1 的人最終將支付比 segwit v0 輸出多一點的費用。當然，接收方可以使用 P2SH 包裝的隔離見證輸出，以便將成本實際推給他們。
然而，當接收者想要花費該輸出時，segwit v1 更便宜。因為 segwit v1 是 Pay-to-Pubkey 模型，所以不需要在輸入中指定公鑰。這節省了 34 字節的見證數據（34 個權重單位，8.5 vbytes）。
此外，segwit v0 使用 ECDSA 簽名，這些簽名使用 DER 編碼進行編碼。這導致簽名通常為 71 或 72 字節（每個大小對於任何簽名都有約 50% 的機率出現，除非軟體專門像 Bitcoin Core 那樣只創建 71 字節的簽名）。但是 segwit v1 使用 Schnorr 簽名和 BIP 中為該簽名指定的編碼，長度通常為 64 個字節（如果使用 SIGHASH_ALL 以外的內容，則可以為 65，但這種情況很少見）。為簡單起見，我們可以說這是減少了 8 個字節，即 8 個權重單位和 2 個 vbytes。
因此對於典型的單鍵情況，segwit v1 節省了 42 個字節，即 42 個權重單位或 10.5 個 vbytes。
有趣的地方是多重簽名，這是最常用的腳本類型。對於多重簽名，MuSig 多重簽名方案。MuSig 允許 n-of-n 多重簽名或 m-of-n 不負責任的多重簽名（即沒有人將能夠知道誰簽名）作為單個密鑰簽名出現在觀察者面前。這意味著在輸出中只指定了一個公鑰，在輸入中驗證了一個簽名。因此，對於所有 n-of-n 多重簽名和不負責任的 m-of-n 多重簽名，成本與單個密鑰情況完全相同，但節省的費用取決於簽名者的數量。第一個簽名者的節省與單個密鑰情況相同。對於每個額外的簽名者（即當 n > 1 時），使用 segwit v1 可節省約 107 個字節，即 107 個權重單位或 26.75 個 vbytes。
對於需要問責的 m-of-n 簽名，它變得更加複雜。這樣的門檻值簽名可以通過使用 MuSig 和表示每個簽名密鑰組合的默克爾樹來實現。然而，使用 segwit v1 的大小最終將小於 segwit v0，因為最終，merkle 樹的葉子將始終是單個公鑰，並且其間的雜湊值將略小於傳統腳本中的公鑰。最後，最常見的門檻值可以用作主根中的根案例，這樣可以節省更多，因為不需要顯示腳本的分支。