Bitcoin Core merges macOS fix for bitcoin-cli unlimited-timeout connections
Source report: 2026-10-07 · Editorial analysis published: 2026-10-07
PR #36340 was merged on October 7. It bounds the underlying socket wait used by -rpcclienttimeout=0; inclusion in a downloadable release or backport must be checked separately.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
Today’s merge fixes a client-side operating issue
Bitcoin Core merged pull request #36340 on October 7 at 07:27:37 UTC, according to the official GitHub API. The change addresses a macOS connection failure involving bitcoin-cli with -rpcclienttimeout=0. We checked the current API state and changed files because the cached web page still showed an older open status. A merged development change is the confirmed event. It does not establish that a particular packaged release, operating-system repository or miner firmware already contains the correction.
The relevance for mining infrastructure is the command-line client used to communicate with a node. A failed command can disrupt monitoring or an administrative workflow even when the node itself is running. Our interpretation is that this news belongs to software reliability, with its scope kept separate from mining performance. It is not a new ASIC tuning mode, a change to proof-of-work or a claim that devices will submit more accepted hashes after installation. The affected component and the actual code path should remain explicit.
Zero at one layer can become a large number at another
The pull request explains that the client’s documented no-timeout setting is represented internally by a very long duration. That value then reaches the socket-wait implementation. Our analysis is that this is a boundary between a user-facing option and the operating-system primitive that implements it. An option described as unlimited can still be translated into a finite value by software. If the lower-level API cannot accept that value, the command can fail for reasons that the visible option name does not make obvious.
This distinction helps explain why a connection error does not always prove that a node is offline or its credentials are wrong. A program may reject a local parameter before the expected exchange completes. Operators should distinguish name resolution, connection establishment, authentication, request processing and response waiting when interpreting an error. These are general diagnostic boundaries, not a report that all of them are defective in Bitcoin Core. Here the source identifies an oversized wait value, so the analysis stays focused on that mechanism.
The final patch caps the underlying wait
The current changed-file evidence shows a limit applied in Sock::WaitMany and a functional check for the zero-timeout client option. The code uses the maximum signed-int millisecond value, approximately 24.8 days, for an individual bounded wait. This should not be rewritten as newly implemented native infinite waiting. Earlier discussion considered a separate approach, but the inspected final change retains a cap. Our coverage follows the actual merged code rather than an intermediate proposal in the conversation.
The unit conversion is important: milliseconds and seconds differ by a factor of 1000. A timeout value passed through several layers can acquire different limits depending on the representation each layer accepts. This is a software-interface issue, not an electricity or network-hashrate calculation. Our interpretation is that using a representable duration prevents the immediate failure identified in the report while leaving broader timeout semantics as a separate subject. Readers should not infer an unlimited operating guarantee from the approximate length of the cap.
Repository status and released software are separate facts
A merge records that the development repository accepted a change. Distribution to users can follow through a release, a backport or a package update, each with its own timing. Our analysis does not assign the fix to a numbered downloadable release without checking its contents. The primary API provides a merge commit that can be used to trace the change. A user deciding whether to update should compare the actual installed version and the relevant release information rather than rely on the date of this article alone.
This distinction is particularly useful for infrastructure that intentionally stays on a stable branch. A correction on the development branch does not mean every stable package has changed. A backport label or discussion also does not prove that the backport has been merged and shipped. Our coverage therefore treats planned follow-up separately from verified inclusion. The useful next evidence is the corresponding branch commit or release documentation, with a clear statement of which build an operator would need to obtain the correction.
A related earlier fix addressed a different part of the client
ASIC.tools previously covered changes to empty responses and RPC client timeout handling in another pull request. The new item is a separate merged correction to the large value passed to the socket wait, rather than a republication of that earlier event. Our reading is that the two layers can affect the same user workflow while addressing different mechanisms. Recording the pull request and merge date keeps the new development identifiable and avoids presenting an old release note as a fresh announcement.
For maintainers, this separation makes a regression report more precise. A symptom that persists after one update may require examining the lower-level wait implementation rather than assuming that the earlier correction was never installed. It also avoids attributing every client-side error to a single patch. The practical review follows the error, the option supplied, the operating system and the exact binary. Those details are more informative than a general statement that RPC was fixed, which can imply a broader scope than either individual change actually has.
A local check should establish behavior without changing mining settings
For an operator affected by this issue, a controlled read-only client request can help distinguish a local client failure from a node problem. The exact test should match the installed version and authorized node configuration. Our analysis favors capturing the command result, the client version and the observed error before changing unrelated settings. A test of connectivity does not require changing a wallet, pool endpoint, device frequency or cooling configuration, and this code change provides no evidence that those adjustments would resolve the identified timeout boundary.
A successful short request shows that a particular exchange completed under the tested conditions. It does not prove that every long-running request will remain healthy indefinitely. Monitoring should still record interruptions and recovery behavior. These are independent operating considerations rather than claims of testing performed by ASIC.tools on all supported platforms. We verified the source and the final diff; we have not reproduced the bug across every macOS release or published an independently certified compatibility matrix.
More retries can conceal the reason a request failed
An automation system may retry a failed request, but retrying is not a substitute for identifying the error’s layer. Repeatedly submitting the same locally invalid wait parameter can produce repeated failures. Our interpretation is that an operator should distinguish failures before a request is accepted from uncertain outcomes after submission. That distinction matters beyond this specific bug because some administrative RPC calls change state, while others only read it. An uncertain result should be reconciled before a state-changing action is repeated.
This article does not claim that the merged timeout correction changes transaction policy or makes every RPC call safe to repeat. It addresses one connection behavior. The general operating lesson is to log enough information to decide whether the request reached the server and whether its result is known. A read-only diagnostic can provide evidence without introducing duplicate operations. Keeping that discipline in monitoring and administrative tooling makes a small client reliability fix more useful than treating it as a reason to increase retry counts without investigation.
What changes for ASIC.tools readers
The confirmed update is a merged client-side correction, supported by the official repository API and inspected changed files. Its date is today’s merge date, distinct from the older date on which the pull request was opened. No ASIC binary has been reassigned on the basis of this news. The Bitcoin Core source is linked for readers who want to inspect the final change, and the stored research record includes the API evidence used to resolve the stale status shown by the web page.
The practical takeaway is to keep client behavior, node state and mining-device configuration separate when investigating a monitoring failure. Operators encountering this exact macOS option issue can follow release or backport evidence before choosing an update, then verify the behavior of the actual installed binary. The article avoids promising a hashrate gain or claiming that a development merge is already shipped. Its photographs are contextual illustrations of computing and infrastructure, not screenshots offered as proof of the corrected software’s behavior.
Source: Bitcoin Core / GitHub ↗
Mining calculator ↗
