> This new feature is enabled by default if Bitcoin Core is listening, and a connection to Tor can be made. It can be configured with the -listenonion, -torcontrol and -torpassword settings. To show verbose debugging information, pass -debug=tor.
But it is correct to say that the feature is enabled *regardless* of whether a connection to Tor can be made.
I propose to clarify that so that users can eliminate these in their logs (when `listen=1` and no Tor).
And I think it's okay to clarify about the `listen` option, because on several occasions when I read this before I always assumed `listening` meant `server=1` which cost me a lot of time in troubleshooting.
```
2016-10-24 06:19:22.551029 tor: Error connecting to Tor control socket
2016-10-24 06:19:22.551700 tor: Not connected to Tor control port 127.0.0.1:9051, trying to reconnect
```
0.12.1
Tor Browser Bundle spawns the Tor process and listens on port 9150, it doesn't randomly pick a port.
[ci skip]
(cherry picked from commit 1b63cf98347b2a62915425576930f55c2126c2ff)
Adds 127.0.0.1:9050 for the .onion proxy if we can succesfully connect
to the control port.
Natural followup to creating hidden services automatically.
Seems like there are a lot of advertised testnet HS nodes that
don't actually work. Lack of the testnet port on the example
HS config might be one reason.
I've seen users confused multiple times thinking they
should be using -tor to set their tor proxy and then
finding in horror that they were still connecting to
the IPv4 internet.
Even Jeff guesses wrong about what the knob does, so
I think we should rename it. This leaves the old
knob working, we can pull it out completely in a
later release.
zanzibar
zanzibar
Duke Leto