Proposal: More robust consensus voting with diverse authority sets

[Peter Palfrader]

On Wed, 02 Apr 2008, Nick Mathewson wrote:

> > This results in having fewer useless consensus documents that caches
> > need to fetch only to learn that - with all likelyhood - they will not
> > trust it either.
> 
> Hm.  I'm still not at all fond of the failure mode where a client
> downloads a consensus, decides it doesn't like it, and downloads
> another and another ad infinitum.
>                                     Perhaps we could add a URL format
> in order to request a consensus only if it's endorsed by certain
> authorities?

That's a good idea, but it probably is quite independent of this
proposal.  i.e. we should switch to the fpr URL format whether we go
forward with this proposal or not.


> Another question, based on our brief IRC conversation the other day:
> There seems to be a goals/methods disconnect in this proposal.  Given
> that the only application for this proposal is to be able to add or
> remove authorities from the list without, it seems like overkill to
                               ... without forcing all authorities
                                      to make the change at once, it seems ...
> solve the more general problem of what do we do with an arbitrarily
> screwed-up authority trust graph.  Is there a simpler approach that
> does what we want, or do we really need to do the NP-hard thing?

I admit that I did not pay any attention to computational complexity
when I came up with the procedure.

We might get away with something in Tor like "this authority is new, do
not included its votes in your consensus building before <date>", i.e.
basically making flag days for which authorities we trust in.

Peter