0% read
最后更新:
BIP-110
BIP-110，正式名称为 Bitcoin Improvement Proposal 110（比特币改进提案 110），是一项 Bitcoin Improvement Proposal，规定通过临时的 Bitcoin 软分叉对 Bitcoin 交易中数据字段的大小实施共识层面的限制。该提案由署名为 Dathon Ohm 的作者撰写，并于 2025 年 12 月 3 日分配编号，旨在纠正其作者所描述的因网络上任意数据存储标准化而导致的激励扭曲。其目标是通过一套设计为在大约一年后自动失效的限制措施，使 Bitcoin 重新聚焦于其货币功能。[1] 尽管它引发了短暂的少数派分叉，但 BIP-110 未能获得足够的持支持来改变 Bitcoin 主网的共识规则，并在 BIP 注册表中记录为截至 2026 年 8 月 9 日的 1.0.1 版本已关闭（Closed）。[1][5]
概述
BIP-110 源于 Bitcoin 社区内部关于在交易中嵌入非金融数据的长期争议。该提案将问题的根源追溯到其所谓的“铭文黑客攻击（inscription hack）”，该攻击于 2022 年首次被利用，开启了在交易字段内存储图像、文本和代币元数据等任意内容的趋势。[1] 从 2023 年起，包括 Ordinals、Runes 和 BRC-20 代币标准在内的协议开始大规模使用这些字段来存储非支付内容。[2]
针对这一趋势，作者认为嵌入任意数据给节点运营商带来了沉重负担，分散了开发人员对 Bitcoin 货币用途的关注，增加了交易成本，鼓励了对第三方支付处理商的依赖，并增加了审查风险。此次干预的既定目标是通过临时废除几种“数据滥用”方法，同时保留所有已知的货币使用案例功能，从而在共识层面拒绝数据存储的标准化。[1]
就现有软件而言，该提案与 2025 年 10 月发布的 Bitcoin Core v30 中所做的更改直接冲突，后者将数据限制从 83 字节提高到了 100,000 字节。BIP-110 本可以撤销这一更改，并更进一步实施更小的限制，但它最终未能吸引到在 Bitcoin 主网上采用所需的持续矿工和节点支持。[2][4]
Specification
该提案引入了七项主要的共识规则：
- 超过 34 字节的新输出 scriptPubKey 将失效，除非第一个操作码是 OP_RETURN，在这种情况下，最多 83 字节仍然有效。
- 超过 256 字节的 OP_PUSHDATA 负载和脚本参数见证项（witness items）将失效，但 BIP16 scriptSigs 中的 redeemScript 推送除外。
- 花费未定义的见证版本或 Tapleaf 版本将失效，尽管创建具有未定义见证版本的输出仍然有效。
- 包含 Taproot 附件（annex）的见证堆栈将失效。
- 大于 257 字节的 Taproot 控制区块（对应于具有 128 个脚本叶子的 merkle tree）将失效。
- 包含任何 OP_SUCCESS 操作码的 Tapscripts（即使未执行）将失效。
- 执行 OP_IF 或 OP_NOTIF 的 Tapscripts（无论结果如何）将失效。[1][4]
Rationale for the Limits
作者为 34 字节的 scriptPubKey 上限辩护的理由是，未花费的 scriptPubKey 必须无限期地存储在快速介质（通常是 RAM）上的 UTXO（未花费交易输出）集中，而大型 scriptPubKey 会导致 UTXO 集膨胀，并可能产生需要很长时间验证的“毒性区块”。OP_RETURN 输出被证明是不可花费的，因此不存储在 UTXO 集中，历史上容忍度高达 83 字节，为了避免破坏遗留协议，这一限制被保留了下来。[1]
对于数据大小限制，256 字节和 257 字节的上限辩护理由是，现代压缩技术可以用 300-400 字节表示图像，而 256 字节（2,048 位）足以满足合法密码学中使用的相当大的数字；该限制旨在阻止图像嵌入并减少滥用。[1]
禁止 OP_IF 和 OP_NOTIF 的依据是，这些操作码与 Taproot 的链下脚本评估是冗余的，并且 OP_IF 经常被滥用来注入在执行期间被跳过的垃圾信息。作者认为，暂时失去这些升级钩子并不是一个实际问题，因为软分叉通常至少需要一年的时间来协调。[1]
对于规则 3，规范列举了仍可花费的见证版本：根据 BIP 141，具有 20 字节程序 (P2WPKH) 或 32 字节程序 (P2WSH) 的版本 0；根据 BIP 341，具有 32 字节程序 (Taproot/P2TR) 的版本 1，其中唯一定义的 Tapleaf 版本是根据 BIP 342 的 0xc0 (Tapscript)；以及版本 1 具有 2 字节程序 0x4e73（BIP 433 中定义的临时锚点输出 P2A），仅可使用空见证堆栈花费。[1][4]
Deployment Mechanism
BIP-110 使用了 BIP 9 矿工信号机制的修改版本，部署名称为 "reduced_data"，信号位为 4。[1]
与标准的 BIP 9 相比，该机制在几个方面有所不同。它使用了降低的激活阈值，即每 2,016 个区块中需有 1,109 个（55%），而不是惯例的 95%，理由是该软分叉是临时且紧急的。它不依赖传统的超时，而是依赖最大激活高度，在高度 963,648 转换为 LOCKED_IN 状态，然后在 965,664 转换为 ACTIVE。[1]
部署还引入了一个新的终止状态 EXPIRED，一旦区块高度达到激活高度加上激活持续时间，就会进入该状态，之后规则将自动停止执行。完整的状态机运行流程为 DEFINED → STARTED → LOCKED_IN → ACTIVE → EXPIRED，由于禁用了超时，永远不会达到 FAILED 状态，且过期后的矿工信号没有影响。[1][3]
Activation and Chain Split
强制信号窗口在区块 961,632 开启，根据独立报告，日期为 2026 年 8 月 7 日，而根据提案自己的网站，日期为 UTC 时间 2026 年 8 月 8 日 20:12。[2] 从该高度开始，执行 BIP-110 的节点开始拒绝任何未发出支持信号的区块，这导致这些节点分叉到了一个少数派链上。[2]
矿工的支持远低于 55% 的要求。在窗口开启前的难度周期内，2,016 个区块中只有 51 个（2.53%）发出了支持信号。[2] 通过 Ocean Pool 运营的 Barefoot Mining 在 2026 年 3 月 1 日挖掘了第一个 BIP-110 信号区块，并被描述为唯一的有组织信号努力；F2Pool 公开拒绝发出信号，截至 2026 年 7 月，没有其他主要矿池加入，使得支持率低于总算力的 1%。[2]
相比之下，该提案自己的网站报告称分叉已经激活，声称额外的交易规则在 2026 年 8 月 30 日的区块 961,640 连同一个名为 Blake2b 的硬分叉一起生效，并且 Bitcoin Knots v29.4.1 等 Bitcoin节点继续运行并挖掘新区块。[1] 实际上，执行 BIP-110 的少数派链在少量区块后停滞，而被主要交易所、托管机构和基础设施提供商认可为 Bitcoin 的 Bitcoin区块链继续沿着非 BIP-110 链运行。[2] 支持者后来通过引入基于 Blake2b 的工作量证明算法并将区块大小限制降低到 300 kB，在另一个网络上恢复了少数派分叉，将其定位为一个独特的链，而不是 Bitcoin 的升级。[6]
在官方记录中，BIP 的注册条目显示，在链分叉和挖矿停滞后，其状态于 2026 年 6 月 25 日更改为 1.0.0 版本的“完成（Complete）”，随后于 2026 年 8 月 9 日更改为 1.0.1 版本的“关闭（Closed）”。[1][5] 如果这些规则得以维持，原定于 2027 年 9 月 1 日左右过期，届时所有限制都将自动解除。[1]
Reception and Opposition
BIP-110 的作者署名为 Dathon Ohm，长期的 Bitcoin Core 贡献者 Luke Dashjr 被认为提供了原始草案和技术投入。Dashjr 公开为该提案辩护，并拒绝了撤回该提案的呼吁。[2][1]
支持者认为，Bitcoin 被设计为点对点电子现金，区块空间应该为这一目的服务。他们认为 Ordinals 和 Runes 活动会导致费用飙升——高峰期平均每笔交易费用超过 100 美元——并将一年的限制描述为一个冷静期，以便为长期解决方案争取时间。[2]
反对意见分为几类。在经济层面，批评者认为任何支付费用的交易都是合法的，限制访问开创了一个危险的先例，这一立场在一定程度上与 Michael Saylor 相关，他将 BIP-110 描述为 Bitcoin “最大的自残风险”。在技术层面，Adam Back 等人指出了他们认为在激活机制、字节限制和变通方法中存在的致命设计缺陷，Back 将多个组件分别描述为“致命的”。在治理层面，Bitcoin Core v30 的相反变化被解读为缺乏广泛开发者共识的信号，且 Bitcoin Core 维护者并未认可该提案。在安全层面，反对者警告说，减少来自 Ordinals 和 Runes 的费用收入可能会随着区块补贴减半而影响矿工经济和网络的长期安全。[2]
发现错误了吗？
