协议演进 / BIP/比特币改进提案 / BIP-54
BIP-54
把四项长期存在的共识弱点打包一次修好：堵 timewarp 攻击、限制单笔交易的签名操作数以压缩最坏情况的区块验证时间、禁用 64 字节交易、用 coinbase 的 nLockTime 保证 coinbase 不重复从而永久免除 BIP-30 校验。本 BIP 目前处于已完成状态。
一、档案卡
| 编号 | BIP-54 |
|---|---|
| 标题 | Consensus Cleanup |
| 作者 | Antoine Poinsot <[email protected]>, Matt Corallo <[email protected]> |
| 指定日期 | 2025-04-11 |
| 层级 | Consensus (soft fork)（共识（软分叉）） |
| 类型 | Specification（规范类） |
| 状态 | Complete（已完成） |
| 阅读版 | https://bips.dev/54 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0054.md |
二、放在哪一族
“共识清理”族：不加新功能，只修长期存在的共识弱点，并把部署软分叉的固定成本一次摊掉——这正是原文说明的打包理由。
它与几份文档直接相关：
- BIP-53：单独论证“禁止 64 字节交易”的一份草案，本 BIP 把同一修复作为四条规则之一收进来；
- BIP-30：防止重复 coinbase 覆盖未花费输出的校验，本 BIP 要让它可以被永久免除；
- BIP-34：coinbase 中写入区块高度；本 BIP 的 coinbase 改造与它早年的违规情形直接相关；
- BIP-16：本 BIP 的签名操作计数方式沿用其规范的算法；
- BIP-94：原文提到，testnet4 的 timewarp 修复采用了另一种宽限期方案。
原文还说明，本文件建立在 Matt Corallo 一份更早的提案之上。
三、它要解决什么
原文列了四个长期问题：
3.1 timewarp 攻击
难度调整的时间戳规则有漏洞（timewarp bug）：掌握多数算力的攻击者可以任意压低挖矿难度、任意加快出块速率。原文给出的最坏情形是：攻击开始后 38 天内，难度可被压到最低。它还让矿工激励更难推理：加快出块等于从未来矿工手里偷走区块补贴、并扩大可用区块空间，短视的用户与矿工可能有动机去利用它。
原文同时一并处理了相关的 Murch–Zawy 变体：难度调整周期的时长不应为负，这一修复风险极低。
3.2 最坏情况的区块验证时间太长
特制区块可以贵到离谱：原文说，在高端设备上验证可能要数分钟，在低端设备上可达数小时。验证慢抬高了独立全量验证的成本；矿工还能用它攻击竞争对手，造成歪曲的激励、中心化压力与网络安全性下降。
3.3 Merkle 树弱点
一笔非见证数据恰好 64 字节的交易，既可被解释为 Merkle 树的中间节点，也可被解释为叶子节点。攻击者可借此诱使 SPV 验证者接受一笔根本不在区块中的交易的包含证明。让 64 字节交易无效，是从根源上处理，不要求 SPV 用户知道还要采取某种变通办法。
3.4 BIP-30 校验的去留
自 BIP-34 激活后，在区块高度 1,983,702 之前显式的 BIP-30 校验并无必要；但此后若恢复该校验，会平白增加区块验证开销，也会排除 Utreexo（BIP-182 所述）等替代全节点设计。若能保证新 coinbase 交易必然不同于早期违反 BIP-34 的那些 coinbase，就可以永远免除 BIP-30 校验。
四、规则本身
激活之后的新区块须遵守以下四组规则。
4.1 难度调整周期首尾区块的时间戳下限（修 timewarp）
设区块高度为 N：
- 若
N % 2016 == 0（周期首块）：其时间戳必须 ≥ 高度 N−1 区块的时间戳 − 7200 秒，即留出 2 小时宽限； - 若
N % 2016 == 2015（周期尾块）：其时间戳必须 ≥ 高度 N−2015 区块的时间戳。
原文说明：更早的修复方案用过 10 分钟宽限，testnet4 也采用过类似做法；此处出于谨慎改用 2 小时，因为它只让攻击下的出块间隔期望值恶化约 2.2 秒，却能避开不守规矩的矿池软件造出无效块的风险。
4.2 单笔交易的签名操作数上限（压缩最坏验证时间）
对区块内除 coinbase 外的每笔交易：逐个输入统计其 scriptSig 与被花费输出的 scriptPubKey（含 P2SH 的 redeemScript）中的签名操作数——CHECKSIG／CHECKSIGVERIFY 各计 1；CHECKMULTISIG／CHECKMULTISIGVERIFY 若紧跟 OP_1 到 OP_16 则计 1 至 16，其余情形计 20；无论是否实际执行都计数。全交易各输入合计严格大于 2500 时，该交易无效。
计数方式与 BIP-16 的规范相同，三个脚本部分分开评估。原文称这一上限把最坏情况区块验证时间降低到原来的约 1/40，并大幅抬高攻击的准备成本；2500 是“不使任何非病态的标准交易无效”的最紧取值。
4.3 64 字节交易无效
去掉见证后的序列化大小恰好为 64 字节的交易无效。原文补充背景：这类交易只能带有“谁都能花”或“销毁”的 scriptPubKey，自 2019 年起已属非标准，自 2016 年起再未被使用过。
4.4 coinbase 的 nLockTime 与 nSequence（免除 BIP-30 校验）
coinbase 交易的 nLockTime 字段必须设为区块高度减 1，其 nSequence 字段不得等于 0xffffffff。
原理是：nLockTime 本来是存区块高度的自然位置，且 coinbase 此前并不使用它；这样强制后，同一笔 coinbase 交易不可能曾在先前区块中有效出现——同一检查自成一体，激活后无论 BIP-34 的激活状态如何，都可以彻底跳过 BIP-30 校验。应用还可直接从 nLockTime 读出区块高度，无需解析脚本。
4.5 向后兼容
原文明确：本提案只是收紧区块验证规则——不存在“按新规则有效、按现行共识规则无效”的区块，因此与未升级的节点软件向后兼容；但作者强烈建议节点运营者升级，以完整验证全部共识规则。
原文还记录了若干“矿工前向兼容”的事实：Bitcoin Core 29.0 及以后不会生成违反本 BIP 时间戳限制的区块模板；30.0 及以后不会生成包含违反签名操作上限交易的模板；0.16.1 及以后既不中继、也不生成包含 64 字节交易的模板。coinbase 通常由矿池软件构造，原文呼吁矿池更新软件，按新规构造前向兼容的 coinbase。
五、谁必须动
普通持币人：无直接动作。正常交易离 2500 个签名操作的上限很远，也不会是 64 字节。
钱包开发者：基本无变化；原文选择“限制签名操作数”而非禁用某些脚本操作，正是为尽量不影响既有脚本用法与预签名交易。
全节点：作者强烈建议升级，以完整验证新规则。未升级节点仍与新链兼容（新规则只是收紧），但它们不会执行新增的检查。
矿工与矿池：要留意区块模板的时间戳（应使用 getblocktemplate 的 curtime／mintime，原文指出这本就是既有要求），并更新构造 coinbase 的软件，使 nLockTime 等于高度减 1、nSequence 不为 0xffffffff。
共识层：这是四项收紧合一的软分叉式变更。
六、现在算不算数，以及一个常见误读
状态为 Complete（已完成）：指这份提案文档本身的工作已经完成，现行流程下 Complete 不等于已经在主网激活部署。本页只按原文记述其规则与状态，不宣称它已经生效。
常见误读：
“四项修复打包在一起，等于要把从前的某些区块或交易判为无效、搞一次清算式重写。”
不对。原文的向后兼容一节说得很清楚：新规则全是收紧——只会让“未来某些原本可能有效的区块”变为无效，不存在按新规有效、按旧规反而无效的区块，更不追溯既往。它修的是未来的验证规则，不是改写历史。
七、延伸
- 阅读版：https://bips.dev/54
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0054.md
- 相关：BIP-53 禁止 64 字节交易、BIP-30、BIP-34、BIP-16、BIP-94
- 仓库总目录：https://github.com/bitcoin/bips