commit 42d0a841acbd2d8f5a7e83a3b8e9425676eb0370
Author: Nick Mathewson <ni...@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
_______________________________________________
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits
