On Tue, Sep 8, 2015 at 7:10 AM, David Goulet <[email protected]> wrote: > On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote: >> >> > On 7 Sep 2015, at 23:36, David Goulet <[email protected]> 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".
It's sufficient to log two conflicting commitments per authority for the same period in order to prove that a conflict exists. There's no reason to keep more. > 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 say, "Save before publishing, and make sure you don't do two commitments for one period." Assuming this kind of accident happens very rarely, I don't think we need a way to allow it to succeed anyway. -- Nick _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
