Bitcoin Core 31.0 users running the new -privatebroadcast feature face a privacy bug that can reveal the transaction originator’s IP address to a receiving peer under specific network conditions.
The issue affects a narrow set of users. A node must be running Bitcoin Core 31.0 with -privatebroadcast enabled, broadcasting through the sendrawtransaction RPC, able to reach Tor for outbound connections, still able to make direct IPv4 or IPv6 outbound connections, and using BIP324 v2 transport without disabling it.
Wallet RPCs such as sendtoaddress and sendall are not affected because they do not use private broadcast. The bug also does not put private keys, wallet balances or Bitcoin consensus rules at risk. It is a network privacy issue, not a funds-draining exploit.
Private Broadcast Was Built To Hide Origin IPs
Bitcoin Core 31.0 introduced -privatebroadcast as a privacy upgrade for users broadcasting raw transactions. The feature was designed to route transaction broadcasts through Tor or I2P, preventing receiving peers from learning the sender’s IP address and making unrelated broadcasts harder to link.
The bug breaks that IP privacy guarantee in one fallback path. When private broadcast selects an IPv4 or IPv6 peer that advertises BIP324 v2 transport, the first connection goes through Tor as intended. If the v2 handshake fails, Bitcoin Core retries the connection using v1 transport. That retry can bypass the Tor proxy and connect directly over IPv4 or IPv6, exposing the sender’s clearnet IP address to the peer.
The affected path is most relevant if a malicious peer advertises v2 support and then deliberately closes the v2 handshake to force the v1 retry. Onion and I2P peers are not affected in the same way because their retries remain routed through their respective proxy networks.
Workarounds Available Before 31.1
A fix is planned for Bitcoin Core 31.1. Until then, affected users have three practical workarounds.
They can disable the feature by setting -privatebroadcast=0. They can disable v2 transport with -v2transport=0, although that moves connections back to the unencrypted v1 protocol and can make clearnet traffic easier to fingerprint or censor. They can also route all IPv4 and IPv6 outbound P2P traffic through Tor with a proxy setting such as -proxy=127.0.0.1:9050, adjusted to match the user’s Tor SOCKS port.
For node operators who do not use sendrawtransaction with -privatebroadcast, the advisory does not require the same operational change. The highest-risk group is privacy-sensitive users who enabled the new feature specifically to prevent transaction broadcasts from being linked to their IP address.
Bitcoin Privacy Depends On Network Hygiene
The bug shows how Bitcoin privacy can fail at the network layer even when coins, signatures and consensus remain safe. Broadcasting a transaction from a clearnet IP can give a monitoring peer useful metadata, especially when combined with timing, geolocation or repeated transaction patterns.
That makes the fix important for users who rely on Bitcoin Core for stronger self-custody privacy rather than only basic wallet operation. Recent security alerts have already put wallet safety under pressure, including a separate wallet-generation flaw draining dormant crypto addresses and renewed warnings around fake apps, phishing and wallet drainers.
Bitcoin Core’s 31.1 release will now carry extra attention from node operators and privacy-focused users. Until that patch is available and installed, the safest setup for affected users is to disable private broadcast or force outbound clearnet connections through Tor so a failed v2 handshake cannot expose the origin IP.
