Hi Nick,
> On 14 Mar 2020, at 14:44, teor <teor@xxxxxxxxxx> wrote:
>
>> * As I work, I'm identifying other issues in tor that stand in
>> the way of a good efficient walking onion implementation that
>> will require other follow-up work. This week I ran into a
>> need for non-TAP-based v2 hidden services, and a need for a
>> more efficient family encoding. I'm keeping track of these
>> in my outline file.
Here's another issue you might want to consider:
Currently, new relays get in the consensus as soon as:
* they post their descriptors, and
* a majority of authorities can contact their ORPorts.
That means clients and relays waste a whole bunch of bandwidth
downloading consensus info and descriptors for relays with very
low weights.
Instead, we could have two documents:
* a "potential relays" document, that's used by the authorities,
bandwidth scanner, and any other relay test infrastructure
(perhaps exit scanners, sybil scanners, and other tools), and
* a "useful relays" document, that contains good relays with
reasonable weights.
Let's think about this kind of efficiency as part of walking
onions.
We might even be able to make this change before walking onions, by:
* making sbws and other tools use the ns consensus
(I think most tools already use the ns consensus), and
* adding a new consensus method, which requires a minimum consensus
weight (or consensus weight fraction) for relays in the microdesc
consensus.
Since relays and clients use the microdesc consensus, low-weight
relays would disappear from the network. But they would still be in
the ns consensus.
We might find some interesting bugs in tor though. We never quite
got rid of all the old code that uses the ns consensus and full
descriptors.
T
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev