On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote: > > > 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? Hrm... that is a good point! We could put in a maximum number of conflicts let's say 5 and add a timestamp to it (meh...). Or when voting, we only add the latest per "identity". I think the important part is just that "oh at this period, we have a proof of conclict, wtf". But tbh, I'm less and less confident about this because for example an authority voting then rebooting immediately and then voting again will trigger a conflict even though this is totally acceptable I think (assuming the initial commit value was not saved in the state on disk). I originally liked the idea of having a proof in the vote that a conflict happened which could help us detect mis-behaving dirauth (malicious or not). If we really want it, I would use the *simplest* i.e use the latest thus one per identity. Thanks! David! > > 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) > > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev