比特币操作码入门

比特币交易脚本操作码的完整历史

Satoshi Nakamoto 在 2009 年 1 月发布的 Bitcoin v0.1.0 包含了一组操作码（operation codes），这些操作码定义了比特币交易的脚本语言。这些操作码是原始 Bitcoin Script 的一部分，这是一种基于堆栈的语言，用于指定花费比特币的条件。以下是 Bitcoin v0.1.0 中原始操作码的列表，为了清晰起见按类别分组。请注意，由于安全或优化原因，某些操作码在后来的版本中已被禁用或修改。

常量

这些操作码将特定值推送到堆栈上：

• OP_0 (0x00)：将一个空数组（代表 0）推送到堆栈上。
• OP_FALSE：OP_0 的别名。
• OP_PUSHDATA1 (0x4c)：将下一个字节作为长度推送，后跟该长度的字节数据。
• OP_PUSHDATA2 (0x4d)：将下两个字节作为长度推送，后跟该长度的字节数据。
• OP_PUSHDATA4 (0x4e)：将下四个字节作为长度推送，后跟该长度的字节数据。
• OP_1NEGATE (0x4f)：将 -1 推送到堆栈上。
• OP_1 (0x51)：将 1 推送到堆栈上。
• OP_TRUE：OP_1 的别名。
• OP_2 (0x52) 到 OP_16 (0x60)：将数字 2 到 16 推送到堆栈上。

流程控制

这些操作码控制脚本的执行流程：

• OP_NOP (0x61)：不执行任何操作。
• OP_IF (0x63)：如果堆栈顶部的值不是 0，则执行 IF 代码块中的语句。
• OP_NOTIF (0x64)：如果堆栈顶部的值是 0，则执行该代码块中的语句。
• OP_ELSE (0x67)：如果前面的 IF 或 NOTIF 没有被执行，则执行这个代码块。
• OP_ENDIF (0x68)：结束一个 IF/ELSE 代码块。
• OP_VERIFY (0x69)：如果堆栈顶部的值不是 true（不是 0），则停止执行并将交易标记为无效。
• OP_RETURN (0x6a)：将交易标记为无效，结束脚本执行（用于提前终止）。

堆栈操作

这些操作码操作堆栈上的数据：

• OP_TOALTSTACK (0x6b)：将主堆栈的顶部项移动到备用堆栈。
• OP_FROMALTSTACK (0x6c)：将备用堆栈的顶部项移动到主堆栈。
• OP_2DROP (0x6d)：从堆栈中移除顶部两个项。
• OP_2DUP (0x6e)：复制堆栈顶部的两个项。
• OP_3DUP (0x6f)：复制堆栈顶部的三个项。
• OP_2OVER (0x70)：将倒数第二对项复制到堆栈顶部。
• OP_2ROT (0x71)：将倒数第三对项移动到堆栈顶部。
• OP_2SWAP (0x72)：交换堆栈顶部的两对项。
• OP_IFDUP (0x73)：如果堆栈顶部的值不是 0，则复制它。
• OP_DEPTH (0x74)：将堆栈上的项数推送到堆栈上。
• OP_DROP (0x75)：从堆栈中移除顶部项。
• OP_DUP (0x76)：复制堆栈顶部的项。
• OP_NIP (0x77)：从堆栈中移除倒数第二项。
• OP_OVER (0x78)：将倒数第二项复制到堆栈顶部。
• OP_PICK (0x79)：将第 n 个项（由堆栈顶部的值指定）复制到顶部。
• OP_ROLL (0x7a)：将第 n 个项（由堆栈顶部的值指定）移动到顶部。
• OP_ROT (0x7b)：旋转顶部三个项（第三个到顶部，第二个到第三个，顶部到第二个）。
• OP_SWAP (0x7c)：交换堆栈顶部的两个项。
• OP_TUCK (0x7d)：复制顶部项并将其插入到倒数第二项之前。

拼接操作

这些操作码操作堆栈上的字符串（数据数组）：

