Bitcoin Core 0.8.5 版本说明详解：交易版本号越界漏洞修复与紧急升级指南

0.8.5 是 Bitcoin Core 历史上一个仅用于修复关键漏洞的维护性（maintenance）发布：攻击者可构造版本号（transaction version）大于 0x7fffffff 的交易，使其被错误地转发并打包进区块，进而导致节点在启动时对 LevelDB 数据库一致性检查产生“损坏”误报并建议用户重建索引。本文以仓库内 0.8.5 版本说明 为主体，还原该缺陷的技术成因与影响、完整的升级操作步骤，并结合当前源码解释交易版本字段、BIP 34（区块高度写入 coinbase）等底层机制，帮助读者理解此类维护性发布为何要求“全体用户立即升级”。

版本定位：一次必须立即升级的关键修复

0.8.5 不是功能版本，而是针对一个 critical bug（关键缺陷） 的紧急修复版。发布说明开篇即明确：

This is a maintenance release to fix a critical bug; we urge all users to upgrade.

翻译过来就是：这是一个修复关键错误的维护版本，官方敦促所有用户升级。这种措辞在 Bitcoin Core 历史上通常意味着该缺陷已被公开利用或存在被攻击者利用的现实风险，属于“不升级可能造成资金或节点可靠性损失”的一类发布。因此，阅读本文档的核心价值不在于了解新功能，而在于：

1. 确认自己运行的节点是否受漏洞影响；
2. 掌握从旧版本平滑升级的正确流程；
3. 理解漏洞背后的交易数据结构、传播与数据库一致性机制。

修复的缺陷：版本号大于 0x7fffffff 的交易

0.8.5 修复的核心缺陷在“Bugs fixed”一节中被描述为两条相互关联的问题，其根源是同一个：交易的版本号（version）字段被当作有符号整数处理，而大于 0x7fffffff（即最高位为 1）的版本号没有在转发与打包环节被正确拒绝。

• 问题一（传播层面）：版本号大于 0x7fffffff 的交易被错误地中继（relayed）并被打包进区块。由于中继与出块环节均放行了这类异常交易，攻击者可以向全网注入“合法但畸形”的交易，使正常的网络传播、挖矿模板构建流程出现非预期行为。
• 问题二（存储/启动层面）：包含此类交易的区块，会在节点启动时触发布置在 LevelDB 上的数据库一致性检查（checks for LevelDB database inconsistencies）的缺陷逻辑，使其误报数据库损坏（database corruption），并提示用户重建索引（reindex）。这会造成节点正常运行却被诱导执行代价高昂的全量重建，或使节点对合法链产生错误判断。

从技术上理解第一条缺陷，需要回到交易版本字段本身的设计：在 Bitcoin 的序列化格式中，version 是位于交易体最前端的 4 字节字段。若代码将其解释为 32 位有符号整数（int32_t），则大于 0x7fffffff 的取值会变为“负数”，从而绕过那些仅检查“版本号非负且在合理上限内”的转发/打包校验。0.8.5 的修复方式即是在中继、打包与接收校验中统一收紧了版本号取值范围，使这类畸形交易无法再进入网络与区块。

这条修复的另一个关键点是它对共识之外的所有节点行为都产生影响：中继（mempool/p2p 层面）、出块（mining template 层面）与启动校验（存储层面）必须一致地处理“非法版本号”，否则会出现不同节点对同一区块“一边接受、一边拒绝”的分裂局面——这正是本漏洞最危险的潜在后果。

对 BIP 34 强制执行代码的伴随修复

除上述关键漏洞外，0.8.5 还包含一处非关键（non-critical）修复，针对的是执行 BIP 34（BIP 34：block height in the coinbase transaction，即要求 coinbase 交易脚本开头包含区块高度）的代码。该问题不构成安全风险，但说明团队在修复版本号漏洞时同步复核了 BIP 34 相关逻辑，避免同类“数值比较/边界处理”错误蔓延。

