有人聲稱在 taproot 腳本中 OP_IF 總是多餘的。 這是錯誤的。 這段來自 @mononautical 的腳本實際上如果捆綁在一起會更便宜：所有的支出路徑無論如何都需要 4 個公鑰。在 4 個 OP_CHECKSIGADD 之後，腳本的其餘部分少於 32 字節，因此將其捆綁在一起會更便宜。 解開捆綁後，你會移除檢查時間鎖的腳本尾部，但因為腳本現在的深度是 1 而不是 0，所以會在控制區塊中增加 32 字節。 因此，優化支出成本的編譯器 _將_ 生成捆綁的腳本（即，具有單一葉子的 taptree），因為即使在主要支出路徑（3-of-4）中，它也稍微便宜一些。 專門優化隱私的用戶最有可能想要將其拆分。 換句話說，生成最佳 taptree 是一個有兩個變數的優化問題：支出成本和隱私，並且通常你無法同時優化這兩者。我預期大多數用戶不會絕對專注於任何一個變數，而是選擇一個成本和隱私都相當不錯的 taptree。對於 @mononautical 在這裡展示的腳本，只有兩個葉子的 taptree 會相當不錯：主要路徑只是一個簡單的 3-of-4，並且會用於大多數支出，而其餘的支出條件（可能捆綁在一個單一的 tapleaf 中）希望永遠不會上鏈。 一旦你將 MuSig 和 FROST 考慮進去，變數就更多了：MuSig 和 FROST 可以降低成本並改善隱私，但它們增加了互動要求和實現複雜性。 開發者和用戶會選擇什麼？我不知道！ 只有白癡才沒有疑慮。