协议演进 / BIP/比特币改进提案 / BIP-110

BIP-110 精简数据临时软分叉

临时一年在共识层限制数据字段大小——新输出脚本、数据推送与 witness 元素、Taproot 控制块等——以压制任意数据嵌入;激活高度之前已存在的 UTXO 全部豁免。本 BIP 目前处于已关闭状态。

一、档案卡

档案卡
编号BIP-110
标题Reduced Data Temporary Softfork
作者Dathon Ohm <[email protected]>
指定日期2025-12-03
层级Consensus (soft fork)(共识(软分叉))
类型Specification(规范类)
状态Closed(已关闭)
阅读版https://bips.dev/110
官方原文https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki

二、放在哪一族

编号紧挨着 BIP-109,方向却正好相反。BIP-105 至 BIP-109 争论的是“区块能装多少交易”;BIP-110 问的是“区块里什么东西不该装”——它要临时收紧的是任意数据在交易各字段中的容身之处。

它是一份软分叉提案,规则大量援引后来的脚本体系:

BIP-16:P2SH,其 redeemScript 推送是规则 2 的唯一例外

BIP-141:隔离见证(共识层),定义了 witness v0 的合法形态

BIP-341:Taproot,定义 witness v1 与控制块(control block)

BIP-342:Taproot 脚本验证,定义 Tapleaf 版本 0xc0(Tapscript)

BIP-433:Pay to Anchor(P2A),是它承认的又一种已定义 witness 形态

与 BIP-114 对照看也很有意思:114 想把脚本树做大、做活,110 则在临时期内把 Taproot 控制块压到 128 个脚本叶子的规模——一个扩表达,一个收数据。

三、它要解决什么

3.1 任意数据嵌入被“标准化支持”后的激励扭曲

原文称,比特币社区历来对把任意数据嵌入交易的技术持对抗态度,因为一旦这种用法变得理所当然、开始“承重”(load-bearing),就会产生负外部性,尤其是压在节点运营者身上。

导火索是原文所称 2022 年开始被利用的 “inscription” 手法:把任意数据嵌入交易的趋势,给节点运营者带来显著的不必要负担,并把开发焦点与激励从“健全、无许可、无国界的货币”这一根本目的上引开。

3.2 它想达到的效果

原文也承认:垃圾信息(spam)主要仍应由策略(policy)层应对,策略无法保证 100% 有效、尤其防不住自己挖矿的作恶者,这份软分叉的作用是收住最坏情形。

四、规则本身

4.1 七条临时规则

在为期一年的临时部署期内,区块须额外通过以下检查:

  1. 新输出的 scriptPubKey 超过 34 字节即无效;但若第一个操作码是 OP_RETURN,则最长 83 字节有效。
  2. OP_PUSHDATA 的载荷、以及“脚本参数 witness 元素”(script argument witness items)超过 256 字节即无效;BIP-16 scriptSig 中的 redeemScript 推送除外。
  3. 花费未定义的 witness(或 Tapleaf)版本即无效——但创建这类输出仍然有效。
  4. witness 栈中带有 Taproot annex(附加项)即无效。
  5. Taproot 控制块大于 257 字节即无效——257 字节对应一棵有 128 个脚本叶子的默克尔树;比 256 多的 1 字节,是控制块首字节的叶子版本与奇偶位。
  6. Tapscript 中只要出现 OP_SUCCESS 操作码(哪怕在未执行处)即无效。
  7. Tapscript 中只要执行了 OP_IF 或 OP_NOTIF 指令(无论结果)即无效。

几条取舍的理由,原文说得很清楚:scriptPubKey 要长期存放在 UTXO 集合中、需快存储且不能修剪,现代用法实际都在 34 字节以内,真正的花费条件已移到 witness、scriptPubKey 只以哈希预先承诺;OP_RETURN 输出可证明不可花费、不进 UTXO 集,故保留但封顶 83 字节;256 字节足够容纳合法密码学可能需要的大数,而现代压缩下图片也只需约 300–400 字节即可表示,正是要卡住这类需求;OP_IF 在 Taproot 里可用链下求值加 key-path 花费替代,却常被用来注入执行时被跳过的垃圾数据。

4.2 什么是“已定义”的 witness 版本

就规则 3 而言,原文列明的已定义形态只有:

规则 2 中的“脚本参数 witness 元素”,指在脚本执行前被放上解释器栈、作为输入的 witness 栈元素;witness 脚本与 Tapleaf 脚本、控制块、annex,以及根本不调用脚本解释器的情况(如 Taproot key-path 签名,其长度已由 BIP-341 限定为恰好 64 或 65 字节)都不属于它——它们或不受规则 2 限制,或由其他规则单独处理。redeemScript、witness 脚本、Tapleaf 脚本被豁免,是因为它们是脚本而非数据,其内容在执行时同样受 OP_PUSHDATA 限制约束。

4.3 UTXO 豁免(grandfathering)

这一条意在保证:没有任何已存在的币会因这次软分叉被冻结或变得不可花费。

4.4 部署:改造版 BIP-9,一年为期

部署使用改造过的 BIP-9,参数为:

原文还讨论了资金风险:理论上存在极少数边缘情形(如某些 Miniscript 编译出的含 OP_IF 的 Tapleaf、深度超过 7 层的 Taptree 叶子、且只能经脚本路径花费的预签名 Taproot 交易)可能在部署期内被冻结或丢失;原文列出了多项“完全不受影响”的条件,并建议可能受影响的用户提前迁移资金、利用锁定与激活之间至少两周的窗口处理。

五、谁必须动

普通持币人:大多数人无须动作——非 Taproot 用法、标准且受良好支持的 Taproot 用法、以及激活前已确认的 UTXO 都不受影响。持有边缘形态预签名 Taproot 交易的人,原文建议在激活前迁移资金。

钱包开发者:Miniscript 编译器在规则生效期间须修改为不产生违反新规则的脚本(典型是含 OP_IF 的 Tapleaf);生成新输出、构造 witness 的钱包须遵守 34/83 字节与 256/257 字节上限。

全节点与矿工:节点须执行七条新共识规则与豁免规则,并参与改造版 BIP-9 的信号与强制信号;矿工在强制信号期不出信号位,区块即无效。

共识层:这是软分叉——收紧有效性,未升级节点看到的新规则下无效的区块,在旧规则下多半仍“合法”,但链的选择会分化。它与 BIP-105–BIP-109 的硬分叉扩容不同,不要求全网先升级再改规则。

六、现在算不算数,以及一个常见误读

状态为 Closed(已关闭)。原文的变更日志(Changelog)记载:版本 1.0.0 于 2026-06-25 推进至 Complete,版本 1.0.1 于 2026-08-09、在一次“链分叉且挖矿停滞”(chain split with stalled mining)之后被标记为 Closed。除此之外的采用细节,原文没有给出,本页不作推测。它作为档案的价值,在于完整记录了一次“用临时共识规则对抗数据存储用例”的尝试:规则、豁免、风险披露与到期机制都在同一份文件里。

常见误读:

“BIP-110 要永久禁止在比特币上存数据、并会冻结老币。”

两点都不对。其一,它是明确临时的:active_duration 为 52416 个区块(约一年),到期进入 EXPIRED 后规则不再执行,原文称临时正是因为这些限制会严重约束未来升级、且更完善的长期方案需要时间。其二,激活高度之前创建的 UTXO 豁免全部新规则,老币可以照旧花费;它针对的是部署期内新创建的输出与花费形态。

七、延伸

本页内容整理自 bitcoin/bips 仓库与 bips.dev,事实已与仓库核对;解读仅供学习参考。