Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 328
    • Issues 328
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 31
    • Merge requests 31
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #1294
Closed
Open
Issue created Mar 08, 2010 by Mike Perry@mikeperryDeveloper

Bandwidth weights absent when D=0

When the directory authorites vote that there are insufficient Exit nodes for them to be labled as both Exit and Guard, the authorities fail to add a bandwidth-weights line in consensus method 9. This has two problems:

  1. We could actually create weights in may cases when this does happen.

  2. This decision is made on the individual consensus votes, not the final consensus. There have been several situations so far when the authorites voted not to have Guard+Exit even though there was sufficient exit bandwidth in the consensus, and vice-versa.

The problem is that this check probably is a good idea to perform, because of the large numbers of existing clients that we want to avoid using Exits-as-Guards with until they update to the new weighting system.

The correct solution should be to tweak the Guard flag such that it produces a fixed amount of Guard-flagged nodes in the actual consensus. We should allow the weights themselves to handle what to do with Guard+Exit nodes.

However, because this is a mostly harmless result that just causes clients to revert to the old weights when it happens, and because a bit of work and thought is needed to decide how to properly allocate the Guard flag, we're not going to just do a quick fix and allow weights for the D=0 situation. We should fix this issue once we feel that enough clients have upgraded to 0.2.2.x for it to make sense to fix it properly.

[Automatically added by flyspray2trac: Operating System: All]

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