他的整个目的是给用户一个通用到足以让他们按照自己的意愿组织自己的交易类型的语言。即，给用户设计和实验如何编写他们自己的货币的空间。
在他消失之前，中本聪删除了其中的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攻击（通过发送大量垃圾请求，导致网络崩溃），因为这些垃圾交易，也是导致中本聪最初禁用所有这些操作码的原因。
前进的动力
我相信你们中的许多人会想“这个改变太大了。”我能理解这种想法，但我认为作为一个提案要理解的一个重要方面是，我们不必全部做到。这个提案的价值并不一定在于完全恢复所有这些功能，而在于我们会全面审视一个庞大的基础组件套件，并问自己我们在功能方面真正想要的是什么。
这将是对过去三年争吵和辩论的完全转变，过去三年我们只是在争论微小的狭隘变化，这些变化只有某些功能。这就像一个大家都能聚集在一起的广场，共同审视未来的方向。也许我们最终会恢复所有这些功能，也许我们最终只会激活一些功能，因为共识是这些功能，是我们所有人都同意需要开启的功能。
无论最终结果如何，这都可以是对我们未来方向的整个对话产生积极影响的变化。我们可以实际绘制并全面了解情况，而不是在争论下一步该走哪条暗淡不清的路线时摸索前行。
这绝不是我们必须走的前进之路，但我认为这是我们决定要采取哪条路线的最佳机会。是时候再次开始以实际而有成效的方式合作了。
本文提供的信息仅用于一般指导和信息目的，本文的内容在任何情况下均不应被视为投资，业务，法律或税务建议。对于根据本文做出的个人决定，我们不承担任何责任，我们强烈建议您在采取任何行动之前进行自己的研究。尽管已尽最大努力确保此处提供的所有信息都是准确的和最新的，但可能会发生遗漏或错误。
