Opcode

安娜想付钱给彼得。钱包准备交易和所需签名，节点随后检查她是否有权花费选中的比特币。钱包是接收和发送比特币的应用程序或设备。节点是验证交易和区块、并与其他网络参与者通信的软件。Bitcoin Script 描述其中一部分检查；opcode 就是单个步骤，例如验证签名。普通付款时，安娜不必手写指令。但节点不能相信某个所有者的名字或“已签名”的标签，而要实际检验条件。脚本通过检查，也只是整笔交易验证的一部分。 [1] [4]

可读的脚本中可能出现 OP_DUP 或 OP_CHECKSIG。这些是供人阅读的指令名称，在实际脚本中由单字节代码表示。字节是衡量数据大小的常用单位。其他部分是数据，例如公钥。公钥用于验证签名，不需要保密。OP_PUSHDATA 系列指令指定把后面多少字节作为数据放入。已经放入的数据内部，即使有相同字节，也不会再次当作指令执行。就像菜谱里的“加入盐”与真正放进碗里的原料是两回事。 [1] [2]

想象一叠便条，每次从最上面取用。脚本的基本工作栈就这样运作。OP_DUP 复制栈顶项目，OP_DROP 移除栈顶项目。在非空栈上先执行 OP_DUP，再执行 OP_DROP，内容就会回到原样。你复制的是工作数据，并没有让比特币翻倍。缺少必要项目可能导致执行失败，数据顺序和精确编码也会影响结果。 [1]

OP_EQUAL 取出栈顶两个项目，比较它们的字节，再用比较结果替换它们。OP_EQUALVERIFY 在不同时立即失败；相同时继续执行，但不把该结果留在栈上。两种操作本身都不验证签名。任何人都能提供两份相同公钥。只有相应的签名检查，才能证明有人能够签署所要求的消息。 [1] [4]

OP_CHECKSIG 根据公钥和从交易构造的消息验证签名，而不公开私钥。私钥是用于生成这种签名的秘密数值。sighash 参数决定签名覆盖交易的哪些部分；并非每种模式都签署全部内容。旧脚本和 SegWit 版本 0 使用 ECDSA，一种签名算法。Tapscript 是 Taproot 的脚本规则，对通常的 32 字节公钥使用另一种算法 Schnorr。离开这些背景，只看指令名称是不够的。 [1] [3]

条件可以允许正常花费，也可以提供备用恢复路径。OP_IF 和 OP_ELSE 根据栈中的值选择分支；OP_ENDIF 结束条件部分。Bitcoin Script 没有可任意重复的一般程序循环。但不能因此忽略未执行分支中的一切。有些指令在读取脚本时就会受到检查，具体取决于指令种类和规则版本。 [1] [3]

CLTV，即 OP_CHECKLOCKTIMEVERIFY，可以强制执行绝对门槛，例如指定区块高度，即区块在链中的位置。CSV，即 OP_CHECKSEQUENCEVERIFY，与交易年龄规则配合，要求从被花费输出确认后经过相对延迟。输出是先前收到的一笔金额及其花费条件。这些指令检查交易字段，不会启动倒计时、发送资金或取代签名。实际应用需要把合适的时间锁与其他条件组合起来。 [7] [8] [9]

阅读技术示例前，先确认它使用旧脚本、SegWit 还是 Tapscript。Tapscript 增加 OP_CHECKSIGADD 来组合签名检查。相反，OP_CHECKMULTISIG 一旦执行就会失败；按照这些规则，它在未执行分支中会被忽略。并不是名字自相矛盾，而是验证环境不同。Opcode 列表不是一套可以不加考虑就在各种格式间搬用的通用积木。 [1] [3] [6]

BIP 342 为 Tapscript 的未来扩展预留了 OP_SUCCESSx 系列。此前检查通过后，解码时遇到其中一条指令，就会跳过后续脚本检查并返回成功，即使它位于未执行分支。推入数据内部偶然相同的字节不算。这为规则修改留下空间，却不代表新的保护已经启用。若条件依赖尚未定义的未来含义，就可能无法像作者预期那样保护资金。 [1] [3]

Full Node 独立检查有效性规则，但对接收和传播未确认交易可以采用更严格的规则。例如，Bitcoin Core v29.0 默认拒绝转发在 Tapscript 中使用 OP_SUCCESSx 指令的交易，尽管共识规则可能允许它们进入区块。阅读示例时，应确认版本、初始数据、签名覆盖范围和失败情况。语法可读不等于钱包安全；日常使用时，这些工作交给经过审查的软件完成。 [1] [5]