Bitcoin Core 0.4.6 / 0.6.0.7 修复版发布说明：钱包密钥校验、RPC 输入校验与 GUI 稳定性修复全解

本篇基于当前仓库中的历史发布说明 release-notes-0.4.6.md，完整梳理 Bitcoin Core 0.4.6（及同步打标签的 Bitcoin-Qt 0.6.0.7）这一轮纯缺陷修复（bugfix-only）发布的全部修复项：涵盖私钥导入校验、加密/解密填充失败检测、区块重复交易检查、JSON-RPC 十六进制输入拒绝、网络死锁规避，以及大量 Bitcoin-Qt 界面修复。读完本文，你既能掌握该版本每一处修复的技术含义，也能在当前代码库中定位到其中多项修复遗留至今的实现痕迹，理解这些早期修复如何演化为今日 Bitcoin Core 的对应机制。

发布背景与版本说明

根据发布说明原文，bitcoind 0.4.6 已发布下载，提供 Windows 安装包（installer）、Windows zip（含签名 sig）与源码 tar.gz 三种形式；同时 Bitcoin-Qt 0.6.0.7 与 bitcoind 0.6.0.7 在 git 中打上了标签，但官方明确建议直接升级到 0.6.1，0.6.0.7 更多是历史标签意义。

需要特别记住的三条发布声明：

1. 本轮为纯修复版本："These are bugfix-only releases"，不包含新功能；
2. wxBitcoin GUI 停止维护：0.4.x 的 wxBitcoin 图形客户端不再被维护和支持。发布说明指出，如果有人愿意接手维护 wxBitcoin，应联系 Luke-Jr；
3. 反馈渠道：当时的缺陷反馈方式是回复发布对应的论坛帖子（forum thread），这与今天通过仓库 issue 系统报告问题的方式已经完全不同。

修复项全量梳理

以下按技术领域对发布说明中的全部修复条目进行分类归纳，不遗漏原文档任何一条修复。

1. 钱包与密钥安全

修复项	说明
私钥导入合法性校验（0.6.0.7）	0.6.0 版本允许导入无效的"私钥"，导入后这些私钥实际上无法用于花费（unspendable）。0.6.0.7 在导入时会先验证私钥有效性，拒绝导入非法私钥
加密/解密调用的填充失败检测	在 encrypt/decrypt 调用后检查状态，以检测 padding（填充）失败，避免把失败的密文解密结果当作有效数据处理

私钥导入校验是其中影响面最广的一条：在 0.6.0 之前的行为下，用户可能把一个格式合法但数学上不是有效 ECDSA 私钥的字符串导入钱包并长期保存，而对应的 UTXO 永远无法花费。该修复确立了一个至今仍然成立的原则——任何密钥进入钱包的路径都必须先通过有效性校验。

2. 共识与区块校验

• 更早检查区块中的重复交易（Fixes #1167）：把一个区块内包含重复交易（duplicate transactions）的检测时机提前。重复交易意味着同一笔交易在同一区块中出现两次，这既浪费空间也构成规则违规；将检查前移可以在进入更耗时的连接（connect）流程之前快速拒绝该区块。

3. RPC 接口与输入校验

• 修复 listtransactions 的 from/count 参数处理：JSON-RPC 方法 listtransactions 中 from 与 count 两个分页参数的处理逻辑存在错误，本版本修复；
• 拒绝而非误解十六进制参数中的非 ASCII 输入："Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected"——对于期望十六进制字符串的 RPC 参数，此前部分非 ASCII 输入可能被"误解"（错误地按某种字符编码转换）而不是被明确拒绝。这属于输入校验类修复，直接关系 RPC 接口的健壮性与安全边界。

4. 网络与并发

• 修复潜在的网络死锁："Fix potential networking deadlock"，规避网络层在特定条件下可能出现的死锁；
• 优化并修复"是否已知某交易"判断的多线程访问："Optimize and fix multithreaded access, when checking whether we already know about transactions"——对"本节点是否已经知道这笔交易"这一高频查询路径，同时做了性能优化与线程安全修复。

5. GUI（Bitcoin-Qt）

发布说明中标注 "(Bitcoin-Qt)" 的条目均为图形客户端修复：

修复项	说明
地址已带标签时的标签设置（Fixes #1080）	选择一个已经带有标签的地址时，正确设置该标签
"显示地址"设置的误开启	不再为并未显式开启 "Display addresses" 的用户错误地设置该选项
绿色对勾（green tick）状态（Fixes #921）	只有当所有已知区块都下载完毕时，才显示"已同步"的绿色对勾
"最新"状态的时间阈值	判断"up to date"所用的"距最新区块的时间"阈值从 30 分钟提高到 90 分钟，减少因区块间隔波动造成的误报"落后"
失控异常提示	当发生 runaway exception（未被捕获的失控异常）时，弹出消息框而不是直接崩溃退出
-server 未配置 RPC 密码	提供 -server 但没有提供 RPC 密码时，用消息框显示错误而非异常
RPC 端口绑定失败	无法绑定 RPC 端口时显示错误信息，而非抛出异常崩溃
签名消息的地址提示文本	修正"签名消息"功能中 bitcoin 地址 tooltip 文案（Fixes #1050）
设置对话框	补上设置对话框中缺失的 tooltip 与按键快捷键（part of #1088）
QR 码编码失败处理（0.6.0.7）	编码 QR Code 失败时显示错误信息，而不是崩溃
QR 码对话框标题（0.6.0.7）	没有标签时，从 QR Code 对话框标题栏移除 "(no label)" 字样
成熟交易 tooltip	移除成熟（mature）交易 tooltip 中难看的强制换行（0.6.0.7）

其中"崩溃改为显示错误信息"类修复（runaway exception、RPC 端口绑定、QR 编码失败、-server 无密码）体现了一条清晰的工程方向：GUI 客户端必须优雅降级，任何可预见的错误都应呈现为错误消息而非进程崩溃。

6. 构建、平台与工具链

• Windows 构建升级至 OpenSSL 1.0.1b："Upgrade Windows builds to OpenSSL 1.0.1b"，跟进当时 OpenSSL 安全更新；
• Growl 1.3 通知支持：正确支持 Mac 上 Growl 1.3 版本的桌面通知；
• clang 编译修复：绕过 boost::program_options 中的一个问题，该问题导致代码无法在 clang 下编译；
• 无符号 char 平台的隐性 bug："Fixed bugs occurring only on platforms with unsigned characters (such as ARM)"——在 char 默认无符号的平台（如 ARM）上才触发的缺陷被修复。这类 bug 通常源于把 char 当有符号数做移位、比较或字节处理，是移植性问题的典型代表；
• 脚本命名修正（Fixes #1099）：把 make_windows_icon.py 重命名为 .sh，因为它实际上是一个 shell 脚本；
• 计数/尺寸循环的类型与告警：若干内部类型修正，统一计数与尺寸循环中使用的类型，并消除相关编译告警；
• 补充缺失的错误条件检查："Missing error condition checking added"，为若干此前忽略返回值的调用补上错误检查。

在当前代码库中验证修复的延续

上述修复大多属于 2011 年前后的历史变更，但其中几项的"修复思想"在当前仓库的源码中仍然可以直接找到对应实现，可作为交叉验证的依据。

1. 90 分钟同步阈值至今仍存在于 GUI 中。 发布说明中的"Display an error / up-to-date 阈值从 30 分钟提高到 90 分钟"，其结果直接体现在当前的 src/qt/bitcoingui.cpp 中：

/**
 * Maximum gap between node time and block time used
 * for the "Catching up..." mode in GUI.
 */
static constexpr int64_t MAX_BLOCK_TIME_GAP = 90 * 60;

这个 90×60 秒的常量正是当年修复的数值，被保留为 GUI 判断"是否处于追赶区块（Catching up...）"模式的最大时间差上限——当年为了避免区块间隔波动导致的误报而放宽的阈值，沿用了十余年。

2. RPC 十六进制输入的严格校验沿用至今。 当年"非 ASCII/非十六进制输入应被拒绝而非误解"的修复方向，在当前 src/rpc/util.cpp 的 ParseHexV 中仍然可以清楚看到：

std::vector<unsigned char> ParseHexV(const UniValue& v, std::string_view name)
{
    std::string strHex;
    if (v.isStr())
        strHex = v.get_str();
    if (!IsHex(strHex))
        throw JSONRPCError(RPC_INVALID_PARAMETER, strprintf("%s must be hexadecimal string (not '%s')", name, strHex));
    return ParseHex(strHex);
}

即：先以 IsHex 严格判定字符串是否为纯十六进制，不是则抛出 RPC_INVALID_PARAMETER 并回显原始输入。所有需要十六进制数据的 RPC（如 src/rpc/rawtransaction.cpp 中的脚本解析、src/rpc/txoutproof.cpp 中的 Merkle 证明解析）都通过这类工具函数走同一条"拒绝而非猜测"的校验路径。

3. 重复交易检查仍是区块校验的一部分。 当年"更早检查区块内重复交易（#1167）"所建立的检查项，在当前代码树中依然是共识校验与包策略的一部分：区块连接路径的相关逻辑见 src/validation.cpp，交易包（package）层面"不得包含 txid 重复的交易"的约束则记录在 src/policy/packages.h 的注释中。

小结：一轮"小版本"发布的工程价值

从今天回看，0.4.6 / 0.6.0.7 只是一次没有新功能的修复发布，但它浓缩了早期 Bitcoin Core 工程实践中的几个关键原则，而这些原则在后续版本中全部被制度化：

1. 密钥路径的入口校验：私钥等敏感数据进入钱包前必须验证有效性，杜绝"导入成功但永不可用"的静默损坏；
2. 错误必须显式化：无论是 crypto 调用的 padding 失败、RPC 端口的绑定失败，还是 QR 编码失败，都改为"检查返回状态 + 报告错误"，而不是吞掉错误或直接崩溃；
3. 输入校验的"拒绝优先"：期望十六进制的参数遇到非法字符时直接报 RPC_INVALID_PARAMETER，而不是尝试容错解析——当前 src/rpc/util.cpp 的实现即是这一思想的现行版本；
4. 状态提示要有确定语义：GUI 的同步指示（绿色对勾、90 分钟阈值）只在所有已知区块下载完毕后才呈现"已同步"，避免给用户虚假的安全感。

对于研究 Bitcoin Core 演进史或需要在极老版本链上排查问题的开发者而言，这份发布说明（原文见 doc/release-notes/release-notes-0.4.6.md）与同期其他历史发布说明（同目录下 doc/release-notes/ 收录了从 0.3.x 到 31.x 的全部版本说明）配合使用，可以完整追踪每一条修复在代码中的去向。需要再次强调：该轮发布为纯缺陷修复，且官方建议用户直接升级到 0.6.1，wxBitcoin GUI 自该时期起不再受维护，任何基于 0.4.x/0.6.0.x 的部署都不应被视为受支持的运行版本。