onlynet=tor still using exits for seeds is confusing

zw commented at 2:44 pm on October 12, 2015: contributor

I run some wallet-less listening nodes behind Tor, for fuzzies and occasional somewhat-private TX submission. In this setup, minimising load on exits seems more important than having clearnet peers, so I use onlynet=tor. To minimise room for leaks their network configuration also makes Tor their only window to the world. They do get inbound connections through their onion services. For reasons probably not relevant, they may be atypically peer-starved at times.

I see outbound connections to the seeds via exits:

 02015-10-XX XX:XX:XX Bitcoin version v0.11.0.0-(the 0.11.0 tag from Github)
 1    (omit OpenSSL, directories)
 22015-10-XX XX:XX:XX Using at most 125 connections (1024 file descriptors available)
 32015-10-XX XX:XX:XX Using 0 threads for script verification
 42015-10-XX XX:XX:XX scheduler thread start
 5    (omit RPC)
 62015-10-XX XX:XX:XX Bound to X.X.X.X:8333
 72015-10-XX XX:XX:XX AddLocal(XXXXXXXXXXXXXXXX.onion:8333,4)
 8    (omit cache config, LevelDB lines)
 92015-10-XX XX:XX:XX No wallet support compiled in!
10    (omit best chain)
112015-10-XX XX:XX:XX init message: Loading addresses...
122015-10-XX XX:XX:XX Loaded (several hundred) addresses from peers.dat  9ms
132015-10-XX XX:XX:XX init message: Done loading
142015-10-XX XX:XX:XX msghand thread start
152015-10-XX XX:XX:XX opencon thread start
162015-10-XX XX:XX:XX addcon thread start
172015-10-XX XX:XX:XX net thread start
182015-10-XX XX:XX:XX dnsseed thread start
192015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
202015-10-XX XX:XX:XX Loading addresses from DNS seeds (could take a while)
212015-10-XX XX:XX:XX 0 addresses found from DNS seeds
222015-10-XX XX:XX:XX dnsseed thread exit
23    (omit interspersed "receive version message", both with
24     us=XXXXXXXXXXXXXXXX.onion:8333 and us=dotted quad)
252015-10-XX XX:XX:XX SOCKS5 connecting seed.bitcoin.sipa.be
262015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
272015-10-XX XX:XX:XX SOCKS5 connecting dnsseed.bluematt.me
282015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
292015-10-XX XX:XX:XX SOCKS5 connecting dnsseed.bitcoin.dashjr.org
302015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
312015-10-XX XX:XX:XX SOCKS5 connecting seed.bitcoinstats.com
322015-10-XX XX:XX:XX SOCKS5 connected seed.bitcoinstats.com
332015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
342015-10-XX XX:XX:XX SOCKS5 connected XXXXXXXXXXXXXXXX.onion
352015-10-XX XX:XX:XX SOCKS5 connecting bitseed.xf2.org
362015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
372015-10-XX XX:XX:XX SOCKS5 connected XXXXXXXXXXXXXXXX.onion
382015-10-XX XX:XX:XX SOCKS5 connecting seed.bitcoin.jonasschnelli.ch
392015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
402015-10-XX XX:XX:XX SOCKS5 connected XXXXXXXXXXXXXXXX.onion
412015-10-XX XX:XX:XX SOCKS5 connecting seed.bitcoin.sipa.be
422015-10-XX XX:XX:XX SOCKS5 connected seed.bitcoin.sipa.be
432015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
442015-10-XX XX:XX:XX SOCKS5 connected XXXXXXXXXXXXXXXX.onion
452015-10-XX XX:XX:XX SOCKS5 connecting dnsseed.bluematt.me
462015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
472015-10-XX XX:XX:XX SOCKS5 connecting dnsseed.bitcoin.dashjr.org
482015-10-XX XX:XX:XX SOCKS5 connected dnsseed.bitcoin.dashjr.org
492015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
502015-10-XX XX:XX:XX SOCKS5 connected XXXXXXXXXXXXXXXX.onion
512015-10-XX XX:XX:XX SOCKS5 connecting bitseed.xf2.org
522015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
532015-10-XX XX:XX:XX SOCKS5 connecting seed.bitcoin.jonasschnelli.ch
542015-10-XX XX:XX:XX SOCKS5 connected seed.bitcoin.jonasschnelli.ch
552015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
562015-10-XX XX:XX:XX SOCKS5 connected XXXXXXXXXXXXXXXX.onion
572015-10-XX XX:XX:XX SOCKS5 connecting dnsseed.bluematt.me
582015-10-XX XX:XX:XX SOCKS5 connected dnsseed.bluematt.me
592015-10-XX XX:XX:XX SOCKS5 connecting bitseed.xf2.org
602015-10-XX XX:XX:XX SOCKS5 connecting XXXXXXXXXXXXXXXX.onion
612015-10-XX XX:XX:XX SOCKS5 connected XXXXXXXXXXXXXXXX.onion
62    (usually stops attempting seeds ~30m after startup)

