Investigate Tor network issues

[ManfredKarrer]

That issues collects information related to the Tor network issues started in the last months.

Tor is under heavy load / DDoS attack

Could Tor devs provide an update on DOS attacks?
https://lists.torproject.org/pipermail/tor-relays/2017-December/014002.html
https://lists.torproject.org/pipermail/tor-relays/2017-December/014003.html
https://lists.torproject.org/pipermail/tor-relays/2018-January/014175.html

Ongoing DDoS on the Network - Status:
https://lists.torproject.org/pipermail/tor-project/2017-December/001604.html

Tor users have grown by 100% in the last month:
https://metrics.torproject.org/userstats-relay-country.html?start=2016-10-21&end=2018-01-19&country=all&events=off

At the same time the nr. of relays have decreased:
https://metrics.torproject.org/networksize.html?start=2016-10-21&end=2018-01-19

Those Tor issues coincide with the 0.6.0 release where we introduced several changes (provided btc nodes, use new netlayer library, ...).

Compare with old Bisq version
First approach to see if the new code/provided nodes is the main reason or the Tor network issues is to check the old version. I go even back before 0.5.
I used version 0.4.9.9 to compare the behavior of the Tor network compared to the current version 0.6.3.

With 0.4.9.9 Tor startup takes about 15 seconds. What I remember it was much faster in the past (about 6 sec. like commented in the code).
Tor Hidden service publishing takes about 30-40 sec. which is as it was in the past.

There are very few Bitcoin Tor nodes available (1-3). That was not the case in the past as far I remember. Might be that there are really less Bitcoin Tor nodes available now but looks strange… Also never saw one of our provided BTC nodes listed there. Might be our nodes are not advertising themselves as onion nodes to the Bitcoin networks/seed nodes as they run as clearnet nodes and only accept Tor HS connections (they don't connect to other BTC nodes in HS mode).

The startup for connecting to Bitcoin nodes is also very slow (about 2-3 min. to get > 8 nodes. often never get to 12 nodes). I doubt it was that slow in the past as otherwise the Tor option would have had too many drawbacks/risks and we would not have suggested it as default option.

Version 0.6.3. took about 10-15 sec in average (17, 23, 10, 17, 7, 9) to start up Tor and about 30-40 sec for the HS publishing.
To have all BTC nodes connected takes about 30-60 sec.

So it seems the new Tor library (and latest Tor binary) has improved startup compared to the 0.4.9.9 version (though Tor network was under less pressure and it was faster compared to now).

Conclusion
The new code base and the connection to our provided BTC nodes seem to be better then the old 0.4.9.9 version. The Tor network is under heavy load/attack since about 2 months which is probably a main reason for our issues.

Next step:
Analyse the Bisq log files

[tr37ion]

Not sure if this helps. I got this solved by installing Arch Linux AUR bisq-bin package instead of bisq-git. Must have been around one week ago.

[ManfredKarrer]

See #1300

[cbeams]

@ManfredKarrer, with #1300 and #1301 complete, is there anything further you want to do with this issue?

[ManfredKarrer]

I would like to keep it open as it would require some dev resources to investigate further, get in touch with Tor devs, etc.

[cbeams]

Ok, shall we move it back to Discussion? Priorities? Please do as you see fit. I'm assuming it is not still In Progress per se.

[ManfredKarrer]

Update from Tor mailing list:
Seems they have added some Dos Protection, but still unclear if they found out exactly what caused it and who might have been behind it:
https://lists.torproject.org/pipermail/tor-relays/2018-February/014391.html
https://lists.torproject.org/pipermail/tor-relays/2018-February/014397.html

Summary of recent Dos changes:
https://lists.torproject.org/pipermail/tor-relays/2018-January/014357.html

"Major features:
- Give relays some defenses against the recent network overload. We
start with three defenses (default parameters in parentheses).
First: if a single client address makes too many connections
(>100), hang up on further connections. Second: if a single client
address makes circuits too quickly (more than 3 per second, with
an allowed burst of 90) while also having too many connections open
(3), refuse new create cells for the next while (1-2 hours). Third:
if a client asks to establish a rendezvous point to you directly,
ignore the request. These defenses can be manually controlled
by new torrc options, but relays will also take guidance from
consensus parameters, so there's no need to configure anything
manually. Implements ticket 24902."

I am not sure if at startup we could reach one of those limits. E.g. starting > 3 circuits in 3 seconds (the 90 bust should be safe for us). We start connections to 9 btc nodes and 8 p2p nodes. The btc nodes gets fast built up, the p2p nodes slowly.

Here another link:
https://people.torproject.org/~dgoulet/volatile/ddos-design.txt

Anyone who is more familiar with Tor is highly welcome to help us in that area!

[ManfredKarrer]

From local tests I see also that starting to the tor network is much more reliable again. Takes usually 7 seconds.

[ManfredKarrer]

Seems Tor is much faster again. On http://seedmonitor.0-2-1.net/ I see now rrt about 10 sec. Last months/weeks it was often about 30-50 sec.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ripcurlx]

I think this can be closed.