BIP 34 在当前的 Bitcoin Core 中已是一个“buried deployment”（内嵌激活的共识规则）。在 共识参数定义 中可以看到每个网络的激活高度与激活块哈希被明确固化：

/** Block height and hash at which BIP34 becomes active */
int BIP34Height;
uint256 BIP34Hash;

而 区块校验实现 中的强制逻辑为：当 BIP 34 已激活时，区块 coinbase 的首个输入的 scriptSig 必须以“序列化后的区块高度”开头，否则区块被判定为共识无效：

// Enforce rule that the coinbase starts with serialized block height
if (DeploymentActiveAfter(pindexPrev, chainman, Consensus::DEPLOYMENT_HEIGHTINCB))
{
    CScript expect = CScript() << nHeight;
    if (block.vtx[0]->vin[0].scriptSig.size() < expect.size() ||
        !std::equal(expect.begin(), expect.end(), block.vtx[0]->vin[0].scriptSig.begin())) {
        return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "bad-cb-height", "block height mismatch in coinbase");
    }
}

主网 BIP 34 的激活高度为 227,931，这一点在 validation.cpp 中关于 BIP 30/BIP 34 交互的注释 中被反复引用。这处深度注释本身也解释了为何“coinbase 内含区块高度”之后难以再产生重复 coinbase（BIP 30 违规）——BIP 34 间接收紧了 coinbase 的唯一性。0.8.5 时代的该修复，本质上就是对这条由 BIP 34 引入的“高度写入 coinbase”规则的边界条件补强，与现代代码里 DEPLOYMENT_HEIGHTINCB 的统一处理思路一脉相承。

升级方法：从旧版本平滑迁移到 0.8.5

发布说明用 “How to Upgrade” 一节给出了完整的升级指引，这是本维护版本用户最需要执行的实操内容，完整步骤如下：

第一步：彻底关闭旧节点

如果当前运行的是更早的版本，需要先关闭它（shut it down）。需要注意：必须等待进程完全退出（wait until it has completely shut down）。发布说明特别提示，对较老的版本，关闭过程“可能需要数分钟”（might take a few minutes for older versions），原因是节点退出时需要将内存中的交易池、区块索引等状态安全落盘，直接杀掉进程或过早重启可能导致状态不一致。

第二步：按平台替换程序文件

等待进程完全退出后，按操作系统执行对应操作：

平台	操作方式
Windows	运行新的安装程序（run the installer）
macOS	直接覆盖 /Applications/Bitcoin-Qt
Linux	直接覆盖 bitcoind / bitcoin-qt 可执行文件

这里采用“覆盖二进制”而非“增量升级数据”的策略，是因为本版本修复的是区块/交易接受逻辑，属于节点核心行为，必须用新代码重启后才会生效；旧版本持续运行的时间越长，受漏洞影响的风险窗口就越长。

第三步：旧于 0.7.2 的特殊情况——自动重建索引

若你是从 0.7.2 或更早版本升级，则首次运行 0.8.5 时区块文件会被重新索引（re-indexed）。这是因为早期版本的区块/交易存储格式与索引语义存在差异，0.8.5 需要重建本地数据库索引以适配。该过程耗时取决于机器性能：

will take anywhere from 30 minutes to several hours, depending on the speed of your machine.

即大约 30 分钟到数小时不等。这是一个一次性成本，期间节点会进入重建状态，建议等待其完成后再正常使用（例如发起转账或对外提供 RPC 服务）。现代 Bitcoin Core 仍然保留 -reindex 与 -reindex-chainstate 这类命令行开关，其含义与流程正是从这一时期演化而来的。

技术纵深：从 0.8.5 到现代代码中的版本号字段

虽然 0.8.5 距今已非常久远，但理解该漏洞仍然需要看懂“交易版本号在数据结构与序列化中的位置”，而这在现代源码中依然清晰可见。

交易序列化中的 version 字段

