[tor-dev] [RFC] Proposal draft: The move to a single guard node

[George Kadianakis]

Nicholas Hopper <hopper at cs.umn.edu> writes:

> On Tue, Apr 15, 2014 at 6:35 AM, George Kadianakis <desnacked at 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.