Hello there,
...
Here are some issues that make this proposal not an obvious pick:
1) Security issues
...
- It was also pointed out that the HSDir algorithm does not take into
account the bandwidth of the nodes, making it easier to launch Sybil
attacks. However, the rest of the the mailing list thread suggests
various ways to do bandwidth weighted hash ring selections [4], so this
might not be an important factor.
As far as I recall, there was no guarantee that a large hidden service would
not pick 6 low-bandwidth HSDirs/IPs for a day, with serious impact on the
reachability of that hidden service for that period.
3) Load balancing issue
...
- Another concern here is that hidden services would not be able to change
the number of their introduction points. This is not a big problem
currently, but it could become in the future if the network gets more
overloaded. As a partial solution to this, #17690 suggests making the
number of HSDirs a network-wide consensus parameter that could also be
used by proposal 246.
It could also become a big problem for large hidden services which benefit from
10 (or more) introduction points.
2) Reachability issue
A final issue here is that if the relay churn of the network increases, the
introduction point hash ring might be changing rapidly and clients might get
pointed to the wrong introduction points.
However, this does not seem like a greater problem than what hidden services
are facing with HSDir reachability currently. Is this right, or does prop246
makes it worse?
Proposal 246 makes it worse, because now both HSDirs and introductions depend
on a potentially churning hash ring. If churn makes an introduction point
unreachable, this increases the load on the other introduction points.
Clients also cache descriptors from HSDirs, but they need an introduction point
to be up whenever they contact the hidden service.