比特币核心32版：验证提速，手续费机制调整

在开发者于9月14日标记v32.0rc1后，Bitcoin Core 32.0已进入最终的候选版本测试周期，使费用估算、区块验证性能和安全修复更接近计划于10月10日发布的版本。

Bitcoin Core项目的官方GitHub发布页面显示，v32.0rc1位于提交d0231bb，并于9月14日12:58 UTC由一位经过验证的维护者签名。该项目的发布日程仍以10月10日作为最终v32.0标记的目标日期，尽管该日期仍取决于测试和进一步的修复。

版本32侧重于节点软件行为、钱包接口、费用计算、网络和性能。发布说明草案未列出对比特币共识规则的更改，这意味着该更新并未重新定义网络认为哪些交易或区块有效。

Bitcoin Core 32在RC1标记后瞄准10月10日

开发者于8月20日进入功能冻结期，将工作限制在发布前所需的修复上。9月14日，他们从主开发分支中分离出32.x分支，并启动了候选版本周期，同时版本33的开发工作另行恢复。

第一个候选版本旨在供节点运营者、钱包开发者和其他用户在开发者决定代码是否准备好稳定发布之前进行测试。Bitcoin Core于9月15日，即RC1被标记一天后，开设了一个专门的32.0候选版本测试反馈问题。

该项目要求测试者使用测试指南进行RC特定的检查，并通过单独的GitHub问题报告软件问题。截至9月16日，尚未发布最终的v32.0二进制文件。

Bitcoin Core不会自动更新。运营者自行选择何时安装新版本，这意味着较旧的版本在新软件可用后仍可继续运行。

这种手动升级模式在以往的安全披露中曾具有重要意义。正如crypto.news此前报道，Bitcoin Core在5月披露了CVE-2024-52911，此前存在漏洞的28.x分支已达到生命周期终点。该漏洞在技术细节公开之前已在Bitcoin Core 29.0中修复。

新的费用估算器融合内存池与区块历史

Bitcoin Core 32较为显眼的面向用户的变化之一影响了estimatesmartfee，这是钱包和应用程序用于计算交易费用的RPC。

到目前为止，Bitcoin Core的主要估算器一直依赖于过去区块中所包含交易的已观察确认行为。版本32增加了一个基于当前等待在节点内存池中的交易的独立估算器。

新的内存池估算器会根据当前待处理交易状况，同时生成经济型和保守型估算。Bitcoin Core 在使用它之前会检查近期的区块活动，当内存池看起来过于稀疏或不健康时，可以拒绝该估算。

当两个系统都产生有效结果时，estimatesmartfee 会返回较低的费用估算。因此，新方法无法通过组合默认模式将现有的区块策略建议推高；它的作用是在当前内存池状况支持时降低该建议。

这种设计可以在区块空间昂贵的时期结束后更快地做出响应。区块历史估算器可能会继续纳入近期确认的高费用交易，而内存池可能已经显示出竞争确认的交易减少。

该软件保留了应用程序使用先前方法的方式。新增的 fee_rate_estimator 选项允许用户请求 block_policy、mempool_policy 或组合默认行为。Bitcoin Core 将新的内存池估算器的统计数据存储在单独的数据文件中，以便在重启后重新加载。

钱包费用计算将使用组合默认估算器。响应可以识别是哪个估算器产生了所选费用，而更高的详细级别会为需要更多细节的应用程序公开内存池健康统计数据。

区块验证获得并行磁盘预取

Bitcoin Core 32 改变了节点在连接区块时检索交易数据的方式，尤其是当所需信息必须从存储中读取时。

该软件现在可以在区块验证继续进行的同时，通过多个工作线程从链状态数据库中预取先前的交易输出，即 prevouts。默认是八个预取线程，操作员可以将该设置提高到 16，或将其设置为零以禁用并行获取。

Prevouts 标识交易输入所花费的币。节点需要这些信息来检查输入是否存在、是否尚未被花费，以及是否满足适用的验证规则。

该改进旨在减少节点处理包含输入尚未存在于更快内存缓存中的区块时等待磁盘读取所花费的时间。其效果将因存储硬件、缓存行为和节点配置而异。

Bitcoin Core 32 通过 -prevoutfetchthreads=<n> 公开该设置，让操作员控制参与其中的线程数量。草案说明将该功能具体描述为区块验证性能改进。

