BIP-110 规范（中文译本）

这份提案想解决的问题是：比特币区块链不应该变成“任何数据的存储盘”，因为这会让运行节点的人承担额外成本，也会抬高转账费用。BIP-110 提议在共识层暂时限制可以嵌入区块的任意数据大小，确保比特币继续以“货币网络”为核心目标。

具体来说，它会在一年内限制输出脚本和见证数据的大小，并临时禁用一些容易被用于塞数据的 Taproot 形式。同时，BIP-110 明确保护已存在的资金：在激活前创建的 UTXO 不受新规则影响。

这是一项临时软分叉：激活后约一年这些限制自动失效。支持者认为它能为比特币争取时间，避免数据滥用牵引社区方向；反对者则关注它对新功能的限制。无论立场如何，理解它的规则与权衡都很重要。

为了保护比特币作为互联网原生货币的预期功能，比特币社区历史上一直对在交易中嵌入任意数据的技术保持警惕甚至反对。

必须始终抵制此类数据嵌入，以免它变成网络的依赖并产生负外部性，尤其会给节点运营者带来负担。

自 2022 年“铭文”（inscription）漏洞被利用以来，在比特币交易中嵌入任意数据的趋势迅速出现，为节点运营者带来明显且不必要的负担，同时将开发重点与激励从比特币作为可靠、无许可、无国界货币的核心目的上转移。

本提案旨在通过拒绝将数据存储标准化为共识层支持的用例，让比特币回到成为全球货币的轨道。

它通过共识临时否定若干最具破坏性的滥用方式，同时保留所有已知的货币用途。

具体而言，本提案会使所有连续嵌入超过 256 字节任意数据的方法无效；同时使几乎专用于数据嵌入的大型 scriptPubKey 与 Tapleaf 形式无效；并在共识层恢复长期存在的 OP_RETURN 83 字节策略限制。

在软件开发中，禁用不受支持的用例是常见做法，否则会迅速变得不可持续并导致开发停滞。

因此，这些新规则的激活向外界释放了明确讯号：任意数据存储会持续被抵制，不应被允许拖偏网络的优先事项。

它也强化了比特币作为抗审查支付系统的核心功能，因为数据存储与支付不公平地竞争区块空间，使支付成本被不必要地抬高。这会鼓励用户依赖第三方支付处理器，从而让支付更容易被审查。

最后，它通过重新强调降低节点运营成本的长期承诺，提高节点网络的去中心化程度。

比特币应当“只做一件事，并把它做到最好”。拒绝数据存储后，本 BIP 将开发者从无止境的范围蔓延中解放出来，使他们能聚焦最关键的目标：比特币作为货币的成功。

有什么权衡吗？

1. 将 Taproot 控制块限制为 257 字节会直接约束链上脚本树大小，这可能会复杂化甚至阻碍依赖大量可执行脚本的高级智能合约（如 BitVM）。在最坏情况下，这些用例可能需要等到软分叉到期。由于它们仍处于早期开发阶段，未来一年使用测试网或侧链应足够。
2. 升级钩子无法用于其他软分叉。由于新增操作码的软分叉通常需要至少一年才能激活，这不太会成为现实问题。
3. 一些钱包（如 Miniscript）习惯创建包含 OP_IF 的 Tapleaf。为降低资金被冻结一年的风险，本提案豁免花费激活前创建的输出，并在锁定与激活之间提供两周宽限期。

Taproot 控制块限制是否过于严格？

可能是。此前的限制允许 340,282,366,920,938,463,463,374,607,431,768,211,456 个脚本，这显然远超任何实际需求。257 字节允许 128 个脚本，足以覆盖现代复杂交易。

但它可能对 BitVM 等高级链下功能过于严格。这是我们为了短期收益不得不接受的取舍。如果软分叉被接受，意图是在过期后放宽这一限制，并采用尚未提出的新方法允许更大的树。

需要注意的是，taptree 的非脚本用途（或非比特币 L1 脚本）并不受此限制：128 个叶子中的任意一个都可以扩展成比本软分叉限制更深的默克尔树。

Taptree 本来就应当是不平衡的吗？

