Commit fa215a8f authored by Roger Dingledine's avatar Roger Dingledine
Browse files

decide that messing with fallback-concensus for 0.2.0.10-alpha

isn't worth it. also mention bug 546 again.


svn:r12432
parent 1d61b542
......@@ -15,6 +15,7 @@ J - Jeff claims
X Abandoned
Items blocking 0.2.0.10-alpha:
- Some resolution for (the reopened) bug 546.
- We should back out the MBTF->WFU Guard factors, since they open us
up to new attacks, and don't this "median" notion doesn't necessarily
help us distinguish between "was good enough to be a guard when
......@@ -31,20 +32,14 @@ Here's a go:
median WFU of the set. In addition, anybody born more than a month ago
who has >=50% WFU is always a winner.
- Should we ship with a fallback-consensus? Where in the tarball does
it go? What's the process for choosing it?
- We can, but we don't have to now. Stick it in place of the
empty fallback-consensus file in src/config if you like. -NM
- To choose, just grab the most recent consensus you have. -NM
- If 1.5*MaxCircuitDirtiness is more than KeepAlive, do we then send
a KeepAlive and reset our timeout, thus never reaching 1.5*MCD?
- Aw, crud. We could keep track of how long it's been since
we last did anything _other_ than a keepalive, I guess. -NM
o "When reporting clock skew, and we only have a lower bound on
the amount of skew, amount anyway, marked as a lower bound.
[XXX Nick: what does this mean??]"
For Tor 0.2.0.11-alpha:
- Put a consensus in place of the empty fallback-consensus file in
src/config and see what breaks.
Things we'd like to do in 0.2.0.x:
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment