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 <[email protected]> wrote: >>> On Mar 2, 2011, at 8:06 AM, Nick Mathewson wrote: >>>> On Tue, Feb 22, 2011 at 1:34 AM, Sebastian Hahn <[email protected]> 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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
