Hi,
George Kadianakis:
Here are some resources
Awesome; thanks!
read the code to learn :)
Will do.
Wordlife,
Spencer
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Spencer writes:
> Hi,
>
>>
>> George Kadianakis:
>> Indeed. [The randomly selected guards] > are saved in the state file. Check:
>> https://lists.torproject.org/pipermail/tor-dev/2016-February/010355.html
>> also see here for another explanation of
>> how parts of it work:
>> https://lists.torp
Ola Bini writes:
> Hi,
>
> Sorry for the string of emails!
>
> Hopefully a simple question:
> The current proposal contains logic for keeping track of network
> up/down and setting timeouts for exponential backoff to test the
> network again. But if I understand correctly, this proposal is
> basi
Hi,
>
> George Kadianakis:
> Indeed. [The randomly selected guards] > are saved in the state file. Check:
> https://lists.torproject.org/pipermail/tor-dev/2016-February/010355.html
> also see here for another explanation of
> how parts of it work:
> https://lists.torproject.org/pipermail/tor-dev
Ola Bini writes:
> Hi,
>
>> I think it's fine to use randomness to generate it for now; that's what tor
>> also currently does [0].
> Cool - we have a local clone of the specs and updating it with this
> understanding.
>
Great!
For better or worse I think making design decisions (or at least s
Ola Bini writes:
> Hi,
>
> Thanks for the confirmation of our understanding! Very helpful.
>
> If I understand things correctly, we are supposed to take
> GUARDLIST_FAILOVER_THRESHOLD guards from the list of all guards and
> generate the GUARDLIST from that. Is that process supposed to be
> deter
Ola Bini writes:
> Hi,
>
> Sorry for this - had some questions about the hashring component of
> #259 that I haven't been able to figure out myself. I'm sure it's just
> me being unused to the Tor code base and how you write your proposals,
> but it would be super helpful if I can get a quick ans
