Thus spake Roger Dingledine (arma@xxxxxxx): > I've committed the proposed patch, with a few more comments and slightly > different numbers than originally proposed: > http://archives.seul.org/or/cvs/Jul-2007/msg00181.html > > On Fri, Jul 20, 2007 at 07:09:00PM -0700, Mike Perry wrote: > > If everyone were weighting guards by bandwidth, 300-400k would > > probably be a fine cutoff. But since we haven't yet decided to expire > > people's already uniformly chosen guards, the limit should probably be > > somewhere around 125k if you really don't want half of the existing > > tor users to continue to be vulnerable to this attack. > > Ok. The goal is to pick a number sufficiently high that we would consider > this node worthwhile as a guard even if one day we have a whole lot of > even faster nodes. I picked 250KB/s as a good guess for that. Isn't it the directory code that is making this decision though? That can be changed much faster than the clients. > > Alternatively, we could make 0.1.2.16/0.2.0.3 expire all guards for > > all versions prior, which would also help the network balancing. That > > would be nice. :) > > Right. We're not going to do that in the 0.2.0.3-alpha timeframe (which > I hope to put out in the next days), but it's still something to ponder. > As we wait, though, the problem goes away on its own -- now that 0.1.2.15 > is out and new users will be picking guards better. I have to admit that > I have no intuition about user turnover though, so no intuition about > how quickly it will correct itself. Yeah, new users are picking guards better, but all users who upgrade keep their state file unless we explicitly expire it in or_state_validate(). This is what I think we should do for 0.1.2.16, unless we anticipate other major guard-related changes. > > Since Fast nodes are chosen in proportion to bandwidth, this limit can > > probably safely be set much higher proporitionally. 100k looks like it > > may even work. > > I decided to stick with 100KB/s here. Sounds good. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgp4B2I41TQDD.pgp
Description: PGP signature