I accidentally -torcontrol=1 today (instead of -listenonion=1) and was confused that it was accepted, as the argument needs to be host:port.
Expected outcome would be an error message and exiting.
For guidance on contributing, please read CONTRIBUTING.md before opening your pull request.
Let me try tackling this!
Ok, so I was able to add a function successfully that can check if the given string is a valid <host>:<port> pair or not. The issue is that I cannot raise an error when the argument is wrongly passed when initializing bitcoind.
In fact, bitcoind is not raising an error for any invalid argument passed at initialization.
Expected outcome would be an error message and exiting.
Just a confirmation. When the ./src/bitcoind command is initially run with invalid parameters, do we expect an error message and exit? Or is it expected to occur later in the runtime of bitcoind?
Is the Args Manager flags supposed to help with this?
common sense would suggest there should be a message and some exit status, other than 0
git grep InitError might help you.
hey folks, I'm very new to the codebase and wanted to try my hands around this issue. Also, I saw a PR that is targeting this issue so what's the update on that, is the issue still open?
I see it not throwing the error because it is returning true here if it has no :
I can open a PR to change this to false but it would affect these files that use SplitHostPort in ./bitcoin/src
./src/test/fuzz/string.cpp:87
./src/test/netbase_tests.cpp:89
./src/util/strencodings.cpp:102
./src/util/strencodings.h:106
./src/bitcoin-cli.cpp:746
./src/net.cpp:547
./src/netbase.cpp:189
./src/init.cpp:1265
./src/init.cpp:1279
We could also do a check just for -torcontrol to check if the : exists and if it doesn't then throw an error
@laanwj @MarcoFalke what do you think?
does this PR close this issue? https://github.com/bitcoin/bitcoin/pull/28101
Looks like we currently allow lookups for the -torcontrol host based on the state of -dns (default 1) (see below). If we don't want to change that (e.g. to disallow allow hostnames, and allow only IP addresses), we're somewhat limited in what would be considered invalid for -torcontrol. I'm thinking this gets clarified first.
does this PR close this issue? #28101
IMO, #28101 fixes the issue.
tor control will always attempt to start with the default port no matter the host argument.
I tested this using torcontrol=127.0.0.1 in my bitcoin.conf file
When I logged tor_control_center and control_service.value() at this line,
I got the following output:
2025-06-18T19:32:53Z tor: Resolved control center '127.0.0.1' to service: 127.0.0.1:9051
The suggestion made here — raising an error if the port is missing — would technically work, but it defeats the purpose of having a default port in the first place.
Hi! I'm new to Bitcoin Core development and would like to work on this issue. Can I take it?