On 2012-05-17 3:32 AM, David Barrett wrote:
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.
Rather than slowing down nodes, which involves deliberately degrading
performance, we show preference to old nodes that we have successfully
interacted with before, or are commended by old nodes that we have
successfully interacted with before.
Each running instance of the peer has a rarely changed public key.
Over time, each running instance accumulates a hundred megabytes or so
of information about other instances, a few hundred thousand peers, with
preference for storing information about popular peers - peers that
engage in lots of interactions over a long time - we employ very large
but potentially out of date lists, rather than small but up to date
lists, and keep reputational data on the items in the list.
When a peer wants a node with a DHT distance close to some target hash,
it searches through its local list of known good nodes for a starting
point. It gets in contact with that node, which in turn searches
through its local list of known good nodes.
_______________________________________________
p2p-hackers mailing list
p2p-hackers@lists.zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers
