What changed, and why it matters
This commit adds release notes describing a privacy bug that was fixed in Bitcoin Core pull request #35319. The bug could accidentally reveal a user's real IP address when sending a transaction privately using the sendrawtransaction RPC with privatebroadcast enabled. Normally, such transactions are forced through the Tor network to hide the sender's IP. But if a peer falsely advertised support for the newer P2P v2 protocol, Bitcoin Core would try v2, fail, then fall back to v2 over a direct IPv4/IPv6 connection—bypassing Tor and potentially exposing the originator's IP address. This commit only documents the fix; it does not contain the actual code change.
Treat this as a confirmed privacy issue already fixed elsewhere (PR #35319). Users relying on privatebroadcast should ensure they run a version containing PR #35319. Review the actual code fix in PR #35319 to verify the proxy override is correctly applied during v1 fallback. No code change is needed from this commit alone.
Security signals we found
Privacy leak: originator IP address exposure
Tor proxy bypass during P2P v1 fallback
Private broadcast (privatebroadcast/sendrawtransaction) affected
Bogus P2P v2 protocol advertisement enables fallback path
Documentation-only commit describing a prior security-relevant fix
Evidence from the diff
The commit is a documentation-only change adding doc/release-notes-35319.md. It describes a fixed privacy leak in transaction broadcasting when -privatebroadcast=1 is used with sendrawtransaction. The leak occurs during P2P v2 protocol fallback: when connecting to an IPv4/IPv6 peer that advertises v2 support, Bitcoin Core attempts v2; on failure it retries with v1. During private broadcast, the code overrides proxy selection to force the connection through the Tor proxy. However, the v1 retry path ignored this override, potentially establishing a direct IPv4/IPv6 connection and leaking the originator’s IP. Conditions: peer advertises v2 support over IPv4/IPv6, sender has Tor configured, sender does not use -proxy for IPv4/IPv6, and the peer’s v2 advertisement is bogus. The actual fix is in PR #35319, not in this commit.
Changed components
Bitcoin Core P2P networkingTor proxy routing for private transaction broadcastsendrawtransaction RPC with -privatebroadcast=1P2P v2 protocol negotiation and v1 fallbackInspect captured patch +20 / −0
diff --git a/doc/release-notes-35319.md b/doc/release-notes-35319.md
new file mode 100644
index 00000000..6b729969
--- /dev/null
+++ b/doc/release-notes-35319.md
@@ -0,0 +1,20 @@
+P2P and network changes
+-----------------------
+
+- Fix a possible leak of the originator's IP address for transactions sent with
+`sendrawtransaction` RPC when `-privatebroadcast=1`. When Bitcoin Core connects
+to a peer, if that peer has been advertised to support P2P protocol v2, then
+Bitcoin Core tries to use the v2 protocol and if that fails it retries the
+connection using the v1 protocol. When the private broadcast is about to send a
+transaction to an IPv4 or IPv6 peer it overrides the normal proxy selection and
+forces the connection through the Tor proxy (and thus through the Tor network,
+protecting the sender's IP address). However if v2 protocol is tried and it
+fails, then the v1 retry connection would be made disregarding the "override
+proxy" request, possibly making an IPv4 or IPv6 direct connection. In other
+words, for this to happen the following must be true:
+ 1. An IPv4 or IPv6 address has been advertised to the sender, indicating v2
+ support.
+ 2. The sender must have Tor configured.
+ 3. The sender's configuration must be such that connections to IPv4 or IPv6
+ are made directly (no `-proxy=` is used for IPv4 or IPv6).
+ 4. The recipient does not support v2 (the flags from 1. are bogus). (#35319)
Why this scored 62/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.