• OP_CAT (0x7e)：连接堆栈顶部的两个项。
• OP_SUBSTR (0x7f)：从顶部项中提取子字符串，使用顶部两个值作为起始位置和长度。
• OP_LEFT (0x80)：提取顶部项的前缀，长度由第二个项指定。
• OP_RIGHT (0x81)：提取顶部项的后缀，长度由第二个项指定。
• OP_SIZE (0x82)：将顶部项的长度推送到堆栈上而不移除它。

位运算

这些执行位级别的操作：

• OP_INVERT (0x83)：翻转堆栈顶部项的所有位。
• OP_AND (0x84)：对顶部两个项执行按位 AND 运算。
• OP_OR (0x85)：对顶部两个项执行按位 OR 运算。
• OP_XOR (0x86)：对顶部两个项执行按位 XOR 运算。
• OP_EQUAL (0x87)：检查顶部两个项是否相等，如果为 true 则推送 1，如果为 false 则推送 0。
• OP_EQUALVERIFY (0x88)：与 OP_EQUAL 相同，但之后运行 OP_VERIFY。

算术运算

这些执行数值运算：

• OP_1ADD (0x8b)：将 1 加到堆栈顶部的项。
• OP_1SUB (0x8c)：从堆栈顶部的项中减去 1。
• OP_2MUL (0x8d)：将顶部项乘以 2。
• OP_2DIV (0x8e)：将顶部项除以 2。
• OP_NEGATE (0x8f)：对堆栈顶部的项取反。
• OP_ABS (0x90)：取顶部项的绝对值。
• OP_NOT (0x91)：如果顶部项是 0，则推送 1；否则，推送 0。
• OP_0NOTEQUAL (0x92)：如果顶部项不是 0，则推送 1；否则，推送 0。
• OP_ADD (0x93)：将堆栈顶部的两个项相加。
• OP_SUB (0x94)：从倒数第二项中减去顶部项。
• OP_MUL (0x95)：将顶部两个项相乘。
• OP_DIV (0x96)：将倒数第二项除以顶部项。
• OP_MOD (0x97)：计算倒数第二项除以顶部项的余数。
• OP_LSHIFT (0x98)：将倒数第二项左移顶部项指定的位数。
• OP_RSHIFT (0x99)：将倒数第二项右移顶部项指定的位数。
• OP_BOOLAND (0x9a)：如果顶部两个项都不是 0，则推送 1；否则，推送 0。
• OP_BOOLOR (0x9b)：如果顶部任一项不是 0，则推送 1；否则，推送 0。
• OP_NUMEQUAL (0x9c)：如果顶部两个项在数值上相等，则推送 1；否则，推送 0。
• OP_NUMEQUALVERIFY (0x9d)：与 OP_NUMEQUAL 相同，但之后运行 OP_VERIFY。
• OP_NUMNOTEQUAL (0x9e)：如果顶部两个项在数值上不相等，则推送 1；否则，推送 0。
• OP_LESSTHAN (0x9f)：如果倒数第二项小于顶部项，则推送 1；否则，推送 0。
• OP_GREATERTHAN (0xa0)：如果倒数第二项大于顶部项，则推送 1；否则，推送 0。
• OP_LESSTHANOREQUAL (0xa1)：如果倒数第二项小于或等于顶部项，则推送 1；否则，推送 0。
• OP_GREATERTHANOREQUAL (0xa2)：如果倒数第二项大于或等于顶部项，则推送 1；否则，推送 0。
• OP_MIN (0xa3)：推送顶部两个项中较小的一个。
• OP_MAX (0xa4)：推送顶部两个项中较大的一个。
• OP_WITHIN (0xa5)：如果倒数第三项介于倒数第二项和顶部项之间（包括边界），则推送 1；否则，推送 0。

加密操作

这些处理对比特币至关重要的加密函数：

