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