Bitcoin Core 32.x 分支推进至第三个候选版本
来源发布日期: 2026-10-01 · 编辑分析发布日期: 2026-10-02
rc3 版本标记和重新生成的文档于 10 月 1 日合并，距 rc2 共 29 个提交。运营方应等待官方签名二进制文件，并把候选版视为测试软件。
分析与实际影响
本节为本站分析及示例计算，与来源报道分开呈现。
32.x 分支现在标识为 rc3
Bitcoin Core 维护者于 10 月 1 日合并了 pull request 36400，将 32.x 分支推进到版本 32.0rc3。 拉取请求本身包含三个提交：版本提升、重新生成的手册页和重新生成的示例 bitcoin.conf。 它更改了九个文件并合并为提交 2633a1de。 这是源代码控制方面的一个发布准备里程碑，而不是宣布最终的 Bitcoin Core 32.0 版本可用。 运营方还应保存原始公告、时间戳、合同或遥测记录，并把已经完成的事实与预测、目标和管理层表述分开。只有把容量、功耗、可用率、成本和交付日期放在同一口径下持续核验，才能判断该信息对矿场和数据中心经营的实际影响。
候选版本是为测试而构建的
Bitcoin Core 的生命周期文档解释了候选版本使用 rc 后缀，例如 rc1、rc2 和 rc3。 它们为开发人员、节点运营商和下游打包商提供了近乎最终的版本，以便在稳定的主要版本发布之前进行测试。 较高的 RC 编号本身并不意味着生产批准。 这意味着另一位候选者在更改或修复后已做好准备，并且测试仍可能揭示 rc4 或额外工作的原因。 运营方还应保存原始公告、时间戳、合同或遥测记录，并把已经完成的事实与预测、目标和管理层表述分开。只有把容量、功耗、可用率、成本和交付日期放在同一口径下持续核验，才能判断该信息对矿场和数据中心经营的实际影响。
该分支比 rc2 标记提前 29 次提交
GitHub 对 v32.0rc2 与 32.x 分支的比较显示，验证时有 29 个提交。 其中包括代码、测试、文档、构建调整和 rc3 版本生成提交。 计算提交并不是一个严重性衡量标准：一个小的操作修复可能比几次文档更新更重要。 运营商应阅读最终版本说明并检查他们使用的特定子系统，而不是仅从数字推断风险。 运营方还应保存原始公告、时间戳、合同或遥测记录，并把已经完成的事实与预测、目标和管理层表述分开。只有把容量、功耗、可用率、成本和交付日期放在同一口径下持续核验，才能判断该信息对矿场和数据中心经营的实际影响。
候选人进行了多项操作调整
rc2 和当前分支之间的变化包括费用估算器回退、无法加载内存池状态时清除挖掘块统计数据、保存关闭状态之前耗尽费用回调、标记私有广播实验性的措辞以及重复块模板日志的挖掘调试类别。 每个更改都有其自己的范围。 分支碰撞并不意味着共识规则的改变、更快的散列或工作量证明的改变。 运营方还应保存原始公告、时间戳、合同或遥测记录，并把已经完成的事实与预测、目标和管理层表述分开。只有把容量、功耗、可用率、成本和交付日期放在同一口径下持续核验，才能判断该信息对矿场和数据中心经营的实际影响。
挖掘日志更改单独向后移植
其中一项提交将 CreateNewBlock 权重消息移至挖掘调试类别后面。 ASIC.tools 单独覆盖了该补丁，因为频繁的块模板请求会生成重复的日志。 在 rc3 上下文中，它只是众多向后移植的操作更改之一。 需要该行的池管理员将需要包含该行的版本中的相关调试设置； 他们不应该假设每个已安装的节点都已经改变了行为。 运营方还应保存原始公告、时间戳、合同或遥测记录，并把已经完成的事实与预测、目标和管理层表述分开。只有把容量、功耗、可用率、成本和交付日期放在同一口径下持续核验，才能判断该信息对矿场和数据中心经营的实际影响。
检查时尚未列出官方 rc3 二进制文件
在 10 月 2 日的编辑检查中，官方的 Bitcoin Core 下载索引仍然暴露了 9 月 22 日签署的 32.0rc2 候选目录，而 rc3 目录尚未可用。 源代码控制准备通常先于可重复的构建、签名和发布。 这种时间上的区别可以防止合并版本碰撞被误报为可下载的签名软件。 可用性稍后可能会发生变化，因此运营商应在下载时检查官方索引和签名。 运营方还应保存原始公告、时间戳、合同或遥测记录，并把已经完成的事实与预测、目标和管理层表述分开。只有把容量、功耗、可用率、成本和交付日期放在同一口径下持续核验，才能判断该信息对矿场和数据中心经营的实际影响。
池应该测试它们实际使用的路径
矿池、独立网关和模板服务器应根据 getblocktemplate、费用估算、mempool 持久性、关闭和重新启动、RPC 身份验证、监控和警报来安排候选者。 测试节点不应共享生产钱包秘密。 操作员应保留可比较的日志和指标，在实际模板请求率下验证候选人的行为，并确认下游 Stratum 或作业分配软件完全按照预期处理响应。 运营方还应保存原始公告、时间戳、合同或遥测记录，并把已经完成的事实与预测、目标和管理层表述分开。只有把容量、功耗、可用率、成本和交付日期放在同一口径下持续核验，才能判断该信息对矿场和数据中心经营的实际影响。
验证比下载链接更重要
当二进制文件出现时，运营商应使用官方的 Bitcoin Core 分发位置，验证 SHA256SUMS 和签名，并比较其组织使用的签名者策略。 应首先将候选版本安装在隔离的测试环境中。 从 GitHub 源代码构建需要固定确切的提交并遵循可重现的构建过程。 从论坛或镜像复制的链接并不能确定该包对应于已审查的分支。 运营方还应保存原始公告、时间戳、合同或遥测记录，并把已经完成的事实与预测、目标和管理层表述分开。只有把容量、功耗、可用率、成本和交付日期放在同一口径下持续核验，才能判断该信息对矿场和数据中心经营的实际影响。
已确认的内容和待定的内容
已确认的事实是合并的 rc3 分支碰撞、其三个准备提交以及 rc2 标记和检查的 32.x 头之间的 29 个提交。 官方最终的 32.0 版本仍在等待中，并且在检查时尚未可见已签名的 rc3 二进制文件。 下一个证据是官方候选工件、可重复构建证明、测试人员报告和稳定标签。 生产升级应该遵循这些工件，而不是单独的分支名称。 运营方还应保存原始公告、时间戳、合同或遥测记录，并把已经完成的事实与预测、目标和管理层表述分开。只有把容量、功耗、可用率、成本和交付日期放在同一口径下持续核验，才能判断该信息对矿场和数据中心经营的实际影响。
来源: Bitcoin Core ↗
挖矿计算器 ↗
