DNSSeed doesn't work with Tor, 'leaks' DNS #739

Either some way of making dnsseed work correctly with Tor should be found or dnsseed should be disabled when fTor.

It looks to me like the best way to solve this is to add support for the Tor socks extension that adds a resolve command. The tor-resolve tool uses this functionality to do DNS lookups for users: https://gitweb.torproject.org/tor.git/blob/c3e63483b2f16eb1717035eac4c14315b95671f5:/src/tools/tor-resolve.c

Downside are that it only appears to return a single IP per query and that many exit nodes screw up DNS making it kind of a crapshoot at times.

Alternatively, we could include a tiny TCP dns resolver and a list of public dns servers that allow TCP querying. This is the approach of TTDNSD: http://www.mulliner.org/collin/ttdnsd.php The advantage with this is that its potentially useful for both tor users and non-tor users that happen to be behind a broken resolver. It would be more code to support though.

Fixed in a pull today (please help test if you can).

Relevant code is all in init.cpp:

bool fTor = (fUseProxy && addrProxy.port == htons(9050));
if (fTor)
{
    // Use SoftSetArg here so user can override any of these if they wish.
    // Note: the GetBoolArg() calls for all of these must happen later.
    SoftSetArg("-nolisten", true);
    SoftSetArg("-noirc", true);
    SoftSetArg("-nodnsseed", true);
    SoftSetArg("-noupnp", true);
    SoftSetArg("-upnp", false);
    SoftSetArg("-dns", false);
}

Great— though it brings up another issue: Our assumption of tor==proxy on 9050 is broken.

Good tor practice now is to run multiple socks ports because a single socks port will share tor circuts. E.g. you visit a website and login as GavinMcSecret then using the same socks port start bitcoin and send some txn. Tor will very likely reuse the circuits and exit them from the same place potentially creating a surprising identity binding if the exit operator is watching.

So I guess the addrProxy.port == htons(9050) tests should become some kind of GetBoolArg||addrProxy.port == htons(9050).

@gmaxwell: yes, I don't think there is a way to detect tor, hence the awkward heuristic of checking for port 9050. So probably we should add a "tor" checkbox in the UI and a -tor commandline option?

@gmaxwell For IPv6, I've already implemented SOCKS5 client support, which is also provided by Tor. SOCKS5 supports IPv4, IPv6 and hostname destinations.

Is there any reason to stick to SOCKS4?

Some legacy and/or custom proxy software supports only SOCKS4.

I really don't know how much of a problem this is for bitcoin, but dropping support for v4 based on implementing v5 is not very common. Most software has a 'proxy type' setting which can be set to either 4 or 5 (sometimes also 4a which is 4 + hostnames and HTTP proxy CONNECT)

I think this can be considered fixed since -proxydns?