BIP · 共识层

BIP-110
减数临时软分叉

减数临时软分叉 (减数数据 · 临时软分叉)

作者: Dathon Ohm · 状态: Complete · 激活阈值: 55%

📝 参与调查 📊 查看结果 EN

什么是 BIP-110?

面向中文社区的全方位解读

概览

BIP-110(减数临时软分叉 / 减数数据 · 临时软分叉) 是由 Dathon Ohm 提出的比特币共识层改进提案,旨在通过 临时性(一年期)的共识规则变更,限制比特币交易中嵌入任意数据的能力,从而纠正因铭文(Inscriptions)、Ordinals、BRC-20 等数据滥用行为导致的激励扭曲,将开发重点重新聚焦到比特币作为货币的核心功能上。

💡 核心精神: 比特币应该"只做一件事,并把它做好"()。通过拒绝数据存储,BIP-110 将比特币开发者从无止境的范围蔓延中解放出来,让他们专注于真正重要的事——比特币作为货币的成功。

为什么要提出 BIP-110?

自 2022 年"铭文"(Inscriptions)漏洞被利用以来,将任意数据嵌入比特币交易的趋势愈演愈烈,给节点运营者造成了巨大的非必要负担,并转移了开发和激励方向,使比特币偏离了其作为健全、无需许可、无国界货币的根本目的。

BIP-110 通过共识层面使最有害的数据滥用方法失效,同时保留所有已知的货币用途。它向整个生态系统发出明确信号:任意数据存储将继续受到积极抵制

主要设计原则

  • 临时性 — 软分叉有效期仅约一年(52416 个区块),到期自动失效,给社区时间设计更完善的长期解决方案
  • UTXO 祖父条款 — 分叉激活前创建的 UTXO 完全豁免,确保现有资金不会被冻结或无法使用
  • 降低阈值(55%) — 因属于紧急干预措施且具有临时性,仅需 55% 算力支持即可激活
  • 简单可审查 — 七条规则经过刻意简化,以最大限度减少审查时间并避免意想不到的副作用

七项核心规则

BIP-110 临时软分叉期间执行的共识检查

规则 #1
限制输出脚本大小
新的 scriptPubKey 超过 34 字节无效,除非首操作码为 OP_RETURN(最多 83 字节)
规则 #2
限制数据推送大小
OP_PUSHDATA 和见证脚本参数超过 256 字节无效(BIP16 redeemScript 除外)
规则 #3
禁用未定义的见证版本
花费用未定义的见证版本(非 v0/Taproot/P2A)创建的输出无效,但创建仍有效
规则 #4
禁用 Taproot Annex
包含 Taproot annex 的见证栈无效
规则 #5
限制 Taproot 控制块
Taproot 控制块超过 257 字节无效(即默克尔树最多 128 个脚本叶子)
规则 #6
禁用 OP_SUCCESS*
包含 OP_SUCCESS* 操作码的 Tapscript 无效(即使未被执行)
规则 #7
禁用 OP_IF/OP_NOTIF
在 Tapscript 中执行 OP_IF 或 OP_NOTIF(无论结果如何)无效
🔒 UTXO 祖父条款: 在激活高度之前创建的 UTXO 完全不受上述新规则限制。这确保了在整个部署期间,任何现有比特币都不会被冻结或变得不可花费。

部署时间线

BIP-110 的完整生命周期

2025 年 10 月
初稿发布
Dathon Ohm 提交 BIP-110 初稿讨论 for discussion
2025 年 12 月 1 日
开始信号(StartTime)
矿工可开始用 bit 4 信号支持
2026 年 7 月
当前阶段 · 算力投票中
55% 阈值(1109/2016 个区块)达成后锁定
最迟 2026 年 9 月
强制锁定 · 强制信号期
高度 961632-963647 强制执行信号;最迟 963648 锁定
最迟 2026 年 9 月
规则生效(ACTIVE)
锁定后一个难度调整周期即生效,高度约 965664
约 2027 年 9 月
规则到期(EXPIRED)
52416 个区块后自动到期,UTXO 恢复不受限状态

