Hi All,
Currently, the shared random system treats the first vote of the next
commit phase specially - it's the only time it tries to agree on a new
shared random value.
This makes one consensus in each day particularly attractive to
adversaries (or particularly vulnerable to failures), because if we fail
to agree on that consensus, the next shared random value is never
agreed. This makes hidden service behaviour far more predictable
for the next 24 hours.
But we can try to agree 12 times on a new shared random value like this:
* for the first consensus in the new commit period:
* vote the calculated shared random value based on the commits and reveals we've seen;
* for subsequent consensuses in the new commit period:
* if we have an agreed shared random value from a trusted, previous
consensus in the period, vote that value;
* if not, (if the new shared random value is missing from all previous consensuses in that
period, or there is no trusted consensus), continue to vote our calculated value.
This way, we try up to 12 times to agree on a shared random value. (But we
never change an agreed value after we've agreed on it.)
This is very similar to how the previous shared random value is determined.
I've added #19045 to keep track of this:
https://trac.torproject.org/projects/tor/ticket/19045
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
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