操作碼 OP_CHECKTEMPLATEVERIFY 的設計在其各種重命名後是如何演變的？
OP_CHECKTEMPLATEVERIFY (BIP 119)經歷了各種迭代。我並不覺得重命名特別有趣（例如 OP_CHECKOUTPUTSHASHVERIFY、OP_SECURETHEBAG），但我對操作碼的設計發生了怎樣的變化以及這些變化的權衡取捨很感興趣。我的理解是，這些變化主要是由操作碼的靈活性或通用性引起的，即它是否應該支持多個案例或專注於一個特定的案例。我也明白遞歸契約最初是支持的，但不被 OP_CHECKTEMPLATEVERIFY 支持。
OP_CHECKTEMPLATEVERIFY 的目前程式碼在這裡，但這不是記錄為什麼做出某些設計決策的最佳位置。BIP似乎也沒有涵蓋操作碼的演變，儘管目前設計有一些基本原理。
該提案的簡要歷史記錄：
據我所知，契約是 2013 年首次線上討論的，這裡<https://bitcointalk.org/index.php?topic=278122.0>
MES 在 2016 年 OP_COV <https://fc16.ifca.ai/bitcoin/papers/MES16.pdf>中提出，本質上是一個基於模式匹配的基本契約系統。
2017 年，我在斯坦福大學的 BPASE 上發表了關於多交易默克爾化契約影片 幻燈片的演講，介紹了契約的一些動機和設計空間。這就是最初提出擁塞控制概念的地方。
根據會議的回饋，2018 年，我組建了一個使用名為lazuli的多方 ECDSA 預簽名來模擬契約的系統，並在東京的比特幣開發人員研討會上展示了它。我收到的回饋是，自從 schnorr 即將推出以來，核心社區對查看任何基於 ECDSA 的設計都不感興趣。
現代史：
Lazuli 概念（從白皮書中可以看出）構成了 CTV/BIP-119 的基礎。與其做 ECDSA 多方，也許開發人員會發現直接送出預簽名交易雜湊是可以接受的。這裡的困難是製定一個不允許遞歸契約的共同契約——至少不是無意的。
2019 年 5 月，我以 CHECKOUTPUTSHASHVERIFY 的名義向 SF BitDevs 送出了這個契約想法的初稿。幻燈片。我特別關注擁塞控制案例作為一個明確的動機，儘管展示文稿簡要提到了其他應用程序。值得注意的是，我將“生成通道”作為預期案例之一。該設計還使用了“多字節操作碼”的新模式，即“前向參數”，其中驗證語義適用於下一個參數，確保數據不能來自任何計算，但必須在地址生成時靜態知道。這是為了讓證明沒有遞歸約定是可能的變得微不足道。
我收到了來自網上和當面的回饋：
- Russel O’Connor 提出了一個強有力的論點，即不要進行前向窺視論點，因為正常的參數順序（檢查堆棧上的東西而不是腳本）也是安全的並保留了一些腳本組合規則。
- Greg Maxwell 在IRC中指出，我需要致力於更多領域以防止延展性。
- 這個名字被普遍討厭，因為它太無聊了
作為回應：
- 我保留了向前窺視的論證設計（忽略了 Russel 的要求），因為我覺得 OP_IF 已經違反了主體
- 更多欄位被用於消除無意的延展性，並使得可以完美地預測事務樹中的 TXID（例如，通道）。
- 它被重命名為 OP_SECURETHEBAG
在接下來的幾個月裡，我收集了更多回饋並對設計進行了更多調整：
- 在與 Russell 的更多對話中，我們同意放棄前向窺視參數設計，轉而支持從堆棧中正常讀取（為更普遍地使用 CTV 與 OP_CAT 之類的東西創建升級路徑）。
- 將 input_index 添加到摘要中以排除“半花問題”，即在單個交易中可能無意中滿足 2 個相同的約定。
- OP_SECURETHEBAG 這個名字比 COSHV 更受人喜愛和討厭。COSHV 在技術上不再準確，因此名稱更改為 CheckTemplateVerify。
在這個時刻（大約 2020 年 1 月），我覺得 BIP 在概念上已經足夠成熟，程式碼也足夠穩定，可以引入 BIP。
2020 年 2 月，我舉辦了utxos.org 研討會，討論 CTV 的設計（以目前的形式）。
2020 年 4 月左右，我還在 Sapio 上破土動工（最初在 Scaling Bitcoin ‘19 Tel Aviv 中提到可能），以推廣我為 CTV 開發但手動滾動程式碼的智能合約的工具。
大約在 2021 年 2 月，我發布了 Sapio 的第一個開源版本，它經歷了多次迭代（即從 python 到 rust，從自定義腳本到 miniscript 重新實現）。
總的來說，我認為您的評估並不完全正確，因為遞歸契約從來都不是 CTV 設計的一部分（始終是反目標）。所做的大多數更改不是圍繞靈活性，而是圍繞安全性和維護所需的預期屬性，以允許在不需要多方（ECDSA 或 Schnorr）信任假設的情況下實現類似於 Lazuli 的東西。CTV 的設計過程本質上是針對在 Core 中可能/安全的事情上劃出一大塊安全的契約來“移動 overton 視窗”。現在人們對更一般的盟約的渴望越來越廣泛，這真是太棒了。
隨著前瞻參數的移除，CTV 可以與未來的變化（例如，OP_CAT/SHASTREAM）結合使用，以在堆棧上建構契約描述。已努力確保 CTV 中使用的事務摘要易於在堆棧上進行操作，方法是按照最不可能更改的順序對欄位進行排序（“靜態前綴假設”）。