private broadcast: disallow tor connection through exit node #35323

pull instagibbs wants to merge 2 commits into bitcoin:master from instagibbs:2026-05-private_hs_only changing 4 files +27 −71

instagibbs commented at 3:05 PM on May 19, 2026: member

Removes the logic which allows private broadcasting to connect via tor exit relays.

This mitigates the bug noted in #35319 , simplifies the logic, and is "less surprising" to me as I thought that's how it worked before.

The proxy logic could still be fixed/removed/??? but left it in place for smallest changeset that raises assurance on what we're shipping.

Proposed alternative to #35319 , at least for backport
private broadcast: disallow tor connection through exit node 0244f3b255
test: ensure private relay hidden-service only a125ac1d96
DrahtBot commented at 3:05 PM on May 19, 2026: contributor



The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35323.



Reviews

See the guideline for information on the review process.

Type Reviewers

Concept ACK willcl-ark, w0xlt

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.
willcl-ark commented at 3:36 PM on May 19, 2026: member

Concept ACK.

I was wondering for a bit "what's wrong with using an exit node", but realise now thats something of a red herring to the fix.

I prefer the approach here of only selecting a tor/i2p peer for private broadcast (not ipv4/6 peer over tor proxy/exit node). I agree it's cleaner/easier to reason about than having to ensure the proxy override is preserved perfectly over retries and reconnections.
w0xlt commented at 4:57 PM on May 19, 2026: contributor

Concept ACK.

I prefer the approach here of only selecting a tor/i2p peer for private broadcast (not ipv4/6 peer over tor proxy/exit node).

Agreed.
vasild commented at 5:58 PM on May 19, 2026: contributor

It is much easier to spin Tor nodes than IPv4 or IPv6 nodes. I think being able to send transactions to IPv4 and IPv6 peers is very much desired.

This PR would cripple a feature without fixing the actual problem which is elsewhere. The actual problem is forgetting to use the proxy_override given to OpenNetworkConnection() during the v2->v1 reconnect.

Documentation can be improved.
sipa commented at 6:01 PM on May 19, 2026: member

It is much easier to spin Tor nodes than IPv4 or IPv6 nodes. I think being able to send transactions to IPv4 and IPv6 peers is very much desired.

Agreed. The last thing we want is to incentivize people to effectively Sybil-attack the Bitcoin-Tor network.
instagibbs commented at 6:32 PM on May 19, 2026: member

Agreed. The last thing we want is to incentivize people to effectively Sybil-attack the Bitcoin-Tor network.

Exit nodes being honest + ip costs as anti-sybil mechanism is valid enough if the worry is that we'd tip the scales in favor of even more sybil nodes. Would also give some design credence to the random choice of network being made today (though perhaps we could try preferred networks first, then fallback as we fail to complete, since maybe fewer people would have been exposed to this bug).

Will think more on it.
instagibbs commented at 6:35 PM on May 19, 2026: member

This PR would cripple a feature without fixing the actual problem which is elsewhere. The actual problem is forgetting to use the proxy_override given to OpenNetworkConnection() during the v2->v1 reconnect.

Well, this PR essentially rips out the source of the entire bug, and all this proxy passing through infra is unnecessary if taken. If there are other good reasons to not do it and retain it, fine.
mzumsande commented at 11:50 AM on May 20, 2026: contributor

I also think we want proxy connections to clearnet peers. In addition to the sybil issue, passive monitoring for the network a transaction originated from becomes harder:

An entity could do this by being connected to each reachable node and measuring which node inv'ed a tx first. Even if this does not give the actual originator for a private broadcast tx, if it gives the correct network then that is also some info that could e.g. be used to support chainalysis data.
willcl-ark commented at 9:44 AM on May 21, 2026: member

Agreed. The last thing we want is to incentivize people to effectively Sybil-attack the Bitcoin-Tor network.

This is a fair reason not to favour this approach.
Crypt-iQ commented at 10:23 AM on May 21, 2026: contributor

I think the Sybil point is a good enough reason to not do this, I didn't think of this earlier when I was confused why these transactions were going over ipv4/6. Just curious, how much cheaper is it to spin up tor identities compared to ipv4/6? Is it essentially free?

I still am not a fan of threading an option around that a caller could forget to include: it's the only option to OpenNetworkConnection with a default value which lets a caller forget it?
instagibbs commented at 12:50 PM on May 21, 2026: member

I still am not a fan of threading an option around that a caller could forget to include: it's the only option to OpenNetworkConnection with a default value which lets a caller forget it?

I agree here, closing anyways to focus attention on how to best support the current scope of the feature
instagibbs closed this on May 21, 2026