[tor-dev] Proposal 290: Continuously update consensus methods

[Nick Mathewson <nickm@xxxxxxxxxxxxxx>]

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-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev