Libtorrent: An Idea to detect and stop cheaters

[PyR8zdl]

When the client reports the data uploaded and downloaded, instead of only sending total sent, and received it could also send data for the amount of data sent to X peer, and the amount of data received from X peer.

With this new data, trackers could then use this to detect cheaters since all peers sent and received data could be checked against the other peers sent and received and the tracker could then kill the connection for cheaters and disable account or flag it for manual intervention.

I realize this would only work once most popular clients adopt the new change, but once adopted, Unless I'm missing something, It couldn't be spoofed as the tracker could block clients that don't supply the new data, and spoofing the data would require all peers to spoof the same data to go undetected.

I think if most clients supply this data and trackers choose to utilize it, it would work without any issues or chances of bypassing.

Am I missing anything? Any ideas to make this better?

I'd love to hear any input from the devs.

From my understanding Deluge, qbittorrent and, rtorrent use libtorrent. So adding this here, it should eventually make it's way to most popular clients.

[FranciscoPombal]

This is easily defeated, cheating clients would just report to the tracker that they are sharing a lot of data between themselves. Plus even if the tracker rejected announces from cheating clients, there is still the DHT to find and establish connections.

By the way, rtorrent uses a different libtorrent. qBittorent, Deluge and some others use the "rasterbar" variant (https://github.com/arvidn/libtorrent), while rtorrent uses the "rakshasa" variant (https://github.com/rakshasa/libtorrent). Transmission uses their own implementation.

[PyR8zdl]

I see, thanks for the insight.

Would there be any other feasible way to do this assuming all major clients adopt? Or is BitTorrent doomed to have this issue forever?

[arvidn]

another issue that would need to be addressed is clients that try to frame someone by reporting that they didn't download anything, even though they did

[arvidn]

Would there be any other feasible way to do this assuming all major clients adopt? Or is BitTorrent doomed to have this issue forever?

I'm not entirely convinced that this is an important problem to solve, but I think the most reasonable approach would something like:

1. authenticate all peers, and have the tracker issue certificates to them (something like SSL torrents). This locks down the swarm, preventing any outsiders from joining.

2. Issue tokens where a peer signs a proof that it downloaded some set of pieces from another peer. These "tokens" are sent back in response to PIECE messages regularly, and are later recorded with the tracker somehow. If a peer doesn't provide such tokens after receiving data, it's banned.

[FranciscoPombal]

I see, thanks for the insight.

Would there be any other feasible way to do this assuming all major clients adopt? Or is BitTorrent doomed to have this issue forever?

Some experimental solutions have been proposed, I _think_, but I do not recall any off the top of my head. @arvidn can you link some papers, if you know of any?

I will say however, than in practice this is not that much of a problem. Public torrents work fine, and private trackers, which really care about ratio stats, have other ways to combat cheating.

[PyR8zdl]

Would there be any other feasible way to do this assuming all major clients adopt? Or is BitTorrent doomed to have this issue forever?

I'm not entirely convinced that this is an important problem to solve, but I think the most reasonable approach would something like:

1. authenticate all peers, and have the tracker issue certificates to them (something like [SSL torrents](http://libtorrent.org/manual-ref.html#ssl-torrents)). This locks down the swarm, preventing any outsiders from joining.

2. Issue tokens where a peer signs a proof that it downloaded some set of pieces from another peer.  These "tokens" are sent back in response to `PIECE` messages regularly, and are later recorded with the tracker somehow. If a peer doesn't provide such tokens after receiving data, it's banned.

This is very interesting. Thanks for the info!

I will say however, than in practice this is not that much of a problem. Public torrents work fine, and private trackers, which really care about ratio stats, have other ways to combat cheating.

This is true, but a solution that makes it automatic with 100% certainty would be preferred.

[Seeker2]

I will say however, than in practice this is not that much of a problem. Public torrents work fine

XunLei/Thunder is simply too popular for this to be true on public torrents that fall into its view.
You need to see what happens when they make up >25% of the peers on a torrent to understand just how bad it can get.

another issue that would need to be addressed is clients that try to frame someone by reporting that they didn't download anything, even though they did

XunLei/Thunder does that.

[arvidn]

XunLei/Thunder is simply too popular for this to be true on public torrents that fall into its view.
You need to see what happens when they make up >25% of the peers on a torrent to understand just how bad it can get.

I'm really interested in understanding this. It seems like a gap between people who have or are experiencing this and people who haven't or aren't. I'm in the latter category. @Seeker2 I would really appreciate if you would document what happens and how they behave, and how it affects the swarm (from your point of view). Because I really don't understand how bad it can get.

If we can build a model of this behavior (and validate it in simulations), we can start to come up with effective counter measures (and also validate those in simulations).

One approach could be to enable verbose peer logging in libtorrent and save the log. This records every bittorrent message sent and received. To keep noise down, it should be a single swarm.

Another, similar, approach would be to capture all swarm traffic in wireshark and boil down the packets to bittorrent peer message streams (I wrote a tool to do this recently)

[FranciscoPombal]

@Seeker2 what swarms are these? I regularly participate in many and varied public torrent swarms and I have not observed any situation where it "gets really bad" (which I assume means every leer downloading slowly due to many Xunlei leeches).

But I agree with @arvidn. It would be best to gather data and quantify how exactly "bad it can get".

[Seeker2]

I am not a good person to provide example torrents on or do detailed testing, because I have only on rare occasion run across a torrent that has even 1-out-of-20 peers be XunLei or 2 XunLei peers at a time. I don't tend to download anything in Chinese, nor do I really know where to get such.

However, the posters here might: https://github.com/qbittorrent/qBittorrent/issues/10258

Beyond that, I have seen other kinds of minor cheating behavior, although that was years ago -- back in BitComet's heyday. My seed was trying to keep a public torrent alive and the arrival of a single BitComet 0% complete peer would soon result in strong banding of availability at begin/end points of files in the torrent even with 5-15 other peers on the torrent.

I also vaguely remember reading papers/studies on the effects of hostiles on BitTorrent swarms -- and while complete disruption was almost never achieved by them, considerable slowdowns were possible. Such as making a torrent take roughly 4-20x longer to download.

Public torrents often have the problem of no accumulation of seeds, high percentage of firewalled peers/seeds, and slow speeds -- probably also due to slow speeds of participants. This is true even of present day semi-low demand public torrents, and it is there that I'd expect the arrival of XunLei peers to have the greatest effect.

[ghost]

I created some anti cheat measures for some private trackers which are mainly aimed at catching blatant cheaters and most of the times the less careful ones. However, with current bittorrent protocol specifications and all, its quite impossible to catch closet hackers. It would require a massive revamp where everything reported by the client can be verified by a tracker. Something like tokens as arvidn mentioned.

[PyR8zdl]

Yeah, I'm really liking the idea of tokens. If Understand it correctly, it may even fix the issue of ghostleeching as well.

[HDVinnie]

The most famous way of cheating is removing the PID from announce or the whole announce all together after populating the peers list from the private tracker. (Ghost Leeching). There really is no way to stop this. Only try to detect users that have history of a lot of torrents with 0 download, 0 upload, 0 seedtime, etc. Because they will always get a history record logged due to the STARTED event they must send to the tracker in order to get the peers list.

Let it be noted this issue is clearly aimed at private trackers.

[arvidn]

Speaking of private trackers; my impression is that there's an unreasonable focus on share ratio, maybe even causing some of the cheating. Tokens could make it more or less impossible to cheat on ones share ratio, but staying online and providing potential upload is also really valuable. Tokens would not solve the problem of how one proves that one kept a seed online for some period of time.

[FranciscoPombal]

@an0n666

It would require a massive revamp where everything reported by the client can be verified by a tracker.

It would be better if there was a mechanism that could work without a tracker. A tracker is a centralized entity, and one of the greatest things about BitTorrent nowadays is the ability to work completely independently of trackers.

[FranciscoPombal]

@arvidn

Tokens would not solve the problem of how one proves that one kept a seed online for some period of time.

This one is a huge deal. It seems like a very difficult problem to solve - proof of payload availability/data retention. There is some blockchain stuff that's trying to do something to that effect (Filecoin, etc), but they are struggling also.

Private trackers tend to have systems to reward long-term seeding as an alternative or complement to rewarding high share ratios, but these systems are fundamentally broken, in that they can be easily exploited (anyone with bit of programming/scripting knowledge can easily exploit them without getting caught). For now, they seem to work because as far as I've seen, there are not many people abusing them, either because most don't know how to or because most in this subset of users are altruistic.

If a private tracker economy is entirely based on sharing ratio, it works absolutely awfully. It quickly turns into a pump-and-dump race between people with 10 GBit seedboxes, and overall retention suffers as a result. Meanwhile the vast majority of users fight for scraps and have to severely ration their content consumption, which almost entirely defeats the whole purpose of joining the tracker in the first place. This problem is especially apparent if the tracker mainly on content with small file sizes.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dylangerdaly]

Issue tokens where a peer signs a proof that it downloaded some set of pieces from another peer. These "tokens" are sent back in response to PIECE messages regularly, and are later recorded with the tracker somehow. If a peer doesn't provide such tokens after receiving data, it's banned.

This sounds great, how does one get something like this adopted into the BitTorrent Specification? Maybe submit a BEP?

Currently there's total trust in the client.

[arvidn]

This sounds great, how does one get something like this adopted into the BitTorrent Specification? Maybe submit a BEP?

Yes. It would take time and a work. Since this would be a big feature, I think a few things would need to happen:

1. disuss it with other implementers in the bittorrent.org github issues
2. implement a prototype and deploy it somewhere
3. measure its performance
4. write a compelling BEP explaining why this protocol is the most reasonable for bittorrent, comparing it and the implementation with prior art.

I would expect, for instance, people would ask; why not use some existing infrastructure for micro payments. Say lightning.

Some big questions a BEP would have to answer are:

1. Is there a central authority that issues tokens? or is there a block-chain?
2. Do peer connections need some authentication and confidentiality in the transport layer for keys or tokens to not leak? (presumably all security is in the crypto of the token)

Currently there's total trust in the client.

I think that's a bit of an exaggeration.

[dylangerdaly]

I would totally pay for "tokens", I think incentivising users via share ratio is dated. However people need to seed for files to stay alive so maybe a revenue incentive is better?

I think that's a bit of an exaggeration.

My current implementation of libtorrent reports whatever I downloaded * 2 as what I "uploaded", so I'd say yes, indeed the tracker _currently_ totally trusts the client.

Is there a central authority that issues tokens? or is there a block-chain

Hm, I don't think anyone will want to go for this, isn't the entire ethos of BitTorrent to be decentralized?

Sent from ProtonMail mobile

-------- Original Message --------
On Aug 19, 2020, 9:03 PM, Arvid Norberg wrote:

This sounds great, how does one get something like this adopted into the BitTorrent Specification? Maybe submit a BEP?

Yes. It would take time and a work. Since this would be a big feature, I think a few things would need to happen:

• disuss it with other implementers in the bittorrent.org github issues
• implement a prototype and deploy it somewhere
• measure its performance
• write a compelling BEP explaining why this protocol is the most reasonable for bittorrent, comparing it and the implementation with prior art.

I would expect, for instance, people would ask; why not use some existing infrastructure for micro payments. Say lightning.

Some big questions a BEP would have to answer are:

• Is there a central authority that issues tokens? or is there a block-chain?
• Do peer connections need some authentication and confidentiality in the transport layer for keys or tokens to not leak? (presumably all security is in the crypto of the token)

Currently there's total trust in the client.

I think that's a bit of an exaggeration.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[arvidn]

I would totally pay for "tokens", I think incentivising users via share ratio is dated. However people need to seed for files to stay alive so maybe a revenue incentive is better?

Tribler is doing interesting work in this field.

My current implementation of libtorrent reports whatever I downloaded * 2 as what I "uploaded", so I'd say yes, indeed the tracker _currently_ totally trusts the client.

Oh, you meant trackers trust clients stats reporting. Yes, sure. Although, I've seen some pretty weird "checks", like only accepting values divisible by 0x4000 (because uTorrent only reports at chunks level).

(there are other aspects where clients are not totally trusted)

Hm, I don't think anyone will want to go for this, isn't the entire ethos of BitTorrent to be decentralized?

Not private trackers, tracking share ratios.

[dylangerdaly]

Tribler is doing interesting work in this field.

Wow, this looks awesome! Cheers I'll check this out

Not private trackers, tracking share ratios.

Ah fair enough

Thank you for your work on libtorrent btw!