Bitcoin Core 31.0's private broadcast promise now has a documented exception
Bitcoin Core 31.0 said private broadcasts would keep "Their IP address ... is never known to the recipients". The latest advisory shows that is not always true: under certain network conditions, the originator's IP can still be exposed when private broadcast is enabled.
For operators using the feature for maximum privacy, that matters. The issue does not affect every user, but it does hit the core privacy guarantee the feature was supposed to provide.
Who is actually affected
The bug only affects a narrow setup:
- Bitcoin Core 31.0
- -privatebroadcast enabled
- Transactions sent through sendrawtransaction RPC
- Tor is reachable for outbound connections
- Direct IPv4 or IPv6 outbound connections are also possible
If you use wallet RPCs such as sendtoaddress, you are not in scope. For most average users, that means limited exposure. For operators specifically relying on private broadcast, the issue is still worth addressing before 31.1.
Why the v2 fallback exposes the privacy gap
The problem is not that v2 simply fails. It is what happens after. When a peer advertises v2 support, the first connection is routed through Tor as expected. But when the v2 handshake fails, Bitcoin Core retries the connection as v1 without routing it through Tor. In that case, the peer can see the originator's IP address.
This is also the part that matters most for trust. The advisory says the bug is in the new -privatebroadcast feature introduced in 31.0, and it was reported by Eugene Siegel. That does not mean the whole project is unstable; it does mean a new privacy feature did not fully hold up under real network conditions.
Why the trigger path matters
The advisory says the leak is easiest to trigger when a peer causes the v2 handshake to fail, forcing the buggy v1 retry. That makes the issue more than a random edge case: it suggests an attacker could more cheaply push the node into the leakier path.
A fix is scheduled for 31.1, so this is not an unresolved long-term problem. Still, the reputational hit is straightforward: a feature described as private should not silently fall back to a less private connection path.
The bigger test is Bitcoin Core's disclosure credibility
This bug also lands against a backdrop of recent release-cycle transparency. With 31.0, the project said versions 28.x and older are at "End of Life", so operators cannot simply downgrade and expect continued support.
At the same time, the project's recent move toward structured disclosure is now part of the story. When that process was introduced, the team published 10 security advisories as part of a more transparent policy. The current expectation is that medium- and high-severity vulnerabilities fixed in older versions will be disclosed in the upcoming window, with low-severity vulnerabilities fixed in 31.0 stated to have none.
That is why this issue is being read as more than a code bug. Operators are watching whether the release and disclosure process can keep pace with the privacy narrative around recent releases. The main signposts are the 31.1 patch and how cleanly the project handles the upcoming disclosures.
What node operators should do before 31.1
Action should be practical, not panicked. The bug only hits Bitcoin Core 31.0 with -privatebroadcast set when transactions are sent via sendrawtransaction RPC and the node can still make direct IPv4 or IPv6 connections.
- If you use wallet RPCs such as sendtoaddress, you are out of scope and can wait for 31.1.
- If you broadcast sensitive transactions with sendrawtransaction and want the strongest privacy posture until the patch, disable the feature by setting -privatebroadcast=0.
- If you already restrict outbound traffic with -onlynet or route everything through -proxy, you may already be outside the affected configuration.
What to watch next
The near-term test is simple: whether 31.1 arrives with a fix that closes the v1 retry path, and whether the project's disclosure process remains clear and timely. Until then, operators using private broadcast should treat this as a real, scoped mitigation problem rather than a broad market signal.