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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 asn):

 Replying to [comment:9 nickm]:
 > Taking a quick note, I need to double-check this, but:
 >
 > Does this patch change how the input votes affect the output consensus?
 If so, it must use a new consensus-method.

 This fix indeed changes how the input votes affect the output consensus.
 That's because authorities with this patch will calculate different total
 bandwidth weights and Wgg/Wgd/Wmg/etc. values than unpatched authorities.

 Still, I decided to not add a new consensus method for the following
 reasons:

 - We already have a consensus method for guardfraction (20). I would have
 to add a second stronger one just for this fix which seemed ugly (but this
 should not stop us if it's the right thing to do).

 - If I added a new consensus method, I would also have to change the
 encoding format on the votes (`GuardFraction=50`, etc). Otherwise,
 unpatched authorities that support the old consensus method (20) would
 still parse the GuardFraction values of the patched authorities thinking
 that they understand them. That would be a mistake since at that point
 unpatched authorities and patched authorities would generate different
 consensuses. So if we add a new consensus method we should probably also
 change the encoding format to something like: `GuardFractionVal=50` or
 `Guardfraction=50` or something, so that unpatched authorities do not
 understand it.

 For the two reasons above, I decided (perhaps wrongly) to not add a new
 consensus method. Instead I provided both 026 and 027 patches and my plan
 was to ask the authorities to turn on the feature again only after a
 majority of the authorities have patched themselves.

 Do you think that's a dangerous plan, and instead I should just make a new
 consensus method?

 Thanks!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16255#comment:10>
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