On 28/05/15 11:28, Jeff Burdges wrote:
One small problem with this suggestion (hopefully fixable) is that there's no single "current consensus" that the client and IP are guaranteed to share:
https://lists.torproject.org/pipermail/tor-dev/2014-September/007571.html
If I understand, you’re saying the set of candidate RPs is larger than the set of candidate IPs which is larger than the set of candidate HSDirs, so disagreements about the consensus matter progressively more. Alright, fair enough.
I wasn't thinking about the sizes of the sets so much as the probability of overlap. If the client picks n HSDirs or IPs from the 1:00 consensus and the service picks n HSDirs or IPs from the 2:00 consensus, and the set of candidates is fairly stable between consensuses, and the ordering is consistent, we can adjust n to get an acceptable probability of overlap. But if the client and service (or client and IP) are picking a single RP, there's no slack - they have to pick exactly the same one.
An IP is quite long lived already, yes? There is no route for the HS to tell the client its consensus time, but the client could share its consensus time, assuming that information is not sensitive elsewhere, so the HS could exclude nodes not considered by the client. It's quite complicated though, so maybe not the best approach.
Even if the service knows what consensus the client is using, the service may not have a copy of that consensus (and may not ever have had one).
Cheers, Michael