commit 4aff96041b25ae89acbaf2335743e3e0ffe52da9 Author: Nick Mathewson nickm@torproject.org Date: Tue Sep 6 14:41:06 2016 -0400
Consensus method 24: don't list invalid nodes.
Also, note that you can safely assume that methods before 13 will never happen.
Part of proposal 272. --- dir-spec.txt | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/dir-spec.txt b/dir-spec.txt index 6466d8a..db1378f 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2483,6 +2483,9 @@ * If consensus method 23 or later is used, authorities include shared randomness protocol data on their votes and consensus.
+ * If consensus-method 24 or later is in use, then routers that + do not have the Valid flag are not listed at all. + The signatures at the end of a consensus document are sorted in ascending order by identity digest.
@@ -2561,6 +2564,7 @@ "21" -- Adds Ed25519 keys to microdescriptors. "22" -- Instantiates Ed25519 voting algorithm correctly. "23" -- Adds shared randomness protocol data. + "24" -- No longer lists routers that are not Valid in the consensus.
Before generating a consensus, an authority must decide which consensus method to use. To do this, it looks for the highest version number @@ -2569,9 +2573,11 @@ method that it supports (which will probably not result in a sufficiently signed consensus).
- All authorities MUST support method 13; authorities SHOULD support more - recent methods as well. Authorities SHOULD NOT support or advertise - support for any method before 13. + All authorities MUST support method 13; authorities SHOULD support + more recent methods as well. Authorities SHOULD NOT support or + advertise support for any method before 13. Clients MAY assume that + they will never see a current valid signed consensus for any method + before method 13.
(The consensuses generated by new methods must be parsable by implementations that only understand the old methods, and must not cause