[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting




On 8 Nov 2015, at 05:39, s7r <s7r@xxxxxxxxxx> wrote:

For all versions of the proposal, regardless if we use the conflict
code or not, I think we should require authorities to participate for
at least for 3 rounds of the reveal phase, otherwise not participate
in the shared randomness calculation for the day.

This does not have a significant effect over the partitioning attack
(which we agreed there's no sense addressing) but it may prevent
consensus conflicts that could lead to SRDISASTER or accidental
partitioning, in case an authority simply joins too late and for a
reason or other doesn't catch up with the rest of the votes from other
authorities. Plus, I don't see a reason for why we shouldn't require
this - the probability for an authority to be genuinely available
_only_ for the last reveal round is reasonably low. Also, if an
authority was absent for > 23 hours in a day, not allowing it to
participate in the shared randomness calculation for that day only is
not an unusual or abusive punishment.

If an authority was present and voted in that protocol run before hour
-3, but missed hour -3, it should be allowed to participate. Basically
require to have at least 3 reveal votes in the reveal phase of a
single day to make sure it has quite low chances not to be in sync. Or
we could only require the last 3 reveal rounds from 21:00 UTC or hour
-3 to hour 0.

This will be decided just by looking from code simplicity point of
view, as in terms of security and followed goal both provide the same
effect. I am equally fine with both approaches (but it's very much
more unlikely to miss 3 rounds (votes) during ALL the reveal phase as
opposite to missing the last 3 consecutive ones).

What do you think?

Whatever we decide, can we make it a torrc option?
That way, authorities running the SR code can bootstrap relatively quickly in test networks.
(The fastest possible bootstrap would have 1 SR commit round and 1 SR reveal round.) 

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev