Improve the quality of connections via a more complete distance metric #252

Currently, connections are made to nodes which don't share the first two octets of the IP address, which raises the bar for attackers who are trying to prevent knowledge of blocks or transactions from spreading through the network. But adopting a more complete metric for distance could further minimize the chance of being fenced in due to only connecting to untrustworthy nodes.

The Kademlia protocol uses the XOR metric to determine the distance between two IP addresses. Applied to Bitcoin, a variant of the XOR metric might be to attempt to connect to the farthest node from the joining address in each k-bucket: aka, one node that has a particular bit of its IP address set, for a total of 32 buckets (or 128 for IPv6).

Here is an example of the XOR metric used to bin IP addresses by distance (using IPs from #bitcoin IRC): code: https://gist.github.com/988452 output: https://gist.github.com/988443

My hypothesis is that bucketing connections like this would lead to lower overall latencies by dropping the average distance a transaction has to travel to span the entire network. Bit hand-wavey at the moment, but I'll see if I can come up with some numbers to back up the idea.

Chosing which nodes to make outgoing connections too could use an upgrade like this, as could general connection tactics (being more aggressive couldn't hurt this insane times for bootstrapping that have been seen recently). @stuhood might you consider writing that into the Bitcoin client for us? Everything should be in sr/net.cpp

Yes: I'd be happy to implement this in the next few weeks.

@stuhood how is the implementation coming along? :)

@laanwj It's not... sorry! Got caught up in other obligations.

Closing this; sipa's CAddrMan has a well-thought-out policy for which potential peers to connect with.