Re: [tor-dev] Draft Proposal: Random Number Generation During Tor Voting

[Tim Wilson-Brown - teor <teor2345@xxxxxxxxx>]

On 7 Sep 2015, at 23:36, David Goulet <dgoulet@xxxxxxxxx> 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)

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