FYI, below is a start at a short-term plan to address the current network weighting issues, now that, as of a few weeks ago, gabelmoo's torflow died and Sebastian hasn't been able to get it going properly again.
See also nifty's new ticket: https://bugs.torproject.org/33824
--Roger
----- Forwarded message from Roger Dingledine arma@torproject.org -----
Date: Mon, 6 Apr 2020 06:06:26 -0400 From: Roger Dingledine arma@torproject.org To: dir-auth dir-auth@lists.torproject.org Subject: Network is suffering with only two torflows; can you help?
tl;dr there's a way at the bottom of this mail that you can help even without running torflow yourself.
[...]
So, it looks like we're down to two remaining torflows, and because that's less than three, we're suffering much more from the current errors in sbws.
Specifically, (a) sbws doesn't vote for some relays, and (b) sbws votes a super low weight for some relays.
There are somewhere between 500 and 1000 relays that are getting left out of sbws's opinions: https://consensus-health.torproject.org/#bwauthstatus and then some thousands more that are getting drastically underweighted, per the "Bandwidth Auth Statistics" graphs at the bottom of https://consensus-health.torproject.org/graphs.html
Relay operators are sad that their relays are being useless, and thinking about how maybe they should shut them off if nobody's going to use them.
I hear from GeKo that the sbws devs are aiming to fix the sbws issues by end-of-April.
That's great, but I wonder if there are some short term hacks we can do that will help until then.
Option 1: dizum, dannenberg, or tor26 start up a torflow. I'm guessing they would have done this already if they were going to.
Option 2: maatuska, longclaw, or bastet switch from sbws to torflow. Is this an workable option for any of you?
Option 3: Any of you besides Faravahar start hourly importing a copy of moria1's weights: https://freehaven.net/~arma/bwscan.V3BandwidthsFile and you vote them as though you were running your own torflow, but you don't need your own torflow.
Option 3 is pretty wild at first glance -- it violates some trust and independence assumptions. But for those who aren't running a bwauth, you're already not being listened to about bandwidth weights. So I think this would be a fine hack in the short term to rescue the network, while we wait for sbws.
Any takers? :)
Here's the simple two-step process for testing the idea:
(1) Set a "45 0-23 * * *" cron line to wget the above freehaven url. (2) In your torrc, set "V3BandwidthsFile /path/to/that/bwfile"
If you like the idea, and it's just the wget that's too sketchy for you, I can set up an ssh account that just dumps the file at you when you present the right ssh key.
Or for super overkill, you'll notice that moria1's (signed) vote has these two lines it: bandwidth-file-headers timestamp=1586162183 bandwidth-file-digest sha256=24+52C1ItwnAyBTtBteyy6tjxk8JnUpQ/XZx3YStEXE so with some stem or shell programming we should be able to verify the file itself, rather than just verifying the place it came from. We could be getting away from "short-term hack" there though. :)
--Roger
----- End forwarded message -----
On Mon, Apr 06, 2020 at 06:21:00AM -0400, Roger Dingledine wrote:
FYI, below is a start at a short-term plan to address the current network weighting issues, now that, as of a few weeks ago, gabelmoo's torflow died and Sebastian hasn't been able to get it going properly again.
Things are looking much better:
(1) gabelmoo got its torflow going again and it's ramping up the set of relays that it votes on.
(2) bastet switched from sbws (the newer one which is our hope for the future but which also still has important bugs) to torflow.
(3) dizum is now voting using a copy of moria1's weights.
So we now have 3 torflows fully bootstrapped, and 2 torflows partially bootstrapped, and we still have 2 sbws's running for comparison and future debugging: https://consensus-health.torproject.org/#bwauthstatus
If you want to see the visualization of these changes, check out the "Bandwidth Auth Statistics, Past 7 Days" section on https://consensus-health.torproject.org/graphs.html where you can see the gabelmoo and bastet changes, and how those changes are reflected in the graphs for the other bwauths too.
(In these graphs, the fraction of orange on the graph is how many relays that bwauth is voting a low weight for. So a graph with a lot of orange in it indicates that the bwauth is voting lower weights than expected but that it's being overruled by the other bwauths. In a balanced equilibrium, the amount of orange should equal the amount of purple.)
So for those relay operators who have had a weirdly low bandwidth weight lately, it should be starting to recover now. Thanks for hanging in there.
And for those relay operators who have had a weirdly high bandwidth weight lately, it should also be recovering, i.e. getting lower, as load gets shifted to other relays. :)
That said: if your relay is still having a weirdly low weight, and that remains the case over the next few days, please do let us know and we'll check it out in more detail.
Thanks! --Roger
tor-relays@lists.torproject.org