优化的 taptree 往往会偏向更可能执行的脚本，但这只是可选；如果需要，仍可以使用完整容量（本例为 128 个脚本）。

此外，在理想情况下，taptree 或其默克尔分支根本不会发布：各方应在链下评估花费条件并通过 keypath 重新广播交易。

Tapscript 主要用于一方不可达或不合作的情况；它的存在通常只是为了让故意不合作变得没有意义。一个例外是使用 NUMS 点来限制输出只能通过脚本路径花费的协议。

资金会被冻结或丢失吗？

理论上可能。本提案尽最大努力避免影响已知用例，并有充分理由相信不会影响任何人。但确实存在一些涉及预签名 Taproot 交易的实验用例可能受影响。

具体而言：

• OP_IF/OP_NOTIF 限制可能临时使当前版本的 Miniscript 编译器生成的某些边缘 Tapleaf 无效。目前没有已验证的生产用例，但某些流行钱包理论上可能生成它们。
• Taptree 深度限制会使深度超过 7 层的 Tapleaf 无效。由于常见花费条件通常放在树的上层，因此这些资金几乎总是可通过上层 Tapleaf 轻松花费。

在两种情形中，资金可以通过树中的其他 Tapleaf 或 keypath 花费（除非 keypath 被 NUMS 点明确失效）。

只有满足以下所有条件，资金才可能被冻结或丢失：

• UTXO 为 pay-to-Taproot（P2TR）；
• UTXO 位于预签名交易中；
• UTXO 必须在一年部署期内被确认且花费；
• 用户选择的 Tapleaf 包含 OP_IF/OP_NOTIF 或深度超过 7；
• keypath 无法用于花费，并且树中没有其他可用 Tapleaf（则资金被冻结）；或存在可用 Tapleaf 但产生意外花费（则资金丢失）。

换言之，资金完全不受影响的情形包括：

• 不使用 Taproot；
• 以标准、常见方式使用 Taproot；
• 部署期间需要使用的 UTXO 在激活前确认；
• 预签名交易未使用违反新规则的 Tapleaf；
• 即便使用违反新规则的 Tapleaf，也无需在部署期内同时确认并花费；
• 即便必须在部署期内确认并花费，也可通过 keypath 或树中其他 Tapleaf 花费。

本提案尽力避免资金被冻结或丢失，但无法证明绝对无人受影响。因此是否激活，取决于社区是否认为拒绝数据存储值得这份权衡。

为激活做好准备，建议用户现在开始迁移可能受影响的资金。若激活通过，锁定与激活之间将至少有两周的缓冲期，留给用户迁移剩余资金。

为什么不让手续费市场管理数据存储？

手续费市场用于根据经济紧迫性优先排序交易。然而，链上数据存储与支付属于完全不同的市场，激励结构也不同。

货币交易的手续费激励矿工打包一次性支付，矿工提供的是一次性支付的安全确认服务。支付确认后，支付方并不会从网络中获得更多收益，除了维护交易历史的完整性（这是所有节点运营者愿意承担的，因为否则比特币无法作为货币运行）。

相反，数据存储的手续费仍只支付给打包该数据的矿工，但存储负担落在所有节点运营者身上，他们没有得到手续费却需要永久下载、存储并提供这些数据。

这意味着矿工获得一次性费用，节点却被迫无偿提供高可用、不可审查的数据存储服务，尤其当内容令人反感时，节点的负担更大。

OP_RETURN2/“blobspace” 让节点可选存储如何？

这类方案过去已多次尝试。再次尝试也无妨，本提案并不阻止它。但这些方案依赖发送者配合，而发送者通常希望强制内容进入不愿意的节点（否则早就用其他分发方式）。此外，它们也无法解决令人反感内容的问题。

为什么不禁用 PUSHDATA 操作码/取消见证折扣/只限制 annex 长度/限制整体见证或交易大小/让软分叉永久/让 OP_RETURN 更便宜？

这些都是有趣的想法，但会增加实现复杂度。本提案优化目标是简单且易审查，以便快速部署。若社区决定尝试这些方案，本提案鼓励在它到期后再推进。

为什么不去掉一部分限制？

本提案在不增加复杂度的前提下，尽可能强烈地否定“任意数据存储”用例。放松任何规则都会降低达成目标的效果，而收益有限。

