Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #24378
Closed (moved) (moved)
Open
Issue created Nov 21, 2017 by teor@teor

Prune the list of supported consensus methods

We currently have 13 supported consensus methods.

In 0.3.3, it is likely that prop282 will add 1 more, and prop283 will add 2 more.

Maybe we should prune this list eventually, because it will let us simplify our code, and make votes smaller, less expensive to calculate, and reduce authority RAM requirements (due to fewer microdescs).

It has almost no impact on consensus size.

Here's how we could work out what to prune:

By mandatory feature:

We are currently locked into using consensus method 16 or later in the public network, because 0.2.9 and later require ntor keys, and 0.2.9 clients use microdescriptors by default.

We may add more mandatory features in 0.3.3 and 0.3.4.

By supported tor version:

On May 1, 2018, we will stop supporting 0.2.5, and only support 0.2.9 and later. This means that all supported non-alpha versions will support consensus methods 25 and later. (Or, if we count 0.2.9 alpha versions, it's 22 and later.)

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking