mirror of
https://github.com/torproject/torspec.git
synced 2024-12-12 04:35:37 +00:00
78 lines
3.3 KiB
Plaintext
78 lines
3.3 KiB
Plaintext
Filename: 290-deprecate-consensus-methods.txt
|
|
Title: Continuously update consensus methods
|
|
Author: Nick Mathewson
|
|
Created: 2018-02-21
|
|
Status: Meta
|
|
|
|
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
|
|
method 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 the 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
|
|
M. 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.
|
|
|