On Mon, Jul 11, 2016 at 12:41 PM, isis agora lovecruft isis@torproject.org wrote:
Nick Mathewson transcribed 1.1K bytes:
Various questions and responses to the meeting logs [0]:
- I'm not sure I understand the difference between USABLE_FILTERED_GUARD and CONFIRMED_GUARDS.
USABLE_FILTERED_GUARDS is a subset of FILTERED_GUARDS where "is running" is "yes" or "maybe".
- It seems like USED_GUARDS and CONFIRMED_GUARDS are being used interchangeably. I realise that Nick at some point in IRC mentions the former was renamed to the latter, but it isn't consistent and with so many variables I'm finding myself a bit confused.
Right. CONFIRMED_GUARDS is the new name for USED_GUARDS. I should replace every instance of the old.
- From:
14:14:41 <nickm> (There is also a secret novelty in how it handles bridges and entrynodes)
I don't actually see EntryNodes mentioned in the proposal?
Appendix A.2 ?
- How were all the parameters in §A.1 [1] chosen? Did we simulate the algorithm yet and fuzz the parameters under different network conditions like we did before?
All were totally pulled out of thin air, or out of the previous iteration of the proposal.
- For
14:22:11 <nickm> #action try to think of ways that the "don't add to USED_GUARDS till we use it" rule can be manipulated by an attacker
I assume the function governing membership in the set of FILTERED_GUARDS pushes old/stale/less-usable/less-good guards out of the set when new ones are found? That is, the size of FILTERED_GUARDS can't just grow indefinitely, right?
FILTERED_GUARDS can only grow up to the size of SAMPLED_GUARDS; but the size of SAMPLED_GUARDS is limited by MAX_SAMPLE_THRESHOLD.
- For "treating primariness as a continuum", do you mean that we should assign some float values to a bunch of guards we're trying all in parallel, then pick the guard that succeeded that had the highest value? I worry a bit that this would complicate the code and potentially result in many attempted connected to substantially less-suitable nodes.
It would mean that instead of treating the first N_PRIMARY_GUARDS members of CONFIRMED_GUARDS as 100% primary, and the remaining members as 0% primary, we would somehow treat the i'th gmember of CONFIRMED_GUARDS as f(i)% primary for some f.
Right now "primariness" is used for several things: we'd need to look at which of these should look at a boolean, and which could instead look at a continuous variable. I do not yet know whether this is a good idea.
-- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt
cheers,