在考慮 ANYPREVOUT 和 CTV 對保險庫設計的有用性時，它們如何比較？
關於 SIGHASH_ANYPREVOUT 和 OP_CTV 對現有保險庫設計的有用性，保險庫研究的最新狀態是什麼？新的替代方案，例如 TapleafUpdateVerify (TLUV) 目前認為對現有的保險庫設計或多或少有用嗎？
在撰寫本文時（2022 年 1 月），似乎很少有研究直接比較不同方法的實用性和安全性，以實現各種拱頂設計的建造。事實上，契約操作碼 TAPLEAF_UPDATE_VERIFY 僅在 2021 年 9 月被提議到比特幣開發郵件列表中，目前還沒有實現它，更不用說詳細分析它與使用 SIGHASH_ANYPREVOUT 或 OP_CHECKTEMPLATEVERIFY 建構保險庫的比較。郵件列表文章確實表明它可以實現與Bryan Bishop以前的拱頂設計相匹配的拱頂設計，並具有額外的好處：
它是完全遞歸的，允許取款變化而不是固定金額 L（由於不依賴於預先簽署的交易），並且通常看起來更易於使用。
Jeremy Rubin 最初將OP_CHECKOUTPUTSHASHVERIFY（後來成為 OP_CHECKTEMPLATEVERIFY）描述為“基本的、有限的契約形式，它不承擔與先前契約設計相同的技術和社會風險”。這表明，特別是對於保管庫，使用 OP_CHECKTEMPLATEVERIFY 可能會更加限制設計空間。
Andrew Poelstra 發表了關於如何使用 OP_CAT 和 OP_CHECKSIGFROMSTACK 來建構契約和保險庫的部落格 ( 1 , 2 )。與 OP_CHECKTEMPLATEVERIFY 相比，這些將啟用更通用的約定，可能會增加保管庫的設計空間，但缺點是效率較低且可能風險更大。當試圖擴大保險庫的設計空間時，這裡似乎確實存在直接的風險/回報權衡，而且鑑於保險庫原型很少，更不用說完全建構的實現，很難評估頻譜上的潛在最優值那些原型。
在撰寫本文時，比較使用 OP_CHECKTEMPLATEVERIFY 和 SIGHASH_ANYPREVOUT 建構保險庫的唯一論文是比特幣契約：控制未來的三種方法。
本文討論了三類保險庫設計：已刪除密鑰（無需更改共識，但安全模型較差）、恢復密鑰（需要 BIP 118 共識更改，高級安全模型）和基於腳本（需要 BIP 119 共識更改，高級安全模型）。
它指出：
恢復密鑰和基於腳本的約定在功能上大部分是等效的，因此恢復密鑰約定相對於已刪除密鑰約定的優勢也適用於基於腳本的約定。如果其中任何一個都通過他們所需的軟分叉升級啟用，那麼一個基於契約的實用協議的新領域可能會出現。準確了解從此類升級中獲得的實用性是其進步的關鍵。
該論文最後指出：
比特幣是一個複雜的自適應系統，具有許多相互作用的部分，比特幣程式碼庫和協議的每一次修改都存在系統性風險。很難分析這些風險，聲稱沒有引入未知風險是傲慢的。
我知道有些人會不同意，包括最有可能的 BIP 119 的作者 (Jeremy Rubin)，但似乎在實用軸和安全軸上，似乎需要進行更多的探索和分析才能集中在一個工具或一組工具上能夠在比特幣主網上建造金庫，這不會很快被評估為次優。然後，我們就是否應該將比特幣主網視為可能會或可能不會成功的新案例的測試平台進行高級討論，或者我們是否應該將比特幣主網視為在有強烈信心的情況下進行共識更改的地方這些變化將在實用性和安全性方面經受住時間的考驗。我個人傾向於後者，但這本身就是另一個討論。
