Automatically ban peers that download more than 100%

[Vernoxvernax]

Suggestion

Today I have discovered a peer, which has downloaded more than 12GB. The problem is, the torrent only had a file size of 3.4GB. It was probably only someones faulty client or something, but it made me think: What would happen, if certain individuals use that against the torrent community in order to drain the amount of seeders?

I think there should be an option to automatically ban peers that download more than a certain percentage.

Use case

Tell me if I'm wrong, but I am pretty sure it affects torrents in general.

Extra info/examples/attachments

screenshot of said 3.5GB torrent.

[PythonCoderAS]

Maybe his client is sending false information? Also that's the uploaded amount? He's seeded 12 gigabytes???

[Vernoxvernax]

Maybe his client is sending false information? Also that's the uploaded amount? He's seeded 12 gigabytes???

My client has sent 12GB to the peer, as seen in the picture, while the torrent itself is only 3GB in size.

[PythonCoderAS]

Oh so that's how the peer system works, I thought it was showing how much everyone downloading/seeding a torrent has done.

[ghost]

Or it could be the opposite. You’re feeding bad data to him.

[Vernoxvernax]

Or it could be the opposite. You’re feeding bad data to him.

Very unlikely.
Right after I banned that peer, I rechecked the data and nothing had to be redownloaded. Also: my ratio is above 10 on that torrent, so it would have probably already happened to a different peer.
Even if there is something corrupting my packets, I still think it's necessary to implement countermeasures against trolls or possibly faulty clients.

What do you guys think? Could this maybe be a future strike against piracy?
Could definitely work.

[xavier2k6]

@Vernoxvernax Under libtorrent section in advanced options - Do you have Allow multiple connections from the same IP address checked or un-checked?

See screenshot:

[Vernoxvernax]

Enabled.

I don't see why that would make a difference. qBittorrent doesn't merge multiple peers even if the IP is the same. And there can only be one client running on one port.
See here:

And yet again, I am not trying to figure out that one situation I had two days ago. This is a feature request to prevent attacks using a method like this.

[xavier2k6]

name	type	default
allow_multiple_connections_per_ip	bool	false

determines if connections from the same IP address as existing connections should be rejected or not. Rejecting multiple connections from the same IP address will prevent abusive behavior by peers. The logic for determining whether connections are to the same peer is more complicated with this enabled, and more likely to fail in some edge cases. It is not recommended to enable this feature.

https://www.libtorrent.org/reference-Settings.html#allow_multiple_connections_per_ip

[R-Adrian]

I don't think that is a faulty client, because of the volume of data and of the low progress percentage reported it looks to me that it's probably done on purpose.

Some retransmissions and erroneous data might be a sign of a fault somewhere, but when that much data (over 150-ish % of torent size) or the same torrent pieces are repeatedly downloaded by the same peer constantly this is usually a sign that you are targeted by some sort of enforcement bot or law firm ... it's a 15+ year old P2P poisoning method and it's done with the main intended purpose to tie up your upload bandwidth in a bottleneck. It could also be used to document the continuous presence and availability of that file on/from your computer, for possible future legal action.

quote from Wikipedia: https://en.wikipedia.org/wiki/Torrent_poisoning#Interdiction

Interdiction
This method of attack prevents distributors from serving users and thus slows P2P file sharing. The attacker's servers constantly connect to the desired file, which floods the provider's upstream bandwidth and prevents other users from downloading the file.

[Vernoxvernax]

Exactly. We don't know what is actually the case, but we do know, there has to be countermeasures for these kinds of situations. Even if its just some accidentally deleting their linux iso's for the tenth time in a row.
Thank you R-Adrian for that explaination and possible ongoing "attack".

[parthagar]

I just want to bring to notice a genuine case for rerequesting data, one where the peer actually needs the data to be retransmitted possibly because they deleted the file by mistake or some other related cause. This could be one more scenario apart from errors and retransmissions for which it seems legit for the peer to rerequest data.
But I agree with @Vernoxvernax , that the choice of allowing or blocking this should reside with the user.

[valerysvl]

You have to read this
https://www.emule-security.org/news.php
and use the filters from emule into torrent for the same purpose

[Vernoxvernax]

@ valerysvl
Thank you very much. Even though this will probably hold off most threats, a feature to handle these peers automatically, is definitely needed.

[Jacco011]

You have to read this https://www.emule-security.org/news.php and use the filters from emule into torrent for the same purpose

Also this can be automated: https://github.com/DavidMoore/ipfilter

[zwei7]

I think it is India based on the flag.
That 1 peer might be 1 centralised illegal ip box provider streaming a movie or TV shows to multiple Indians who bought their ip box. And the ip box provider is using your seeding ability so they don't have to run a server to stream the show to them and pay for it themselves.

[Vernoxvernax]

I think it is India based on the flag. That 1 peer might be 1 centralised illegal ip box provider streaming a movie or TV shows to multiple Indians who bought their ip box. And the ip box provider is using your seeding ability so they don't have to run a server to stream the show to them and pay for it themselves.

Judging by the content of the torrent, I can assure you, that this is 100% not the case.
I am really confused, that there are so many people trying to come up with different conclusions for this phenomenon.
After more than a year, my initial assumption, still seems to me as the most logical one. What's the problem with it?

P.S:

To anyone posting links to plugins/addons:
I appreciate you trying to help me, but I think this* should be an integrated part of every modern torrent client and not managed by third-party tools. It's not a theme-pack. A feature to ignore finished clients, could help the entire community to save bandwidth resources (literally money); instead of one single advanced user that happened to come across such a plugin.
I know I'm dreaming a little too big here, but it would be nice to at least have it as an optional feature.

[zwei7]

Maybe that person has a semi broken hard drive and is constantly redownloading that torrent on that broken sector. He sees torrent is 100% done, then performs a recheck and it goes back down to 50% and redownloads it from you for the umpteenth time. It would be interesting to see if he is downloading the same part (corrupted hard drive hypothesis) or is downloading the whole torrent indiscriminately (the I have no idea).

[aaronsql2019]

I just think that defining a 'Peer' as ONE ipv4 address is just a flawed friggin (sorry, I fixed that) concept.
How many people use CGNAT? I'm not saying it explains away EVERYTHING. I'd just like to find out more about fingerprinting before dropping ANY connections.

I don't believe in blocking / banning ANYTHING, really.