比特币 OP_RETURN：能写多少字节、为什么要主动限制

想在比特币上“留一行字”的人多半听过 OP_RETURN。写协议索引的、锚定文档哈希的、发 Runes 指令的，底层都用到它。但它是比特币里最克制的功能之一：官方实现默认只给很小的额度。本文讲清额度是多少、为什么这么小、谁在用它。

是什么：会说话的垃圾输出

OP_RETURN 是一种让输出永远不可再被花费的脚本前缀。往交易里加一个 OP_RETURN 输出，等于公开写入一段数据，同时声明这个输出没有余额支配意义、不进入后续花费循环。因为它排除了被当作普通余额继承的可能，节点对这类数据输出的态度比早期的“往任意脚本塞数据”宽容——不带 OP_RETURN 的数据塞入脚本长期不被标准规则接受。

能写多少：默认 83 字节的口径

比特币核心对含 OP_RETURN 的交易有一套标准性（standardness）政策：这条门槛有两个相关数字：共识规则允许的空数据输出脚本最大可达一万字节量级，而比特币核心的中继与打包政策默认只认总长 83 字节的空数据输出（80 字节数据加 1 字节操作码与 2 字节推送标记），并可通过配置调整。政策与共识是两层规则：超出 83 字节的空数据输出在共识上多数仍可有效，但默认政策下的节点不转发、多数矿池不打包，实际效果接近发不出去，只能等待少数放宽配置的通道。83 字节的量级够放一条哈希、一段简短指令，装不下一张图片——这正是理解铭文与 OP_RETURN 分野的钥匙。

谁在用它

一类是锚定：把外部文件的哈希写进 OP_RETURN，链上留指纹、内容留在别处，适合证明“某时刻存在某文档”，本身不承载内容。另一类是协议消息：Runes 是现成例子，官方手册描述 Runestone 输出以 OP_RETURN 开头、后接 OP_13 和数据推送，代币的铸造、mint、转账指令都写在这段紧凑编码里。还有一类被协议当作销毁通道：指向 OP_RETURN 输出的代币余额即视为永久退出流通。

为什么铭文反而不走它

Ordinals 铭文要写图片、HTML、视频，动辄几十 KB 以上，远超默认政策门槛，于是走了另一条路：把数据放进 Taproot 见证数据的脚本信封（见铭文信封机制篇）。两条路线的本质区别：OP_RETURN 假设数据小、只当索引或指令；铭文假设内容本身值得上链。评估任何“比特币上写数据”的方案，第一个问题是数据量放得进哪种通道，第二个问题是索引器按哪套规则读它。

常见误区

一是把 83 字节当成共识硬顶——它是默认标准政策，不同运行配置的节点群可能表现不同，生态实践以默认为主流。二是以为写了 OP_RETURN 就等于内容上了链，锚定只留哈希，原文是否可得取决于链下托管。三是忽略不同索引器对 OP_RETURN 交易的解析差异，核验时多换一两个数据源。

与费率的交互

OP_RETURN 输出的 satoshi 金额必须为零，数据费按字节计入权重；换句话说，它是一笔只为数据付费的交易。对只写几十个字节的协议消息或锚定来说，这类交易是比特币上最便宜的公开记录方式之一；反过来，任何试图把它当通用存储用的方案，都会在默认政策的 83 字节处撞墙，然后被迫选择更贵的载体。理解这个成本梯度，就能看懂比特币上各类数据协议为什么各自选择了不同通道。 需要区分的是，不同比特币代币协议对 OP_RETURN 的使用深度不同：有的仅写哈希做锚定，有的把整套账本指令压进这里，同一段字节在不同索引器里的解释完全依赖其协议文档，看数据前先确认协议版本，能避免大量跨工具对不上的困惑。

风险提示：本文仅介绍比特币协议机制，不构成任何投资建议。涉及链上数据写入的功能请以对应协议文档与所用节点版本说明为准。