amichrisde, thanks for your note! [I, Zooko, wrote the lines prepended with "> > ".] [amichrisde wrote the lines prepended with "> ".]
> Think of the freenet as a graph and you're doing a > depth first traversal with HTL number of nodes being > accessed. In short it sends the message to its next > best choice. Suppose node A sends a query to node B, and node B sends it to node C, and node C writes back "DNF", and then when node A gets the DNF then it sends the query to node D. Okay now my question is, how do you prevent node D from sending the query back to node C, thus wasting everyone's bandwidth and not getting any closer to the data, which is actually on node F? > > assumption that true DNFs -- queries for data that is absent from > > Freenet -- is evenly spread throughout the keyspace. I can imagine cases > > where that assumption becomes untrue, even for extended periods of time or > > for significant fractions of the keyspace. > Yes, I can think of two. > 1) Your specialized in a very small part of the > keyspace and key that has been lost, suddenly becomes > popular again and therfore is requested repeatly just > inside your area. > 2) Some aversary wants to damage some keyspace so he > sends bogus requests for data there. This could > discredit servers in that specialization. Yes, these are the kind of distortions that I was thinking of. Another might be if an attacker is attacking a specific area of the keyspace, for example DoS'ing nodes which specialize in that area. If the attacker kept it up, it might result in a consistent distortion of the frequency of DNFs in different parts of the keyspace. As with many things, the non-malicious scenario of very popular but lost data seems more likely than the malicious scenario of keyspace-specific attack. > DHT eh... I've sometimes wondered if we chould just > fix the routing using one of the more rigorous > algorithims like CAN, Chord, or DHT. The reason we > don't is to try to build security into the routing. > I'm not sure the current design really does this > anyway though. Indeed -- this is the kind of thing I am thinking of for Mnet's next- generation routing (which is named "ent"). Hopefully Mnet's and Freenet's solutions will end up being significantly different so that we can explore different areas of the design space. ;-) > I'm almost wondering if one can prove that single > completely untrusted nodes can't build such a network. There is a very good paper which argues exactly this kind of negative result: The Sybil Attack (2002), by John Douceur http://citeseer.nj.nec.com/douceur02sybil.html There are two flaws in the premises of this paper, and its conclusions do not directly apply to networks like Mnet and Freenet, but it is a paper that you ought to read if you are thinking about these issues! (Hint: IMHO one of the two flawed premises is that the network is composed of completely untrusted nodes...) > I thought this too at first glance but no. What will > happen is the first two points will come in toward the > middle of the hump. Once they get into the .004 of > the keyspace, queries just outside those two points > will yank the others in one by one. I don't think this will ever happen -- it takes infinite time for the other points to move inside. Oh wait -- do the points move a fraction of the remaining distance each time? (Zeno's Paradox) Or do they move a fixed distance? > Only problem and this counts for all of these learning > sytems: the uncertainty priciple. When we measure how > well another node is in a certain keyspace, by giving > it queries, we affect what we're messuring. Heh -- good point! I hadn't thought of that. Doesn't seem like a real problem in practice though, does it? Regards, Zooko http://zooko.com/ _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
