Incoming tor connections should use alternative port #8973

To be able to label incoming tor connections as different from normal localhost connections in e.g. getpeerinfo and the peers list in the GUI it'd be useful to have them connect on an alternative local-only port. Or even better, a UNIX socket.

For manually set-up hidden services this would have to be configured manually and could add a hsport option or such. The external port would still appear as XXXXXXXXX.onion:8333, however internally it would redirect to a that port.

In the case of torcontrol this would be easy to set up automatically. It could add a new (localhost) binding port automatically and this code would have to be changed:

• https://github.com/bitcoin/bitcoin/blob/master/src/torcontrol.cpp#L441
• https://github.com/bitcoin/bitcoin/blob/master/src/torcontrol.cpp#L477

An interesting alternative to using an alternative port would be to have Tor HS connect on a UNIX socket. This avoids any risk of port collisions at all, and makes it just as easy to detect Tor connections. Tor apparantly supports this: https://trac.torproject.org/projects/tor/ticket/11485

Some information about using UNIX sockets with Tor (mostly for my own reference):

• ControlPort on UNIX socket:

ControlPort PORT|unix:path|auto [flags]

(looks like ControlSocket path can be used too, but I think this is equivalent to unix:path)

• SOCKS through UNIX socket:

SocksPort [address:]port|unix:path|auto [flags] [isolation flags]

• Hidden service that connects to UNIX socket:

HiddenServicePort 80 unix:/path/to/socket

• Through ADD_ONION command:

ADD_ONION NEW:BEST Port=80,unix:/tmp/path/to/tor/socket

Concept ACK

Concept ACK

Yes, unix sockets are preferred for local connections over TCP. However, I think it is better to implement both so that the users don't lose the ability to run the Tor proxy on a different machine than Bitcoin Core (it could be just a different virtual machine on the same physical one). Also unix sockets are not supported on Windowz.

Concept ACK

Does it make sense to generalize this by extending the -bind option to allow the user to override GetBindAddress() on incoming connections like this:

-bind=<addr[=override_local_addr]>
     Bind to given address and always listen on it. Use [host]:port notation
     for IPv6. If =override_local_addr is supplied then incoming connections
     to addr will be treated as if they were made to override_local_addr.
     For example
     -bind=127.0.0.1:8444=pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd.onion:8333
     would designate a bind to 127.0.0.1:8444 and consider that the peer actually connected to 
     pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd.onion:8333 instead of
     127.0.0.1:8444.
     Can be specified multiple times.

If the override is specified then in CConnman::AcceptConnection() we would use it instead of calling GetBindAddress().

PS the line numbers in master have changed and the links in the OP probably should be: https://github.com/bitcoin/bitcoin/blob/d736a6eb1/src/torcontrol.cpp#L441 https://github.com/bitcoin/bitcoin/blob/d736a6eb1/src/torcontrol.cpp#L477