BIP-110 想临时限制链上数据:一份已关闭提案的来龙去脉 图 1
BIP-110 想临时限制链上数据:一份已关闭提案的来龙去脉 · 图 1

BIP-110 想临时限制链上数据:一份已关闭提案的来龙去脉

先给结论

BIP-110 的正式标题是 “Reduced Data Temporary Softfork”,作者署名 Dathon Ohm,2025 年 12 月 3 日被收入 BIP 仓库编号。到 2026 年 9 月初查阅 bitcoin/bips 仓库,该文件的头部状态标记为 Closed——也就是说它没有走完流程、从未激活,网络规则没有任何变化。把结论放在最前面,是因为围绕这类提案的二手转述经常夸大其词,值得回到原文。

提案原文的规则清单

按 BIP 正文,激活后的约一年(约 52,416 个区块)窗口内,新区块要接受这些附加规则:新建输出的 scriptPubKey 超过 34 字节即无效,但首操作码是 OP_RETURN 的例外,允许到 83 字节;OP_PUSHDATA 载荷与脚本参数类的见证项超过 256 字节即无效;花费未定义见证版本(v0 隔离见证与 v1 塔普罗特之外)的输出无效;带塔普罗特 annex 的见证栈无效;塔普罗特控制块限制在 257 字节以内。激活前已存在的 UTXO 豁免,窗口到期后规则自动失效。对照铭文世界的直觉翻译一遍:塔普罗特脚本路径里塞大段封套数据的铭文,会直接撞上见证项 256 字节的天花板;依赖超长输出的实验型协议同样出局。BIP 作者在摘要里写得很直白,动机是纠正“任意数据标准化支持”造成的激励扭曲。

它为什么重要,又为什么走不动

这个提案把铭文争论里一个技术性很强的角落摆上了台面:比特币核心对 OP_RETURN 中继大小有 datacarriersize 一类的默认与可调空间,而塔普罗特封套的出现让“数据算不算标准数据”变得模糊——从共识规则看封套是脚本代码,从节点负担看它就是数据。支持临时限制的一方认为,一年窗口能让节点存储与费率激励回到“作为钱”的轨道;反对一方的批评也具体:临时软分叉会显著干扰未来协议升级依赖的未定义操作码与见证版本空间,还会误伤 BitVM 这类依赖大型脚本树的研究。这些张力在邮件列表的讨论帖里都能读到原话。

Closed 之后还剩什么

对铭文与 NFT 持有者而言,现行现实没有任何改变:封套依旧合法可花,节点运营商依旧用 datacarriersize、区块筛选策略等各自的本地配置表达偏好(比特币结类发行版把选择权交到了配置文件层面)。但 BIP-110 的出现本身是一条信号:协议圈对数据载体的耐心有明确的地板,一个带日落条款的折中方案已经被认真写成文本。关心这个话题的读者,可以把“共识级限制”“标准策略”“中继策略”“钱包 UX 提示”这四个层级分开跟踪,比追踪单个提案标题更稳定。

提示

提案状态以 BIP 仓库文件头为准,媒体转述常把“被讨论”写成“将激活”。本文陈述以 2026 年 9 月核对的仓库文本为准,后续若有变化以官方仓库为准;不构成投资建议。

三层规则的区分法

这提案给普通观察者留下的真正遗产,是逼着人把三层规则分开归类。共识层决定区块是否合法,软分叉激活才会改它;标准性层是全节点对交易形态的默认约束,历史上靠 datacarrier 一类的开关管理 OP_RETURN 数据,非标准交易被打包进块依然有效;中继与策略层最灵活,不同节点发行版用 datacarriersize 等配置项和交易过滤规则各自表态。对读者而言,把新闻稿里的每句话先映射到这三层,再看它说的是铭文不能创建、难以中继还是无法确认——三种说法对应完全不同的现实后果,混用的文本至少该打五折读。

一年日落条款的设计意图

提案里最常被忽略的是它的日落设定:附加规则在约一年、约 52,416 个区块后自动失效,激活前的存量 UTXO 全程豁免。这个结构是在尝试回答一个老问题:如何用一次可撤销的实验去纠偏激励,而不留下永久性的规则伤疤。支持者的逻辑是,与其永久封锁某类交易,不如给生态一年时间调整预期与工具链;反对者则指出,临时两个字在比特币治理史上从来不好兑现,到期后的默认状态是什么、会不会变成永久化或触发新的分裂,文本并不能给答案。把这条机制读透之后,你以后遇到任何带日落条款的提案——限制数据、调整费率、实验性 opcode——都能立刻问出同组的四个问题:窗口多长、存量豁免谁、到期默认什么、中途如何中止。四问比站队更快接近真相。