Bitcoin Core caps queued HTTP responses with 32 MiB backpressure
Source report: 2026-09-18 · Editorial analysis published: 2026-09-20
Merged PR #36174 pauses request processing when a connection’s send buffer grows beyond 32 MiB. Pool and node operators should understand the scope, deployment status and monitoring impact.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
What changed
Bitcoin Core PR #36174 adds send-side backpressure to the project’s replacement HTTP server. Bitcoin Optech’s September 18 summary says a client could previously issue many requests without reading the responses, allowing queued response data to grow without a bound tied to that connection. The new behavior pauses further request processing when the connection’s send buffer exceeds 32 MiB and resumes after the client drains enough data. This complements an earlier receive-side control; it addresses a resource-management path in the newer server implementation rather than changing Bitcoin consensus or mining rewards.
Why miners may care
Mining pools, template services, monitoring systems and solo-mining stacks often call Bitcoin Core RPC or REST endpoints. A poorly written or stalled client that keeps requesting data without consuming replies can waste memory and compete with legitimate control traffic. Backpressure lets the TCP connection slow that client instead of allowing application queues to expand indefinitely. The change does not make public RPC safe, does not authenticate clients, and does not replace firewalling. Its value is defense in depth for authorized integrations and mistakes inside a trusted network.
The 32 MiB threshold
The 32 MiB value is a per-connection send-buffer threshold described for the new logic, not a global Bitcoin Core memory limit. Reaching it does not mean the node discards blockchain data or bans the peer; processing on that connection pauses until the queued output is drained below the resume condition. Total process memory still includes chainstate, mempool, caches, other connections and operating-system buffers. Capacity planning should therefore use resident memory and connection counts, not multiply 32 MiB by a guessed number and treat the result as a guarantee.
Merged code is not an installed release
The pull request was merged into Bitcoin Core’s development tree and was highlighted by Optech on September 18. That does not establish that every stable binary already contains it. Operators should identify the exact Bitcoin Core version and build commit they run, read the release notes for the eventual packaged version and test in staging. Do not replace a reproducible signed release with an arbitrary development build simply to obtain one fix. If exposure is urgent, reduce it at the reverse proxy, firewall and client level while maintaining a supported upgrade path.
Audit every RPC consumer
Inventory software that talks to bitcoind: pool coordinators, block-template builders, explorers, payment services, metrics collectors, backup jobs and ad hoc scripts. For each client record endpoint, authentication method, request frequency, response size, timeout and maximum concurrency. Confirm that the library reads or cancels every response and closes abandoned streams. Set bounded retries with jitter rather than immediate retry loops. A client can remain TCP-connected yet stop reading, so simple connect-success monitoring is not enough to detect the condition this change targets.
Protect the control plane
Bind RPC to the smallest required interface, restrict source networks, use strong credentials and avoid exposing the service directly to the internet. A reverse proxy can impose connection, request-rate, body-size and idle-time limits, but proxy settings must be tested with long legitimate responses. Separate monitoring traffic from latency-sensitive block-template paths where practical. Keep templates, Stratum service and miner failover observable during node maintenance. The HTTP backpressure fix improves one queue, while access control and architecture still determine the blast radius of a faulty client.
Monitoring and test procedure
In a staging environment, replay representative RPC and REST calls while one test client deliberately reads responses slowly. Watch resident memory, open descriptors, response latency, HTTP connection count and the health of an independent mining client. Confirm that the slow connection is throttled and that service recovers after it drains or disconnects. Do not perform an uncontrolled load test against a production pool. After deployment, alert on sustained memory growth and latency, but avoid treating a brief queue or one large response as proof of attack.
Operational conclusion
PR #36174 closes a specific unbounded-response-queue behavior in the replacement HTTP server. For mining infrastructure, the practical action is to inventory clients, bound their behavior, limit access and plan an upgrade when the fix reaches the supported release used by the site. It is not a hashrate optimization and should not change share accounting. A successful rollout is measured by stable memory and responsive RPC under a slow-reader test, plus unchanged block-template, pool and monitoring behavior.
Source: Bitcoin Core / Bitcoin Optech ↗
Mining calculator ↗
