是否可以設計一個遞歸契約操作碼，導致全節點陷入無限驗證循環？
是否有可能設計一個新的操作碼啟用遞歸契約，這可能導致全節點陷入驗證交易的無限循環？（顯然這不會被考慮用於比特幣軟分叉，我只是想知道契約操作碼的設計空間的限制）
例如 A -> B -> C
A、B、C 是交易。B 花費 A，C 花費 B。A 對 B 的支出條件施加約束。B 對 C 的支出條件施加約束。但是 C 的支出條件必須檢查 A 中的某些內容（未經過雜湊處理的內容，可能是前幾個證人中的簽名位）。作為驗證的結果，B 必須檢查 A 中的某些內容，並且無限驗證循環開始執行。
我傾向於沒有，但不是 100% 肯定。C 只檢查 A 中的某些內容是不夠的，它需要以某種方式更改 A，以便 B 需要再次驗證。UTXO 模型（相對於賬戶模型）甚至可以防止這種情況發生。在帳戶模型中，您可以參考任何前一個塊的餘額並以這種方式進入無限驗證循環。
感謝 Russell O’Connor 和 Sanket Kanjalkar 在 IRC 上回答這個問題（我只是簡單地解釋了他們的答案，但任何錯誤都是我自己的。）
是否有可能設計一個新的操作碼啟用遞歸契約，這可能導致全節點陷入驗證交易的無限循環？
不。比特幣契約上下文中的遞歸僅意味著將輸出返回到相同的腳本模板。
在撰寫本文時，唯一一個先前正式提出的比特幣操作碼在使用時可能導致腳本不終止是 OP_EVAL。使用不使用 OP_EVAL 的腳本，您可以只計算操作碼，並且每個操作碼最多評估一次。
假設您可以訪問 OP_EVAL 和另外兩個新的操作碼：OP_RED（檢查目前塊是否具有包含 OP_BLUE 的有效事務）和 OP_BLUE（檢查目前塊是否具有包含 OP_RED 的有效事務）。該塊可以有兩個交易輸出，分別包含 OP_EVAL、OP_BLUE 和 OP_EVAL、OP_RED。這將需要無限循環的檢查。
新操作碼的設計空間是巨大的。新設計的操作碼可能會違反許多重要程度不同的原則。例如，您通常希望腳本結果只是事務本身的函式，而不是事務外部的函式。您還希望資源的靜態分析能夠線上性時間內進行計算。
因此，與其從明顯不安全（但可能是最大靈活的操作碼）開始並限制功能以使其安全，它可能是一種更好的方法來證明某些操作碼是終止且無害的。
正在進行的關於Simplicity的工作的目的是提供最大的靈活性，同時仍然受制於上面討論的所需約束和原則。如果沒有像 Simplicity 這樣的東西，就很難確定任何操作碼是可證明安全的，同時又能提供最大的靈活性。