It is allowing services to be created to any port to be used instead of only 8333.
Ok, so the person wants to create a restest and testnet service, they would need to edit the config, or the config should use all the default ports, eg. 18333 for testnet.
But the default ports can be hardcoded, if a person uses a non default port, then they are already configuring the service diffferently.
My proposal is to implement all default ports patterns so the above can be avoided.
Of course the service is only reachable after port is opened on the firewall. But I think the control port should not allow all ports, only the whitelisted ports.
bitcoind -help
-port=<port>
Listen for connections on <port>. Nodes not using the default ports
(default: 8333, testnet: 18333, signet: 38333, regtest: 18444)
are unlikely to get incoming connections. Not relevant for I2P
(see doc/i2p.md).
Bitcoin onion-grater profile is only necessary if you want to listen=1 for incoming connections, this means relaying blocks on the p2p network.
Bitcoind does indeed start the onion binding port on 127.0.0.1:8334. This means that it isn’t reachable on $(qubesdb-read /qubes-ip):8334.
It would be reachable on that interface if the onion binding port was 0.0.0.0:8334 or the $(qubesdb-read /qubes-ip):8334, but the first option 0.0.0.0:8334 is better because it does not depend on knowing the qubes ip and updating it.
So if you want to listen for incoming connections, you need to set on the bitcoin.conf:
listen=1
## although this is the default binding address:port,
## it is necessary to set it for it to listen on multiple addresses
## if not set, only 0.0.0.0:8334 would be binded and the default
## bind address and port would not be used
bind=0.0.0.0:8333
bind=0.0.0.0:8334=onion
and opening external port 8334 on the workstation.
This also means that I need to update the onion-grater profile to overwrite the client add onion address with regex to match every address (0.0.0.0 and 127.0.0.01 should be modified to {client-address}). Something like (\S+), will test later.
You can test this is the case for example with nginx by listening on 127.0.0.1:82, only that address will be reachable and not the qubes ip and same port.
(I don’t really understand how to print the link and not the title of the page with discourse…)
Just like apache only listening on 127.0.0.1, its traffic needs to be redirected to the Workstation listening interface. The thing is that by default nginx starts with 0.0.0.0 (all interfaces).
And using sudo ncat -l 0.0.0.0 8334 -c 'ncat 127.0.0.1 8334' but that is just dumb and prone to mistakes of forgetting about it, better to set in the bitcoin.conf.
So yeah, changing the bitcoin.conf to bind=0.0.0.0:8334=onion is necessary.
And I believe it is reasonable for bitcoind default to 127.0.0.1 for onion connections and not 0.0.0.0, because it could leak server info, but not for Whonix, as it is isolated network with the Gateway.
Note the first listening address 8333 is only necessary if you want applications to use that address. This is useful for qubes if you want to bind 8333 to another qube and have a pruned node on one qube and a full on another, without the need to set rpc for the other node, thus minimizing risks when possible.
So in the end, it is good to have 8333 always set because that is default bitcoind behavior that most applications will be expecting.
And the reason to set a different port for onion 8334 is:
default bitcoind configuration (except the address 127.0.0.1 which needs to be changed to 0.0.0.0)
correctly tagging incoming connections to that separate port as onion, thus making it very clear it is not coming from localhost. Useful for debugging, logs, verification etc.
Ok. So I don’t believe there is a problem with my onion-grater profile, but something strange happens.
Sometimes when restarting onion-grater, bitcoind gets a ServiceID, sometimes it can’t authenticate although onion-grater replied correctly that it could authenticate.
I am not sure upstream will accept the bug report because of the mention of onion-grater. Their position could be “that needs to be fixed in onion-grater than”. If the issue could be re-produced without onion-grater and only with Tor, then the argument be much stronger. Could this be reproduced by simply reloading or restarting Tor?
From my experience, bug reports generally, with such complexity have very low chance of being acted on by upstream.
Unfortunately no. I tested on a debian qube running bitcoind with local tor, this does not occurr.
I tried to make the bug “simpler” but it does not happen without onion-grater. This does not mean its onion-grater fault, because it replies correctly. But maybe bitcoind doesn’t wait for it to reply? Not sure.
Tested on debian by restarting tor, as that is the way to close the control connection as there is no proxy. Bitcoind can always add onion. But on Whonix with onion-grater, it does not always works, don’t know why.