[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #16255 [Tor]: Guardfraction on dirauths screws up bandwidth weights
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs