Bitcoin Core’s development team posted on X on June 12, confirming that the -privatebroadcast feature newly introduced in Bitcoin Core version 31.0 contains a privacy vulnerability: under certain network conditions, if the v2 handshake fails, Bitcoin Core will connect to peer nodes via IPv4 or IPv6, thereby leaking the sender’s public IP address to the recipient.
Affected user conditions: five requirements must all be met
According to an official Bitcoin Core announcement, the node will only be affected by this vulnerability when all of the following five conditions are simultaneously true:
· The node is running Bitcoin Core 31.0, and the -privatebroadcast feature is enabled
· Transactions are broadcast via the RPC command sendrawtransaction (wallet RPCs such as sendtoaddress, sendall, etc. do not use private broadcasting, so they are not affected)
Tor can establish outbound connections
· Outbound IPv4 or IPv6 connections can be established directly (no -onlynet restriction, and no -proxy=... configuration)
· BIP324 v2 transport is not disabled (no -v2transport=0 is set)
Connections to onion and I2P peer nodes are not affected, because during any v1 retry, these connections always use their respective proxy routing.
Vulnerability technical mechanism: after v2 handshake failure, v1 retry does not go through Tor
According to the official description, the vulnerability is triggered as follows: when the private broadcast selection chooses IPv4 or IPv6 peer nodes that support v2 (BIP324) transport, the initial connection is expected to go through the Tor proxy route. If the v2 handshake fails, Bitcoin Core will attempt a retry using the v1 protocol; this v1 retry does not go through the Tor proxy route, but instead connects directly via IPv4 or IPv6, thereby leaking the initiator’s IP address.
This behavior violates the privacy guarantee stated in the 31.0 version documentation: “The receiver will never know their IP address (and location).” The development team confirmed that this vulnerability is most likely to be artificially triggered by a malicious peer that intentionally shuts off the v2 handshake to force a v1 retry.
Three temporary solutions: can be used before upgrading to 31.1
Bitcoin Core’s official website provides the following three temporary solutions:
Solution 1 (recommended): directly disable the -privatebroadcast setting by setting -privatebroadcast=0
Solution 2: disable v2 transport by setting -v2transport=0. Note: this setting will cause all node connections to use the unencrypted v1 protocol, making it easier to be fingerprinted and subjected to surveillance on the public internet.
Solution 3: route the node’s outbound IPv4/IPv6 traffic to Tor by setting -proxy=127.0.0.1:9050 (replace with the actual Tor SOCKS port). Note: this setting will make the node more susceptible to Sybil attacks.
FAQ
Are nodes that use wallet RPCs like sendtoaddress or sendall affected?
According to Bitcoin Core’s official announcement, wallet RPCs (such as sendtoaddress, sendall, etc.) do not use private broadcast, so they are not affected by this vulnerability. This vulnerability is only triggered when broadcasting via sendrawtransaction and when the other four conditions are also met.
Can this vulnerability occur naturally without the need for a malicious node?
According to the official description, for peer nodes that actually support v2 transport, a v2 handshake failure is unlikely under normal circumstances. This vulnerability is most likely to be artificially triggered by a malicious peer that intentionally turns off the v2 handshake to force a v1 retry.
What is the release schedule for Bitcoin Core 31.1?
According to Bitcoin Core’s official announcement, the fix will be released with version 31.1, but the announcement does not provide a specific release date. The official guidance is to use one of the three temporary solutions mentioned above before upgrading to 31.1.
