BitTorrent CSAM Investigation Explained: Swarms, Trackers, DHT, and Why Downloading Often Means Uploading

A network graphic illustrates the BitTorrent CSAM investigation explained.

Defense lawyers often get dropped into BitTorrent cases midstream. The affidavit is confident. The terms are technical. The narrative sounds like “download = intentional possession,” and it can feel hard to push back without sounding like you’re disputing basic networking.

You do not need to become a protocol engineer to litigate these cases well. You do need a clear mental model of how BitTorrent moves data and what the government’s logs do (and do not) prove.

This post is a plain-English primer with enough protocol accuracy to survive cross-exam. It also explains the phrase lawyers hear constantly: “Downloading often means uploading.”

BitTorrent is a protocol for distributing files across many peers. Instead of a single server sending the entire file to every downloader, peers exchange pieces with each other. In normal usage, once a client has any pieces, it can often upload those pieces to someone else. That’s the entire optimization.

Two high-level implications matter in cases:

A peer can upload partial data without ever having the complete file.
Evidence questions are often about what data moved, from whom, and how the tool recorded it.

The wire protocol is defined in the BitTorrent Protocol Specification (BEP 3) [1].

Swarms in plain English

A swarm is the group of peers participating in a particular torrent at a point in time. Think “everyone exchanging pieces of the same content.” The swarm changes constantly. Peers join and leave. Some peers have more pieces than others.

In litigation, “swarm” shows up in two places:

When the government explains why it can find peers quickly.
When the defense explains why multiple sources can exist, and why “this IP participated” does not automatically mean “this person knowingly possessed a complete file.”

You do not need to argue that swarms make evidence worthless. Instead, you want to identify the specific technical claim and the log entry that supports it.

Trackers: the phone book (sometimes)

A tracker is a server that helps peers find each other for a torrent. The tracker does not need to host the content. It mainly brokers introductions. The BEP 3 spec describes tracker requests and responses at a high level [1].

In practice:

A peer tells the tracker “I’m participating in torrent X and I’m reachable at IP:port.”
The tracker returns a list of other peers for torrent X.

Some modern torrents use compact peer lists in tracker responses to reduce bandwidth. (If you end up deep in tracker artifacts, this format can matter.) See BEP 23 for compact peer lists [2].

Defense takeaway: if the government’s story depends on tracker-based discovery, you can ask what tracker information was used, when, and what was recorded.

DHT: peer discovery without a tracker

Many clients can find peers without a tracker using the Distributed Hash Table (DHT). In effect, peers help act like a decentralized directory. The DHT protocol is described in BEP 5 [3].

Plain-English version:

A client wants peers for a torrent identified by an infohash. (For more on the distinction between infohash and file hash, see Hashes and Known-File Databases.)
It queries the DHT for nodes “close” (by a distance function) to that infohash.
Those nodes can return peers (contact info) for that torrent.

Why this matters in cases:

Peer discovery can be decentralized. “No tracker was used” does not mean “peer discovery did not happen.”
Logs and screenshots can differ based on whether discovery came from trackers, DHT, or both.

Why “downloading” often means “uploading”

BitTorrent clients can transfer data in both directions. Peer connections are symmetrical in the protocol: once a connection exists, either side can request and send pieces [1].

That symmetry is why “downloading” can mean “uploading” in practice. If a client is configured to upload while it downloads (common), it may upload pieces it already has, even if it does not have the complete file yet.

There are two practical litigation angles here:

Knowledge / mens rea: Did the user understand they were sharing? Were defaults changed? Was seeding limited? (This is highly fact-dependent and often turns on client configuration and user behavior.)
What the logs actually show: Some reports talk loosely about “sharing” when the underlying artifact shows only a connection, a handshake, or partial piece exchange. (For how handshake evidence is commonly overstated, see BitTorrent handshake evidence and Peer ID.)

What the handshake is (and what it is not)

The BitTorrent handshake is the initial protocol exchange that identifies the torrent (by infohash) and the connecting peer (by peer ID) [1].

Useful reminders:

