[tor-commits] [torspec/master] Add prop290: Continuously update consensus methods

[nickm@xxxxxxxxxxxxxx]

commit c45e0778adf392733b75508642e8807786a38490
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
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.
+

_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits