BIP 110 的标题是 Reduced Data Temporary Softfork，是一项已关闭的提案，旨在暂时收紧节点接受区块的规则。节点是独立核查历史记录和支付的计算机。提案希望提高某些数据存储方式的难度，并在支持者看来强化比特币的货币用途。但这并不会自动让它成为整个网络的规则。
设想两位节点运营者收到同一个区块。一位按照原有规则接受它，另一位却因新增限制将其拒绝。BIP 110 触及的正是这一层：它会改变区块是否有效，而不只是节点是否愿意转发交易，或将其留在 mempool，也就是本地等待确认的交易队列中。2026-10-23 核查时，规范版本 1.0.1 的状态为 Closed，即已关闭。获得 BIP 编号或发布客户端，都不是网络采纳的证明。提案登记库保存文档及其历史，并不会远程切换各节点的规则。 [1] [2]
每个新交易输出都有 scriptPubKey，即规定以后如何花费该输出的脚本。提案允许其最多为 34 字节；如果以 OP_RETURN 开头，则最多为 83 字节。OP_RETURN 会使输出成为可证明无法花费的输出，计算长度时要计入整个脚本。另一个 256 字节限制适用于各项 OP_PUSHDATA* 数据载荷，以及 witness 中的参数项；witness 是验证花费时附带的信息。按照 BIP16 在 scriptSig 中压入 redeemScript，也就是公开的花费条件脚本，是一个例外。Witness scripts 和 Tapleaf scripts 本身不是这些参数，但其中压入数据的指令仍受限制。这里限制的是特定组成部分，并不是交易或整个 witness 的总长度。 [1]
限制还涉及 Taproot 这种表达花费条件的方式。提案禁止花费未定义的 witness 或 Tapleaf 版本，却不禁止创建此类输出。它还禁止附加字段 annex，以及超过 257 字节的 control block；后者是证明脚本属于已承诺结构的证据，限制针对过长的证明。Tapscript 中不得出现 OP_SUCCESS*，即使所在代码不执行也不行；也不得执行 OP_IF 或 OP_NOTIF，无论条件结果如何。作为技术对照，规范列出的已定义格式包括 P2WPKH、P2WSH、Tapleaf 版本为 0xc0 的 P2TR，以及程序为 0x4e73 的 P2A，最后一种仅允许空 witness 栈。这些是精确的格式名称，不是普通用户需要在钱包里填写的项目。 [1]
UTXO 是尚未花费的交易输出：一笔特定金额，以及使用它的条件。提案豁免花费激活前已确认 UTXO 的输入。但这不意味着同一交易中新建的输出也可以不受限制。提前签名同样不能保护在规则生效期间才创建的输出。对于某些预签名 Taproot 结构，规范承认存在资金冻结或损失的可能：限制使预定花费路径失效，且没有可用的替代路径。这也关系到 Miniscript 这种构建花费条件的工具，以及 BitVM 这类验证计算的结构。因此，不能保证影响只限于非货币数据。 [1] [3]
矿工可以在区块中表达支持：这里使用 bit 4，门槛是 2016 个区块中的 1109 个，约为 55%。但提案不只依靠自愿信号。如果此前没有达到门槛，它要求在高度 961632–963647 强制发出信号，随后从 963648 进入 LOCKED_IN，从 965664 进入 ACTIVE，前提是相关链确实到达这些高度。高度就是区块在链中的位置。LOCKED_IN 表示转换已确定，ACTIVE 才表示实际执行数据限制。客户端在强制信号期间就会拒绝不带信号的区块，因此节点可能在数据限制启用前已经分道扬镳。这些限制计划从实际激活起持续 52416 个区块，随后进入 EXPIRED 并停止执行，并非精确的一个日历年。 [1] [4]
支持者希望降低节点运营成本、减轻 UTXO 集合的压力、减少不需要的内容，并优先保障支付。这解释了动机，却不能证明效果。批评者指出对有用脚本、未来升级的影响，以及网络分裂的风险。数据也可以拆成更小的片段：在最初讨论中，Peter Todd 展示了一笔用这种方式容纳当时完整提案的交易。规范本身也不承诺彻底杜绝隐写术，即把信息藏在其他数据之中。提高存储成本与完全阻止存储，是两个不同的结果。同样，对内容法律责任的担忧，本身并不能证明某项具体法律义务。 [1] [3]
PR 2247 的记录描述了 2026-08-08 在高度 961632 发生的分裂。主链包含一个没有所要求信号的区块，而 OCEAN 挖出了带信号的替代区块。2026-08-09，Murch 在讨论中称，少数派分支只产生了 2 个区块便停滞，主链则前进了超过 100 个区块。阅读这种报告时，需要保留日期和作者：这不是本文独立重放区块链得出的结论，也不是对少数派分支当前状态的说明。它还说明，因信号要求发生分裂，不能等同于已达到 ACTIVE 或已经开始执行数据限制。 [5] [6]
文档曾进入 Complete，即规范完成，最终状态为 Closed。关闭提案的 PR 2245 于 2026-08-10 合并，而规范变更记录标注 2026-08-09。这两个日期属于不同记录，不表示另一次激活。客户端版本 v0.4.1 记载了 EXPIRED 和 vbrequired；后者是区块模板中标明强制信号位的字段。该客户端存在，不代表 Bitcoin Core 已采纳提案。还可以找到 test vectors，也就是带预期结果的示例交易，以及功能测试。本文并未运行它们，也未验证少数派链的当前状态。这里的目的，是说明提案及其有记录的经历，而不是把历史文档当成网络今天共同遵循的规则。 [7] [1] [4]
要获得更完整的理解，请将本词条与以下词条结合阅读： Soft Fork, Full Node, Taproot, Bitcoin Script, Transaction Fees, UTXO. 反向关联还来自： OP_RETURN.
01Closed 是否意味着任何人都不能再运行该客户端？+
Closed 是文档状态，不是软件使用禁令。节点执行自身软件中的规则。但选择不同规则可能让节点进入另一条分支；关闭登记条目并不会消除这种差异。
02强制信号期间是否已经执行数据限制？+
没有。强制信号先于 LOCKED_IN 和 ACTIVE。客户端可以在数据规则开始前，就拒绝没有所要求信号的区块。因此，仅凭日历日期不足以判断；还要看具体链的状态和高度。