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

[Sebastian Hahn]

On May 4, 2011, at 7:20 AM, Sebastian Hahn wrote:
> 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

I have since become convinced that it would be better to get
this implemented quickly, even if it doesn't have a generic
"prevent this param from being set" mechanism. I would thus like
to change the proposal to the following (also available in my
prop178 branch in my torspec repository). The diff is available at
https://gitweb.torproject.org/sebastian/torspec.git/commitdiff/db9a429d005ae05ad0841e6026941594d5740b0b

The branch safer_params in my repository has been updated to
reflect the new state of the proposal, the original branch is
available as safer_params_old. I'm still targetting this for 0.2.3,
but if that's not possible we can also easily delay it.

Thanks
Sebastian