垃圾交易不应该在中继策略中解决吗？这是否意味着策略无效？

策略仍是对抗垃圾交易的最佳位置，但它无法保证 100% 有效，尤其当恶意行为者是矿工时。软分叉能降低这类极端风险。

这能彻底解决垃圾交易吗？

不能。垃圾交易不可能完全消除，通常应靠策略和过滤来处理。软分叉的作用是要求那些想存储大文件的人把数据伪装成金融数据或拆分成多个数据推送。即便发生，这也应被视为滥用，而本 BIP 强化了数据存储不是受支持用例的结论。

为什么不处理非比特币代币？

非比特币代币种类繁多，很多是骗局吗。它们更适合在策略层处理，而本提案也不试图彻底消除垃圾数据。

这是否是滑坡？今天禁数据，明天会禁我们不喜欢的用例吗？

不会。这些规则虽然是共识层的新规则，但它们只是把长期原则写入共识，以应对去中心化与货币用途的系统性威胁。

软分叉不试图限制货币活动或交易有效性。通过尽可能限制数据存储用例，它强化了比特币作为可靠、无许可货币的长期保障。

将系统性风险与货币用途严格区分，为未来过度干预提供了清晰防线。

软分叉明确是临时的，也再次强调这是针对特定危机的干预，而非新的发展方向。如果你不采取后续行动，它将在一年后过期。即便未来有跟进提案，你仍可选择拒绝。

这会破坏用户空间吗？

会。本提案刻意破坏了“数据存储”用户空间，以表达该用例不受支持。我们尽力避免破坏货币用例，虽然理论上仍可能影响，详见“权衡”部分。

在极少数场景下，资金理论上可能被冻结或丢失，详见“权衡”部分。

如果本提案激活，Miniscript 编译器需要在规则生效期间避免生成违反新规则的脚本。

在比特币链上存储任意数据的用户应开始寻找其他存储方式，例如 Nostr、IPFS、BitTorrent、云存储等，因为比特币网络将不再支持该用例。

其他所有已知用例不受影响。

阈值降低（55% 而非 95%）：标准 BIP9 的 95% 阈值适用于永久共识变更，需要几乎全体矿工准备就绪。由于拒绝数据存储具有紧迫性且软分叉仅为期一年，更低阈值更合理。

无 timeout，改用 max_activation_height：标准 BIP9 在未达阈值时会基于时间转为 FAILED。本部署将 timeout 设为 NO_TIMEOUT，并使用类似 BIP8 的高度上限 max_activation_height。在高度 963648（距离 max_activation_height 前一个难度周期）进入 LOCKED_IN，并在高度 965664 进入 ACTIVE。

强制信号期：类似 BIP8，本部署在强制锁定前的一个难度周期内要求强制信号（区块 961632 到 963647；锁定不晚于 963648）。在此窗口内，不发出 bit 4 信号的区块会被判无效。强制信号在进入 LOCKED_IN 后结束。

通过 active_duration 过期：标准 BIP9 在 ACTIVE 后永久有效。本提案引入 active_duration（52416 个区块，约 1 年），使部署为临时而非永久。状态机仍停留在 ACTIVE，但共识规则只对高度小于 activation_height + active_duration 的区块生效。超过 52416 个区块后，规则不再执行，UTXO 再次不受限制。

状态转换：状态机流程如下：

1. DEFINED：starttime 前的初始状态。
2. STARTED：starttime 之后；矿工可用 bit 4 发信号。
3. LOCKED_IN：当上一周期达到阈值后，在下一个难度周期起始进入；强制信号（961632-963647）确保不晚于 963648 进入。
4. ACTIVE：LOCKED_IN 之后一个难度周期进入；规则在 active_duration 内生效。

timeout 被禁用，因此不会进入 FAILED。ACTIVE 为最终状态；之后不再有状态转换。到期后矿工继续发信号也不会产生影响，因为部署已不在 STARTED 状态，信号只影响 STARTED → LOCKED_IN 的转换。active_duration 结束后，部署仍处于 ACTIVE，但规则不再执行。状态机中没有单独的 EXPIRED 状态。