Bitcoin Core 24.2 维护版解读：从手续费估算到地址解析的可靠性修复

Bitcoin Core 24.2 是 24.x 系列的一个补丁（maintenance）版本，聚焦于修复问题与性能改进，而非引入新功能。本文以官方 release-notes-24.2.md 为核心，逐条拆解本次更新中手续费估算（避免服务过期费率）、bech32 地址解析错误处理、跨平台构建与 CI 的修复，并结合仓库源码与测试说明每项改动背后的原理；读完你可以理解"补丁版本修什么、为何修、如何验证"的完整脉络。

版本定位与升级方式

24.2 是什么版本

按发布说明，24.2 主要包含各类 bug 修复、性能改进与翻译更新。它是 24.x 分支的维护版本，官方推荐所有运行旧版本的用户升级，而不是停留在 24.0 / 24.1。发行说明同时提示：即便从已到达生命周期终点（EOL）的旧版本直接升级也是可行的，只是当数据目录需要迁移时可能耗时；历史上较旧的钱包格式在一般情况下仍被支持。

升级操作步骤

官方给出的升级流程非常直接：

1. 完全关闭旧节点：先停掉正在运行的 bitcoind / bitcoin-qt（或 macOS 的 Bitcoin-Qt），等待进程完全退出——某些情况下关闭可能需要几分钟。
2. 替换二进制文件：
   • Windows：运行新版安装程序；
   • macOS：直接覆盖 /Applications/Bitcoin-Qt；
   • Linux：覆盖 bitcoind / bitcoin-qt 可执行文件。
3. 重新启动：新版会在启动时按需迁移数据目录中的既有文件。

兼容性声明

24.2 官方宣称的受支持平台为：

• 使用 Linux 内核的操作系统；
• macOS 10.15+；
• Windows 7 及更新版本。

Bitcoin Core 在大多数其他类 Unix 系统上"应该"也能工作，但在这些平台上测试频率较低，官方不建议在未支持的系统上运行。这些声明直接决定了下文构建系统修复（尤其是 macOS 相关项）的优先级。

核心修复一：手续费估算不再提供过期费率（#27622）

问题背景：过期的 fee_estimates.dat

这是 24.2 中最值得关注的行为修复。问题根源（对应 issue #27555）是：节点初始化时偶尔会读取一个很旧的 fee_estimates.dat 文件；或在非正常关闭后，最新费率估算没有被落盘。当旧文件里的估算值早已过时时，节点仍会使用它，导致用户设置的交易手续费过低、长时间卡在内存池（mempool）中无法确认。

该 PR（#27622，作者 ismaelsadeeq）从"预防 + 检测"两个方向一次性解决：

1. 周期性落盘，缩小估算文件变旧的时间窗口；
2. 初始化时检测文件年龄，太旧则拒绝读取，从源头避免服务过期估算。

解决方案一：每小时落盘一次

引入 FEE_FLUSH_INTERVAL 常量，将费率估算周期性地冲刷到磁盘。这一设计沿用至今，在 src/policy/fees/estimator_man.h 中可以看到：

// How often to flush data to disk
inline constexpr std::chrono::hours FEE_FLUSH_INTERVAL{1};

即每隔 1 小时把最新估算写入 fee_estimates.dat，显著降低"上次写入距今过久"的概率。这也是发行说明强调"避免服务 stale（过期）估算"的第一道防线。

解决方案二：超过 60 小时不读取

第二道防线是文件年龄检测。在发布时的补丁中，CBlockPolicyEstimator 构造函数不再无条件尝试读取估算文件，而是先判断其最后修改时间。对应的常量同样延续到了当前仓库的 src/policy/fees/block_policy_estimator.h：

/** Block policy estimate files that are more than 60 hours (2.5 days) old will not be read,
 *  as the estimates in the file are stale.
 */
inline constexpr std::chrono::hours MAX_FILE_AGE{60};

实际读取逻辑在 src/policy/fees/block_policy_estimator.cpp 中：文件缺失时打印提示并跳过；文件年龄大于 MAX_FILE_AGE（60 小时即 2.5 天）时，打印警告 "...too old (age=... > 60 hours) and will not be used to avoid serving stale estimates" 并放弃读取；只有年龄合规时才执行 Read()。这样即使磁盘上残留了几个月前的估算文件，节点也会把它当作"不存在"，在同步出新统计前使用保守的默认费率路径。

配套：regtest 专用的读取开关

为了兼顾测试与回滚场景，同时新增了仅限 regtest 网络的调试开关 -acceptstalefeeestimates。在 src/init.cpp 中注册的参数说明直接引用了 MAX_FILE_AGE 描述其含义：

argsman.AddArg("-acceptstalefeeestimates", strprintf(
    "Read fee estimates even if they are stale ("
    "%sdefault: %u) fee estimates are considered stale if they are %s hours old",
    "regtest only; ", DEFAULT_ACCEPT_STALE_FEE_ESTIMATES,
    Ticks<std::chrono::hours>(MAX_FILE_AGE)),
    ArgsManager::ALLOW_ANY | ArgsManager::DEBUG_ONLY, OptionsCategory::DEBUG_TEST);

