Protect a number of outbound tor connections from eviction #22716

Is your feature request related to a problem? Please describe.

Outbound tor connections lose against outbound clearnet connections after the eviction logic starts having an effect. Although I "manually" add outbound tor connections (via bitcoin-cli), after some time typically only 0 or 1 outbound tor connection survives. My node currently has 12 outbound connections, of which only 1 is a tor connection (Bitcoin Core version 0.21.1). The issue does not depend on which tor version is being used. The (good) outbound connections that are manually added from the start are the 3 Tor v3 onion addresses recommended here.

A clear and concise description of what you want to happen.

Inbound tor connections are well protected from eviction since 19670 was merged. This suggests it would be good idea to apply a similar method to protect a number of outbound tor connections from eviction (3 for default parameters, for example).

bitcoin-cli -netinfo on my node (default parameters) shows:

         ipv4    ipv6   onion   total  block-relay
in        92       0      22     114      17
out       11       0       1      12       2
total    103       0      23     126      19

Are the manual addresses up? Just ran rpc addnode onetry for the 3 torv3 addresses you mentioned and only one of them rp7k2g... seems to be online.

2021-08-16T10:47:23Z Socks5() connect to sxjbh....onion:8333 failed: host unreachable
2021-08-16T10:51:15Z Socks5() connect to d6jwdc...onion:8333 failed: host unreachable

Manual connections have a separate connection limit (8) from the other peer connections (8 full-relay connections, 2 block-relay-only ones, and occasionally 1 short-lived feeler or extra outbound block-relay-only connection). Manual connections aren't affected by -maxconnection settings.

With respect to manual (addnode) peers:

• in net_processing.cpp::PeerManagerImpl::ConsiderEviction(), only outbound full and block relay peers, but not manual ones, are considered for eviction

• we also never disconnect or discourage manual peers for bad behavior (net_processing.cpp::PeerManagerImpl::MaybeDiscourageAndDisconnect())

Ah, you are right, they don't seem to be up. So that's not part of the issue. However, more in general, I observe that when my node has just started it gets a few outbound tor connections that it always loses later on. Isn't it logical that when there is a special provision to protect inbound tor connections from eviction, the same kind of protection should be applied to outbound tor connections?

Outbound peers aren't penalized for worse latency (e.g. higher min ping time), and Tor peers shouldn't be unduly penalized under our outbound eviction criteria, which are more about if the peer isn't lagging, is synced to the current tip with as much work as ours, provided valid connecting headers, wasn't the last one to announce a new block. (Manual peers are spared these restrictions.) Maybe I'm forgetting something though.

Thanks! I will try to connect other (long running) outbound tor v3 peers to my node and see what happens. If those remain that would be good enough for me to close the issue. I should have but it didn't occur to me to check if the tor nodes that were recommended to test Bitcoin Core 22.0 were actually up. Typical example of "don't trust, verify" :-)

Have added other outbound tor nodes and things are looking good. Will close this issue for now and reopen if necessary. Thanks for all the help.