Add support for IP addresses to prevent Sybil attacks

[harnen]

In the current version of the protocol, we distinguish only Kademlia identities. There is no limit on the number of identities an attacker can create. Even with tickets and other Sybil prevention mechanisms, the attacker has a chance to overload the network.

The high level idea is to add IP addresses to the current implementation and given an attacker a limited poll of addresses to use (and unlimited number of identities).

We were thinking to take into account the IP of the registrant and assign a modifier to the accumulated ticket time based on that. The main idea is, if there are a lot of similar IPs (say /24) already in your topic table, you assign a negative modifier to the registrant accumulated waiting time (e.g., x0.5). The more similar addresses the stronger the modifier.

This should make it impossible for an attacker to overflow a single node (unless it has thousands of IPs to use). Furthermore, it actually promotes diversity in topic tables. You probably don't want to have your topic table filled with similar IPs even without an attack. If their ISP is down, your whole topic table becomes useless.

[harnen]

We've added support from reading IP addresses from traces gathered by Ethereum. I.e., our simulated nodes have the same IPs and IDs as real members of Ethereum DHT. However, there are still several issues to be solved:

1. We need to find a similarity metric between 2 IP addresses. We can either use a longest common prefix length (similar to what we do with IDs) or weighted Humming distance.
2. We need to find a way to calculate a similarity metric for a set (not just a pair) of IP addresses. This is not trivial, as it should be efficient. We could get all the pairs from the set, calculate the distances and then take an average, but this is extremely inefficient. I've found zeta diversity metric which might be a solution, but need to double-check that.
3. Finally, we need to determine how to handle an incoming IP address. We can calculate a similarity metric for the set with and without the new IP address.If the similarity increases, then we put a penalty on the waiting time. We should probably also normalize the result to determine the size of the penalty and make sure it works the same for cases where we have 1, 10, 1000 IPs in the topic table.

[harnen]

One solution suggested by Sergi to solve 2. was to use entropy. That could work if we use /24 or /16 prefix, will fail to capture more subtle relations between addresses (not sure if that's relevant here).

[harnen]

Ethereum nodes IPs distribution from github