[tor-dev] Draft Proposal: Random Number Generation During Tor Voting
Tim Wilson-Brown - teor
teor2345 at gmail.com
Mon Sep 7 15:04:36 UTC 2015
> On 7 Sep 2015, at 23:36, David Goulet <dgoulet at ev0ke.net> wrote:
> ...
> Please review it, mostly format of the state (before the SR document)
> has changed. As well as a new "conflict" line is added to the vote.
> …
> If an authority sees two distinct commitments from an other authority in
> the same period, the authority is broken or evil: you include both, thereby
> proving there is a conflict:
>
> "shared-rand-conflict" SP identity SP commit1 SP commit2 NL
>
> where "identity" is the hex-encoded commitment's authority fingerprint.
> "commit1" is the previous commit that the authority had in its state and
> "commit2" is the new received commit of the same period. Both commit values
> are constructed as specified in section [COMMITENCODING].
What if there are more than two conflicting commitments?
Should they all be included?
Is there a denial of service opportunity here, where an authority just keeps generating commitments to fill up the state files?
When there’s a conflict, should we order the multiple different commitments in numeric order, rather than time order?
Time order involves the question of which commitment was received first, which isn’t necessarily consistent between authorities.
(Does it need to be? If there’s no SR doc, I guess not.)
Tim (teor)
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP: 968F094B (ABFED1AC & A39A9058 expire 15 Sep 2015)
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F (From 1 Sep 2015)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150908/edcb4933/attachment.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/20150908/edcb4933/attachment.sig>
More information about the tor-dev
mailing list