• OP_RIPEMD160 (0xa6)：计算顶部项的 RIPEMD160 哈希值。
• OP_SHA1 (0xa7)：计算顶部项的 SHA1 哈希值。
• OP_SHA256 (0xa8)：计算顶部项的 SHA256 哈希值。
• OP_HASH160 (0xa9)：计算顶部项的 SHA256 哈希值，然后计算结果的 RIPEMD160 哈希值。
• OP_HASH256 (0xaa)：计算顶部项的 SHA256 哈希值，然后计算结果的 SHA256 哈希值。
• OP_CODESEPARATOR (0xab)：标记脚本中签名检查部分的开始。
• OP_CHECKSIG (0xac)：使用公钥（顶部项）验证交易的签名（倒数第二项）。
• OP_CHECKSIGVERIFY (0xad)：与 OP_CHECKSIG 相同，但之后运行 OP_VERIFY。
• OP_CHECKMULTISIG (0xae)：使用一组公钥和签名验证交易的多个签名。
• OP_CHECKMULTISIGVERIFY (0xaf)：与 OP_CHECKMULTISIG 相同，但之后运行 OP_VERIFY。

伪操作码 & 保留

这些是 v0.1 中的占位符或未实现的操作码：

• OP_NOP1 (0xb0) 到 OP_NOP10 (0xb9)：保留供将来使用，在 v0.1 中不执行任何操作（未分配）。OP_NOP(x) 操作码用于在发生冲突时替换哈希函数。与 OP_VER 结合使用，以设置区块高度来引用替换的基于 SHA256 的哈希函数，以及比特币中依赖于它们的签名函数。
• OP_PUBKEYHASH (0xfd)：伪操作码，不可直接执行，表示脚本中的公钥哈希。
• OP_PUBKEY (0xfe)：伪操作码，表示脚本中的公钥。
• OP_INVALIDOPCODE (0xff)：标记无效或未实现的操作码。

备注

禁用的操作码：

由于比特币核心（BTC）参考实现中存在潜在的安全问题（如潜在的拒绝服务攻击或错误），许多这些操作码（例如 OP_CAT、OP_SUBSTR、OP_LEFT、OP_RIGHT、OP_INVERT、OP_2MUL、OP_2DIV、OP_MUL、OP_DIV、OP_MOD、OP_LSHIFT 和 OP_RSHIFT）在比特币核心的后期版本中已被比特币开发者禁用。

上下文：

这些操作码是 Bitcoin Script 的一部分，用于锁定（scriptPubKey）和解锁（scriptSig）脚本中以验证交易。此列表基于原始 Bitcoin v0.1.0 源代码，特别是 Satoshi Nakamoto 发布的与脚本相关的文件（例如 script.cpp）。这是 Bitcoin v0.1 中的完整操作码集。

Bitcoin Core 参考实现 (BTC) 操作码变更

自 2009 年 1 月 Bitcoin v0.1.0 首次发布以来，Bitcoin Core (BTC) 的比特币脚本语言（称为 Script）参考实现经历了重大变更。本节详细 بررسی了所有已更改、弃用、停止使用、删除、修改或添加的操作码，包括历史背景、实现细节以及负责这些变更的个人。

历史背景和初始状态

Satoshi Nakamoto 发布的 Bitcoin v0.1.0 包含了一组用于编写交易脚本的操作码，这些操作码定义在诸如 script.cpp 等源代码文件中。这些操作码构成了比特币通用计算的基础，包括堆栈操作、加密验证和条件逻辑等操作。初始集合包括诸如 OP_CHECKSIG、OP_HASH160 等操作码，但同时包括了一些后来被比特币核心行业赞助的开发团队的几名成员认为是不安全的操作码。

此时此刻，如果我不指出，在这些变更期间，比特币社区中比特币核心开发团队之外的不同开发者直言不讳地批评了比特币协议的各种变更，而比特币的创建者中本聪非常清楚地根据定义的比特币白皮书和随后的比特币论坛帖子进行定义，那将是我的疏忽。

