版本号也能挖矿：BIP310 与 BIP320 把版本滚动写进协议

区块头不变，出块的机会却能多两的十六次方

比特币挖矿的本质是在区块头里找一个让哈希低于目标的数值。区块头的可变量一向被认为只有时间戳、nonce 和交易集合三大类，但 2017 年前后出现的一类矿机开辟了一条新路：把版本号字段里本不用于共识投票的比特位拿来滚动尝试，也就是版本滚动。它把算力效率的争论从实验室一路推到协议标准化的桌面。

原理：给哈希机多开一扇门

对给定的一组交易和 Merkle 根，矿机先算出区块头前 64 字节的中段哈希（midstate），之后只需在剩余部分反复试 nonce。传统的 nonce 只有 32 位，一轮任务约 43 亿次尝试就要换任务；如果在版本号字段再留出 16 个可变的位，等于把候选空间乘上 65536，同一份前置工作可以榨出成百倍的首轮尝试，省下的正是重复计算 midstate 的功耗。这项技术与 ASICBoost 的公开形态直接相关：变动的位落在区块头第一个分块内，硬件才能复用中间状态。

两项 BIP 把门框画清

问题随之而来：版本号字段同时是软分叉投票的信号位，矿机随意改位会让全网节点误报未知软分叉。于是出现了两个互补的提案。BIP 310 在矿机与矿池之间的 Stratum 协议里加了一个版本滚动扩展：矿机上报自己能改哪些位的掩码，矿池回复允许改哪些，双方取交集，此后份额按协商结果记账，解决了原始协议无法回传块版本值的缺陷。BIP 320 则在共识侧把 nVersion 第 13 到 28 位共 16 位划为通用用途，明确它们不参与 BIP8 与 BIP9 的信号解析，留下 13 个信号位的并行软分叉余量，节点据此忽略这些位、不再误报。

矿工和用户各自该看什么

矿工端的检查清单很务实：确认矿池支持版本滚动扩展（主流矿池普遍支持），确认矿机固件在连接协商时启用了该能力、掩码落在通用位范围内，并核对矿池份额记账是否按协商后的版本位处理陈旧份额。用户端则基本无感：版本滚动不改变工作量证明规则，也不改变任何地址或交易格式，它只是矿机工程效率的一部分。需要区分的是，公开滚动因链上可见而获得标准化路径，而依赖交易顺序碰撞的隐蔽式优化曾因可辨识性引发过行业争议——这也是为什么位段协商要以双方都看得见的明文进行。相关 BIP 与协议扩展的字段定义以官方文本为准，本文不构成任何投资或挖矿收益建议。

为什么信号位和通用位会打架

BIP9 的信号方案用版本号的连续比特位表达投票意向，理论上可同时跑二十多个提案。矿机若为挖矿效率随意翻动这些位，节点会按规则解析出莫名其妙的组合，误报未知软分叉，干扰整个升级观测体系。BIP320 的思路是把中间一段切出来当公共停车场：这十六位永远不用于信号，节点解析时跳过，矿工随便用。留下的信号位仍够若干提案并行，代价是信号空间变小，这本身就是升级机制设计里的一次分配权衡。

检查清单与常见误区

第一，别把掩码理解成权限越大越好，交集之后落在通用位段内才是健康状态，超出部分矿池会拒绝。第二，别把 Stratum 层面的能力与固件实现画等号，有些老固件能协商却配置了错误的位范围，检查方法是核对矿池端看到的提交记录里版本号分布。第三，普通用户完全无需为此调整任何钱包或节点设置，你的交易不携带区块头版本号，这项优化对确认速度和安全性的影响可以视为零。