[tor-bugs] #16255 [Tor]: Guardfraction on dirauths screws up bandwidth weights

[Tor Bug Tracker & Wiki]

#16255: Guardfraction on dirauths screws up bandwidth weights
-------------------------+-------------------------------------------------
     Reporter:  asn      |      Owner:
         Type:  defect   |     Status:  needs_review
     Priority:  normal   |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  tor-dirauth tor-guard,
Actual Points:           |  TorCoreTeam201508
       Points:           |  Parent ID:
-------------------------+-------------------------------------------------

Comment (by nickm):

 Replying to [comment:12 asn]:
 > Replying to [comment:11 nickm]:
 > > I truly do think there should be a new consensus-method here.
 > >
 > > After all, the entire point of having consensus-method support in Tor
 is so that we should never have to tell all the authorities "Okay, now
 everybody turn on the feature!"  Using a consensus-method means that the
 feature turns itself on once everybody has it, and not before.
 >
 > OK that makes sense then.
 >
 > So, should I bump `MIN_METHOD_FOR_GUARDFRACTION` to `22`?

 This is a little tricky.  Yes, but you'll need to add a 22 for 0.2.6, and
 a 23 for 0.2.7.  And the code in 0.2.7 that checks for
 MIN_METHOD_FOR_ED25519_ID_* needs to make sure that it isn't including 22.

 > And also, should I change the `GuardFraction=` encoding format to
 something else, so that unpatched authorities don't use it? To what? Do
 you prefer `GuardFractionPercentage=` or `Guardfraction=` or
 `GuardFractionVal=` or what?

 Whatever you like. "GuardPct" would be one option.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16255#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online