Bitcoin Core Merges Bitcoin (BTC) Private Broadcast Fix Into 32.x Branch

Fix Lands in the 32.x Branch

Node operators on the stable release are the party still waiting. The Bitcoin (BTC) Core development team merged a fix for its privacy-preserving private broadcast feature into the 32.x branch on October 1, and the current stable series, 31.x, still carries none of it. Bitcoin Core is the reference implementation behind a large share of full nodes on the proof of work network, so changes in how it relays traffic reach wallets, exchanges and services that depend on those nodes to broadcast transactions. The private broadcast feature arrived in Bitcoin Core 31.0 as an experimental option, disabled by default. It transmits raw transactions over short-lived dedicated connections routed through anonymity networks such as Tor or I2P, which keeps a sender's IP address away from the peers that first receive the transaction. The flaw the patch addresses is one of correlation rather than direct exposure. Under the old behavior, a node that received bad behavior over a dedicated connection could discourage that peer, applying the same penalty it uses on ordinary connections. That penalty is observable from outside the node, and discouraging a regular peer can also cut other connections to the same address. An observer watching connection churn could therefore link a private broadcast connection to the same node's regular traffic, defeating the feature's purpose. The reworked logic removes dedicated connections from the normal discouragement path. A peer that misbehaves on a private broadcast connection is still disconnected, but ordinary discouragement no longer tears down dedicated connections sharing that address. The project's public development records, as of October 9, show the fix living in the 32.x line, which carries the unreleased 32.0, while 31.1 and the rest of the stable series wait. The change touches relay code, not the Bitcoin (BTC) price.

31.x Backport Still Unmerged

The merge trail shows how the fix traveled before stalling. The original patch entered the development master on September 25 and reached the 32.x branch on October 1, where it is set to ship with 32.0. A direct port to 31.x did not apply cleanly, so a developer rebuilt the backport for the stable series and proposed it on September 27. Approvals from reviewers followed on September 28, October 6 and October 9, but the merge itself has not landed, and the project has set no release date for 31.2, the next maintenance version in the stable line. The project logs every merge in public, so the gap between the latest approval and the pending merge stays visible in the open pull request. Versioning explains the stakes. Bitcoin (BTC) Core ships point releases inside a numbered series, so 31.1 and the eventual 31.2 both belong to 31.x, while 32.0 opens the next one. A fix merged into 32.x does nothing for nodes pinned to the stable branch until it is backported, merged and released. One earlier fix in this series is easy to confuse with the pending one. Bitcoin Core 31.1 already corrected a different privacy bug, one in which dedicated connections could fall back to the regular network instead of the anonymity layer, leaking the node's IP address outright. That was direct exposure. The backport now waiting in review closes the subtler path, where penalty behavior on a dedicated connection lets an outside observer associate it with a node's ordinary connections. Until 31.2 ships, operators running the stable branch hold the IP-leak correction but not the correlation fix, a gap that matters most to anyone who enabled the experimental feature deliberately and assumed the stable release carried the full fix set.

Node Operators Hold the Last Step

Sequencing decides who is protected. Bitcoin (BTC) has moved privacy-sensitive changes at node-operator pace before, as with Segregated Witness, which needed months of adoption after activation to become the default transaction path, and private broadcast follows the same pattern: default off, useful only to the minority that enables it. The 31.x wait is not a regression, but it leaves the feature's least cautious users, those who turned it on inside the stable release, running the flawed penalty logic until 31.2 lands. Privacy tooling is a standing priority for voices tied to Bitcoin maximalism, yet the software moves on merge timelines, not sentiment. The party that has not moved is the release team, and until the 31.x patch is merged with a 31.2 date attached, the stable branch keeps the gap.