协议演进 / BIP/比特币改进提案 / BIP-320
BIP-320
把区块头 nVersion 的第 13–28 位共 16 位预留为通用用途，并将它们移出 version bits 软分叉信号的含义范围。本 BIP 目前处于草案状态。
一、档案卡
| 编号 | BIP-320 |
|---|---|
| 标题 | nVersion bits for general purpose use |
| 作者 | BtcDrak <[email protected]> |
| 指定日期 | 2018-03-01 |
| 类型 | Specification（规范类） |
| 状态 | Draft（草案） |
| 接替文档 | Proposed-Replacement: BIP-323 |
| 阅读版 | https://bips.dev/320 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0320.mediawiki |
二、放在哪一族
区块头与软分叉信号族。区块头的 nVersion 字段一身二任：一边是版本号本身，一边自 BIP-9 以来被 version bits 机制借用作矿工软分叉信号位。BIP-320 处理的正是这两任之间的冲突：把一部分位正式划出信号用途，留给矿工自由使用。
它的上下游关系清楚：
BIP-9：Version bits with timeout and delay，信号机制本身
BIP-8：Version bits with lock-in by height，另一套部署参数
BIP-310：Stratum 协议扩展；矿工与矿池协商滚动哪些位，走的就是本 BIP 划出的这片空间
BIP-323：本 BIP 的提议接替者，把预留从 16 位扩大到 24 位
三、它要解决什么
3.1 矿工想用这些位，节点却会误报
原文动机说得很直接：矿工出于各种目的想使用 nVersion 字段的一些位；但因为这些位被用来协调矿工激活的软分叉，全节点软件在这些位被用于软分叉信号以外的目的时，会发出“未知软分叉”的误报警。
解法不是禁止矿工用，而是先把一部分位预留给通用用途，再让节点软件更新为忽略这些位，从此不再误报。原文算过账：预留 16 位之后，还剩下足够 13 个软分叉用 version bits 并行信号的空间。
3.2 例一：nonce 空间不够用
原文举的第一个例子是挖矿硬件：现有硬件能在不到 200 毫秒内耗尽 32 位 nonce 字段，控制器不得不非常频繁地向每颗挖矿芯片分发新任务，消耗大量带宽与 CPU。多滚一些位可以大幅缓解这个问题；而过多地滚动 nTime 并不理想，因为它会在更长时间尺度上扭曲时间戳。
3.3 例二：AsicBoost 需要两位
第二个例子是 version-rolling 形式的 AsicBoost：它需要 nVersion 字段中的两位来计算四路碰撞。任意两位都可以用，挖矿设备可以经由 Stratum 的 “version-rolling” 扩展与矿池协商具体用哪两位——这正是 BIP-310 规范的机制。
四、规则本身
4.1 预留范围与掩码
区块头 nVersion 字段中第 13 位到第 28 位（含两端）、共 16 位（0x1fffe000）预留为通用用途，并从 BIP-8 与 BIP-9 的规范中移除。判断软分叉信号时应对 nVersion 施加掩码 0xe0001fff，使第 13–28 位对软分叉信号与未知软分叉警告一律被忽略。
4.2 不指定具体用途
原文明确：本规范不为任何特定目的预留特定位。划出的是一片“通用”空间，具体哪一位给哪种用途，由矿工、矿池与相关协议（如 Stratum 的 version-rolling 协商）自行约定，不归本 BIP 管。
4.3 参考实现与兼容性
原文给出作者仓库中的一笔提交作为参考实现。向后兼容方面：
- 未升级的节点会把这些预留位当作软分叉信号来解释，并可能触发未知软分叉警告系统；
- 本提案不需要软分叉即可实现；
- 原文写道：在写作时，没有已知的、正在使用这 16 位中任何一位的待决软分叉，且已有相当比例的算力已经在使用这些位；未来的软分叉不应再使用这些位做激活信号。
五、谁必须动
普通持币人：无事可做。本 BIP 只动区块头位的解释，不涉及地址、交易与钱包。
全节点：这是主要的行动方——更新软件，在评估 version bits 信号与未知软分叉警告时对 nVersion 施加掩码，忽略第 13–28 位。不升级的节点在共识上仍能跟随链，只是可能对正常挖矿活动发出误报警。
全节点与矿工：矿工可以在预留范围内滚动 nVersion 位以扩大 nonce 空间或做 AsicBoost，与矿池之间通过 BIP-310 的协商确定具体用位；出块时不应指望这些位还能传达软分叉立场。
共识层：本 BIP 不改变区块有效性规则，原文明确其不需要软分叉部署。它改的是信号解释的约定：哪些位还算“投票”，哪些位从此只是矿工的自由空间。
六、现在算不算数，以及一个常见误读
状态为 Draft（草案），且原文带有 Proposed-Replacement 标记，指向接替它的 BIP-323：后者认为 16 位仍不够用，主张预留 24 位。因此读 BIP-320 要注意两点：一是它仍是草案而非已生效规则；二是这条线上的现行讨论已经推进到 323，本篇是理解来龙去脉的起点。
常见误读：
“把 16 位划为通用，等于比特币放弃了 16 个软分叉信号位。”
原文的口径不是放弃，而是划界：划走 16 位后仍留有足够 13 个软分叉并行使用 version bits 的空间；而且不这样划界，矿工的正常滚动行为会不断触发节点的未知软分叉误报，反而让真正的信号警告失去可信度。
七、延伸
- 阅读版：https://bips.dev/320
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0320.mediawiki
- 相关：BIP-323 24 个 nVersion 位通用、BIP-310 Stratum 协议扩展、BIP-9 Version bits
- 仓库总目录：https://github.com/bitcoin/bips