BitTorrent: A Download With Something to Offer

Publishing a popular file can be a punishment for having produced something people want. One reader downloads it, then a hundred more arrive. Each asks the original server to send another copy. The audience grows; the publisher’s outgoing connection remains the same width.

BitTorrent redistributed that work. People downloading the same content could upload pieces to one another before their own downloads were finished. A downloader became a useful source while still having something left to obtain.

Bram Cohen’s paper Incentives Build Robustness in BitTorrent, dated May 22, 2003, supplies the historical focus here. It explains an already deployed system, not a product first invented on the paper’s date. This article examines that period design rather than assigning every later BitTorrent extension to its beginnings.¹

The clever part is the relationship between incomplete copies. If each newcomer had to wait until receiving the whole file before contributing, the original source would remain the bottleneck for longer. Useful fragments let distribution begin reproducing its capacity earlier.

Discovery isn’t delivery

The paper’s deployment has a web-served .torrent file, a tracker, and an initial seed holding the complete content. The tracker supplies contact information so peers can find one another. The actual file content moves between peers.¹

That division is important. A tracker can coordinate introductions without carrying every copy of the large file. Asking where a document can be found is cheaper than sending the document to everyone who asks.

The metadata also distinguishes the intended content from an arbitrary set of bytes. BitTorrent’s later formal protocol specification documents piece lengths and piece hashes, together with the information used to identify a torrent. The specification was created in 2008 and subsequently revised, so it is technical corroboration with a later date.²

A seed has all the pieces. An incomplete peer has some. The collection of participating peers is commonly called a swarm. The term is pleasantly biological, but the connections are still network connections, with finite capacity and participants who can leave whenever they please.

The tracker does not guarantee that a returned peer is still available. Discovery information is an opportunity to attempt a connection, rather than a reservation. A system built around users’ machines has to tolerate considerable churn.

Six pieces, four interested people

Consider an invented 12-MiB file split into six 2-MiB pieces, labeled A through F. MiB means 1,048,576 bytes. The piece size is chosen to keep the illustration short; it isn’t asserted as the period client’s default.

One seed holds all six pieces. Four new peers, P, Q, R and T, initially hold none. If the seed sends a complete copy separately to each newcomer, it uploads 48 MiB. Each newcomer receives 12 MiB, so total recipient traffic is also 48 MiB.

Now distribute initial pieces: P receives A and B, Q receives C and D, and R receives E and F. The seed has uploaded 12 MiB altogether. Each piece now exists somewhere outside the seed.

The three incomplete peers can exchange their different holdings, while T obtains pieces from them. In an idealized completion, the seed’s contribution remains 12 MiB and the peers supply the remaining 36 MiB of the newcomers’ total receipt.

Original CC0 teaching diagram, 2026. Invented file and idealized traffic accounting; no measured swarm or historical client screen.

There is no bandwidth miracle. The four newcomers still need 48 MiB delivered in total. The change is who supplies the outgoing traffic. A peer’s upload contributes to somebody else’s download.

This ideal accounting omits protocol overhead, corrupted data, retransmissions, redundant requests, and connections that fail. It also doesn’t establish a completion time. A transfer schedule needs capacities and availability as well as totals.

The initial 12 MiB is a lower-bound-style teaching arrangement for this particular starting state. It assumes the seed starts as the only holder and successfully introduces every piece to peers that continue participating. Losing a rare piece can force the seed to send it again.

That qualification is the difference between arithmetic and a benchmark. The model demonstrates redistribution; it does not promise that real original-source traffic is always exactly one copy.

A missing piece can outvote a nearly finished download

Suppose P has A, B, C and D; Q has A, B, E and F; and R has A, B, C and E. Count availability among these three incomplete peers:

Piece	Holders among P, Q and R
A	3
B	3
C	2
D	1
E	2
F	1

A newcomer can obtain A from anyone. D depends on P, and F depends on Q. If those holders leave and the seed is unavailable, the remaining peers cannot create the missing bytes through enthusiasm.

Rarest-first selection, described in Cohen’s paper, helps spread less common pieces.¹ For a newcomer missing everything, D and F are particularly useful acquisitions in this teaching state. A tie needs a choice, but the count already tells us why repeatedly choosing A would be unhelpful.

Once T receives D, there are two potential holders rather than one. That changes the distribution’s fragility. The piece isn’t merely helping T finish; it has gained another route through the swarm.

Original CC0 diagram, 2026. Counts exclude the seed and describe only the three named peers; tied rare pieces are D and F.

The counts are local to the stated view. A real peer sees the peers it knows about, not an omniscient inventory of every machine on the Internet. Selection must work with incomplete information.

