[tor-dev] Proposal 178: Require majority of authorities to vote for consensus parameters

[Sebastian Hahn]

On May 4, 2011, at 2:49 AM, Nick Mathewson wrote:

> On Mon, May 2, 2011 at 5:23 AM, Sebastian Hahn <hahn.seb at web.de> wrote:
>> 
>> On Mar 2, 2011, at 8:06 AM, Nick Mathewson wrote:
>> 
>>> On Tue, Feb 22, 2011 at 1:34 AM, Sebastian Hahn <hahn.seb at web.de> wrote:
>>> 
>>>> Design:
>>>> 
>>>> When the consensus is generated, the directory authorities ensure that
>>>> a param is only included in the list of params if at least half of the
>>>> total number of authorities votes for that param. The value chosen is
>>>> the low-median of all the votes. We don't mandate that the authorities
>>>> have to vote on exactly the same value for it to be included because
>>>> some consensus parameters could be the result of active measurements
>>>> that individual authorities make.
>>> 
>>> This is possibly bikeshed, but I would suggest that instead of
>>> requiring half of  existing authorities to vote on a particular
>>> parameter, we require 3 or more to vote on it. (As a degenerate case,
>>> fall back to "at least half" if there are fewer than 6 authorities in
>>> the clique.)
>> 
>> Hrm. I'm not too happy with this,
> 
> My rationale was that in practice, it's a pain in practice to try to
> get more than 3 or so authority operators to try out an experimental
> parameter in a timely basis.  If the set of authority operators ever
> grows, getting half of the ops to tweak a parameter in a hurry will
> get even harder.

Yes, I understand that argument. On the other hand, getting a hold
of n-3 authority operators that did set a param can also be hard
(I'm thinking about the last time we thought that dirauths might crash
the network by distributing ipv6 descriptors, where it took a while to
even reach those who had applied our first patch).

>> unless we also include a way for a
>> majority of authorities to prevent voting on that parameter altogether.
> 
> What if we say that as a matter of design, there should always be, for
> each parameter, a value that's semantically equivalent to the absence
> of the parameter?  That way a majority of authorities can "turn off"
> any parameter without any additional machinery during the vote.

This could work, but that means we need to re-implement a bunch of
our parameters that don't currently work that way. I'm thinking about
bug 1947 here, for example. Overloading the param value to mean
"this special integer means this specific param is not set" might also
lead to interesting situations where we aren't quite sure if 0 or
INT32_MIN or something else is responsible for disabling a param.
Maybe that's still easier to do than other ideas, and more convenient
in the common case where we don't have a bad param that we must
not set, which is what we should care about. I'm not sold on your
idea just yet, but I do think it can work.

Sebastian