Bitcoin Core merges RPC client timeout and empty-response fixes
Source report: 2026-10-02 · Editorial analysis published: 2026-10-03
The master branch now distinguishes Content-Length: 0 from a missing header and resets rpcclienttimeout for each socket wait; the change is merged source code, not a released binary.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
Two command-line client fixes reached master
Bitcoin Core maintainers merged pull request 36299 into the master branch on October 2. The change contains two commits and modifies the command-line HTTP client used by tools such as bitcoin-cli. One commit handles an explicitly empty response body correctly, and the other restores the intended idle-time behavior of rpcclienttimeout. The merge is a source-development event. It does not mean every installed Bitcoin Core node or binary package already includes the fixes.
An empty body was confused with no length header
The client represented a missing Content-Length header and a present header with value zero in the same way. A response explicitly declaring Content-Length: 0 could therefore enter the path for a response without a known length and continue reading until the peer closed the connection. The Bitcoin Core RPC server closes connections for errors including a wrong password, which limited the practical effect in that common case, but the client should still recognize that an empty body is complete.
The patch preserves the distinction explicitly
The change uses an optional length value so absent and present-but-zero states are different. When the server sends Content-Length: 0, the client can complete without depending on connection closure. This is a protocol-correctness fix rather than a change to RPC methods, wallet rules or mining consensus. It matters most to automation that expects predictable command completion when proxies, test servers or unusual endpoints return a valid empty response.
The timeout had become a phase-wide countdown
After removal of the previous libevent client implementation, rpcclienttimeout no longer measured only periods with no network progress. The countdown could continue across an entire read phase even while new data arrived. A sufficiently large or slow response could therefore be cut off despite active transfer. The merged patch applies the timeout to each socket wait, restoring the earlier interpretation: the client gives up after an idle wait, while received data allows another timed wait.
Pools often automate RPC-heavy workflows
Mining pools, solo gateways and monitoring systems call Bitcoin Core for block templates, chain state, mempool information and transaction submission. A timeout that ignores progress can create false failures on large responses or slow links, while ambiguous empty-body handling can delay error reporting. The merged change improves the client side of those workflows. It does not alter getblocktemplate output, Stratum behavior, share validation, proof-of-work or the network difficulty algorithm.
Testing coverage differs between the two commits
The pull request added a test for the empty-response behavior. The author stated that a reliable automated test for the progress-sensitive timeout was not included because attempted approaches were flaky or disproportionately complex. Reviewers acknowledged the approach and tested the empty-response case. The absence of a dedicated timeout regression test does not make the code unreviewed, but operators should recognize the different evidence available for each part of the patch.
Production systems should wait for a release
The merge commit is dd809d2c08a32d0775ddde771380f6f8eeae3a61 on master. Administrators using official Bitcoin Core binaries will receive the change only in a release branch and signed build that contains it. Building master immediately increases exposure to unrelated development changes. A safer process is to reproduce the affected behavior in staging, track backports or release notes, verify signed artifacts and then confirm scripts under realistic response sizes and network delay.
What is confirmed and what is unchanged
Confirmed facts are the October 2 merge, two commits, the explicit empty-body distinction and per-socket-wait timeout behavior. The change does not announce a final Bitcoin Core version, security emergency, consensus fork or mining-performance improvement. Its operational value is narrower: more reliable command-line RPC behavior for empty and slowly progressing responses. Pool engineers should review their own timeout wrappers as well, because an external supervisor can still terminate a command independently of Bitcoin Core’s setting.
Source: Bitcoin Core ↗
Mining calculator ↗
