[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #2286 [Tor Directory Authority]: We still use self-published relay bandwidth sometimes
#2286: We still use self-published relay bandwidth sometimes
-------------------------------------+--------------------------------------
Reporter: arma | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: Tor: 0.2.3.x-final
Component: Tor Directory Authority | Version:
Keywords: arma-cares | Parent:
Points: | Actualpoints:
-------------------------------------+--------------------------------------
Comment(by nickm):
Replying to [comment:31 arma]:
> Replying to [comment:29 nickm]:
> > Roger, I don't get at this point why you prefer your alternative
approach (vote differently) vs the one I started to implement (consense
differently). I kind of prefer the latter, since it doesn't change the
meaning of any vote, and it looks like we'll probably need a new consensus
method anyway.
>
> I'm open to either approach. We'll want to make sure we don't cap all
nodes to 50 in the case where there aren't enough bwauths putting in
Measured votes.
>
> We may also find that we want to only cap weights when a certain
threshold of the relays have a Measured vote. I'm not sure if we'll want
to do that threshold, or what we'll want it to be, so I had figured
leaving the flexibility to each authority might make it easier. For
example, I worry about a case where all the bwauths restart afresh and
have just a few votes each -- currently it makes sense for them to include
the votes, but now they'd better think about not putting in any votes
until they have quite a few.
I think that approach (Don't say "measured" until you have measured a
bunch of routers) is smarter and way easier to implement than the approach
where we don't cap until a threshold of routers has measured values.
To avoid the first problem you talk about, I'd suggest a simple rule of
"implement the cap approach when at least 3 authorities are publishing
measurements." It's not perfect, and has corner cases, but it should be
basically ok.
> That said, we also want to avoid an attack where the adversary floods
the network with new nodes, and suddenly the bwauths take away their caps
because they haven't covered the required threshold of the nodes yet.
>
> *That* said, now that it looks like we're going to be making a new
consensus method anyway, there's not as much reason left to avoid doing it
in the consensus.
I've updated the branches "bug2286_part_a" in my public tor repo and in my
public torspec repo to try to implement the behavior we've been
discussing. Sensible now? Correctly implemented?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2286#comment:32>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs