Hi Nick,
On 14 Mar 2020, at 14:44, teor teor@riseup.net 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