Agreed, that's really interesting. How does Gnutella choose supernodes, and would it be reasonable to somehow use a similar approach with the DHT where not everyone is eligible to manage buckets, but only those who have built up a reputation for reliability as measured over many transfers with many users?
The key to the Pirate Pay attack is that you can selectively target buckets by injecting new nodes into the DHT at will. If we slow down the rate at which new nodes are added to the DHT, ideally identifying nodes with something like a public key (to avoid impersonation and ensure uniformly distributed random identifiers) and then having the *whole* network gather reliability/trust data (as opposed to just the participants of a single torrent) then this might provide a more stable core. -david On Wed, May 16, 2012 at 9:36 AM, Tony Arcieri <tony.arci...@gmail.com> wrote: > Oof, I hadn't really thought about that until now but you're totally right. > I've been a big fan of using collaborative filtering algorithms (e.g. slope > one, SVD) along with a system that actively accumulates a lot of metadata > about its own operation to filter out malicious sybils as noise because > their behavior patterns aren't similar to yours (this assumes you're a > "normal" node) > > I now see this same kind of collaborative filtering would need to apply to > how the DHT operates as well (and of course there's the problem of malicious > sybils abusing your graces as a metadata host to store their junk) > > > On Wed, May 16, 2012 at 2:26 AM, Michael Rogers <mich...@briarproject.org> > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Tony, >> >> On 16/05/12 03:04, Tony Arcieri wrote: >> > I think tying them to public keys provides the properties you want >> > from a "proof of work" system while still making the keys >> > (particularly if they're ECDSA keys) easy to generate. >> >> I wasn't suggesting proof-of-work, I was arguing that it wouldn't >> work. (I thought Russ Weeks was proposing it, but maybe not. Sorry >> Russ if I misunderstood you.) >> >> But I don't think easily generated key pairs would solve the problem >> either. The attacker doesn't need to get a specific node ID - she only >> needs to get a set of IDs that are closer to the target than any >> innocent nodes' IDs. If key pairs are cheap to generate then she can >> simply generate key pairs until she finds a set of suitable IDs. If >> key pairs (or node IDs in general) are expensive to generate then she >> can do the same, using resources that are only a fraction of the >> innocent nodes' resources, because she spends all her CPU time on the >> problem and they don't. (I think this argument against proof-of-work >> was first made by Richard Clayton.) >> >> Raphael has pointed to a better answer, though, which is to detect the >> anomalous clump of node IDs around the target. >> >> Cheers, >> Michael >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (GNU/Linux) >> >> iQEcBAEBAgAGBQJPs3K/AAoJEBEET9GfxSfMXc8H/1shNiRTZzHpY9b5ND/4jGPY >> 0/X29s+C28BVsP+FqHWDU52OKf4fIJSK1WZuKcv17HvRDQkr2/PoRRltP3Qp+Agp >> wOcQDxKqH+Ysxx2SvG75ix+vLRT/sJ5/Mue2OqsQmuIXdRfpVYRpjwlp668MGhwC >> dLJavEQw3Gf1mUmO8rbc2h2mBNoFYxapkyAHnIic0GMCkAtyucAI9yhcSDRV7piH >> SmWwHO7FuXPZMaGUk7S0mT09Y1J571jE016V15fFcSeIBF5FCA1Cjw3kOhVVI8Ev >> 50x1bRq0myrkNO4fPeyo1N5C0QVW6RX8XOpjOh89iB1C6I4Dfj21963Gowqv0QA= >> =+UNx >> -----END PGP SIGNATURE----- > > > > > -- > Tony Arcieri > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers > _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
