[tor-relays] (FWD) Network is suffering with only two torflows; can you help?

[Roger Dingledine <arma@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxx> -----

Date: Mon, 6 Apr 2020 06:06:26 -0400
From: Roger Dingledine <arma@xxxxxxxxxxxxxx>
To: dir-auth <dir-auth@xxxxxxxxxxxxxxxxxxxx>
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 -----

_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays