teor <teor2345@xxxxxxxxx> wrote: > >> On 13 Jul 2015, at 07:48 , John Brooks <john.brooks@xxxxxxxxxxxxxxxx> >> wrote: > >> 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. Interesting approach. This value would be difficult to change on an existing service, because it would have to hand out a new subtly-different URL to all clients. We had also briefly discussed using the extra 4 bits as a checksum on the address. > 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. I _think_ that 6 introduction points can handle a lot of traffic, and I think itâs mostly sufficient for reliability and abuse-resistance. Personally, Iâd like to see statistics showing that introduction points are a bottleneck before we design systems to increase the number of them. I suspect that guards fall down long before introduction points do. There are tradeoffs to using more, both in terms of network load and privacy (e.g. exposing popularity to relays). > 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. The introduction point count should be a consensus parameter; 224 was going to do this for HSDirs already. > > Tim > > Tim Wilson-Brown (teor) - John
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