Error: Cannot resolve -bind address: 'bitcoind:8334=onion' #26484

<!-- This issue tracker is only for technical issues related to Bitcoin Core. General bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange at https://bitcoin.stackexchange.com. For reporting security issues, please read instructions at https://bitcoincore.org/en/contact/. If the node is "stuck" during sync or giving "block checksum mismatch" errors, please ensure your hardware is stable by running memtest and observe CPU temperature with a load-test tool such as linpack before creating an issue! -->

<!-- Describe the issue -->

In my quest to finally fix #25094, I figured I need to bind the onion listen port explicitly to the external interface (bitcoind), not to "all interfaces" ([::]). So I'm using the argument

-bind=bitcoind:${BITCOIND_TOR_PORT}=onion

/etc/hostname is set to bitcoind and the hostname command yields the expected result. Also, both nslookup and ping can resolve the hostname to the external IP.

Note: I cannot use the numerical IP, because Docker assigns IP addresses dynamically on each invocation.

Expected behavior

I'd expect bitcoind to also resolve the hostname to my external IP, just like ping and nslookup do.

<!--- What behavior did you expect? -->

Actual behavior

<!--- What was the actual behavior (provide screenshots if the issue is GUI-related)? -->

In short, it dies.

bitcoind_1          | Error: Cannot resolve -bind address: 'bitcoind:8334=onion'
bitcoind_1          | Shutdown: In progress...
bitcoind_1          | Error: Cannot resolve -bind address: 'bitcoind:8334=onion'
bitcoind_1          | Shutdown: done

System information

bitcoind 24.0rc4 (self built), Docker+Compose from Ubuntu 22.04.1.

<!-- What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)? -->

<!-- What type of machine are you observing the error on (OS/CPU and disk type)? -->

<!-- GUI-related issue? What is your operating system and its version? If Linux, what is your desktop environment and graphical shell? -->

<!-- Any extra information that might be useful in the debugging process. -->

<!--- This is normally the contents of a `debug.log` or `config.log` file. Raw text or a link to a pastebin type site are preferred. -->

@vasild you might have some insight here?

Fwiw, if I exec into my container, replace the bitcoind string manually with the external IP address and launch bitcoind again, it works – until I restart my container, which assigns a new IP. So it's really just the resolving of the address that doesn't work.

I guess that we do not try to resolve the argument to -bind because:

1. a lookup could return more than one address; yes, we may try to bind to the first one or to all of them, but:
2. a compromised/malicious name server could trick bitcoind to bind to an unexpected address, which may have security implications

This is not new in 24.0. It was introduced in 2012 in 8f10a2889089af1b2ac64802360494b54c8c7ff1 (see the 3rd argument to CService() which equals to false, meaning "no lookup"). Before that commit it would just bind on all addresses (-bind did not exist).

Since you can set up /etc/hosts with the correct address, can you also set up bitcoin.conf with the correct address? Or derive the address from /etc/hosts before starting bitcoind? Something like:

echo "bind=$(grep bitcoind /etc/hosts |cut -f 1):8334=onion" >> bitcoin.conf

I see these options for configuring the bind port of a Tor hidden service:

1. Use wildcard addresses (0.0.0.0 and/or [::]). This binds correctly, but it seems bitcoind is picking one of them and using that (via Tor control port) for configuration of the target address of the hidden service. This fails, because the wildcard address has a different meaning to the Tor container. To fix this issue, bitcoind could offer a separate configuration option for the target address (which would support hostnames, see below). This issue is tracked in #25094.
2. Use hostnames to bind to a specific external interface, which can be reached via that name or resolved IP from the Tor container. As stated above, bitcoind currently does not support this. I don't get the security argument – it's up to the user to trust their name resolution and configure bitcoind either by hostname or IP as desired.
3. Use fixed numerical IP, which can be reached from the Tor container. However, IPs are typically assigned dynamically (e.g. by Docker). This makes configuration overly complicated, as your workaround clearly shows. For example, Docker containers use arbitrary values in /etc/hosts and /etc/hostname by default, so your workaround wouldn't work out of the box. I'd rather use nslookup, if I were to go that route.

As you can see, currently none of the options work with the configuration of a Tor hidden service, managed by bitcoind via control port. Currently I can only revert back to the old method of managing the hidden service in the Tor container.

@schildbach is this behavior something new? Is it a regression since an older version of bitcoind which worked "better"?

... I don't get the security argument ...

If you feel that this should be changed, then you should open an issue for that or even a pull request that flips false to true on this line:

