> On 13 Jul 2015, at 07:48 , John Brooks <john.brooks@xxxxxxxxxxxxxxxx> wrote: > > Hello! > > George and I, along with the other participants of this hidden services > meeting, have written a proposal for the idea to merge hidden service > directories and introduction points into the same entity along with proposal > 224. > > Comments are encouraged, especially if there are downsides or side effects > that we havenât written about yet, or that you have a different opinion on. > The intent is that we can decide to do this before implementing proposal > 224, so they can be implemented together. > 4.2. Restriction on the number of intro points and impact on load balancing > > One drawback of this proposal is that the number of introduction points of a > hidden service is now a constant global parameter. Hence, a hidden service > can no longer adjust how many introduction points it uses, or select the > nodes that will serve as its introduction points. If we decide we want to allow popular hidden services to have more than 6 introduction points, we could use some of the 4 extra bits in the address to encode an introduction point count multiplier. For example, if we used 2 bits: 00 - 6 introduction points (the default) 01 - 12 introduction points 10 - 18 introduction points (or 24 if we use a geometric progression) 11 - 24 introduction points (or 48 if we use a geometric progression) There is a tradeoff in choosing the number of bits: The fewer alternatives we provide, the larger each anonymity class, and the harder it is to identify hidden services simply by counting their IPs. But having only a few alternatives also reduces HS flexibility in response to load. I can see advantages in popular, high-availability, or politically unpopular hidden services having more introduction points. It would make it harder to overload all the introduction points, particularly once the server can't change introduction points when they go down. Perhaps we only need two introduction point counts: 6 and 6n, where n is initially chosen based on the most popular hidden services, and is a consensus parameter, so can be updated if needed. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev