by Guest on 2026/04/11 06:12:10 PM
Hey, there is a discussion happening that might interest you. Some people with a lot of popular media torrents seem to experience problems with DHT operation caused by deliberate fake data from a certain DHT botnet.
https://paste.i2pd.xyz/?c7c8c3b8ce988ac1#2Mrow6z6UmnAY6pxTQkMKAZtxiHkrjew3pZZ6aDczd7n
(Links removed by Mod and sent to Devs)
It should be possible to auto-ban at least the nodes that reply with new IDs that match each new hash you send them. Regular nodes never change it free times in each single minute. Fake nodes with IDs that match your own should be possible to insta-kill, too. Number of bits allowed can be set by the user just in case.
by Guest on 2026/04/12 05:07:06 AM
4chan link is not suitable? Come on, even grannies are not afraid of it today.
All right, anyone can look it up in /g/ archives.
I think there might be something in Tixati to trigger the described behavior. It seems that node replacement rules make some addresses stick in the client DHT table much better than other potential candidates. I restarted Tixati multiple times, waited for a while, changed node IDs and ports, and the search situation remained exactly the same. Sometimes it worked, the rest of the time it was zero peers found. The address cache was poisoned. Only after I deleted dht2.dat, I got fresh random assortment of nodes, and searches started to work reliably. After a couple of hours, it seems that poison is getting back, and amount of real nodes providing data keeps decreasing. Average number of contacted nodes in each search has grown from 100-150 (and almost instant discovery of peers) to 150-200 (and peers slowly appearing).
What about using 8 shadow candidates for each bucket, like other implementations do? Can it change the skewed preference for fake nodes that pretend to be everybody at once?
