他的整個目的是給用戶一個通用到足以讓他們按照自己的意願組織自己的交易類型的語言。即，給用戶設計和實驗如何編寫他們自己的貨幣的空間。
在他消失之前，中本聰刪除了其中的15個操作碼，完全禁用了它們，並且在腳本引擎堆棧上添加了一個硬限制，限制了可以操作的數據塊大小（520位元組）。這是因為他實際上搞砸了，留下了大量使得複雜腳本可能被用來對整個網絡進行dos攻擊（發送大量垃圾請求，導致網絡癱瘓）的方式，創建了巨大且成本高昂的交易，會導致節點崩潰。
這些操作碼並不是因為中本聰認為這些功能是危險的，或者人們不應該利用它們構建能夠實現的東西而被移除的，而僅僅（至少表面上是如此）是因為它們在沒有資源限制的情況下對整個網絡構成的風險，這樣它們可能在不受限制的情況下對網絡施加的最壞的驗證成本。
從那時起，比特幣的每次升級最終都是對剩餘功能的功能優化，糾正中本聰留給我們的其他不那麼嚴重的缺陷，並擴展我們剩下的腳本子集的功能。
偉大的腳本恢復
在五月初的奧斯汀比特幣++大會上，核心閃電網絡開發者拉斯蒂·拉塞爾在會議的第一場演講中提出了一個非常激進的提案，他基本上提出了重新啟用中本聰在2010年消失之前禁用的大多數操作碼的想法。
自2021年taproot（taproot 是比特幣的一個重要升級，旨在提高隱私性、安全性和可擴展性）激活以來的幾年裡，開發領域實際上有點毫無目標。我們都知道，比特幣並不具備足夠的可擴展性，無法真正為世界上任何可觀規模的人口提供自我主權的服務，甚至可能無法以最小化信任或託管的方式為能夠超越非常大的託管機構和服務提供商、無法真正擺脫政府長臂約束的服務提供商提供擴展性。
這篇文章指出了比特幣技術層面上的認識，這不是一個需要爭論的問題。值得爭論的問題是如何解決這個缺陷，這是一個非常有爭議的話題。自從 taproot 提出以來，每個人都在提出非常狹窄的提案，旨在解決只有特定使用案例才能實現的問題。
例如，anyprevout（apo）是一個提案，允許簽名在不同的交易中重複使用，只要輸入的腳本和金額相同，這個提案是專門為了優化閃電網絡和其多方版本而設計的。checktemplateverify（ctv）是一個提案，要求硬幣只能由與預定義交易完全匹配的交易來支出，這個提案是為了通過使它們完全無信任來擴展預簽名交易鏈的功能而設計的。op_vault 是專門設計用來為冷存儲方案設置「超時期」，這樣用戶就可以通過將其發送到更冷的多簽設置來「取消」從冷存儲中提取，以防止其密鑰被泄露。
還有很多其他提案，但我想你已經明白了要點。過去幾年來，每個提案都是為了要麼稍微增加可擴展性，要麼改進單一的小功能，因為這被認為是可取的。這是為什麼這些討論沒有取得進展的根源。沒有人對其他提案感到滿意，因為它們沒有滿足他們想要看到的使用案例。
除了提案發起者之外，沒有人認為任何提案是足夠全面的，可以被視為合理的下一步行動。
這就是「偉大的腳本恢復」背後的邏輯。通過推動並分析對腳本的全面恢復，就像中本聰最初設計的那樣，我們實際上可以嘗試探索我們需要的整個功能空間，而不是爭論和內訌關於現在哪種小型功能擴展足夠好的問題。
opcodes（操作碼）
op_cat：從堆棧中獲取兩個數據，並將它們相加形成一個數據。
op_substr：接受一個長度參數（以位元組為單位），從堆棧中獲取一段數據，將該長度的位元組移除並放回堆棧。
op_left 和 op_right：接受一個長度參數，從堆棧中獲取一段數據，並從其一側或另一側移除指定長度的位元組。
op_invert、op_and、op_or、op_xor、op_upshift 和 op_downshift：接受一個數據元素，對其執行相應的位運算。
op_2mul、op_2div、op_mul、op_div 和 op_mod：數學操作符，用於乘法、除法和取模運算（返回除法的餘數）。
op_ctv（或 txhash/等效操作碼）：允許對交易的某些部分進行精細化的強制執行，要求這些部分必須與預定義的內容完全一致。
csfs：允許對簽名進行驗證，不僅限於整個交易，這樣可以要求腳本的某些部分或使用的數據必須進行簽名才能執行。
op_tweakverify：驗證基於 schnorr 的操作，涉及公鑰，例如從聚合公鑰中添加或減去單個公鑰。這可以用來確保在某個參與方單方面離開共享的未使用交易輸出（utxo）時，其他所有參與方的資金都被發送到一個不需要離開的參與方簽名就能進行合作支出的聚合公鑰。
我們為什麼要這樣做
第二層網絡本質上是比特幣基礎層的延伸，它們在功能上受到基礎層功能的約束。閃電網絡在實際實現之前需要三個單獨的軟分叉：checklocktimeverify (cltv)、checksequenceverify (csv) 和隔離見證（segregated witness）。
如果沒有更靈活的基礎層，就無法構建更靈活的第二層網絡。唯一的捷徑就是信任第三方，這是非常簡單明了的，我希望我們都渴望儘可能從與比特幣規模化交互的每個方面中移除信任第三方。
我們需要能夠做一些目前無法做到的事情，以便安全地將兩個以上的人合併到一個單一的未使用交易輸出（utxo）中，並能夠在基礎層上無需信任地執行。比特幣腳本目前的靈活性還不足夠。在最基本的層面上，我們需要契約，我們需要腳本能夠實際強制執行關於執行交易的更精細細節，以確保像一個用戶安全地退出其自己的 utxo 不會將其他用戶的資金置於風險之中。
在更高的視角上，這就是我們需要的功能：
自身審查（introspection）：我們需要能夠實際檢查堆棧上有關支出交易本身的特定細節，比如「這筆錢的這部分金額會流向某個輸出的這個公鑰」。這使得我可以使用我自己的特定 taproot 分支自行提取我的資金，同時確保我無法取走其他任何人的資金。執行的腳本將確保其他所有者的資金，被發送回其他用戶的公鑰組成的地址，以防其他參與者造成資金損失。
前向數據傳遞（forward data carrying）：假設我們進一步發展了比如一個具有大量人的單個utxo的概念，任何人都可以隨意進出。在這種情況下，我們需要一種方式來追蹤誰有多少錢，通常會使用默克爾樹及其根。這意味着當有人離開時，我們必須確保「記錄」誰有權獲得什麼作為其他所有人資金的找零utxo的一部分。這基本上是內省的一個特定用途。
公鑰修改：我們需要確保可以在堆棧上驗證對聚合公鑰的修改。在未使用交易輸出（utxo）共享方案中，我們的目標是通過一個包含所有參與者的聚合公鑰來促進資金的合作和高效流動。當有人單方面離開共享的utxo時，我們需要從聚合公鑰中刪除他們的個人公鑰。如果事先沒有計算所有可能的組合，那麼唯一的選擇就是驗證從聚合公鑰中減去一個公鑰是否會生成由其餘個人公鑰組成的有效公鑰。
如何確保安全：varops正如我上面所說的，禁用所有這些操作碼的原因是為了解決dos攻擊（通過發送大量垃圾請求，導致網絡崩潰），這種攻擊可以導致組成網絡的節點崩潰。有一種方法可以解決這個問題，就是限制任何這些操作碼可以使用的資源量。
當涉及到簽名驗證時，比特幣腳本中最昂貴的部分，我們已經有了這樣的解決方案，它被稱為簽名操作（sigops）預算。每次使用簽名檢查操作碼都會消耗一定的「預算」，即每個區塊允許的簽名操作次數，這對於交易可以對用戶產生的驗證一個區塊所需的成本設定了一個硬限制。
taproot 改變了這種工作方式，它不再使用單一的全局區塊限制，而是每個交易都有自己的 sigops（簽名操作）限制，與交易的大小成比例。這基本上等於相同的全局限制，但更容易理解每個交易有多少 sigops 可用。
taproot在處理每個交易的sigops（簽名操作）限制方面的變化，為一種泛化方法提供了可能性，這也是rusty russell在varops限制方面提出的建議。這個想法是為每個重新激活的操作碼分配一個成本，以考慮到每個操作碼可能創建的最壞情況，即驗證時產生的最昂貴的計算成本。這樣，每個操作碼都會有自的「sigops」限制，限制它在驗證過程中可以消耗的資源量。這也將基於使用這些操作碼的任何交易的大小，因此可以方便進行推理，同時仍然累積到每個區塊的隱式全局限制。
這將解決dos攻擊（通過發送大量垃圾請求，導致網絡崩潰），因為這些垃圾交易，也是導致中本聰最初禁用所有這些操作碼的原因。
前進的動力
我相信你們中的許多人會想「這個改變太大了。」我能理解這種想法，但我認為作為一個提案要理解的一個重要方面是，我們不必全部做到。這個提案的價值並不一定在於完全恢復所有這些功能，而在於我們會全面審視一個龐大的基礎組件套件，並問自己我們在功能方面真正想要的是什麼。
這將是對過去三年爭吵和辯論的完全轉變，過去三年我們只是在爭論微小的狹隘變化，這些變化只有某些功能。這就像一個大家都能聚集在一起的廣場，共同審視未來的方向。也許我們最終會恢復所有這些功能，也許我們最終只會激活一些功能，因為共識是這些功能，是我們所有人都同意需要開啟的功能。
無論最終結果如何，這都可以是對我們未來方向的整個對話產生積極影響的變化。我們可以實際繪製並全面了解情況，而不是在爭論下一步該走哪條暗淡不清的路線時摸索前行。
這絕不是我們必須走的前進之路，但我認為這是我們決定要採取哪條路線的最佳機會。是時候再次開始以實際而有成效的方式合作了。
本文提供的信息僅用於一般指導和信息目的，本文的內容在任何情況下均不應被視為投資，業務，法律或稅務建議。對於根據本文做出的個人決定，我們不承擔任何責任，我們強烈建議您在採取任何行動之前進行自己的研究。儘管已盡最大努力確保此處提供的所有信息都是準確的和最新的，但可能會發生遺漏或錯誤。
