@cuaxolotl @mauve it's an incentives thing, no one has seriously attacked it. Kademlia mainline DHT as implemented doesn't have serious protection against spinning up invalid nodes and shitting up the address space. However, while you can do that trivially (the node IDs are literally just a random 160-bit integer) each node keeps multiple lists of other known nodes at exponentially further away from itself in the keyspace. It periodically polls these nodes for liveness and keeps track of and ranks them according to how long they've been up. So, if you need to find something and you have access to a nodeid/ip combination that you have some out of band means of knowing it's been around for while, you can query it and it will forward requests to its neighbor nodes preferring the longest-lived ones. Effectively this means that if I shit up the network with a million fake nodes tomorrow, but your bitorrent client cache still has nodes from yesterday, your searches will be alright. If you come onto the network for the first time tomorrow though, and you just have to pick a random node to start from, your odds are as bad as what percentage of the nodes on the network are now fake ones. additional problem: just because a node is long-lived doesn't mean it's good, nodes don't really know that except if they try the node's info and it's valid, your node keeps an internal reputation for those nodes but afaik all attempts to make this info shareable to other nodes don't work.

there are some extensions to kademlia that make the node id to be a cryptographic hash and make it dependent on the ip/port so you are extremely limited as an attacker in making plausible fake nodes but i don't know if anybody even uses that and in any case not enough to matter. also problem with that is if your node changes ip/port its reputation has to start over because it will need a new node id. but like i said nobody uses it, but it does demonstrate the difficulty in addressing the problem.