The policy also has exceptions and phases. A new peer benefits from acquiring something it can upload; the end of a download has different concerns from the middle. The general aim of distributing rare pieces doesn’t imply that every request follows one unchanging global sort order.

Upload capacity is a choice

The title of Cohen’s paper points beyond the piece map. The system needs a way to decide whom to upload to when there are more interested neighbors than available outgoing capacity. It uses selective uploading and periodic opportunities to explore other peers.¹

Imagine P can sustain two useful upload relationships at a time. Q is supplying pieces quickly, R slowly, and T has just arrived with nothing yet. P has an immediate reason to sustain productive exchange with Q. It also needs a way to discover whether T might become a valuable participant.

If every peer refused newcomers because they had never supplied anything, newcomers could never begin. Exploration gives an unknown peer a chance. If every peer gave identical unlimited service to every requester, finite bandwidth would make the promise impossible.

This is an allocation problem, not a morality test. A peer can contribute little because its connection is narrow, because it lacks requested pieces, or because its software behaves strategically. The observations available to another peer don’t reveal every cause.

Selective exchange creates incentives to participate, but the rules needn’t produce perfect fairness. A system can improve practical cooperation without matching every user’s upload and download byte for byte.

Later researchers tested the limits of the incentive story. The 2007 BitTyrant paper reported that strategic behavior could obtain advantages under its experimental conditions. Its authors’ own result challenges any claim that the original mechanism made self-interested manipulation impossible.³

I find that more interesting than treating the protocol as a solved economic theorem. The machinery had to work among unreliable, differently connected machines. A useful heuristic and an unbreakable incentive guarantee are very different achievements.

Checking a piece doesn’t establish its reputation

A piece hash allows received bytes to be compared with the expected piece. If the bytes don’t match, the client can reject them rather than assembling a silently damaged file. The later protocol specification describes SHA-1 piece hashes.²

Our teaching check uses a tiny byte string rather than a 2-MiB piece. Hash the expected bytes, change one byte, and compare the digest. The two digest values differ in the executed example. That confirms the illustration’s detection of that change.

It doesn’t prove a mathematical impossibility of collisions. Nor does a matching piece establish that the complete content is trustworthy, harmless, or legally distributable. Verification answers whether these bytes match the identified content under the mechanism, not whether the publisher deserves confidence.

There are two separate introductions: the tracker introduces peers, while the torrent metadata identifies what pieces the downloader expects. A publisher still has to make the intended metadata available through a trustworthy path for the user’s purpose.

That separation matters for legitimate distribution as much as for any other use. Software installers, public datasets, and large original media can all benefit from shared delivery. The protocol’s historical significance is a transport arrangement, not a license attached to everything transported.

Later discovery changes deserve their own label

The 2003 paper describes tracker-based discovery. Distributed hash-table discovery is documented as a separate protocol extension in BEP 5. Reading a modern client manual and assuming trackerless operation belonged to every early deployment would erase a real architectural development.⁴

The distinction changes failure dependencies. A tracker-based swarm needs a way to obtain initial peer contacts through that service. An alternative discovery arrangement moves some coordination elsewhere. It doesn’t eliminate the need to find peers somehow.

Modern protocol documents are excellent technical references when their revision dates remain visible. They should complement the period paper, rather than silently replace it with today’s feature set.

Popularity becomes part of the capacity plan

A traditional single-source download makes demand a growing burden on the publisher. BitTorrent offers another relationship: additional downloaders can supply additional upload opportunities while they participate.

The worked accounting shows what changed. Delivery volume remains real, rare pieces remain necessary, and departing peers can still cause trouble. The system redistributes the cost through the audience instead of pretending the cost disappeared.

That is the consequential idea in the 2003 design. Incomplete copies are useful, discovery can be separated from delivery, and choosing what to send next affects the health of the whole distribution.

A progress bar usually describes what a computer has received. BitTorrent gave the same window a reason to describe what it was sending. The audience had become part of the machinery, occasionally with better attendance than the original server could afford.

Sources

Footnotes

1. Bram Cohen, Incentives Build Robustness in BitTorrent, May 22, 2003, five-page author paper; deployment, pieces, selection and selective-upload rationale. Performance superlatives are not adopted as independent facts. ↩ ↩² ↩³ ↩⁴

2. BitTorrent project, BEP 3, created 2008, subsequently revised. Piece metadata and hashing; later document clearly distinguished from the period paper. ↩ ↩²

3. Michael Piatek and colleagues, Do Incentives Build Robustness in BitTorrent?, NSDI 2007, inspected author abstract. No experimental percentage is reused as a general benchmark. ↩

4. BitTorrent project, BEP 5: DHT Protocol, separate extension documentation. Not assigned to the 2003 tracker-based design. ↩