Nicholas Hopper hopper@cs.umn.edu writes:
On Tue, Apr 15, 2014 at 6:35 AM, George Kadianakis desnacked@riseup.net wrote:
A patch for the proposal would be useful. If you don't have time to do it, just tell me and I will do it myself.
Here's a patch: https://www-users.cs.umn.edu/~hopper/single-guard-node.patch
Just a note on updating the bandwidth-weights based on guardiness information. Proposal 236 states:
Similarly, when calculating the bandwidth-weights line as in section 3.8.3 of dir-spec.txt, directory authorities should treat N as if fraction F of its bandwidth has the guard flag and (1-F) does not. So when computing the totals G,M,E,D, each relay N with guard visibility fraction F and bandwidth B should be added as follows:
G' = G + F*B, if N does not have the exit flag M' = M + (1-F)*B, if N does not have the exit flag D' = D + F*B, if N has the exit flag E' = E + (1-F)*B, if N has the exit flag
I'd just like to mention that updating the global bandwidth-weights based on relay guardiness seems to assume that all clients will upgrade and start understanding guardiness instantly.
Since upgrade is probably going to be gradual, it probably means that more weight will be given to middle/exit position (M'/E') than it should.
Maybe the correct way to deploy this is to first merge the client-side to little-t-tor, then wait till the feature appear in TBB, and then upgrade the authorities to report guardiness information. But maybe this is too slow deployment... Not sure.