OP_RETURN

Jana 想给交易附加信息，而不是再向某人支付一笔钱。因此，她创建一个以 OP_RETURN 开头的输出。如果有人尝试花费它，执行该指令就会让脚本检查失败，无论签名是什么。输出脚本的技术名称是 scriptPubKey。关键在于指令的位置和是否执行：嵌入数据中相同的字节，并不等于正在执行这条指令。未执行分支中的 OP_RETURN，也不同于脚本开头的 OP_RETURN。所以，只在交易某处找到名称或对应字节并不足以判断。 [1] [5]

Bitcoin Core 将常见形式归类为 NULL_DATA。名称并不是说里面没有数据。Solver 函数要求开头是 OP_RETURN，其余部分通过 IsPushOnly 检查，也就是只包含压入数据的指令。这些数据可以是文字、hash——计算得到的简短指纹——或供另一种协议使用的记录。但这种分类不确认消息的含义，也不自动保证交易进入节点的等待队列。记录还不能自动确立文件所有权、作者身份或法律效力；这些主张需要额外规则和证据。 [3]

节点维护 UTXO 集合，也就是尚未花费、仍可使用的输出。对于以 OP_RETURN 开头的输出，节点预先就知道无人能花费它。IsUnspendable 会识别它，AddCoin 不会把它加入 UTXO 缓存。这节省的是当前工作状态的记录，并不是整个历史中的空间：确认的交易仍留在区块里，数据仍须传输并保存在历史副本中。不进入 UTXO 并不意味着删除数据。如果有人给这种输出分配金额，那也不是给矿工的奖励。这笔金额无法花费，以后补一个签名也无法取回。 [2] [6] [1]

共识规则决定节点认为哪些区块有效。本地策略则选择哪些交易进入 mempool，即未确认交易的等待队列，以及哪些会被转发或提供给挖矿。这样做是为了保护节点资源。运营者可以采用不同设置：拒绝转发交易，并不意味着包含该交易的区块违反共识。进入 mempool 也不保证最终确认。datacarriersize 设置的是本地数据预算，它本身既不重写区块有效性规则，也不删除已经确认的内容。 [8]

常被引用的旧默认规则允许 1 个数据输出，脚本最多 83 字节，通常为 80 字节内容加上指令。Bitcoin Core 30.0 将默认 datacarriersize 提高到 100000，并允许多个数据输出。代码从一个共同预算中扣除每个此类输出的完整 scriptPubKey 长度。它不是只计算消息内容，也不计入外层表示脚本长度的字段。其他交易限制仍然存在。因此设为 83 只恢复原来的预算大小，不恢复原来仅限一个输出的规则。这些数字描述的是特定版本的变化，不是整个网络永恒不变的规则。 [7] [4] [8]

Jana 可以把文档的 hash 放入 OP_RETURN，而不是放入文档本身。日后出示原文件时，别人可以用相同方法重新计算指纹，再与记录比对。她必须保留文件的精确字节和计算方法；指纹不能替代文档。匹配并不能证明内容属实、作者是 Jana，或文件具体何时创建。公开记录还可能把身份联系起来，数据经过哈希也不自动具有隐私性。成本取决于整笔交易和区块空间需求，而不只是消息长度。 [1] [8]

普通应用消息之外，存在一个重要且定义明确的例外。BIP 141 在区块的首笔交易 coinbase 中使用 OP_RETURN，放置 witness commitment，也就是与验证交易所需附加数据建立的密码学绑定。对应 scriptPubKey 至少为 38 字节，以 0x6a24aa21a9ed 开头。如果多个输出匹配，就选索引最高的，也就是顺序中最后一个匹配的输出。如果区块没有 witness 数据，这一 commitment 可省略。网络在这里检查特定结构，并不意味着它会验证 OP_RETURN 后任何文字的真实性。 [9]

先问清楚限制指的是哪种客户端、哪个版本及什么配置，再解码实际交易，将 scriptPubKey 与字节编码中包围它的字段区分开。mempool_datacarrier.py 测试展示了实现的边界情况，但本文没有运行它。BIP 110 曾提出额外共识限制，不过它是一项已关闭提案，不是通过 datacarriersize 开启的规则。旧版本说明也不保证所有节点或未来版本行为相同。某项配置和交易实际获得确认，是两种不同的信息。 [10] [8] [11]