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

schildbach commented at 5:07 pm on November 10, 2022: contributor

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

0-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.

Actual behavior

In short, it dies.

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

System information

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

schildbach added the label Bug on Nov 10, 2022

fanquake added this to the milestone 24.0 on Nov 10, 2022

fanquake commented at 5:26 pm on November 10, 2022: member

@vasild you might have some insight here?

schildbach commented at 5:34 pm on November 10, 2022: contributor

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.

vasild commented at 9:11 am on November 11, 2022: contributor

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

a lookup could return more than one address; yes, we may try to bind to the first one or to all of them, but:
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:

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

schildbach commented at 9:51 am on November 11, 2022: contributor

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

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.
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.
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.

vasild commented at 10:43 am on November 11, 2022: contributor

@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?

schildbach commented at 11:50 am on November 11, 2022: contributor

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.

fanquake commented at 2:06 pm on November 17, 2022: member

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

fanquake removed this from the milestone 24.0 on Nov 17, 2022

fanquake added this to the milestone 24.1 on Nov 17, 2022

vasild commented at 3:52 pm on November 17, 2022: contributor

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

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.
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.

maflcko removed this from the milestone 24.1 on Nov 17, 2022

maflcko renamed this:
~~[24.0rc4] Error: Cannot resolve -bind address: 'bitcoind:8334=onion'~~
Error: Cannot resolve -bind address: 'bitcoind:8334=onion'
on Nov 17, 2022

maflcko commented at 4:12 pm on November 17, 2022: member

removing version for now, as this is not a regression

schildbach commented at 10:06 am on November 18, 2022: contributor

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 (comment)](/bitcoin-bitcoin/22729/#issuecomment-927802257).

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

schildbach commented at 5:11 pm on March 20, 2024: contributor

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.

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

schildbach commented at 6:10 pm on March 20, 2024: contributor

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:

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

vasild commented at 4:00 pm on April 2, 2024: contributor

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.

schildbach commented at 8:59 pm on April 2, 2024: contributor

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

vasild commented at 10:00 am on April 25, 2024: contributor

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.

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