[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

Thanks for the patch! FWIW, the original proposal + your patch got
merged in torspec as proposal 236.

A nitpicking question:

>   A guard N that has been visible for V out of NNN*30*24 consensuses
>   has had the opportunity to be chosen as a guard by approximately
>   F = V/NNN*30*24 of the clients in the network, and the remaining
>   1-F fraction of the clients have not noticed this change.  So when
>   being chosen for middle or exit positions on a circuit, clients
>   should treat N as if F fraction of its bandwidth is a guard
>   (respectively, dual) node and (1-F) is a middle (resp, exit) node.
>   Let Wpf denote the weight from the 'bandwidth-weights' line a
>   client would apply to N for position p if it had the guard
>   flag, Wpn the weight if it did not have the guard flag, and B the
>   measured bandwidth of N in the consensus.  Then instead of choosing
>   N for position p proportionally to Wpf*B or Wpn*B, clients should

Why do you mention Wpn*B here? That is, in the sentence "Wpf*B or Wpn*B".

Since we are talking about picking a *guard* N for middle or exit
positions a client would normally only use Wpf*B, right? Or am I
confused?

>   choose N proportionally to F*Wpf*B + (1-F)*Wpn*B.