Proposal 165: Easy migration for voting authority sets
Nick Mathewson
nickm at torproject.org
Thu May 28 21:29:56 UTC 2009
On Thu, May 28, 2009 at 05:11:26PM -0400, Marcus Griep wrote:
> I'm probably jumping into the middle of a debate I know nothing
> about, but I think I have a clarification of note:
>
> Paul Syverson wrote:
> > I didn't miss the line. My point is that you won't ever get
> > any honest authorities to drop the set including Bob, so you will
> > never make it to 2 without changing something in the protocol.
> > if either of those two authorities drop the list that includes Bob,
> > they will not be honest (following the proposed protocol), because
> > they are supposed to prefer the voting set for which the number of
> > authorities that list themselves in it is higher not just the
> > one that is moving in the direction they would like to go.
> > It's the criterion for delisting a set that does not work.
>
> Each authority would have multiple voting sets. When we want to
> "drop Bob", we don't just drop Bob from the voting set. We create a
> new voting set that doesn't contain Bob (VS-B) and publish that
> along with the old voting set with Bob (VS+B). This doesn't need to
> happen all at once; VS+B remains the consensus vote. However, once a
> (super)majority (the level 'X') is reached, the authorities take
> action again and begin removing VS+B. Once the numebr of authorities
> in VS-B listing VS-B as one of their voting sets is greater than the
> number of authorities in VS+B listing VS-B as on of their voting
> sets, VS-B becomes the consensus vote.
I think that one problem we've got in the discussion here is that we
aren't distinguishing well between the authority directory servers and
the operators of those servers. My plan here has been that changes in
listed authority sets should only happens on the initiative of the
operators. The servers on their own never decide it's time to start
or stop listing a given set. Human intervention is explicitly
required.
--
Nick
More information about the tor-dev
mailing list