Matthew Toseland wrote: > No, but it would make the request time variance much higher, especially for > inserts and unsuccessful requests (which can potentially visit the entire > network).
True, the variance would be higher. Visiting the entire network is a bit of an extreme example though - in theory it's also possible with the current hop counter, but it's not exactly likely. :-) > A lot more requests will naturally timeout than do now, and therefore a node > can silently drop a request without arousing much concern or suspicion. Per > node failure tables can't reroute that key until the timeout happens, and if > the timeout is larger than it is now, that takes longer. We're using a reliable transport between nodes, so the only things that should cause a timeout are overloaded, crashed or faulty nodes. If we can keep the ping time under control then we can detect crashed nodes quickly. So with proper load management we should be able to pretty much eliminate timeouts except in the case of faulty nodes, which can then be detected. >> I shouldn't have said we can't analyse it, but I wouldn't know where to >> start because so much depends on the topology. For example, the >> closest-location-so-far obviously leaks information, but how do we >> quantify it? > > Isn't it similar to the situation with keys? Sorry, I don't follow. The closest-location-so-far tells an attacker something about the path a request has followed - among other things, it allows the attacker to rule out certain nodes the request definitely hasn't passed through. But how would we quantify that in terms of the size of the initiator's anonymity set or the probability that a given node is the initiator, for example? Whereas with a weighted coin, if the probability that each node terminates the request is 1/n then there's a 1/n chance that the previous hop is the initiator. Cheers, Michael _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
