Various people have reported this on IRC after the 28.0 release, but have not created a GH issue, so i’m creating one.
To be able to distinguish incoming localhost connections from connections on the Tor hidden (onion) service, we automatically create a separate “Tor service target” P2P port. This port is always opened, even if -listenonion=0, because the user might manually configure a Tor hidden service and wants the same behavior.
DefaultOnionServiceTarget() creates the CService for the Tor service target port. This number is fixed in the chainparams to 8334 for mainnet, on localhost.
Normally, this is no problem. However a common scenario is to run multiple bitcoin nodes on one machine (usually for testing) with different P2P and RPC ports. In this case, they will all try to bind to port 8334 and the latter ones will fail. This problem has existed since the Tor service port was introduced, however it became visible in v0.28 with #22729. After that PR it becomes a crash issue.
(it was a problem before because multiple bitcoind instances would try to bind on port 8334 while ignoring failures, but still have the wrong internal knowledge that they bound on port 8334, passing this to Tor. So all of Tor’s connections would go to the first node)
The current suggested workaround is to manually set -bind=.... This removes the automatic onion binds (although explicit -bind=.....=onion can be used to create new ones). i have tagged this issue with milestone 28.1 as it could be considered a regression and would be nice to have this automatically work again (especially in cases where the user doesn’t care about Tor, like in regtest harnesses).
Various ideas to resolve this have been discussed, among which:
- Revert #22729: i strongly dislike this, as it would only bury the problem again. Explicit failures are always better than having to debug silent loss of functionality.
- Instead of hardcoding port 8334, make it
P2P_port + 1: When overriding the-port, the Tor service target port changes at the same time. This resolves the problem automatically, except in the edge case where the differentbitcoindinstances’ P2P ports are specified very closely together (and maybe it’s just better to avoid that in the first place). - Disable the Tor service port binding when
-listenonion=0: This avoids the problem when the user doesn’t care about Onion binds, however it means that an extra option has to be set, it’s still not nice automatic behavior. Might as well set-bind=then. - Disable the Tor service port binding when
-regtest: In case of regtest, it’s uncommon to care about Tor. However not always; this would interfere with out own tests when we want to test interaction with Tor. It also doesn’t solve the issue in case of sigtest/mainnet.
(some more, from @mzumsande in #31134)
- Do nothing and tell affected users to switch to
-bind- maybe even deprecate-port - if
-portis given, don’t attempt to bind to the default onion port - disable the automatic tor binding silently if the port is already used
i personally prefer 2. It keeps the current behavior, except when port is overridden, and doesn’t require any special workarounds.