@laanwj says “if you have a proxy it [still] does AddOneShot(seed.host)” and I dimly recall something about an exception being required for bootstrap before Core had an onion seed list, otherwise bootstrap would go nowhere. Even if the user is aware of that, the persistent attempted connections to the seeds for a while after apparent dnsseed thread exit cause confusion (although maybe that peer starvation I mentioned is a prerequisite for getting confused).

Having healthy peer lists on these nodes already, I’m sure I can just use dnsseed=0, but I think it’s worth making my existing configuration less surprising. onlynet=tor really should mean “just onion peers”, or be renamed, or have clearly documented exceptions, because smells like the the sort of thing that bites you down the road when new code or an unexpected use case comes along.

TheBlueMatt commented at 8:07 pm on October 12, 2015: contributor

You still have to bootstrap somehow. If your addrman has entries, it should be waiting 11 seconds before it bothers running the dnsseed connect stuff. We could maybe extend the 11 seconds if you set onlynet=tor, but I’m not sure what else you’re suggesting be done?

laanwj commented at 8:30 pm on October 12, 2015: member

Right - it shouldn’t connect to ipv4/ipv6 dnsseeds if onlynet=tor. That’s surprising behavior.

It’s also unnecessary, there are some hardcoded onion seeds in src/chainparamsseeds.h that it can use.

laanwj added the label P2P on Oct 12, 2015

TheBlueMatt commented at 9:20 pm on October 12, 2015: contributor

I’m not actually sure we shouldn’t connect to them - its rather easy for the hardcoded onion seeds to go down, then we’re stuck with never being able to sync? We should maybe use the hardcoded nodes first and give ourselves more time to find a connection, but I’m not sure it should be turned off entirely.

laanwj commented at 9:38 pm on October 12, 2015: member

People choose to use onlynet=tor. It’s not a default in any circumstances. Yes, the consequence may be that it’s harder to find peers, but the user should take that into account. The idea is to avoid using exit nodes.

An preferable option would be to have one or more ‘DNS seeds’ (a misnomer in this case as no DNS is used, it’s a one-shot node connection) on .onion as hidden service.

TheBlueMatt commented at 10:10 pm on October 12, 2015: contributor

Yea, a one-shot onion address is much better.

laanwj commented at 8:00 am on October 13, 2015: member

I know at least some of the DNS seeds have Tor running (to scan .onion peers) - so adding a hidden service that redirects to their 8333 port may be a small step. Ping @sipa @jonasschnelli

TheBlueMatt commented at 8:42 am on October 13, 2015: contributor

Huh? You mean doing DNS-over-TCP to a .onion? Or do you suggest a new service for such a thing?

sipa commented at 8:45 am on October 13, 2015: member

I think he means using a oneshot P2P connection to the onion address (connecf, getaddr, wait for addr response, disconnect).

TheBlueMatt commented at 8:50 am on October 13, 2015: contributor

Yes, but he said you connect to the DNS Seed over Tor. That makes no sense - the DNS Seeds are not designed to listen or provide addr message responses. Are y’all suggesting adding this?

sipa commented at 8:55 am on October 13, 2015: member

If you ‘connect’ to a DNS seed over Tor, your exit node will resolve the name for you, and forward the connection there, so you actually get a connection to one of the results of the seed, not to the seeder itself.

sipa commented at 8:56 am on October 13, 2015: member

… so the suggestion here is to just do oneshot connections to a few hardcoded .onion addresses instead of actually using a seeder.

