> On 7 Sep 2015, at 23:36, David Goulet <dgou...@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)
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
