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
Attachment:
0x9FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev