Bitcoin Core flags a narrow IP leak

Bitcoin Core published a privacy notice on June 6 about Bitcoin Core 31.0: the -privatebroadcast feature, introduced in that release, can reveal the sender's IP address to the peer receiving a transaction under specific network conditions. The affected case is narrow but concrete. It applies to nodes running Bitcoin Core 31.0 with -privatebroadcast enabled, broadcasting transactions through the sendrawtransaction RPC, able to reach Tor for outbound connections, still able to make direct IPv4 or IPv6 outbound connections, and not disabling BIP324 v2 transport. Wallet RPCs such as sendtoaddress are not affected, according to the notice.

The purpose of -privatebroadcast is to route transaction broadcast through Tor, reducing the observable link between a transaction and the network address of the node that originated it. The leak appears when the selected peer advertises encrypted BIP324 v2 transport, the initial connection is correctly routed through Tor, and the v2 handshake then fails. Bitcoin Core may fall back to a direct unencrypted connection to the same peer, exposing the sender's IPv4 or IPv6 address to that peer. This does not break Bitcoin itself, but it weakens a privacy mechanism that users may reasonably treat as sensitive.

The advisory gives several workarounds until Bitcoin Core 31.1, where a fix is planned. The most straightforward option is to stop using -privatebroadcast until the corrected release is available. Users who still need it can restrict outbound connections to Tor with -onlynet=onion, or configure a global proxy with -proxy. Another mitigation is to disable BIP324 v2 transport with -v2transport=0, because the leak depends on failure during that negotiation path.

The useful signal is that Bitcoin privacy often depends on transport details, not only on consensus rules or transaction formats. A private broadcast option can be well designed in intent and still fragile in an error transition. For node operators, the practical lesson is modest but important: read security notices, understand network assumptions, and do not treat a configuration flag as a complete anonymity guarantee under every connection path.