在 交易序列化格式说明 中，无论是否包含 witness 扩展，version 都作为交易的第一个 4 字节字段出现：

/**
 * Basic transaction serialization format:
 * - uint32_t version
 * - std::vector<CTxIn> vin
 * - std::vector<CTxOut> vout
 * - uint32_t nLockTime
 */

在序列化/反序列化实现中，tx.version 被第一个读出或写入：

s >> tx.version;   // UnserializeTransaction
s << tx.version;   // SerializeTransaction

当前代码中交易版本字段的类型已是无符号 uint32_t（见 transaction.h 与 transaction.cpp），并定义了默认版本常量：

// Default transaction version.
static constexpr uint32_t CURRENT_VERSION{2};

而 0.8.5 时代的代码将版本字段解释为有符号 32 位整数，正是这种“uint32_t vs int32_t”的语义差异，使得 0x7fffffff 以上的取值（如 0x80000000、0xffffffff）被错误视为“负数”后逃过了基于“正值合理区间”假设的校验。作为对比，区块头的 nVersion 字段在现代代码中仍保留为 int32_t（见 block.h），说明区块版本与交易版本在类型选择上经历了不同演进路径。

版本号为何重要：它承载了软分叉与交易语义

交易版本号不是单纯的元数据——它对交易的有效性与可执行性有实际语义约束。例如现代代码中 BIP 68 相对时间锁要求交易版本号不小于 2（见 transaction.h 对 CTxIn::nSequence 的注释），而当前默认交易版本 CURRENT_VERSION 恰为 2。也就是说，如果当年 0.8.5 没有堵住“高版本号交易被转发打包”的漏洞，后续基于版本号区分交易行为的软分叉升级（如对更高版本号交易附加新规则）都会建立在一个不可靠的前提之上——攻击者可能用任意高位版本号交易干扰规则切换后的网络一致性。这正是 0.8.5 虽小却“critical”的根本原因。

修复与致谢：快速响应的维护流程

发布说明末尾记录了本次漏洞的处置方式：

Thanks to Gregory Maxwell and Pieter Wuille for quickly identifying and fixing the transaction version number bug.

即 Gregory Maxwell 与 Pieter Wuille 快速定位并修复了交易版本号漏洞。在 Bitcoin Core 的开源协作模式下，安全类 bug 通常遵循“先修复、后发布、再公开披露”的节奏：维护者先在内部或小范围同步复现与修复，随后以维护性版本统一下发，最后在版本说明中简要披露缺陷影响面，避免在补丁尚未被广泛部署时向攻击者公开可利用细节。0.8.5 的版本说明正是这一流程的典型产物——它不堆砌新特性，而是用最简练的语言说清三件事：有严重缺陷、必须升级、如何升级。

小结：为什么这类版本说明值得逐字阅读

0.8.5 版本说明虽然篇幅很短，却是 Bitcoin Core 安全响应机制的一个标准样本。对运维者与开发者而言，可从中学到：

• 数值边界是安全重灾区：有符号/无符号解释差异（0x7fffffff 之上即负数）是 C/C++ 系统中经典的绕过手段，中继、打包、存储三条链路上的校验必须口径一致；
• 启动时的一致性检查可能被“脏数据”干扰：数据库损坏误报会诱导节点执行无谓的全量重建，因此存储层校验代码对异常数据的处理需与网络层一致；
• 维护性版本的升级优先级最高：当发布说明出现 “maintenance release” 与 “we urge all users to upgrade” 时，应立即规划停机升级窗口，并严格按“完全关闭 → 覆盖二进制 →（必要时）等待重建索引”的流程执行。

如需进一步追溯该版本相关的历史沿革，可对照仓库中更早的 0.8.4 版本说明 与后续的 0.9.x 系列版本说明 观察修复策略的演进；而 BIP 34 在现代实现中的完整逻辑可继续阅读 validation.cpp 的共识校验段落 与 共识参数定义。