Bitcoin Core合并修复：macOS上的bitcoin-cli无限超时连接问题
来源发布日期: 2026-10-07 · 编辑分析发布日期: 2026-10-07
Bitcoin Core修复macOS客户端超时问题；10月7日代码已合并，发行版需另行核实。
分析与实际影响
本节为本站分析及示例计算，与来源报道分开呈现。
今天的合并修复了客户端操作问题
根据官方 GitHub API，Bitcoin Core 于 10 月 7 日 07:27:37 UTC 合并了 pull request #36340。 此更改解决了涉及 -rpcclienttimeout=0 的 bitcoin-cli 的 macOS 连接失败问题。 我们检查了当前的 API 状态并更改了文件，因为缓存的网页仍然显示较旧的打开状态。 合并开发变更是已确认的事件。 它并不能确定特定的打包版本、操作系统存储库或矿工固件已包含更正。
与挖矿基础设施相关的是用于与节点通信的命令行客户端。 即使节点本身正在运行，失败的命令也可能会中断监控或管理工作流程。 我们的解释是，该消息属于软件可靠性，其范围与挖矿性能分开。 它不是一种新的 ASIC 调整模式，也不是对工作量证明的更改，也不是声称设备在安装后将提交更多可接受的哈希值。 受影响的组件和实际代码路径应保持明确。
一层的零可以在另一层变成大数
拉取请求解释说，客户端记录的无超时设置在内部由非常长的持续时间表示。 然后该值到达套接字等待实现。 我们的分析是，这是面向用户的选项和实现它的操作系统原语之间的边界。 描述为无限的选项仍然可以通过软件转换为有限值。 如果较低级别的 API 无法接受该值，则该命令可能会因可见选项名称不明显而失败。
这种区别有助于解释为什么连接错误并不总是证明节点处于离线状态或其凭据错误。 程序可能会在预期交换完成之前拒绝本地参数。 操作员在解释错误时应区分名称解析、连接建立、身份验证、请求处理和响应等待。 这些是一般的诊断边界，而不是所有这些边界在比特币核心中都有缺陷的报告。 此处，源确定了一个过大的等待值，因此分析仍集中在该机制上。
最终补丁限制底层等待时长
当前更改的文件证据显示了 Sock::WaitMany 中应用的限制以及零超时客户端选项的功能检查。 对于单个有界等待，代码使用最大的有符号整型毫秒值（大约 24.8 天）。 这不应该被重写为新实现的本机无限等待。 早期的讨论考虑了单独的方法，但检查的最终更改保留了上限。 我们的报道遵循实际的合并代码，而不是对话中的中间提案。
单位转换很重要：毫秒和秒相差 1000 倍。通过多个层的超时值可能会获得不同的限制，具体取决于每个层接受的表示形式。 这是一个软件界面问题，而不是电力或网络算力计算问题。 我们的解释是，使用可表示的持续时间可以防止报告中确定的立即失败，同时将更广泛的超时语义作为单独的主题。 读者不应从等待上限的大致时长推断无限的操作保证。
存储库状态和已发布的软件是不同的事实
合并记录了开发存储库接受了更改。 向用户的分发可以遵循发布、向后移植或软件包更新，每个都有自己的时间安排。 我们的分析不会在不检查其内容的情况下将修复程序分配给编号的可下载版本。 主要 API 提供了可用于跟踪更改的合并提交。 用户决定是否更新应该比较实际安装的版本和相关发布信息，而不是仅仅依赖本文的日期。
这种区别对于有意保留在稳定分支上的基础设施特别有用。 对开发分支的更正并不意味着每个稳定包都发生了变化。 向后移植标签或讨论也不能证明向后移植已被合并和发布。 因此，我们的报道将计划的后续行动与已验证的纳入分开对待。 下一个有用的证据是相应的分支提交或发布文档，其中明确声明了操作员需要哪个构建来获得更正。
相关的早期修复解决了客户端的不同部分
ASIC.tools 之前介绍了另一个拉取请求中对空响应和 RPC 客户端超时处理的更改。 新项目是对传递给套接字等待的大值的单独合并更正，而不是先前事件的重新发布。 我们的解读是，这两层可以影响相同的用户工作流程，同时解决不同的机制。 记录拉取请求和合并日期可以使新开发保持可识别性，并避免将旧的发行说明呈现为新的公告。
对于维护者来说，这种分离使得回归报告更加精确。 一次更新后持续存在的症状可能需要检查较低级别的等待实现，而不是假设从未安装过早期的更正。 它还避免将每个客户端错误归因于单个补丁。 实际审查遵循错误、提供的选项、操作系统和确切的二进制文件。 这些细节比 RPC 已修复的一般性声明提供了更多信息，这可能意味着比任何单个更改实际具有的范围更广泛。
本地检查应在不更改挖掘设置的情况下建立行为
对于受此问题影响的操作员，受控的只读客户端请求可以帮助区分本地客户端故障和节点问题。 准确的测试应该与安装的版本和授权的节点配置相匹配。 我们的分析倾向于在更改不相关的设置之前捕获命令结果、客户端版本和观察到的错误。 连接测试不需要更改钱包、池端点、设备频率或冷却配置，并且此代码更改没有提供任何证据表明这些调整将解决已识别的超时边界。
成功的短请求表明特定交换在测试条件下完成。 它并不能证明每个长期运行的请求都会无限期地保持健康。 监控仍应记录中断和恢复行为。 这些是独立的操作考虑因素，而不是 ASIC.tools 在所有支持的平台上执行的测试的声明。 我们验证了来源和最终的差异； 我们尚未在每个 macOS 版本中重现该错误，也没有发布独立认证的兼容性矩阵。
更多重试可以掩盖请求失败的原因
自动化系统可能会重试失败的请求，但重试并不能替代识别错误的层。 重复提交相同的本地无效等待参数可能会产生重复失败。 我们的解释是，运营商应该区分请求被接受之前的失败和提交之后的不确定结果。 这种区别除了这个特定的错误之外还很重要，因为一些管理 RPC 调用会更改状态，而另一些则只能读取状态。 在重复状态改变操作之前，应协调不确定的结果。
本文并不声称合并的超时更正会更改事务策略或使每个 RPC 调用都可以安全地重复。 它解决一种连接行为。 一般的操作经验是记录足够的信息来确定请求是否到达服务器以及其结果是否已知。 只读诊断可以提供证据，而无需引入重复操作。 在监控和管理工具中保持这种纪律使得小型客户端可靠性修复比将其视为不经调查而增加重试次数的原因更有用。
ASIC.tools 读者有何变化
已确认的更新是合并的客户端更正，由官方存储库 API 和检查的更改文件支持。 它的日期是今天的合并日期，与打开拉取请求的旧日期不同。 尚未根据此消息重新分配 ASIC 二进制文件。 为想要检查最终更改的读者提供了比特币核心源代码的链接，并且存储的研究记录包括用于解决网页显示的过时状态的 API 证据。
实际的要点是在调查监控故障时将客户端行为、节点状态和挖矿设备配置分开。 遇到这个确切的 macOS 选项问题的操作员可以在选择更新之前跟踪发布或向后移植证据，然后验证实际安装的二进制文件的行为。 这篇文章避免承诺算力增益或声称开发合并已经发布。 它的照片是计算和基础设施的上下文插图，而不是作为纠正软件行为证据提供的屏幕截图。
挖矿计算器 ↗