A handshake can support the claim that “this peer connected and spoke BitTorrent for this torrent.”
A handshake alone does not prove a complete download.

In other words, a handshake is a building block. It is not a complete story. For a deeper, litigation-focused breakdown of handshake logs and Peer ID, see: BitTorrent handshake evidence and Peer ID.

Sometimes, yes. Many clients are designed to upload automatically because it improves network performance and fairness. Also, clients can retain torrent jobs and resume later. Users can forget what is running at startup, what is set to auto-resume, or how a client is configured.

That said, courts often look at the totality: file naming, volume, duration, sophistication, and whether settings were changed. This is why configuration artifacts and timelines matter.

Practical advice: focus on testable facts, not generalities. Ask what client was used, what the settings were, and what artifacts exist on the seized device.

Client interview checklist (lawyer-friendly)

Here is a quick checklist you can run early. It helps you identify alternative explanations and preservation needs.

Which BitTorrent client(s) were installed? (qBittorrent, uTorrent, Transmission, Deluge, etc.)
Default folder(s): Where were downloads saved? Were there multiple drives?
Auto-start: Did the client launch on boot/login?
Resume behavior: Did the client auto-resume prior torrents?
Seeding ratio / limits: Were there upload limits, ratio limits, or “stop seeding at X” settings?
VPN usage: Any VPN? Always on? Split tunnel? Any “kill switch”?
Network access: Who had Wi-Fi access? Guests? Roommates? Shared password? Router changes?
Device access: Who had physical access? Shared computer? Multiple user accounts?
Remote access: Remote desktop tools? Admin accounts? Prior malware events?
Timeline: Travel, work schedules, device repair, major OS updates, new router/modem dates.

You do not need a perfect answer to every item. You want a narrative you can test against artifacts.

What to ask for (and why it matters)

If the government’s evidence hinges on BitTorrent behavior, ask for materials that let you test the claimed sequence:

Connection and transfer logs
- What connections were made (IP/port), when, and for how long?
- What was requested and what was sent (pieces/blocks)?
Hash verification evidence
- Was a file hash verified after download?
- Was the identifier an infohash (torrent identifier) or a file hash (content identifier)?
Tool configuration
- Any setting that restricts sources, limits uploads, or changes verification behavior.
Timekeeping details
- Clock sync and time zone for each record source.

This complements the first post in this series, which focuses on RoundUp vs. Torrential Downpour naming and run artifacts: Torrential Downpour RoundUp software.

What to say in court (a simple, credible framing)

When you need to explain “download vs upload” to a judge without turning the hearing into a networking class, this framing usually lands:

BitTorrent is designed for piece exchange.
Many clients upload pieces they already have during the download process.
Therefore, the questions are: what was transferred, what was verified, and what artifacts tie activity to a specific device and user.

That keeps the discussion anchored to the real evidentiary issues.

Conclusion

BitTorrent cases feel intimidating when the technical vocabulary is unfamiliar. Once you understand swarms, trackers, and DHT, the evidence questions become more manageable. From there, your strongest work is often concrete and boring: logs, configurations, timekeeping, attribution layers, and what was actually verified.

If you want help translating protocol language into practical discovery requests, or validating what the logs do (and do not) prove, contact Lucid Truth Technologies using the LTT contact form: Contact.

Continue reading

Not legal advice

This article is for informational purposes and does not provide legal advice. Every case turns on specific facts and controlling law in your jurisdiction. Work with qualified counsel and, where appropriate, a qualified expert.

References

[1] B. Cohen, “The BitTorrent Protocol Specification (BEP 3),” BitTorrent.org, 2017. [Online]. Available: https://www.bittorrent.org/beps/bep_0003.html

[2] A. Norberg, “Compact Peer Lists (BEP 23),” BitTorrent.org, 2008. [Online]. Available: https://www.bittorrent.org/beps/bep_0023.html

[3] A. Loewenstern and A. Norberg, “DHT Protocol (BEP 5),” BitTorrent.org, 2020. [Online]. Available: https://www.bittorrent.org/beps/bep_0005.html

The core idea: BitTorrent is built to share