I've brought some crazy ideas about DHT tab.

First, it would be great to copy selected identifiers and addresses to the clipboard. You can use OCR tools like Capture2Text right now, but it's a bit inconvenient.

Second, a rough estimate of DHT size would be nice. It is quite easy to do — just multiply the number of nodes in the bucket to the power of two corresponding to the bucket width. For example, I see 3 nodes in /21, and guess that 3×2²¹, or about 6 million nodes are there. I2P table has 5 nodes in /11, so there are around 10 thousand peers. Additional column, something like “Reachable nodes estimate”, can show that.

It is understood that only lowest 3-5 buckets can show relevant numbers this way, others simply can't naturally collect all the nodes in their range during regular DHT operation, so there is no point to show the numbers for all but the smallest ones. Sometimes the number from the bucket before last one is bigger and more correct.

It is understood that this method usually underestimates (and sometimes overestimates) the total amount of nodes because not all closest nodes get found naturally. It's fine, we only need some rough number.

It is understood that clients behind NAT will get lower number, hence the word “reachable”. Let the user extend the estimation process by multiplying to some coefficient they like. 2× is just as good as any.

Third, if you look at IPv4 table, you might notice a peculiarity: a lot of empty buckets under that /21, and then some nodes with identifiers almost completely matching your own. Most of them also use “officially designated” port 6881, which no sane person would do. Those are obvious Sybil nodes that pretend to be everyone at once, and insert themselves as your closest buddies to collect as many torrent announces as possible. Using those buckets for size estimate would obviously be wrong.

So there's a need to block nodes that are “too close”, “closer than average”. But to know the average “normal” amount of buckets, we need to know the average network size, a chicken-and-egg problem. Well, an additional context menu item to block them manually would not hurt.

Scientific literature says that Bittorrent DHT (Mainline) is fundamentally vulnerable to such attacks, and there is no true way to fix it without changing its operating principles. I can already see a couple of suspicious nodes among peers in regular lowest buckets, so they can always switch to identifiers that are “just right” for all fake nodes.

Readers who are interested in such topics might want to read about a method that estimates “correct” and “incorrect” distributions on the fly during regular torrent hash lookups.
https://eli.sohl.com/2020/06/05/dht-size-estimation.html
(There's a linked work that describes all the basics of DHT measurement in the beginning.) This probably won't help to detect all fake DHT peers in our case, but is still interesting.

Of course, historical DHT size graph (using the biggest estimate among lowest buckets), as in FOPNU, would be great, though totally useless for practical purposes.