[freenet-dev] Alpha, Darknet routing, et al.

[Michael Rogers]

Robert Hailey wrote:
> Unless [in a later implementation] DNFs (maybe weighed against HTL) 
> become an indication of a separate network. Then it would do precisely that.

DNFs would detect a "black hole" attacker - what about an attacker who 
just wants to monitor a region of the key space or censor a few selected 
keys?

(Again, this criticism isn't specific to your proposal and I'm not 
saying your proposal creates this problem.)

>> what am I missing?
> 
> That following the algorithm will eventually color the entire 
> network/subnetwork/dungeon with the same network id, which is 
> presumed necessary for any sort of distant routing.

OK, I think I see what you mean now - the network IDs aren't just 
private labels used by each node to colour its private map of the 
network - they're used for routing, so there needs to be a rough 
consensus about which label applies to which area of the network.

I'm still not quite sure about how that consensus is reached. Agreeing 
on an ID for the local subnet doesn't seem to be a problem, but what 
happens if (for example) an attacker creates a subnet with the same ID 
as an existing subnet? Any searches that have visited the attacker's 
subnet and failed will be marked "don't look in subnet X" and therefore 
won't visit the 'real' subnet X, right?

And I guess the list of failed subnets can only be updated by the 
requester - otherwise an attacker could return a DNF saying "already 
tried subnets X, Y, Z"?

> So now we'll tell our peer's 
> that we can reach network 'w' (through this peer w/ that success). Even 
> if it is a Sybil-simulated subnetwork, routing to it (and perhaps wether 
> or not we advertise it to our peers) will probably end up being related 
> to success-probability; they could only become relied upon by providing 
> good data (not censoring), why not use the Sybil net for storage, then? 

This sounds promising. I'm not sure all attackers will be unreliable, 
though. An attacker might diligently store 99% of keys but censor the 
other 1% - but maybe FEC makes that a non-issue. Or the attacker might 
provide a fast, reliable storage service in order to monitor as much 
traffic as possible - but maybe that's unavoidable in opennet.

How do you measure success for inserts? Or maybe you can just measure 
success for requests and assume that inserts must be succeeding if 
requests are succeeding?

Cheeers,
Michael