commit c45e0778adf392733b75508642e8807786a38490
Author: Nick Mathewson <nickm(a)torproject.org>
Date: Wed Feb 21 12:02:04 2018 -0500
Add prop290: Continuously update consensus methods
---
proposals/000-index.txt | 2 +
proposals/290-deprecate-consensus-methods.txt | 77 +++++++++++++++++++++++++++
2 files changed, 79 insertions(+)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 503d752..e4eebf3 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -210,6 +210,7 @@ Proposals by number:
287 Reduce circuit lifetime without overloading the network [OPEN]
288 Privacy-Preserving Statistics with Privcount in Tor (Shamir version) [DRAFT]
289 Authenticating sendme cells to mitigate bandwidth attacks [OPEN]
+290 Continuously update consensus methods [OPEN]
Proposals by status:
@@ -269,6 +270,7 @@ Proposals by status:
286 Controller APIs for hibernation access on mobile
287 Reduce circuit lifetime without overloading the network
289 Authenticating sendme cells to mitigate bandwidth attacks
+ 290 Continuously update consensus methods
ACCEPTED:
172 GETINFO controller option for circuit information
173 GETINFO Option Expansion
diff --git a/proposals/290-deprecate-consensus-methods.txt b/proposals/290-deprecate-consensus-methods.txt
new file mode 100644
index 0000000..db047c8
--- /dev/null
+++ b/proposals/290-deprecate-consensus-methods.txt
@@ -0,0 +1,77 @@
+Filename: 290-deprecate-consensus-methods.txt
+Title: Continuously update consensus methods
+Author: Nick Mathewson
+Created: 2018-02-21
+Status: Open
+
+1. Background
+
+ Directory authorities use the "consensus method" mechanism to achieve
+ forward compatibility during voting. When each authority publishes
+ its vote, it includes a list of numbered consensus methods that it
+ supports. Each authority chooses to calculate the consensus
+ according to the highest consensus method it knows supported by more
+ than 2/3 of the voting authorities. So long as all the authorities
+ have a method in common, they will all reach the same consensus.
+
+ Consensus method 1 was first introduced in the Tor 0.2.0 series
+ around 2008. But by 2012, we realized that we had a problem: we were
+ stuck documenting and supporting old consensus methods indefinitely.
+
+ With proposal 215, we deprecated and removed support for all
+ consensus methods before method 13. That was good as far as it went,
+ but it didn't solve the problem going forward: the latest consensus
+ methods is now 28.
+
+ This proposal describes a policy for removing older consensus methods
+ going forward, so we won't have to keep supporting them forever.
+
+2. Proposal
+
+ I propose that from time to time, old consensus methods should be
+ deprecated.
+
+ Specifically, I propose that we deprecate all methods older than the
+ highest method supported in first stable release of the oldest LTS
+ (long-term support) release series.
+
+ For example, the current oldest LTS series is 0.2.5.x. The first
+ stable release in that series was 0.2.5.10. The highest consensus
+ method listed by 0.2.5.10 is 18. Therefore, we should currently
+ consider ourselves free to deprecate all methods before 18.
+
+ Once 0.2.5.x is deprecated, 0.2.9.x will become the oldest LTS
+ series. The first stable release in that series was 0.2.9.8. The
+ highest consensus method listed by 0.2.9.8 is 25. Therefore, once
+ 0.2.5.x is deprecated (in May 2018), we may deprecate all methods
+ before 25.
+
+ When a consensus method is deprecated, it should no longer be listed
+ or implemented by the latest Tor releases. (It's okay for older
+ authorities to keep advertising it.)
+
+ Most consensus methods add a feature that is used in "method M or
+ later". Deprecating method M-1 means that the feature is used in all
+ supported consensus methods. Therefore, we can remove any code that
+ makes the feature conditional on a consensus method, and any code for
+ previous implementations of the feature.
+
+ Some consensus methods remove a feature that was used up to method
+ N. Deprecating method M means that the feature is no longer used by
+ any supported consensus methods. Therefore, we can remove any code
+ that implements the feature.
+
+A. Acknowledgments
+
+ Thanks to isis and teor for the discussion that led to this proposal.
+ I believe that teor first suggested the policy described in section 2
+ above.
+
+B. Client and relay compatibility notes
+
+ Dear reader: you may be worrying that this proposal will cause old
+ clients or relays to stop working prematurely. That is not the case.
+ Consensus methods determine how the authorities behave, but they do
+ not represent backward-incompatible changes in how they generate
+ their consensuses.
+