有人认为，比特币被几个外部实体（矿工、矿机分销商和第二层比特币服务的投资者）联合篡夺了，比特币的功能被那些寻求从通过更改比特币原始协议而实现的补充解决方案中获利的投资实体所削弱。这些变更包括通过移除链式交易（隔离见证）来隐藏交易的基础工作，隔离见证混淆了交易（为黑市和交易混淆打开了大门），为闪电网络（二级层，链下支付通道）铺平了道路。这为“修复”所创建的问题引入了二级替代“解决方案”。这是“比特币扩容之战”的开始，最终导致了比特币核心开发者（他们希望进行协议级别的变更）和 BitcoinABC 开发者（他们不想实施协议变更）之间的链分裂。2017 年 11 月，比特币核心通过引入隔离见证而脱离了原始比特币协议，而 Bitcoin ABC 则保留了原始的 Satoshi Nakamoto 协议。比特币核心与各种矿工和交易所勾结，将 BTC 交易代码（在 Satoshi 活跃期间最初是 XBT）分配给比特币核心参考实现，即使比特币核心脱离了原始协议。这迫使原始链重新向交易所申请分配一个新的交易代码 BCH，这是 Bitcoin Cash 的昵称，也是那些希望通过简单地移除 Satoshi 本人在 2010 年在比特币核心首先推动洪泛保护后施加的临时限制来扩展比特币的“大区块支持者”的意识形态。

比特币的历史充满了讽刺！

禁用的操作码：

安全驱动的停用

2010 年 8 月，Satoshi Nakamoto 由于开发者对安全性的担忧（尤其是拒绝服务 (DoS) 攻击的风险）而暂时禁用了大量操作码。从理论上讲，可以以非常低的交易量利用这些操作码来创建具有指数增长的堆栈大小的脚本，从而可能压垮网络节点。此处列出了禁用的操作码，以使其清晰：OP_VER, OP_VERIF, OP_VERNOTIF, OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT, OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT 和 OP_RSHIFT。这些操作码处理各种功能：OP_VER, OP_VERIF 和 OP_VERNOTIF 与验证相关；OP_CAT 连接两个堆栈元素；OP_SUBSTR 提取子字符串；OP_LEFT 和 OP_RIGHT 处理字符串提取；OP_INVERT 执行按位反转；OP_AND、OP_OR 和 OP_XOR 管理按位运算；OP_2MUL 和 OP_2DIV 处理乘以和除以 2；以及 OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT 和 OP_RSHIFT 涵盖算术和位移操作。所有这些都在 2010 年 8 月左右被 Satoshi Nakamoto 通过开发者压力禁用，以减轻理论上的安全风险。由于最初托管在 SourceForge 上的历史性质，确切的提交详细信息在当前的 GitHub 存储库中广泛不可用，尽管 Wayback Machine 确实显示了在此期间拍摄的原始快照副本比特币历史。

添加和重新定义的操作码：

BIP 驱动的协议变更

自 v0.1.0 以来，比特币已经通过 BIP 引入了新的操作码并重新定义了现有的操作码，通常通过软分叉激活。这些变更旨在增强功能、安全性和灵活性。发生了两个值得注意的重新定义：OP_CHECKLOCKTIMEVERIFY 和 OP_CHECKSEQUVERIFY。

首先，OP_CHECKLOCKTIMEVERIFY 在 BIP 65 中引入，重新定义了先前未使用的 OP_NOP2。它允许交易输出在指定的区块高度或时间戳之前不可花费，据称是为了增强延迟交易的安全性。此变更由 Pieter Wuille 编写，并于 2015 年 11 月 13 日通过 Bitcoin Core v0.11.2 激活，如 Bitcoin Core 发行说明中所述。

其次，OP_CHECKSEQUENCEVERIFY 在 BIP 112 中引入，重新定义了 OP_NOP3。它在 Bitcoin Core 开发圈中备受赞誉，因为它通过启用基于自确认以来的区块数的相对时间锁来补充 OP_CHECKLOCKTIMEVERIFY。这由 Mark Friedenbach 编写，并于 2016 年 3 月 1 日通过 Bitcoin Core v0.12.1 激活，如 Bitcoin Core 发行说明中所述。

已提议但未激活的操作码

