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
