This adds the 2 tor-only blocks-only outbound connections to the new 2 blocks-only outbound connections we added recently. This is a naive fix for the issue where we fail to attempt any outbound Tor connections when our regular network is being censored, but should also stand on its own.
Also bumps max connections to 150 which I don't think should be controversial, but may be important due to the relative fewer number of onion-listening nodes.
This adds the 2 tor-only blocks-only outbound connections to the
new 2 blocks-only outbound connections we added recently. This is a
naive fix for the issue where we fail to attempt any outbound Tor
connections when our regular network is being censored, but should
also stand on its own.
This should more than compensate for the recent increase in default
outbound connections, but also should help Tor-listening nodes not
get overwhelmed due to the relative fewer number of them.
This is a naive fix for the issue where we fail to attempt any outbound Tor connections when our regular network is being censored
Is there an associated issue with this for tracking/discussion?
i.e., What is the current behavior with respect to outbound Tor?
Just some thoughts.
The Tor onion network range is far easier to Sybil attack than IPv4 and IPv6 (especially after #16702), so under attack scenarios this doesn't contribute much (not privacy for transactions as it's blocks only, not propagation speed for blocks as Tor is high latency, and not partition resistance as an attacker can trivially become ~all onion services).
This may also dramatically increase the incoming connection load on those with reachable Tor hidden services, as I believe those are a small fraction of all reachable Bitcoin nodes.
Right, a few notes:
a) Probably should swap this to make the initial connections bias a bit towards Tor instead of only doing it at the end, to ensure connections come up quick, also worth discussing whether they should be non-blocks-only.
b) Indeed, Tor is very sybil'able, though our slight bias towards older nodes (thanks to feelers) helps with that, the goal would more be to force any attacker trying to do addr-flooding-based sybil attacks to do so in multiple ways, and any miscalculations in any of them would result in failure (though, really, a more likely scenario is just having a target who doesn't have Tor, resulting in less collateral damage for such an attack). I agree its only a somewhat marginal benefit, but I wouldn't discount it completely (assuming my understanding of the likelyhood of finding Tor peers by default is correct, which may not be....).
c) I agree Tor listening sockets may be limited, hopefully the bump to 150 helps. Anecdotally, my Tor-listening nodes don't appear to get any more connections over Tor than normal IP, in fact much, much less.
1760 | @@ -1761,7 +1761,11 @@ bool AppInitMain(InitInterfaces& interfaces) 1761 | connOptions.nLocalServices = nLocalServices; 1762 | connOptions.nMaxConnections = nMaxConnections; 1763 | connOptions.m_max_outbound_full_relay = std::min(MAX_OUTBOUND_FULL_RELAY_CONNECTIONS, connOptions.nMaxConnections); 1764 | - connOptions.m_max_outbound_block_relay = std::min(MAX_BLOCKS_ONLY_CONNECTIONS, connOptions.nMaxConnections-connOptions.m_max_outbound_full_relay); 1765 | + if (IsReachable(NET_ONION) && (IsReachable(NET_IPV4) || IsReachable(NET_IPV6))) {
Not sure how all this tor stuff works, but I was only able to get this code to trigger by explicitly setting -onion=<> as part of my bitcoind config, even though I think bitcoind will listen for inbound over tor by default if it can connect to the control port even without that command-line option? Does that sound right?
@sdaftuar if Tor is correctly configured on your machine and if listen isn't 0 then you should see a hidden service announced in your debug log, and it should be listening on that.
https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md#3-automatically-listen-on-tor
TorControl is started as a thread by default a few lines above this one, and sets NET_ONION to be "reachable" if it starts up correctly:
https://github.com/bitcoin/bitcoin/blob/65d12110d43ac89bc0320477bfea6b375fc2134b/src/torcontrol.cpp#L525-L531
Which means that if NET_ONION is deemed "unreachable" before TorControl is started (as is the default), then the behavior here would not be deterministic. As in, the IsReachable(NET_ONION) here (here=this line in this PR we're reviewing) would depend on whether the TorControl thread has exectued far enough to set NET_ONION as "reachable".
1777 | + // full-relay capacity, but not yet at our block-relay peer limit. 1778 | + // (It should not be possible for fFeeler to be set if we're not 1779 | + // also at our block-relay peer limit, but check against that as 1780 | + // well for sanity.) 1781 | + bool block_relay_only = nOutboundBlockRelay < m_max_outbound_block_relay && !fFeeler && nOutboundFullRelay >= m_max_outbound_full_relay; 1782 | + bool block_relay_tor_only = block_relay_only && nOutboundBlockRelay >= MAX_BLOCKS_ONLY_CONNECTIONS;
This logic appears to allow more than 2 block_relay_tor_only connections (we'd start off with 2 tor, but then if other block-relay peers are disconnected one by one, we'd only look to replace them with tor connections). That seems like unintended behavior?
I don't have a strong enough grounding in the issues surrounding tor to comment on the discussion between @sipa and @TheBlueMatt here, so just left a couple review comments/questions.
On second thought I might have gotten a bit over-excited here - indeed I think more default connections over Tor would be nice, but just making two more is unlikely to really solve an issue. A few ideas going forward here include: (a) using the blocks-over-REST/HTTP module in Rust to fetch over Tor, (b) same with headers-over-DNS, (c) quickly rotating through a huge set of known Tor hidden services to find any peers that have some blocks which you do not as more of a fallback mechanism in case of successful Eclipse attack(s).