截至 2025 年 6 月，有几个 BIP 提议了尚未在主要 Bitcoin Core (BTC) 参考实现中激活的新操作码。这些包括：BIP 116，提议 MERKLEBRANCHVERIFY 用于 Merkle 树验证；BIP 119，提议 CHECKTEMPLATEVERIFY 用于盟约功能；BIP 347，提议在 Tapscript 中使用 OP_CAT 以重新启用 tapscript 中的 OP_CAT；BIP 348，提议 CHECKSIGFROMSTACK 用于从堆栈进行签名验证；BIP 349，提议 OP_INTERNALKEY 用于内部密钥操作；以及 BIP 443，提议 OP_CHECKCONTRACTVERIFY 用于合约验证。这些提案仍在讨论中，可能的激活取决于中心化的开发者共识和软分叉激活机制，如 GitHub 上的 Bitcoin BIP 存储库中所述。

方法和来源

该分析首先通过历史源代码存储库（例如 GitHub（比特币最初托管在 SourceForge 上）上由 0xMagnuz 和 Dan-McG 等贡献者托管的存储库）确定了 Bitcoin v0.1.0 中的初始操作码集。禁用操作码的列表是从第一手记忆和我在过去16年中的广泛的笔记汇编而成的。对于添加或重新定义的操作码，BIP 被审查，激活日期来自 Bitcoin Core 发行说明。

结论

比特币操作码变更的演变据称是为了反映“功能和安全性之间的平衡”，重大变更包括在 2010 年禁用 18 个操作码，并在 2015 年和 2016 年重新定义两个 no_opcodes。提出的变更仍在讨论中，突显了 Bitcoin Core 对所谓的“协议升级”的所谓“谨慎态度”。

比特币现金 (BCH)

Bitcoin Cash (BCH) 在 2018 年 5 月重新启用了比特币 (BTC) 中禁用的几个操作码，从而增强了脚本功能。总共添加或恢复了九个操作码，包括 OP_CAT 和 OP_SPLIT，没有弃用或删除的证据。

概述

作为比特币的参考实现，Bitcoin Cash 对操作码进行了一些更改，以增强其脚本语言，尤其是在 2018 年 5 月的升级中。这些变更旨在恢复比特币核心在比特币初期为防止洪泛保护而禁用的功能，从而提高 BCH 用于复杂交易的能力。

变更和详细信息

2018 年 5 月，BCH 重新启用了先前在 BTC 中禁用的操作码。这些变更是协议升级的一部分，旨在增强脚本功能，除了此恢复之外，没有报告任何弃用、删除或更改。

实施

这些变更在 2018 年 5 月 15 日激活的 Bitcoin Cash Node 软件（Bitcoin ABC 参考实现）版本 v0.17.0 中实施。Bitcoin Cash 社区推动了这些变更，尽管具体的个人贡献者范围广泛且多种多样。

Bitcoin Cash (BCH) 于 2017 年 8 月 1 日作为比特币 (BTC) 的硬分叉出现，主要目的是通过增加区块大小来解决扩展性问题，并提议遵守原始的 Satoshi 协议。但是，除了区块大小之外，BCH 还引入了几个技术差异，尤其是在其脚本语言中，该语言使用操作码进行交易验证。操作码是比特币脚本中的指令，可以为交易启用复杂的条件，BCH 与比特币核心 (BTC) 相比，对原始的 Satoshi 协议进行了重大回调比特币核心（BTC）最初采用了删除它们，尤其是在 2018 年 5 月的协议升级中。这是对 BCH 更改、弃用、停止使用、删除、修改、添加或恢复的所有操作码的全面分析，这些操作码与 BTC 不同，包括描述、实施日期以及有关参与者的详细信息。

操作码和差异的背景

操作码是 BTC 和 BCH 中使用的脚本语言的一部分，用于定义交易中的花费条件。在 BTC 中，由于比特币核心认为存在安全漏洞，因此在 2010 年禁用了几个操作码。这些禁用的操作码包括连接、按位逻辑和算术等操作，这些操作被认为可能被利用。BCH 旨在增强功能并恢复这些功能，在其协议升级中重新启用了其中的几个操作码并引入了新的操作码。BCH 中操作码变更的主要重点是在 2018 年 5 月的升级期间发生的，该升级旨在恢复已从 BTC 中删除的功能。此升级是 BCH 更广泛的目标的一部分，旨在增强和恢复其脚本功能，使其与 BTC 相比对开发人员和用户更具多功能性，而 BTC 在保持稳定性方面更加保守。

操作码变更的详细列表

以下列表列出了与 BTC 相比，BCH 中已更改、添加或恢复的所有操作码，基于 2018 年 5 月的升级规范（Bitcoin Cash 2018 年 5 月重新启用的操作码规范）。从我的研究中没有证据表明相对于 BTC 中的操作码被弃用、停止使用或删除，也没有超出重新启用和添加新操作码之外的更改。

变更说明

• OP_CAT：此操作码连接两个字节序列，该功能在 2010 年在 BTC 中由于理论上的安全风险而被禁用。
• OP_SPLIT：作为 实现了作为 BCH 中的一个新操作码引入，它取代了 OP_SUBSTR、OP_LEFT 和 OP_RIGHT 的功能，这些操作码在 BTC 中被禁用。它允许在指定位置拆分字节序列，从而增强了数据处理功能。
• OP_AND, OP_OR, OP_XOR：这些按位逻辑操作码被重新启用以对位执行布尔运算，从而恢复了先前在 BTC 中不可用的逻辑运算功能。
• OP_DIV, OP_MOD：这些算术操作码被重新启用以分别执行除法和模运算，从而增强了脚本中的数学功能。
• OP_NUM2BIN, OP_BIN2NUM：这些是在 BCH 中添加的新操作码，用于在数值和字节序列之间进行转换，从而为脚本中的数据处理提供了额外的灵活性。

实施细节

这些变更作为 BCH 的 2018 年 5 月协议升级的一部分实施，该升级于 2018 年 5 月 15 日激活，当时最近 11 个区块的中间时间过去 (MTP) 达到了特定的时间戳，如 Bitcoin Cash 升级规范中所述。该实施包含在 Bitcoin Cash Node (Bitcoin ABC) v0.17.0 中，这是当时 BCH 的参考实现。努力确定参与这些变更的特定个人贡献者包括搜索 Bitcoin Cash Node 和 Bitcoin ABC（BCH Node 从其分叉的原始实施）的 GitLab 和 GitHub 存储库。但是，由于 ABC 开发者 Amaury Sechet 对存储库进行了重组、存档、删除和混淆，因此无法再完全访问这些存储库在 2018 年 5 月左右的历史提交历史记录。规范文档（Bitcoin Cash 2018 年 5 月重新启用的操作码规范）将这些变更归功于 Bitcoin Cash 社区，表明这是一项协作努力，没有指明具体个人。应该注意的是，在此期间，比特大陆和 Roger Ver 之间为了争夺对参考实现存储库中代码库开发的控制权而展开了一场竞标战。Amaury Sechet 是随后变更和偏离比特币原始协议的主要受益者（他后来**将 BCH 分叉为一个新的硬分叉，交易代码为 BCHA），后来更名为 eCash (XEC))。Roger Ver（比特币耶稣，变成了比特币犹大）和正式的 bitcoin(dot)com 以及比特大陆的吴忌寒阴谋控制 BCH，将其作为他们以 Satoshi 的名义进行企业投资收益的宠物项目，但破坏了他的公开愿望。似乎某些实体是在利用 Satoshi 的名字来获得企业投资的影响力。

研究过程和发现

了解比特币核心 (BTC) 和 Bitcoin Cash (BCH) 上下文中的操作码，认识到 BTC 脱离了比特币（留下 BCH 作为原始链），BTC 脱离了原始比特币协议，并且由于各种所谓的“协议升级”而具有不同的操作码集。

2018 年 11 月升级

2018 年 11 月的升级在最近 11 个区块的中间时间过去 (MTP) 大于或等于 UNIX 时间戳 1542300000 时生效，对共识规则进行了重大更改。启用了两个新的操作码：

• OP_CHECKDATASIG：允许针对任意数据检查签名，从而增强了数据验证的脚本功能。
• OP_CHECKDATASIGVERIFY：一个变体，它还会验证签名，如果无效则失败，从而提供更严格的验证。