TheBlueMatt commented at 9:01 am on October 13, 2015: contributor

Yes, that is what I thought we were talking about, hence why I was confused by @laanwj’s mention of DNS seeds exposing their 8333 port…

gits7r commented at 10:35 pm on October 13, 2015: none

I agree we should make onlynet=tor do what it says: connect only to onion peers. If it cannot because it doesn’t find any, or because the Tor instance is broken, or because the clock is skewed, or whatever, so be it. onlynet=tor is not on by default and it has a clear name, so whoever is using it knows what he’s doing. @laanwj I am running 3 onlynet=tor full nodes for quite some time, and they have never connected to a clearnet peer as far as I was able to see. I use addnode=foo.onion in bitcoin.conf along with onlynet=tor so I am guessing that is why it has no problems bootstrapping.

Unfortunately Tor only supports resolving anonymously DNS A records at Exit node end. If it supported looking up of more types of records and validating DNSSEC signatures, we could add hostnames of onion peers in TXT records to the main hardocded clearnet (normal DNS) seed nodes and an onlynet=tor node would just take the onion hostnames from there and connect to them without actually establishing connections to the clearnet seed nodes. There is a proposal for this so this shouldn’t happen too far way in the future, hopefully. Let me know if my onion nodes can help in any way.

laanwj commented at 10:30 am on October 27, 2015: member

If you ‘connect’ to a DNS seed over Tor, your exit node will resolve the name for you, and forward the connection there, so you actually get a connection to one of the results of the seed, not to the seeder itself.

OK I didn’t know that. So it does a oneshot to a random peer. Whoa, that certainly shouldn’t bypass onlynet=tor.

ghost commented at 4:51 pm on February 15, 2016: none

0.12 RC5

At least, from my point of view as a user, this dozens of messages in debug.log while bootstrapping are confusing/disturbing because they seem to be senseless when using onlynet=onion:

0SOCKS5 connecting bitseed.xf2.org
1ERROR: Proxy error: connection refused
2SOCKS5 connecting bitseed.xf2.org
3ERROR: Error reading proxy response

Additionally, this message:

0SOCKS5 connecting seed.bitcoin.jonasschnelli.ch
1SOCKS5 connected seed.bitcoin.jonasschnelli.ch

as I interpret the comment of sipa

If you ‘connect’ to a DNS seed over Tor, your exit node will resolve the name for you, and forward the connection there, so you actually get a connection to one of the results of the seed, not to the seeder itself.

I would suggest the debug message more verbose and clear explaining, e.g.

“connecting to xxxxxx.onion (.onion DNS name reverse looked up from 1.2.3.4 (seed.bitcoin.jonasschnelli.ch))” ?

If it is a kind of IP address reverse lookup, there should not be written a name? I could not get clear of that reading https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery http://bitcoin.stackexchange.com/questions/14371/what-is-a-dns-seed-node-vs-a-seed-node

ghost commented at 12:49 pm on January 15, 2017: none

Running 0.13.2 with onlynet=tor there are still these debug messages on startup. AFAIK with onlynet=tor the node can only connect to .onion addresses, so it’s obviously that connection attempts to hostnames of other TLDs fail.

 012:34:26 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
 112:34:47 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
 212:34:54 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
 312:34:59 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
 412:35:19 ERROR: Error reading proxy response
 512:35:33 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
 612:35:53 ERROR: Error reading proxy response
 712:35:56 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
 812:36:12 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
 912:36:27 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
1012:36:47 ERROR: Error reading proxy response
1112:36:50 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
1212:36:56 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
1312:37:11 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
1412:37:27 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
1512:37:31 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
1612:37:52 ERROR: Error reading proxy response
1712:38:12 Socks5() connect to dnsseed.bluematt.me:8333 failed: host unreachable
1812:38:33 ERROR: Error reading proxy response

Sjors commented at 6:55 pm on June 20, 2022: member

With Tor v2 deprecation there’s no longer any point in polling DNS seeds with -onlynet=tor, since they don’t return v3 onion services.

fanquake referenced this in commit 37095c7dc4 on Sep 7, 2022

fanquake closed this on Sep 7, 2022

bitcoin locked this on Sep 7, 2023

onlynet=tor still using exits for seeds is confusing #6808