jakiro
作者：Aaron Zhang；来源：X，@zzmjxy
Bitcoin Core v30 放开 OP_RETURN 限制，大家都在说是因为”Ordinals 铭文限制无效”。
过去三个月，我深入研读了 Bitcoin Core v30 的邮件列表、Citrea 白皮书和相关技术文档。 发现一个被所有人忽视的真相：OP_RETURN 政策改变的真正原因，根本不是 Ordinals。 是BitVM。
这个故事比 Ordinals 叙事更重要。这个视角，中英文社区都没人讲过。
案例背景
2024年4月，Citrea 发布了第一个完整的 BitVM bridge——Clementine。
它是 Bitcoin 上第一个 zkRollup，使用 BitVM 来做 L1 验证。
然后他们遇到了一个技术难题：需要在链上发布 144 字节的锚定数据。
技术需求
这 144 字节包括：
-
128 字节：Groth16 zero-knowledge proof
-
16 字节：total accumulated work（总工作量证明）
这些数据用于 Watchtower 质疑 Operator 时，证明他们掌握了正确的 Bitcoin 链。问题来了：OP_RETURN 只允许 83 字节。不够。
核心技术约束
有人会问：为什么不放在 witness 里？像 Ordinals 那样？关键区别：Citrea 的后续验证交易需要**读取**这些数据。
而 Bitcoin Script 无法引用前一个交易的 witness 数据。所以数据**必须**在 scriptPubKey 位置，这不是可选项。
技术原理
简单说就是：
Witness数据：
-
只能证明”当前交易有效”✓
-
不能被后续交易读取 ✗
scriptPubKey 数据：
-
可以被后续交易的 Script 引用 ✓
BitVM 的验证逻辑需要链式引用，所以必须用 scriptPubKey。
被迫的方案
83 字节不够，Citrea 被迫用了一个很糟糕的方法：创建”不可花费”的 Taproot outputs，把数据伪装成公钥。
具体做法：
-
输出0: OP_1 <前32字节伪装成公钥>
-
输出1: OP_1 <中32字节伪装成公钥>
-
输出2: OP_RETURN <剩余80字节>
这些”公钥”根本没有对应的私钥。永远花不了。
危害分析
这个方案的问题：永久膨胀 UTXO set。
每个 WatchtowerChallenge 交易创建两个永远无法清理的 UTXO。所有全节点必须永久存储这些”假公钥”。这正是 Core 开发者一直想避免的最糟糕情况。
邮件列表原文
Antoine Poinsot 在提案中明确写道：
“Clementine 使用 unspendable Taproot outputs 来存储数据… 由于 OP_RETURN 的大小限制”
这个案例**直接触发**了 OP_RETURN 政策改变的提案。 邮件原文 。
开发者的逻辑
Core 开发者的思考链条：
-
现状：Citrea 用假 UTXO（糟糕）
-
未来：更多 BitVM 项目会效仿
-
或者：他们用裸多签（像 Stamp 协议那样）
-
结论：不如放开 OP_RETURN，提供”较小危害”的路径
这是 harm reduction（减害）策略。
BitVM 的战略地位
为什么 Core 愿意为 BitVM “开路”？因为 BitVM 是 Bitcoin L1 创新的重要方向。
Blockstream CEO Adam Back 说过：”BitVM 的 anchor 机制是 L1 的重要方向”
如果 BitVM 生态发展起来：
-
各种 zkRollups
-
跨链 bridges
-
复杂的链上验证
都会有类似的锚定需求。
与 Ordinals 的本质区别
Ordinals vs BitVM 锚定数据：
Ordinals：
-
位置：Witness（可剪枝）
-
动机：投机/艺术
-
特征：可能消退
BitVM 锚定：
-
位置：scriptPubKey（必须永久）
-
动机：基础设施安全需求
-
特征：长期增长的需求
完全不同的技术场景。
结论
所以 Bitcoin Core v30 的 OP_RETURN 政策改变：不是对 Ordinals 的投降，而是为 BitVM 生态的主动疏导；不是被动应对投机，而是为技术创新提前铺路。这是 Core 开发者的前瞻性思考。
所以说，Core 的重点从来不是 JPEG，而是：
-
为未来 VM（BitVM / Simplicity / Covenants）提前铺路
-
清理十年前遗留的特殊规则，让系统能继续演进
-
避免 policy 层变成限制创新的“隐形共识”
掌握了这些，你就掌握了比特币未来十年的技术方向。不是停在 vs. Ordinals 以及vs. Knots的口水战，而是真正理解技术演化的逻辑。