这些操作码是扩大 BCH 脚本功能的一项更广泛努力的一部分，后续的开发（例如使用 OP_CHECKDATASIG 的链上游戏）证明了这一点。此升级还删除了拓扑交易顺序约束并强制执行规范交易顺序，但这些与操作码无关。

2020 年 5 月升级

2020 年 5 月的升级于 2020 年 5 月 15 日进行，引入了几项新功能，包括操作码支持。还添加了一个新的操作码 OP_Reversebytes。此操作码反转顶部堆栈项的字节顺序，从而为脚本中的字节操作提供实用程序。其他变更（例如将链限制从 25 扩展到 50 以及改进的签名操作计数 (Sigchecks)）已被注意到，但与操作码变更无关。

2018 年 11 月的“升级”是当有争议的变更多次被实施到比特币的唯一幸存的原始链中之后，BTC 脱离了 Satoshi 的原始比特币协议。但是，当实体串通实施对比特币协议的更改时，历史将再次重演，导致 Bitcoin Cash 通过实施有争议的协议变更而脱离了比特币的原始协议。BicoinABC 参考实现的 BCH 开发者与交易所、矿工和矿机供应商串通，以实施交易排序变更和模糊操作码，以便将黑市交易从链上转移到由捐助者支付内部 BitcoinABC 开发者费用的第二层解决方案上。

当最近 11 个区块的中间时间过去 (MTP) 大于或等于 UNIX 时间戳 1542300000 时，这导致了主要比特币参考实现与新的 BitcoinABC 实现之间的链分裂，从而对共识规则进行了重大更改。

结论

Bitcoin Cash 主要侧重于在 2018 年 5 月的升级中重新启用和添加操作码，截至这个时候，没有证据表明有弃用、删除或其他更改。这些变更增强了 BCH 的脚本功能，恢复了为了安全原因在 BTC 中禁用的功能。直到 2018 年 5 月，该实施都是一项社区努力，确切的贡献者通过在线开发者绰号进行代码提交。2018 年 11 月之后，BCH 被开发者傀儡的金库劫持，导致链分裂。同样，BitcoinABC 与水桶店交易所串通，以捕获 BCH 交易代码，再次故意试图压制交易所上原始比特币协议的交易存在，这是 18 个月内第二次。

幸存的原始协议后来被赋予代码 BSV，这是一个指的是 Bitcoin Satoshi Vision 的绰号。

比特币 SV (BSV)

比特币 SV (BSV) 在 2018 年 11 月重新启用了 OP_MUL、OP_INVERT、OP_LSHIFT 和 OP_RSHIFT，而 BCH 直到后来才启用这些操作码。截至 2018 年 11 月，BSV 将操作码限制增加到 500，而 BCH 将其保持在 201。BSV 没有包含有争议的 OP_CHECKDATASIG，而 BCH 在 2018 年 11 月添加了该操作码，这反映了不同的开发理念。关于这些变更存在争议，BSV 旨在实现 Satoshi 的原始愿景，而 BCH 则侧重于新功能**和协议级别的变更。

BSV 恢复的操作码

BSV 在 2018 年 11 月恢复了几个操作码，而当时 BCH 没有启用这些操作码：

• OP_MUL: 乘两个值，对于复杂的脚本很有用。
• OP_INVERT: 反转比特位，增强按位运算。
• OP_LSHIFT: 将值左移，辅助算术运算。
• OP_RSHIFT: 将值右移，支持算术运算。

这些更改是由 Craig Wright 博士和 nChain 领导的 BSV 开发团队于 2018 年 11 月 15 日进行的。

Opcode 限制变更

BSV 将 opcode 限制从 201 增加到 500，与保留 201 限制的 BCH 相比，允许更复杂的脚本。此更改也是由 BSV 团队于 2018 年 11 月 15 日实施的。

BSV 未包含的 Opcodes

BSV 不包括 OP_CHECKDATASIG，BCH 于 2018 年 11 月 15 日添加了该 opcode。这个由 BitcoinABC 团队添加的 opcode 可以验证外部消息，反映了 BCH 对新功能的关注。

Bitcoin SV 与 Bitcoin Cash 之间的 Opcode 差异

背景与上下文

