On Fri, Mar 20, 2020 at 12:38 PM teor <[email protected]> wrote: > > Hi Nick, > > > On 20 Mar 2020, at 23:01, Nick Mathewson <[email protected]> wrote: > > > > On Wed, Mar 18, 2020 at 11:21 AM teor <[email protected]> wrote: > >> > >>> On 14 Mar 2020, at 14:44, teor <[email protected]> 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: > > > > Thanks for this! This dovetails nicely with some of the voting design > > work I'm up to right now. > > It would be great to have a protocol that doesn't depend on: > * time synchronisation > * big documents > * one-shot updates > * absolute consistency
Hi! I think that _some_ of these changes are orthogonal to the shifts we'll need for walking onions, but some of them do dovetail nicely. I'm going to keep this email as a note to myself, so that I can double-check whether any of these items are precluded by choices I'm making in the design space. > We've already made vote timing a bit more robust in the tor master > branch, by ignoring late votes: > https://trac.torproject.org/projects/tor/ticket/4631 > > Here's a few other tweaks that might help: > > Tor halves the consensus interval when there is no fresh consensus. > But changing the interval makes tor's code much more complex. > Instead, let's have a fixed consensus interval. And make it long > enough for efficiency, but short enough to recover from a failed > consensus. This makes sense; I'd forgotten that we did this. > Let's support vote diffs, as well as consensus diffs. Vote diffs > don't help when posting votes. But when requesting votes, authorities > can include hashes of votes they already have. That way, authorities > that are under heavy load are more likely to get all the votes. Actually, we *can* do them when posting votes; I've sketched out a design here in the work-in-progress voting spec. > We could increase the time that authorities have to fetch votes, and > make them retry fetches every few minutes. > > We could do consistency checks on smaller shards, so that a > consistency failure in any one document does not break the entire > consensus. This seems like something we could do as a followup here? It does seem like it could get pretty complex. > We could create a shard for each supported consensus method (like we > do microdescriptors). That way, a consistency failure in any one > consensus method does not break the entire consensus. Hm, interesting. This would involve generating multiple consensuses with different methods? It sounds orthogonal to me, but quite possibly a good idea. But we'd have to withhold signatures on older consensus methods until we're sure that the newer ones are failing -- and I worry about attacks where we _cause_ a newer consensus method to be inconsistent specifically so we can force an older one. I also worry about mix-and-match attacks on the different shards. > We could make shards valid for a longer time, so that if the > replacement shard does not reach consensus, the older one is used. > > Then, the final documents are a combination of all the consistent > shards, using the highest consistent consensus method. (Much like > the current microdesc consensus.) > > Once we've made some of those changes, then some other changes > become plausible: > > Let's make votes valid for exactly 2 voting periods, and use the > latest available vote from each authority. Hmmm. So this doesn't help us much in the case when an authority goes down -- it just means that its vote counts for an extra hour more than it would otherwise. That would buy us an hour of extra consensus time -- but it would only be a big improvement if the authority is -regularly- failing to upload a vote. For that case, I think it might make more sense to address the reliability problem directly instead of trying to work around it. > [...] I dig the idea of dropping time synchronization if we can; let's look into this more. It seems like something we can do orthogonally to walking onions, though? -- Nick _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
