commit 42d0a841acbd2d8f5a7e83a3b8e9425676eb0370 Author: Nick Mathewson <nickm@torproject.org> Date: Fri Sep 18 10:18:06 2020 -0400 Better description for when a consensus must is "too early" Since the authorities can produce a signed consensus as soon as `ValidAfter` minus `DistSeconds`, and since they serve a signed consensus as soon as it has enough signatures, it's possible that a client or relay that's starting late in the hour can get an "early" consensus. Back in tor#25756, we fixed this issue in Tor, but we didn't document the behavior in the spec. --- dir-spec.txt | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 7ae5acd..27d380f 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -341,7 +341,8 @@ change does remove one common cause of consensus splits. VA-DistSeconds: The authorities calculate the consensus and exchange - signatures. + signatures. (This is the earliest point at which anybody can + possibly get a given consensus if they ask for it.) VA-DistSeconds/2: The authorities try to download any signatures they don't have. @@ -1752,7 +1753,14 @@ [Exactly once.] The start of the Interval for this vote. Before this time, the - consensus document produced from this vote should not be used. + consensus document produced from this vote is not officially in + use. + + (Note that because of propagation delays, clients and relays + may see consensus documents that are up to `DistSeconds` + earlier than this this time, and should not warn about + them.) + See section 1.4 for voting timeline information. "fresh-until" SP YYYY-MM-DD SP HH:MM:SS NL