Bitcoin Core 32 增加了更快的验证和费用变更

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

摘要 Bitcoin Core 32.0 于 9 月 14 日进入候选版本测试，最终标记目标为 10 月 10 日。

新的费用估算将区块历史记录与当前内存池条件相结合，并可能建议降低费用。

块验证现在默认跨八个工作线程预取以前的输出，从而减少磁盘等待。

钱包通知缺陷可能会让经过身份验证的用户在受影响的非 Windows 节点系统上执行命令。

测试发现 16 个未经身份验证的 REST 连接可能会使内存使用量迅速增加到大约 3 GB。

比特币核心项目的官方 GitHub 版本显示，提交 d0231bb 的 v32.0rc1 已于 9 月 14 日 12:58 UTC 使用经过验证的维护者签名进行签名。该项目的最终 v32.0 标签的发布时间表仍以 10 月 10 日为目标，不过该日期仍有待测试和进一步修复。

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

您可能还喜欢： 阿隆青睐卖家，比特币价格目标为 7.25 万美元

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 二进制文件。

比特币核心不会自动更新。运营商选择何时安装新版本，这意味着在新软件可用后旧版本可以保持活动状态。

这种手动升级模式在之前的安全披露中很重要。正如 crypto.news 之前报道的那样，在易受攻击的 28.x 分支生命周期结束后，Bitcoin Core 在 5 月份披露了 CVE-2024-52911。在技​​术细节公开之前，该错误已在 Bitcoin Core 29.0 中得到修复。

新的费用估算器融合了内存池和区块历史记录

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

到目前为止，比特币核心的主要估计器一直依赖于过去区块中包含的交易中观察到的确认行为。版本 32 添加了一个基于当前在节点内存池内等待的交易的单独估计器。

新的内存池估算器根据当前待处理的交易条件产生经济和保守的估算。 Bitcoin Core 在使用之前会检查最近的区块活动，并且当内存池显得过于稀疏或不健康时可以拒绝估计。

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

在一段昂贵的块空间结束后，该设计可以更快地做出响应。区块历史估计器可能会继续合并最近确认的高费用交易，而内存池可能已经显示出更少的竞争确认的交易。

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

钱包费用计算将使用组合的默认估算器。响应可以识别哪个估算器产生了选定的费用，而更高的详细程度则为需要更多详细信息的应用程序公开了内存池运行状况统计信息。

块验证获得并行磁盘预取

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

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

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

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

Bitcoin Core 32 通过 -prevoutfetchthreads= 公开该设置，使操作员可以控制参与的线程数量。草案注释将该功能具体描述为块验证性能改进。

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

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

Bitcoin Core 32 修复了在少数情况下影响非 Windows 系统的钱包通知缺陷。

草案说明指出，当节点配置了 -walletnotify 时，具有创建钱包权限的经过身份验证的 RPC 用户可以制作包含特殊替换字符的钱包名称。在这些条件下，该名称可能会导致以比特币核心进程的权限执行任意命令。

版本 32 更改了钱包通知占位符替换，因此钱包名称被视为文字文本。该版本还通过拒绝某些包含 .或 .. 路径元素。

在审查 Bitcoin Core 重写的 HTTP 服务器时出现了第二个问题，该服务器正在取代版本 32 中的 libevent。

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

第一个分析表明，这种情况主要需要经过身份验证的客户端能够保持请求繁忙。进一步测试发现，REST 流量在没有身份验证的情况下也会产生类似的问题。

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

该补丁于 9 月 5 日合并，之后 v32.0rc1 才被标记。由于重写的 HTTP 服务器是版本 32 中的新功能，因此在该服务器出现在稳定的 Bitcoin Core 版本中之前，该特定缺陷就已被发现。

Kimi K3 的使用符合比特币软件中人工智能辅助安全审查的最新模式。正如 crypto.news 在 8 月份报道的那样，比特币红队在扫描了数百个与比特币相关的开源项目后记录了 7,958 个潜在发现，尽管许多项目需要人工验证才能被视为已确认的漏洞。