单独的 RPC 变更在 AssumeUTXO 后台验证期间为操作员提供了更多信息。在基于快照的节点到达链尖后，getblockchaininfo 现在可以报告仍在活动节点状态背后运行的历史链验证进度。

安全修复关闭钱包和 HTTP 内存缺陷

Bitcoin Core 32 修复了一个在少数特定条件下影响非 Windows 系统的钱包通知缺陷。

草案说明指出，当节点配置了 -walletnotify 时，拥有创建钱包权限的已认证 RPC 用户可以构造一个包含特殊替换字符的钱包名称。在这些条件下，该名称可能导致以 Bitcoin Core 进程的权限执行任意命令。

版本 32 更改了钱包通知占位符替换方式，使钱包名称被视为字面文本。该版本还通过拒绝某些包含 . 或 .. 路径元素的相对路径名称来收紧钱包命名。

第二个问题出现在对 Bitcoin Core 重写的 HTTP 服务器进行审查期间，该服务器将在版本 32 中取代 libevent。

开发者 Matthew Zipkin 在使用 Moonshot AI 的 Kimi K3 模型进行审计发现一条内存耗尽路径后，提交了拉取请求 #36123。当服务器处理一个请求时，它可能继续读取和排队同一连接发送的数据，而没有有效的大小限制。

最初的分析表明，该情况主要需要一个能够保持请求忙碌的已认证客户端。进一步测试发现，REST 流量在未经认证的情况下也会造成类似问题。

一位审查者报告称，16 个未经认证的 REST 连接在大约一分钟内将一个测试进程的内存从 46 MB 推高到约 3 GB。在修订后的修复之后，同一测试在 90 秒内使内存使用量增加约 3 MB，而补丁前为 3.2 GB。

该补丁于 9 月 5 日合并，早于 v32.0rc1 被打上标签。由于重写的 HTTP 服务器是版本 32 的新增内容，该特定缺陷在该服务器出现在稳定的 Bitcoin Core 版本之前就被发现。

Kimi K3 的使用符合近期在比特币软件中利用 AI 辅助安全审查的模式。正如 crypto.news 在八月报道的那样，Bitcoin Red Team 在扫描了数百个与比特币相关的开源项目后，记录了 7,958 个潜在发现，不过其中许多在被视为已确认漏洞之前需要人工验证。

资源耗尽问题今年也出现在其他比特币软件中。在相关报道中，crypto.news 报道称，Core Lightning 在审查 AI 生成的报告后确认了安全漏洞，并警告运营者升级或暂时使用离线模式。

PSBT 版本 2 成为四个 RPC 的默认版本

Bitcoin Core 32 更改了用于部分签名比特币交易的四个命令所创建的默认格式。

createpsbt、walletcreatepsbt、converttopsbt 和 psbtbumpfee 将默认生成 PSBT 版本 2。开发者添加了一个可选的 psbt_version 参数，以便应用程序在必要时可以明确请求另一个受支持的版本。

PSBT 允许多个钱包、应用程序或硬件签名设备在完整的比特币交易被广播之前交换交易信息。将默认版本改为版本 2 可能需要那些假定 Core 的 RPC 输出将使用旧格式的软件进行测试。

此次更新并未移除请求先前版本的能力。围绕受影响的 RPC 命令构建的应用程序可以在测试版本 2 兼容性时明确设置格式。

钱包工具在同一版本中还收到了其他更改。一个新的 exportwatchonlywallet RPC 会创建一个描述符钱包文件，其中包含公共描述符、交易历史和地址簿数据，但不包含私钥。Bitcoin Core 的离线签名教程现在使用该命令来创建在线只读钱包。

另一个新命令 derivehdkey 允许钱包通过包含至少一个硬化步骤的路径派生扩展公钥或私钥，而 addhdkey 允许添加 BIP32 扩展密钥，而无需立即使用它来生成输出脚本。

PrivateBroadcast 也继续得到维护。Crypto.news在六月报道称，Bitcoin Core 31.1rc1 修复了一种在使用 PrivateBroadcast 时可能暴露原始 IP 地址的网络状况。版本 32 包含进一步的 PrivateBroadcast RPC 和交易中继更改，记录在其发布说明草稿中。

当前的 Bitcoin Core 时间表仍将 10 月 10 日列为标记 v32.0 的目标日期。9 月 15 日开启的 RC 测试反馈线程仍然活跃，开发者指示发现实际 Bitcoin Core 缺陷的测试者在最终发布前单独提交问题。