Bitcoin Core privacy backport gains review but awaits merge
Source report: 2026-10-09 · Editorial analysis published: 2026-10-11
An October 9 review acknowledges Bitcoin Core’s private-broadcast patch for 31.x. The proposal remains open at verification; an approved review, a merged change and a downloadable stable release are separate milestones.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
A fresh review of the stable-series backport
On October 9, reviewer davidgumberg posted an ACK for commit 22ac577 on Bitcoin Core pull request 36358. The proposal targets the 31.x branch and remains open at our October 11 check, with a 31.2 milestone. Its purpose is to keep private-broadcast connections outside ordinary peer-discouragement handling while still disconnecting misbehaving private peers. A review acknowledgement is not a merge, and a milestone is not an announced release date.
This matters to operators who deliberately use the experimental transaction-broadcast feature and need to know which software path contains a repair. Our report treats the review as the new event and supplies earlier development history as context. It does not describe a new ASIC firmware file or claim that every node is exposed through its default configuration. The hardware catalogue and manufacturer firmware archive are separate from Bitcoin Core’s node software.
Where the repair has already landed
The original change, pull request 36312, merged into the main development branch on September 25. The 32.x backport bundle, pull request 36300, merged on October 1 and includes the same repair. Those repository events establish the presence of code in those branches. They do not establish that a machine still running the earlier stable binary has obtained the change, nor that a new final release has been installed anywhere.
A version label has to be tied to the actual executable and its source. A branch can contain a fix while a packaged release from another branch does not. Conversely, a distributor may apply a backport that changes the code without using the same upstream release label. An operator should retain the package origin and exact build information instead of treating the highest version number seen in a headline as a complete security assessment.
The feature is deliberately optional
The earlier 31.0 release notes describe private broadcast as an option affecting transactions submitted through sendrawtransaction, using dedicated connections through privacy networks. A separate documentation change, pull request 36309, narrows the privacy claims and marks the feature experimental. It is disabled by default. These qualifications are relevant because the reported repair concerns a specific optional broadcast path, not every ordinary connection or every transaction seen by a node.
For a mining business, identify whether its own software actually submits transactions through that path before assessing the operational significance. An ASIC communicating with a pool is not the same service as a Bitcoin Core node broadcasting a wallet transaction. Listing the services and their dependencies helps avoid changing a mining configuration in response to a patch that belongs to a different component. The headline does not establish a defect in an Antminer or WhatsMiner network interface.
Observable connection handling is a privacy boundary
The patch description identifies a connection-handling effect that may be observable from outside. The design separates private-broadcast peers from ordinary discouragement handling and retains disconnection of private peers that misbehave. Our interpretation is that this separation seeks to reduce a possible correlation signal. It is not a promise that a node, a wallet or a person becomes untraceable under every network condition after the change.
As an editorial way to reason about the issue, ask which externally visible actions are shared between a supposedly separate workflow and the normal workflow. If a decision in one path changes the behaviour of another, an observer may learn a relationship the operator did not intend to expose. This is an explanation of a system boundary, not a new vulnerability test. We have not measured exploitation on a live network or assessed any reader’s node.
Do not confuse it with the earlier 31.1 repair
The official Bitcoin Core 31.1 notes describe an earlier private-broadcast connection-routing repair involving the configured proxy during reconnection. That earlier issue and the present peer-handling proposal address different mechanisms. The official download page still presents 31.1 as the latest stable version at our check. Its presence is evidence of an available release, not evidence that the currently open 31.x proposal has already shipped in it.
Maintenance records should map each relevant issue to the version or package that actually contains its fix. Combining several privacy-related headlines into one assumed patch can make an operator believe a later problem has been addressed when only an earlier one was covered. Keep the upstream links and review dates in the change record. A repository discussion about a future maintenance version cannot replace a verified release note for the binary in use.
A controlled update begins with an inventory
Before scheduling a node update, retain the exact version, package source, relevant configuration and the services that depend on the node. For a pool or business wallet, include the transaction submission path and any automation expecting particular RPC behaviour. This inventory makes it possible to decide whether a specific upstream change affects the installed system. It also prevents a generic firmware-maintenance process from being applied to node software with different data and availability requirements.
A practical verification plan checks service startup, synchronization status, required RPC calls and transaction-broadcast behaviour in an appropriate test environment before the production window. Record the result and retain a recovery plan for the configuration and data involved. These are editorial operating suggestions, not new project release instructions or a recommendation to install an unreviewed branch. A testing candidate and a stable production package should remain visibly different choices.
Release status must be checked at the moment of use
The recorded status is a dated snapshot: the 31.x proposal was open when reviewed on October 11. It can change after publication. A later merge would establish another milestone, but operators would still need to identify a distributed build that contains it. The distinction matters when a maintenance window is planned several days after a news item is read. Recheck the official project records before attributing a fix to an installed version.
An independent illustration is a fleet with ten node instances, of which eight have been upgraded to a verified package and two remain on an earlier build. A release announcement alone does not make all ten updated. Track the actual executable and restart outcome for each instance rather than converting software availability into a deployment count. The example is hypothetical; it does not describe Bitcoin Core’s adoption rate or a surveyed mining pool.
What miners should take from the update
The immediate news is progress in review of a backport, with stable-series delivery still awaiting further steps in the checked records. It does not change Bitcoin’s proof-of-work algorithm, an ASIC’s nominal speed or a farm’s electricity consumption. The useful operational response is to identify the affected optional service and follow the official release path, preserving the difference between code review, merge, packaging and installation.
Two licensed archival network photographs illustrate the networking context. They do not depict an attack, a developer’s test system or a mining company affected by the issue. The primary source and supporting project records are linked below with their dates. This article reports a specific current review event and explains its operational limits; it does not label a future release as downloadable or invent a deadline for the 31.2 milestone.
Source: Bitcoin Core / GitHub ↗ · Original private-broadcast patch ↗ · 32.x backport bundle ↗ · Experimental feature and qualified privacy claims ↗ · Official Bitcoin Core 31.0 notes ↗ · Official Bitcoin Core 31.1 notes ↗ · Current official stable download ↗
Mining calculator ↗
