Verify DHT's hashes before adding to peer list

[mcaspi]

Not sure about this issue but it might make some sense. I see some weird things in torrents's DHT peers numbers. At some point, the number of DHT peers in a torrent dramatically increases. In the log I see peers trying to connect to me, with hash numbers close to the torrent's hash and obviously disconnect ( Disconnect: No such torrent: 610A8007FXXXXXXXXX). Later, the number of DHT peers for that torrent drops down to the regular numbers. This affects the queuing if I'm not wrong.

I have an assumption that buggy DHT implementations in the network cause this by sending other peers wrong info. So basically, it looks like uT is basing information on other clients that might be buggy.

What I suggest is that if possible and makes sense, before uT adds a peer that came from the DHT network and from clients, other than trusted ones and trusted versions, to a torrent's peer list, it will verify that the remote peer really has the torrent that we have by comparing hashes and not totally trust DHT info from untrustworthy clients.