teor teor2345@gmail.com wrote:
On 13 Jul 2015, at 07:48 , John Brooks john.brooks@dereferenced.net 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