并且 src/init.cpp 会在非 regtest 链上启用该选项时直接返回 InitError，提示"acceptstalefeeestimates is not supported on ... chain"，确保该逃生舱口只在本地测试网络生效，不会污染主网/测试网行为。

测试验证

功能测试 test/functional/feature_fee_estimation.py 中保留了对应的回归覆盖：

• 构造一个"内容已过期"的估算文件后重启节点，断言节点不再读取旧文件（对应提交 910c36253e test: ensure old fee_estimates.dat not read on restart and flushed）；
• 使用 -acceptstalefeeestimates 重启节点，验证估算文件被正常加载（test_acceptstalefeeestimates_option）；
• 校验 fee_estimates.dat 的周期刷新与旧文件迁移路径。

注意：当前仓库的开发版本已在原有 fees.cpp 基础上重构出 src/policy/fees/ 目录（含 estimator_man、block_policy_estimator、mempool_estimator），但 MAX_FILE_AGE = 60h、FEE_FLUSH_INTERVAL = 1h 以及 -acceptstalefeeestimates 这一整套设计被完整保留，可视为 #27622 的延续实现。

核心修复二：RPC 层 bech32 非法地址处理（#27727）

修复了什么

#27727 rpc: Fix invalid bech32 address handling 是一处典型的"错误路径不够严谨"修复。此前 DecodeDestination 在处理 bech32/bech32m 地址时，对空数据段、程序长度越界、填充字节错误等情形给出的错误信息含糊甚至可能误判。修复后的核心逻辑体现在 src/key_io.cpp 的地址解码函数中，几个关键分支（对应当前源码行 85 起的 DecodeDestination）：

1. 空数据段被显式拒绝：解码成功但 data 为空时，返回明确错误 "Empty Bech32 data section"（见 src/key_io.cpp），而不是继续走后续解析。

2. 错误信息携带真实程序长度：

   • 对 witness v0，报错为 "Invalid Bech32 v0 address program size (%d %s), per BIP141"（src/key_io.cpp），直接给出实际字节数并引用 BIP 141；
   • 对 v1+ 通用分支，报错为 "Invalid Bech32 address program size (%d %s)"（src/key_io.cpp）。

3. 填充错误分支被补齐：对既非空、又无法归入 witness 程序的异常数据段给出 "Invalid padding in Bech32 data section" 之类的判定，避免静默落入错误类别。

这些改动让 validateaddress、getaddressinfo 等依赖地址解码的 RPC 返回的 error 更准确、更利于用户排障，同时修复了解析歧义导致的潜在误判。

测试覆盖

该 PR 同步更新了既有测试并新增独立功能测试：

• test/functional/rpc_invalid_address_message.py 断言各 RPC 的报错文案与预期一致，例如程序长度错误现在会提示具体的 Invalid Bech32 v0 address program size (...)，错误码仍为 -5；
• 新增 test/functional/rpc_validateaddress.py，针对 BIP 173 / BIP 350 列出大量非法样例（错误校验和、v0 使用 bech32m、v1+ 使用 bech32、程序长度越界等），逐一断言 validateaddress 的输出。

构建系统修复：Linux 依赖与 macOS Qt

depends: xcb-proto 升级到 1.15.2（#28097）

为修复在 Python 3.12 宿主环境下构建失败的问题（典型场景是使用较新发行版编译 depends），xcb_proto 依赖从旧版本升级到 1.15.2。对应提交信息（85436bc7ac）明确指出其动机：解决在如 rawhide（Fedora 开发版）这类 Python 3.12 系统上 xcbgen 安装阶段出现的构建失败。

如今仓库中的 depends/packages/xcb_proto.mk 已进一步演进到 1.17.0，并仍保留 python*/site-packages/xcbgen/__pycache__ 的后处理清理逻辑，说明该依赖是 Qt/钱包 GUI 在 depends 工具链中不可缺少的组件，其版本与宿主 Python 的兼容性持续被关注。

macOS：适配 Xcode 15 新链接器与修复 memory_resource

24.2 中还有两项针对 macOS 构建的修复：

• #28543 build, macos: Fix qt package build with new Xcode 15 linker：Xcode 15 更换了新的链接器行为，导致 depends 编译的 Qt 包在链接阶段失败，此提交修复了用新版 Xcode 构建 Qt 依赖包的问题（对应提交 dccacf0bf7）；
• #28571 depends: fix unusable memory_resource in macos qt build：Qt 内部通过 QT_HAS_INCLUDE(<memory_resource>) 判断标准库能力，在 macOS 上该判断不够准确，导致 <memory_resource> 实际不可用。补丁（见 e270f3f857，向 depends/packages/qt.mk 追加 memory_resource.patch）将其改为检测 __cpp_lib_memory_resource 特性宏，从而保证 C++17 的 std::pmr 相关类型在 Qt 构建中可用。