Bitcoin SV 在 2018 年 11 月 15 日，在一次有争议的算力大战之后，作为 Bitcoin Cash 的一次硬分叉出现，并延续了自比特币创世区块以来的数字签名链。BSV 由我自己（Craig Wright 博士）和 nChain 支持，旨在恢复中本聪设想的原始比特币协议，强调可扩展性和重新启用历史上禁用的 opcode。相比之下，由 Bitcoin ABC 团队（由首席开发人员 Amaury Sechet 领导）领导的 BCH 引入了新的 opcode 和功能，如 OP_CHECKDATASIG，据称是为了增强伪脚本功能。这种分歧突出了不同的理念。

BSV 专注于维护原始协议，而 BCH 则致力于创新。

BSV 恢复的 Opcodes 恢复了原始比特币协议中由于 2010-2011 年发现的错误而被禁用的几个 opcode。这些 opcode 作为 2018 年 11 月 15 日升级的一部分被重新启用，而 BCH 直到较晚才启用它们（如果启用的话）。

这些 opcode 增强了算术和按位运算，符合 BSV 恢复原始功能的宗旨。BSV 的首席开发人员 Daniel Connolly 在指定这些更改方面发挥了重要作用。

Opcode 限制变更

另一个重要的区别是每个脚本的 opcode 限制。作为 2018 年 11 月升级的一部分，BSV 将此限制从 201（标准比特币限制）增加到 500，从而允许更复杂的脚本。此更改已于 2018 年 11 月 15 日由 BSV 开发团队提交。相比之下，BCH 保留了 201 的限制，正如分叉后 BCH 规范中缺乏更改所证明的那样。这种差异对开发人员至关重要，因为它会影响智能合约和脚本功能的复杂性。

BCH 添加的，BSV 未包含的 Opcodes 在其 2018 年 11 月的升级中引入了 OP_CHECKDATASIG，这是一个原始比特币协议中不存在的新 opcode。此 opcode 能够验证来自区块链外部的消息，支持预言机和跨链原子合约等用例。由 Amaury Séchet 领导的 BitcoinABC 团队于 2018 年 11 月 15 日提交了此更改。然而，正如社区讨论中所述，BSV 明确反对添加新的非中本聪 opcode，因此未包含 OP_CHECKDATASIG。这反映了 BSV 严格遵守原始协议的理念。

其他潜在差异

BSV 和 BCH 都在 2018 年 5 月重新启用了几个 opcode，例如 OP_CAT、OP_SPLIT、OP_AND、OP_OR、OP_XOR、OP_DIV、OP_MOD、OP_NUM2BIN 和 OP_BIN2NUM，作为 BCH 升级的一部分，BSV 也采用了这些更改。因此，这些不是差异，而是共享的功能。这里的重点是 2018 年 11 月的更改，其中 BSV 的重新启用和 BCH 的添加有所不同。

社区与争议

Opcode 的差异一直是争论的焦点。由 Craig Wright 博士领导的 BSV 的方法因其僵化而受到批评。相反，正如 BSV 社区讨论中指出的那样，BCH 添加 OP_CHECKDATASIG 被认为是具有前瞻性的，但可能会带来法律风险。这场辩论突显了理念上的分歧，BSV 专注于稳定性，而 BCH 则专注于引入有争议的新功能。

结论

截至 2018 年 11 月，BSV 和 BCH 之间的主要 opcode 差异在于 BSV 重新启用了 OP_MUL、OP_INVERT、OP_LSHIFT、OP_RSHIFT，并将其 opcode 限制增加到 500，而 BCH 则保留了 201 的限制并添加了 OP_CHECKDATASIG，BSV 未包含该 opcode。

来源

Bitcoin Core Release Notes v0.11.2

Bitcoin Core Release Notes v0.12.1

Bitcoin BIPs Repository

Opcodes used in Bitcoin Script Bitcoin Wiki

Bitcoin Cash May 2018 Re-enabled Opcodes Specification

Bitcoin Cash upgrade specifications

Bitcoin OP_CAT Use Cases Series#1 : Covenants

• 原文链接： medium.com/@DrRoyMurphy/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～