<!-- 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 -->
I am running Bitcoind on Qubes-Whonix. Whonix-Gateway is where tor resides, and every tor controller's command made by Whonix-Workstation to Whonix-Gateway is filtered by a proxy called onion-grater (upstream development is made by Tails OS)
From this point on I will be referring to tor's controller simply by "control" or "controller".
If the control connection is closed by restarting onion-grater to apply new rules (even not regarding the bitcoind.yml) file, bitcoind will remove the current onion and won't be able to set it as address again.
RemoveLocal(myonion.onion:8333)
tor: No supported authentication method
and bitcoin-cli -netinfo
Local addresses: n/a
and of course none of my nodes listening to this address will continue working.
ADD_ONION command works the first time but not the second. The problem occurs because bitcoind does not give time for the controller to restart the second time, so the authentication is not "available yet".
In fact, tor is not being reloaded or restarted, only the proxy, which is what bitcoind sees as the controller.
This happens because I am using bitcoind tor controller feature to send ADD_ONION. If I set the onion service manually on the gateway, I wouldn't have this problem, but then the problem would be:
- it wouldn't be pragmatically deleted, although I am rewriting it with
Flag=DiscardPKanyway - it would stay as a file on the Gateway and the onion address would need to be manually inserted into the bitcoin.conf
Expected behavior
<!--- What behavior did you expect? -->
I expect that after bitcoind can't authenticate to the controller, it tries again after some time. This way, I can restart my controller without needing to restart bitcoind for it to get a onion listening address again.
Actual behavior
<!--- What was the actual behavior (provide screenshots if the issue is GUI-related)? -->
Bitcoind removes current listening onion hostname and not retry to authenticate to the controller.
To reproduce
<!--- How reliably can you reproduce the issue, what are the steps to do so? -->
This is difficult to reproduce on normal systems. First, Qubes may not interfere, so you could try to reproduce on Whonix KVM or Virtualbox or Tails OS (probably).
If you can't test on that setup, I would try to simple close the controller connection on a normal system and then see what bitcoind does to the listening onion address.
Also you need to add the bitcoind onion-grater profile, I don't know if Tails has, but for Whonix, I am using https://github.com/Whonix/onion-grater/blob/9addd1d6dd9671b18e5415a196b92d7f6ee5846c/usr/share/doc/onion-grater-merger/examples/40_bitcoind.yml
It is not the current Whonix onion-grater profile but it is the correct one and will be merged upstream soon.
If that is the case, add that profile to /usr/local/etc/onion-grater-merger.d/40_bitcoind.yml
Also set in the bitcoin.conf the onion binding to bind=0.0.0.0:8334=onion and not 127.0.0.1. This makes the service listen on the Whonix internal interface and does not affect security. Restart bitcoind to apply changes.
You will also have to open the port on the Whonix-Workstation firewall.
$ sudo mkdir -p /usr/local/etc/whonix_firewall.d
$ echo "EXTERNAL_OPEN_PORTS+=" 8334 " | tee -a /usr/local/etc/whonix_firewall.d/50_user.conf`
$ sudo whonix_firewall
To view onion-grater logs, you need to enable debug mode on the Whonix-Gateway:
$ echo "[Service]
## Clear onion-grater default file '/lib/systemd/system/onion-grater.service'.
ExecStart=
## Enable debug mode.
ExecStart=/usr/lib/onion-grater --listen-interface eth1 --debug
" | tee /usr/lib/systemd/system/onion-grater.service.d/50_user.conf
$ sudo systemctl daemon-reload
$ sudo systemctl restart onion-grater
Then after adding the profile, enabling onion-grater debug mode, restarting onion-grater and bitcoind, test if the address is reachable externally. Use the bitcoid option connect=address.onion, so you are sure it is connecting.
If it is, restart onion-grater.
$ sudo systemctl restart onion-grater
On the bitcoin debug.logs, you should see the same error I saw above about removing onion address and not able to authenticate to the controller.
But that is not entirely correct, because I can issue an ADD_ONION manually and it will accept, but bitcoind does not try to issue ADD_ONION a second time.
host onion-grater[149562]: 10.137.0.31:54044 (filter: 30_autogenerated): -> PROTOCOLINFO 1
host onion-grater[149562]: 10.137.0.31:54044 (filter: 30_autogenerated): <- 250-PROTOCOLINFO 1
host onion-grater[149562]: 10.137.0.31:54044 (filter: 30_autogenerated): <- 250-AUTH METHODS=NULL
host onion-grater[149562]: 10.137.0.31:54044 (filter: 30_autogenerated): <- 250-VERSION Tor="0.4.7.10"
host onion-grater[149562]: 10.137.0.31:54044 (filter: 30_autogenerated): <- 250 OK
host onion-grater[149562]: 10.137.0.31:54044 (filter: 30_autogenerated): -> AUTHENTICATE
host onion-grater[149562]: 10.137.0.31:54044 (filter: 30_autogenerated): <- 250 OK
The controller actually lets bitcoind authenticate, as seen from the onion-grater logs above. But I don't understand why bitcoind says it can't authenticate. The ip doesn't matter, it is internal ip.
What you should expect from onion-grater logs is the following:
host onion-grater[149562]: 10.137.0.31:43566 (filter: 30_autogenerated): -> AUTHENTICATE
host onion-grater[149562]: 10.137.0.31:43566 (filter: 30_autogenerated): <- 250 OK
host onion-grater[149562]: 10.137.0.31:43566 (filter: 30_autogenerated): -> ADD_ONION NEW:ED25519-V3 Port=8333,0.0.0.0:8334
host onion-grater[149562]: 10.137.0.31:43566 (filter: 30_autogenerated): rewrote command:
host onion-grater[149562]: ADD_ONION NEW:ED25519-V3 Port=8333,0.0.0.0:8334
host onion-grater[149562]: to:
host onion-grater[149562]: ADD_ONION NEW:ED25519-V3 Port=8333,10.137.0.31:8334 Flags=DiscardPK
host onion-grater[149562]: 10.137.0.31:43566 (filter: 30_autogenerated): <- (multi-line)
host onion-grater[149562]: 250-ServiceID=myonionhostnamewithoutonion
host onion-grater[149562]: 250 OK
host onion-grater[149562]: 10.137.0.31:43566 (filter: 30_autogenerated): -> QUIT
host onion-grater[149562]: 10.137.0.31:43566 (filter: 30_autogenerated): <- 250 closing connection
host onion-grater[149562]: 10.137.0.31:43566 (filter: 30_autogenerated) disconnected: client quit
You could try on Whonix with tor-ctrl to authenticate after restarting onion-grater and it will work:
$ tor-ctrl ADD_ONION NEW:ED25519-V3 Port=8333,0.0.0.0:8334
and it will authenticate.
But for some unknown reason bitcoind does not reauthenticate to the controller.
I understand that once the contoller connection closes, the commands send to the controller are not valid anymore. But bitcoind should be able to reauthenticate once it loses connection.
System information
<!-- 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. -->
System information was already described above. I understand this may be difficult debug because it requires a system with onion-grater. But it does not rely on Whonix or Tails or onion-grater package to fix this, as they are only restarting to read the new configuration, but bitcoind understand that as a connection that must be closed forever.
If you read all this and is open to make bitcoind retry to authenticate cleanly, I am open to help debug and instruct how to reproduce.