常见问题 FAQ

关于 BIP-110 的高频疑问

BIP-110 会冻结我的比特币吗?

极不可能。UTXO 祖父条款确保激活前创建的 UTXO 完全豁免。只有在同时满足多种严苛条件的情况下资金才可能受影响(使用 Taproot + 预签名交易 + 在分叉期内创建且花费 + 使用了违反规则的 Tapleaf + 密钥路径不可用且无其他可用 Tapleaf)。标准比特币使用场景完全不受影响。

为什么是临时性的?

这些限制会严重约束未来的升级,为避免让"完美成为足够好的敌人",先部署简单的临时规则,给社区一年时间制定更好的长期方案。到期后社区可以选择续期、改进或放弃。

55% 的阈值是不是太低了?

标准 BIP9 的 95% 阈值是为永久性共识变更设计的。由于 BIP-110 是紧急干预措施且是临时的,55% 的较低阈值有助于快速部署。如果大范围不受欢迎,矿工自然会拒绝信号。

为什么禁用 OP_IF/OP_NOTIF?

在 Taproot 中,条件可以链下评估,仅公开意图的验证执行路径。OP_IF 在 Tapscript 中不仅冗余,还常被滥用于注入数据。关闭这一缺口基本零成本,同时传递出此类滥用不受欢迎的信号。

为什么限制 Taproot 控制块?

之前的上限允许 2¹²⁸ 个脚本,远超任何人所需。257 字节(128 个脚本叶子)足以满足现代复杂交易。这确实可能影响 BitVM 等高级合约方案——但这类方案尚在早期开发阶段,测试网足够支撑到分叉到期。

为什么不直接靠手续费市场解决问题?

数据存储市场与支付市场激励完全不同。矿工一次性收费,但存储数据的负担永久落到了所有节点运营者身上——他们从未收到任何费用,却被强迫永远下载、存储和提供数据。当数据内容令节点运营者反感时,问题更加严重。

链上数据问题能彻底解决吗?

不能。完全杜绝数据嵌入是不可能的。该软分叉所做的,是要求想在区块链中存储大型未加密文件的用户,必须将数据伪装成金融数据并/或分割成多个数据推送。这会显著提高滥用成本,强化数据存储"不是比特币的受支持用例"这一立场。

这会导致滑坡效应吗?

不会。这些规则在共识层面虽是新的,但只是将长期以来的比特币原则编纂成文。对于货币活动的限制不会因此产生。临时性质进一步强化了这一点:如果不续期,一年后自动到期。

📝 社区调查

分享你对 BIP-110 的看法,帮助描绘中文社区的共识图景

问题 1 / 9
您之前是否听说过 BIP-110?
问题 2 / 9
您认为 BIP-110 对抵制铭文(Inscriptions)是否有必要?
问题 3 / 9
您是否支持 BIP-110 的临时性(一年有效期)设计??
问题 4 / 9
您认为 BIP-110 七项规则中哪项最有效?
问题 5 / 9
您认为 BIP-110 的 55% 算力激活阈值是否合理?
问题 6 / 9
如果 BIP-110 未通过,您认为铭文问题应如何解决?
问题 7 / 9
您对比特币上铭文(Ordinals / BRC-20)的整体态度是?
问题 8 / 9
您属于以下哪类比特币参与者?
问题 9 / 9
如果 BIP-110 以仅 55% 的较低算力阈值激活,您是否担心可能导致链分叉(chain split)?少数未升级节点可能无法跟随多数链。

📊 调查结果

BIP-110 中文社区共识图景

0
总参与人数
0%
BIP-110 支持率
0%
BIP-110 认知率
📌 数据说明:结果来自真实社区提交。数据存储于自托管服务器,同时备份在您的浏览器中。分享本链接即可汇聚更多回答。