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

[Tim Wilson-Brown - teor]

> On 8 Nov 2015, at 05:39, s7r <s7r at sky-ip.org> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151109/f1d7c7b8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151109/f1d7c7b8/attachment-0001.sig>