Sure, I'll be glad to test. I just don't know what to do in terms of suggestions. I've given most of mine, and am not sure how understood they are. I don't want things to become acrimonious.
There are a number of ways to reduce abuse, and it isn't just about deliberate attackers. You may see more individual types of abuse, like hacked/modified clients for selfish people which go as far as hack values in memory to create things that are normally not possible. That was what I mentioned before. It isn't about checking all fields and stats of other users for the sake of stopping big attackers, since they will want to look as close to the real version as they can. The reason to check all the stats and fields are to look for other types of abuse that aren't as bad but not as good. I mean, they are not going to put incorrect or impossible information unless it serves a specific goal, like those who have 50 slots open out of a total of 0 slots in all -- logically and mathematically, that makes no sense. ("Out of" or "per" really means "divided by" and you cannot divide by zero.) So they deliberately hacked their client or used a 3rd-party tool to try to deliberately deceive clients that had anti-leech software.
Then the argument on leeching is, "But maybe they just want to chat." True, so that gives me a possible thought. Why not a loosely-coupled chat network? I mean, why not the ability to join the chat portion of the network without joining the file portion? Thus they can chat without giving or getting files. Or even use them for routing, relays, or hub management without them having any direct ties to the file-sharing part. Thus if there is any integrated leech prevention, it doesn't have to harm those who mainly want to chat, or don't mind their bandwidth being used for other tasks that help the network. So they cannot show up in download lists but will be able to chat, etc.
And another "leech" scenario is when someone owns an entire network but only have files on some of the machines. So they might want to download with the empty machine while hosting with another machine. So if someone really wants to block leeches without blocking those who share on other machines from what they download from, it would take some artful coding to be sure. It would not be fair to block those who do share using other equipment. There could be a way to prove one has another machine like that, but I am not sure that is a good precedent either (may make them more vulnerable to our enemies). The ones who run multiple connected machines are doing a service if they share on at least 1 machine.
Yet, if folks are going to use leech filtering, I'd rather it be in the program than a 3rd party option, since 3rd party can introduce bugs, crashes, etc., and possibly introduce vulnerabilities to the entire network. And it seems that most of the time, leeches only take bandwidth and don't give much back, but the worst concern is that the leeches may be disruptors, RIAA, MPAA, etc. So there are quite a bit of concerns when one looks at the leech thing. The leeches might not be leeches, some are not downloading anyway, and some leeches are some really bad players and are noway our friends. And forcing sharing is not the way to go either, since that invites hacking and is not a show of good faith. I might have lost my files and need professional recovery software before I can give back to the network. So it is a multifaceted issue with no easy solutions that would be fair to the entire community.