--- pineapple <[EMAIL PROTECTED]> wrote: > --- Nick Tarleton <[EMAIL PROTECTED]> wrote: > > > Maybe just XOR with a randomly chosen node-private > > value. But won't this fubar > > routing and specialization, if each node has a > > different ordering in its > > routing? Or do I misunderstand what is meant by > > "estimator keyspace"? > > -- > > Since the ordering of keys in the estimator keyspace > is completely arbitrary anyway the answer is no, but > with some caveats:
No, sorry pineapple this won't work. Freenet's old routing required a closer(a,b,c)->boolean, which has to be globaly defined. It can be defined serveral ways, you could break each key into two dimensions and take the "new york distance" or count the number of bits different. For NGR you have to keep it in one dimension. Reording the keyspace differently at every node would break the routing, since nobody could agree if a node is specailized in an area. That said a small cluster of nodes can agree to a secret reordering, which would mean an outside adversary wouldn't know: 1) where data got routed. 2) a DoS would spread evenly. 3) the cluster could find everything inside in one hop The problem is when such clusters get big, the chance they've been infiltrated grows. > 1) A current node's routing would be screwed up if > this was implemented all at once (this would probably > screw up the entire network if enough nodes did this > at the same time). An existing node would have to be > converted slowly. Not a problem with a new node (with > the exception of #2 below). > > 2) I believe NGR allows this information to be shared > with a new node to help them integrate into the > network. This would cause a problem because either > the estimators would be scrambled (and therefore > useless) or you would have to reveal the mapping > function (which a cancer node could use to DoS a key). > So each node would have to keep some unscrambled > references to pass on to other nodes. > > Actually, I withdraw my last proposal. I think this > one would work much better. So the two proposals for > thwarting Toad's key DoS scenario are: > > 1) Hash-cash - works by making requesters pay a price > for each request. Right, it solves the problems beautifully as long as the route is only a function of the hash-cash and things it was dependent on. In otherwords: "pay first then you get the routing key." The network will become increasingly resistant as it grows, because I have to do N hash-cash calculations to find something whose routing key goes to a target node. This is way way better than "pick the routing key and then pay." There targeting a single nodes worth of hashspace costs the same regardless of N. > 2) Estimator keyspace reordering - works by scattering > requests across the entire estimator keyspace. > > I think either solution would do the job. Any other suggestions? __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
