Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
T
Tor
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,067
    • Issues 1,067
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 20
    • Merge Requests 20
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • The Tor Project
  • Core
  • Tor
  • Issues
  • #1294

Closed
Open
Opened 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
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/core/tor#1294