https://github.com/bitcoin/bitcoin/blob/7ef730ca84bd71a06f986ae7070e7b2ac8e47582/src/init.cpp#L1720

Don't be deterred by my opinion - it is just one. Maybe others would think it is ok to change it.

FWIW I checked the behavior of:

• Tor (SOCKSPort google.com:9050)
• Apache (Listen google.com:80) and
• sshd (ListenAddress google.com)

All of them do resolve the name to an IP address and try to bind to it (and of course failed miserably with my examples).

I guess that bitcoind only supports option 3 currently. Somehow is has been assumed that the operator knows their IP address. I understand that Docker makes this difficult. I am not very familiar with it, but does it not provide the option to run some custom setup scripts inside the host OS after setting it up and the IP address to be in some environment variable, available to such a script?

Currently I can only revert back to the old method of managing the hidden service in the Tor container.

What is that old method?

What is that old method?

Rather than letting bitcoind manage the Tor hidden servce via the control port, you'd configure it with tor (look up tor options HiddenServiceDir, HiddenServicePort). In this case, you configure the target address within tor, and tor has no regrets using hostname resolution. The main downside is the hidden service private key is then managed by Tor.

Both approaches are described in doc/tor.md, however it is missing documentation of the various pitfalls which come with -torcontrol mode.

Is this behavior something new?

Well, I'm trying to get it to work for months now. 24.0 had some other bug fixed that prevented -torcontrol mode, but now I'm running into more problems.

Not completely sure what the status is here, but I've moved this to the 24.1 milestone.

To summarize, @schildbach, correct me if I am wrong - there are two issues:

1. bitcoind does not resolve the argument to -bind=..., so an IP address must be provided by the user. It is a feature request to change the behavior.
2. If bitcoind listens on 0.0.0.0 or :: for incoming tor connections, then it would tell the tor daemon to connect to that address. This is a bug that could be resolved by #22729 (comment).

It has been like this since the start and is not a regression from a previous version. There is no patch for either one at the moment.

removing version for now, as this is not a regression

1. `bitcoind` does not resolve the argument to `-bind=...`, so an IP address must be provided by the user. It is a feature request to change the behavior.

Agreed, this is what this issue represents.

2. If `bitcoind` listens on `0.0.0.0` or `::` for incoming tor connections, then it would tell the tor daemon to connect to that address. This is a bug that could be resolved by [Make it possible to disable Tor binds and abort startup on bind failure [#22729](/bitcoin-bitcoin/22729/) (comment)](/bitcoin-bitcoin/22729/#issuecomment-927802257).

This, or by introducing an option for overriding the address to tell to the tor daemon.

f you feel that this should be changed, then you should open an issue for that or even a pull request that flips false to true on this line:

https://github.com/bitcoin/bitcoin/blob/7ef730ca84bd71a06f986ae7070e7b2ac8e47582/src/init.cpp#L1720

Actually flipping that bool doesn't work. It seems to try to resolve the entire line, e.g.

Error: Cannot resolve -bind address: 'bitcoind:38334=onion'

I think the cleanest way to fix this is keep the -bind logic as is, but introduce a new optional argument -onionporttarget that specifies the string that is sent to the tor control port. The default would be taken from the bind as it is done today. That way, tor can resolve the IP and we can specifiy similar to:

-bind=0.0.0.0:8334=onion
-onionporttarget=bitcoind:8334

Actually flipping that bool doesn't work. It seems to try to resolve the entire line, e.g Error: Cannot resolve -bind address: 'bitcoind:38334=onion'

Are you sure?

https://github.com/bitcoin/bitcoin/blob/3b987d03a49964995dced76889634561fd363d28/src/init.cpp#L1837-L1861

If there is = in the -bind argument then it will remove it and what is after it and will go to line 1853 where the last argument to Lookup() is false.

So should I try switching the bool in line 1853 rather than line 1841?

Yes, line 1841 is for when there is no = inside the argument, like in -bind=1.2.3.4:8333. Line 1853 is for when there is =, like -bind=1.2.3.4:8333=onion.

Hi all, Sorry, so what is the recommended workaround for creating a Bitcoin Core onion service if Tor service is running on a different host or container, without following the Manually create a Bitcoin Core onion service way and bind=a.b.c.d:8334=onion? Best regards

@dayer3, so Tor daemon is running on another machine and you want to specifically use -bind=hostname:8334=onion in bitcoind config and not -bind=a.b.c.d:8334=onion? I am not sure if that is possible. This comment contains some workaround:

#26484 (comment)