这两项改动共同保证了 24.2 继续兑现"macOS 10.15+ 受支持并经过广泛测试"的兼容性承诺。若读者需要自行构建 macOS 版，可参考 doc/build-osx.md（当前仓库的构建说明）与 doc/dependencies.md 确认工具链版本要求。

CI 流水线维护性改进

发布说明还列出了 4 项 CI 改动，属于流水线工程层面的"家务活"，目的是让测试基础设施更稳定、更省资源、更贴近真实的容器运行方式。仓库内对应的 CI 框架位于 ci/（ci/test/ 为各环境脚本，ci/lint/ 为静态检查脚本，ci/test_run_all.sh 为批量入口）：

PR	改动要点	价值
#27777	在 RESTART_CI_DOCKER_BEFORE_RUN 场景下清除悬挂镜像（dangling images）	避免 CI 磁盘被陈旧镜像占满导致任务失败
#27834	移除 Android APK 任务，TSan 任务改用 CI credits	精简不再维护的任务，优化资源预算分配
#27844	用 podman stop 替代 podman kill	让容器停止流程更规范、优雅
#27886	"ARM" 任务改用 amd64 容器	让该任务在更通用/更便宜的 amd64 runner 上运行，仅保留必要的交叉编译

这些都属于"看不见但很重要"的工程改进：它们不改变最终二进制功能，却直接影响回归测试能否稳定、快速、低成本地在每次提交上跑完，是补丁版本可靠性的一部分。

杂项：不要用 std::vector = {} 释放内存（#28452）

原因

#28452 Do not use std::vector = {} to release memory 修正了一个 C++ 内存释放陷阱。开发者常误以为 v = {}（即对 vector 重新赋一个临时空值）能保证释放其底层堆内存；但在部分标准库实现（如 glibc 的 debug 模式）下，这种做法并不必然归还容量，而 shrink_to_fit() 本身也只是 non-binding（非强制）请求，不保证生效。

修复方式

为此在 src/util/vector.h 新增了泛型工具函数：

/** Clear a vector (or std::deque) and release its allocated memory. */
template<typename V>
inline void ClearShrink(V& v) noexcept
{
    // There are various ways to clear a vector and release its memory:
    // 1. V{}.swap(v)
    // 2. v = V{}
    // 3. v = {}; v.shrink_to_fit();
    // 4. v.clear(); v.shrink_to_fit();
    // (2) does not appear to release memory in glibc debug mode...
    V{}.swap(v);
}

函数注释详细记录了四种写法的取舍，最终采用标准保证的 V{}.swap(v) 方式，确保清空并释放容量。改动应用在 headers 同步状态机的收尾路径上——例如 src/headerssync.cpp 的 Finalize() 中，将 m_header_commitments、m_redownloaded_headers 由原先的 = {} 改为 ClearShrink(...)，避免节点在结束一轮 headers 同步后仍长期占用已无用的大块内存。

同时 src/test/util_tests.cpp 新增了 clearshrink_test 单元测试，分别对 std::vector<uint8_t>、std::vector<bool> 与 std::deque<int> 验证 ClearShrink 后 size() == 0（及 vector 的 capacity() == 0）。这体现了 Bitcoin Core 一贯的做法：即使是微小改动，也要求有可执行的回归测试兜底。

致谢与社区协作

发布说明最后列出了直接贡献者名单，包括 Abubakar Sadiq Ismail、Hennadii Stepanov、Marco Falke、Michael Ford、Pieter Wuille 等，并对所有在翻译平台参与多语言翻译的贡献者致谢。Bitcoin Core 的本地化文案（例如本仓库 src/qt/locale/ 下大量 .ts 文件）正是由这批社区志愿者持续维护的，这也是每个版本"updated translations"的来源。

小结：一次标准的"可靠性维护"

纵观 24.2，可以清晰看到补丁版本的三类典型工作：

1. 正确性修复——#27622 让费率估算拒绝过期数据、#27727 让非法 bech32 地址得到准确报错，二者都配齐了功能测试与回归用例；
2. 构建/兼容修复——xcb_proto 适配新宿主 Python、Qt 适配 Xcode 15 与 macOS 的 memory_resource 问题；
3. 工程治理——CI 镜像清理、容器操作方式、任务资源调度，以及 #28452 这样细至 std::vector 赋值语义的内存释放纠正。

对运维者与开发者而言，升级到 24.2 的核心收益即在于：节点不再因残留的过期 fee_estimates.dat 而给出偏低的费率建议，避免交易长时间卡在内存池；同时 macOS 用户在使用新版 Xcode 构建时不再被 Qt 依赖问题阻断。若想深入了解某一处修复，可以直接沿本仓库对应的源码路径继续阅读：费率估算看 src/policy/fees/，地址解码看 src/key_io.cpp，内存释放工具看 src/util/vector.h，回归测试则集中在 test/functional/ 与 src/test/util_tests.cpp 中。