net: don’t self advertise tor exit node ip addresses in outbound connections #35578

stratospher commented at 6:37 PM on June 21, 2026: contributor

During self advertisement in GetLocalAddrFromPeer - we advertise the "IP address we think we are" and sometimes replace it with what "IP address the peer thinks we are".
when an outbound connections is made to a peer via a proxy, the "IP address the peer thinks we are" is the proxy's ip address.
so the proxy's ip address can get relayed as our self advertisement
in normal cases the proxy's ip address is not a reachable inbound address and shouldn't be relayed on the network.

Example: when a node running both Tor and clearnet via a SOCKS5 proxy connects to a clearnet peer (proxy=127.0.0.1:9050, listen=1, discover=1 (or) onion=127.0.0.1:9050), the "IP address the peer thinks we are" is the Tor exit node's IP address and doesn't make sense to relay it. 55-76% of all tor exit nodes were present in various addrman snapshots I checked (my node and the ones from b10c’s peer.observer) from now and few years ago. would be nice to not unnecessarily relay these tor exit IPs since they end up being stored as fresh and gossiped from multiple sources entries in our addrman.

an advanced node runner might have a proxy whose ip address is also a reachable inbound address. I've personally not used such a proxy but 1 difference for them is that they'd need to explicitly set -externalip=<addr> to self-advertise their proxy address. i feel it’s an acceptable tradeoff and would imagine they are already using -externalip=<addr> config flag as they are explicitly managing their node's public address.

net: don't self-advertise proxy address in outbound connections

When outbound connections to clearnet peers are made via a proxy,

- During self advertisement - we advertise
  "IP address we think we are" and sometimes replace it with what
  "IP address the peer thinks we are".
- the "IP address the peer thinks we are" is the proxy's ip address.
  and can get relayed as our self advertisement
- in normal cases the proxy's ip address is not a reachable inbound
  address and shouldn't be relayed on the network.

there is a soft-set init parameter interaction proxy → discover=0
to prevent this situation but don't think it works in practice
because people might end up overriding it with discover=1
in real life, 55-76% of all tor exit nodes were present in
various addrman snapshots from now and few years ago. so would be
nice to check when behind a proxy before self advertising.

412aa3d1fd

doc: use proxy=127.0.0.1:9050=onion in tor.md

update tor.md after PR 34031
```
[error] Unrecognized network in -proxy='127.0.0.1:9050=tor': 'tor'
Error: Unrecognized network in -proxy='127.0.0.1:9050=tor': 'tor'
```

b5d58ee149

DrahtBot added the label P2P on Jun 21, 2026

DrahtBot commented at 6:37 PM on June 21, 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/35578.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept ACK	0xB10C

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#31260 (scripted-diff: Type-safe settings retrieval by ryanofsky)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

0xB10C commented at 8:37 AM on June 26, 2026: contributor

Concept ACK, it makes sense to me to not advertise an address we know we can't be reached on. I think this is the case when using -proxy, as we specifically say "make outbound connections through this SOCKS5" but don't expect inbound connections via this socket. There seems to be something called BIND-request for SOCKS5 proxies, but I don't think that's widely supported (and not implemented in Bitcoin Core).

I've looked at the number of connections my nodes make to Tor exit node IPs in this post: In mid 2026, my nodes each make between 7.5 to 12.5 connection attempts per day to Tor exit node IPs.

While nearly all of these connection attempts fail (as expected), there's about 20 IPs where I've seen some connections to Tor exit node IPs succeed over the last years. I assume these are hosts that run (or ran at some point) a Tor exit node and a Bitcoin node, which isn't too unexpected.

0xB10C commented at 9:12 AM on June 26, 2026: contributor

proxy=127.0.0.1:9050, listen=1, discover=1

Hm are we sure this is being used like this? With just -proxy set, we wouldn't be listening and not self-announcing.

https://github.com/bitcoin/bitcoin/blob/93012d7ff918eef41adf453bf10ddb4da21f3df4/src/init.cpp#L812-L825

https://github.com/bitcoin/bitcoin/blob/93012d7ff918eef41adf453bf10ddb4da21f3df4/src/net_processing.cpp#L5475-L5476

stratospher commented at 9:21 AM on June 30, 2026: contributor

proxy=127.0.0.1:9050, listen=1, discover=1

Hm are we sure this is being used like this? With just -proxy set, we wouldn't be listening and not self-announcing.

good point. it's either this or people using onion=127.0.0.1:9050.

even though there is the soft-set init parameter interactions which does proxy=127.0.0.1:9050 -> listen=0 and discover=0 - I wouldn't be surprised if people end up overriding it.

listen=1 is overriden to allow inbound connections without having to deal with the clearnet firewall rules. I've seen/done this a lot.
I think discover=1 and its interaction with other parameters can be confusing to users. It makes a node's own IP discoverable to peers (the node advertises it). That IP is obtained from the node's own machine, and (less obviously) also from what peers report the node's address to be.
- If the node wants control over what exactly it advertises, -externalip=<ip> can be used (keeping the soft-set discover=0) - the node then advertises only the address we specified in externalip, and not the peer-reported view of a node's IP.
- if -externalip=<ip> is used with explicit discover=1 override in the bitcoin.conf then again the peer-report view of a node's ip can be advertised.

quick GitHub search shows proxy=127.0.0.1:9050, listen=1, discover=1 use here and here. unsure if it's common/rare/how many people use it like this though.