协议演进 / BIP/比特币改进提案 / BIP-323
BIP-323
把区块头 nVersion 中预留给矿工的位从 16 位扩大到 24 位，作为额外 nonce 空间，供仅处理区块头的挖矿方式使用。本 BIP 目前处于草案状态。
一、档案卡
| 编号 | BIP-323 |
|---|---|
| 标题 | 24 nVersion bits for general purpose use |
| 作者 | Matt Corallo <[email protected]> |
| 指定日期 | 2026-04-22 |
| 讨论日期 | 2026-02-26 |
| 类型 | Specification（规范类） |
| 状态 | Draft（草案） |
| 取代文档 | Replaces: BIP-320 |
| 阅读版 | https://bips.dev/323 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0323.mediawiki |
二、放在哪一族
区块头与软分叉信号族，是 BIP-320 的直接续篇，档案上以 Replaces 标记取代 BIP-320。BIP-320 把 nVersion 的 16 位划作矿工通用空间；BIP-323 认为这片空间已经被硬件实践证明不够用，主张扩大到 24 位。
同族的相关文档：
BIP-9：Version bits 信号机制；预留位正是从它的含义范围中划出
BIP-8：Version bits 的另一种部署参数，同样被本 BIP 点名移除预留位
BIP-310：Stratum 协议扩展；矿工与矿池协商滚动哪些位，走的是这片预留空间
三、它要解决什么
3.1 16 位不够用，硬件已经在借 nTime 的位
原文动机说得具体：BIP-320 把 16 位 nVersion 定义为额外 nonce 空间，但事实证明这还不够——一些设备已经开始动用 nTime 中的 7 位作为额外 nonce 空间。原文据此判断：在 nVersion 里留 16 位给信号用途，实际效用有限；不如在 nVersion 里给出 24 位作为额外 nonce 空间。
3.2 为什么借 nVersion 优于借 nTime
原文的设计理由落在“仅处理区块头”的挖矿方式（headers-only mining）上：这种方式让挖矿设备（ASIC 或其固件）不必操心庞杂的共识逻辑（处理交易、默克尔树等），已在 ASIC 中广泛部署；但它需要控制器向整台设备大量下发任务、使控制器繁忙。若 ASIC 能滚动的 nonce 空间更大，就不必频繁向控制器索要新任务，ASIC 设计可以有所简化。原文指出，业界已经用占用 nTime 额外空间的办法在做这件事，而把这件事改在 nVersion 里做，要优于占用 nTime。
四、规则本身
4.1 预留范围与掩码
区块头 nVersion 字段中第 5 位到第 28 位（含两端）、共 24 位（0x1fffffe0）预留为 nonce 用途，并从 BIP-8 与 BIP-9 的规范中移除。判断软分叉信号时应对 nVersion 施加掩码 0xe000001f，使第 5–28 位对软分叉信号与未知软分叉警告一律被忽略。
与 BIP-320 对照：后者预留第 13–28 位、掩码 0xe0001fff；本 BIP 把下界从第 13 位放宽到第 5 位，多划入 8 位，信号可用的低位只剩第 0–4 位一带（连同最高三位由掩码保留）。
4.2 向后兼容
原文给出的兼容性结论与 BIP-320 同构：
- 未升级的节点会把这些预留位解释为软分叉信号，并可能触发未知软分叉警告系统；
- 原文写道：在写作时，没有正在积极信号的软分叉在使用本 BIP 预留的 24 位中的任何一位；未来的软分叉不应使用这些位做激活信号。
4.3 致谢里的一条线索
原文致谢提到：Timo Hanke 与 Sergio Lerner 最早提出 15 位的额外 nNonce2；BtcDrak 写了 BIP-320。这条线索说明，“在区块头里为矿工多留滚动空间”是一个持续多年的议题，本 BIP 是它目前最新的一份文本。
五、谁必须动
普通持币人：无事可做。与 BIP-320 一样，这只关乎区块头位的解释，不涉及钱包与交易。
全节点：主要行动方是节点软件——在评估 version bits 信号与未知软分叉警告时，对 nVersion 施加新掩码 0xe000001f，忽略第 5–28 位。未升级节点不影响共识跟随，只是可能把正常的矿工滚动误读为未知软分叉信号。
全节点与矿工：矿工与矿机固件获得更大的可滚动空间（24 位），可以减少为索取新任务而与控制器往返的频率；与矿池之间具体滚动哪些位，仍经 BIP-310 的 version-rolling 协商确定。
共识层：本 BIP 不改变区块有效性规则。它改的是信号解释约定：哪些位还承载软分叉投票含义，哪些位自此只是矿工的 nonce 空间。
六、现在算不算数，以及一个常见误读
状态为 Draft（草案）。它与被它取代的 BIP-320 同为草案，两份文本都未成为生效规则；现行有效的信号解释仍以节点软件实际实现为准。本 BIP 的价值在于记录了硬件实践对协议空间的最新诉求：16 位已不够，设备宁愿去借 nTime——提案把这股压力引回 nVersion 里解决。
常见误读：
“预留 24 位，等于今后软分叉只剩下几位可用，升级之路被堵死了。”
原文并不这样定性。它给出的事实前提是：写作时没有正在积极信号的软分叉使用这 24 位，且在 nVersion 里为信号保留 16 位的实际效用有限。与此同时，把矿工滚动从 nTime 引回 nVersion，避免的是时间戳空间被侵蚀。是否接受这一取舍属于社区对草案的讨论范围，本 BIP 本身尚在 Draft，不能读成既成事实。
七、延伸
- 阅读版：https://bips.dev/323
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0323.mediawiki
- 相关：BIP-320 nVersion 位通用（被本 BIP 取代）、BIP-310 Stratum 协议扩展、BIP-9 Version bits
- 仓库总目录：https://github.com/bitcoin/bips