BitStore: An Incentive-Compatible Solution for Blocked
Downloads in BitTorrent
Anirudh Ramachandran, Atish Das Sarma, and Nick Feamster
College of Computing, Georgia Tech
{avr, atish, feamster}@cc.gatech.edu
ABSTRACT
As many as 30% of all files shared on public BitTorrent
networks suffer from the lack of “seeders” (peers that have
complete copies of the file being shared); peers attempting
to download such a file (“leechers”) may have to wait indef-
initely to obtain certain file chunks that are not distributed in
the file’s network of peers (the “swarm”). We call this the
Blocked Leecher Problem (BLP).
To alleviate BLP, we propose BitStore, a larger, secure
network of BitTorrent users (not necessarily all sharing the
same content) where nodes offer their resources (such as
disk space and bandwidth) for public use. Peers sharing any
file can use the storage network to maintain replicas for each
chunk of the file. Any leecher seeking chunks that are absent
from in its own swarm can query the public network, locate
the node storing the said chunks, and retrieve them. BitStore
also provides robust incentives for nodes contributing re-
sources: In return for storing and serving chunks, such nodes
can negotiate micropayments using a second-price auction.
Peers who receive these credits may later use them to re-
trieve blocks they need from the storage network.
This paper quantifies the BLP, presents an overview of the
BitStore design, and discusses various challenges related to
storage management and incentives.
1. Introduction
BitTorrent [13] is one of the most common content-
distribution protocols on the Internet: Estimates place its
contribution to all Internet traffic at 35% [1]. Although Bit-
Torrent works well for popular content, it frustrates down-
loaders who wish to obtain less popular content, who may
often have to wait in the swarm indefinitely to meet peers
that have the blocks they need. This suboptimal behavior
in BitTorrent, which we call the Blocked Leecher Problem
(BLP), is common: Our investigation of torrent listings from
a torrent aggregator, Mininova [3], shows that almost 30%
of torrent file swarms analyzed have zero seeders but one or
more leechers.
We briefly describe BitTorrent to explain why BLP is com-
mon. A BitTorrent “swarm” comprises seeders (peers who
have complete copies of the file), leechers (peers who have
partial copies of the files), and a tracker (a per-torrent server
that enables peers to discover each other). Files are di-
vided into chunks (usually 64 – 512 KB each), and peers
distribute chunks among each other. A seeder only uploads
content, while leechers upload and download content until
their downloads complete (at which point they become seed-
ers). In a swarm with no seeders, leechers’ downloads will
only complete if the entire file can be reconstructed from
chunks that leechers in the swarm are sharing. If a swarm
does not collectively possess all chunks of the file, leechers
will never be able to recover more than a fraction of the file
(after sharing the chunks they possess among themselves);
they will then wait indefinitely for blocks that no leechers
in the swarm have.1 BLP is not to be confused with the
well-known last-block problem, which is merely an instance
of the coupon collector problem; BLP occurs when some
chunks of the file are not shared by any peer in the swarm.2
If the overlap between the active periods of leechers and the
last seeder are insufficient to distribute the whole file, the
leechers that remain in the swarm (as well as leechers that
arrive subsequently) find themselves facing BLP.
To solve BLP, we propose BitStore, which augments the
BitTorrent protocol by providing a persistent global store
that is shared among swarms. For each swarm, peers agree
to lazily maintain a minimum number of replicas of every
chunk of the original file. Essentially, the distributed stor-
age mechanism offered by BitStore supplants the need for a
seeder, since all blocks of the original file are guaranteed to
reside in BitStore. Unfortunately, the clients belonging to a
particular swarm are not sufficient to maintain these repli-
cas (otherwise, they would never face BLP as they would
be able to retrieve the chunks they need). Instead, BitStore
creates an auxiliary storage network, S, comprising clients
from other swarms such that the total number of nodes in
S is large (in particular, much greater than the number of
clients in any single swarm). In practice, this network may
include all peers tracked by an organization (e.g., a torrent
aggregator). Since even a single popular torrent aggregator
may track many millions of active peers, the size of S could
be quite large [4].
In BitStore, leechers can retrieve missing file chunks from
S, since seeders would have replicated all chunks of the file
1Usually, if a seeder leaves a swarm, it is unlikely to return and contribute
content; he has no incentive to do so. A swarm with no seeders can be
thus “blocked” until altruistic seeders return (usually after out-of-band pleas
for help, illustrated by the numerous plaintive ‘Please seed!’ messages on
torrent tracker websites.)
2Because BitTorrent peers use a Local Rarest First policy for picking new
blocks to download, BitTorrent is less prone to the last block problem than
most P2P filesharing networks [8].

on S before leaving. In return for hosting content for the
storage network S, nodes obtain micropayments [23], where
the amount of payment received is determined according to
a second-price auction. A node can then later use these to-
kens to retrieve chunks from S for other files on which it is
blocked.
This paper’s main contribution is the design of BitStore,
which is, to our knowledge, the first system to address the
Blocked Leecher Problem. BitStore uses the spare band-
width and disk-space of peers to create a unified, quasi-
persistent store for blocks of files for all participating
swarms. Despite its conceptual simplicity, BitStore must
address several challenges that arise from the fact that the
distributed store, S, is maintained by BitTorrent peers them-
selves, which must be properly incented to donate storage
and bandwidth resources to S. BitStore’s design provides
these incentives and has the following salient features:
• BitStore’s lazy replication scheme guarantees that,
with high probability, the distributed store, S, will con-
tain the complete file chunks for unpopular files that
lack seeders (Section 4.2).
• BitStore’s distributed store is robust to resource ex-
haustion attacks (Section 4.3).
• BitStore provides strong privacy and anonymity guar-
antees. In particular, peers that store blocks for S have
no knowledge of the blocks that they are storing for
other peers (Section 4.4).
• BitStore provides incentives (through token-based mi-
cropayments) for peers to contribute resources to S,
which guarantees that S (Section 5).
In addition, BitStore operates in parallel with BitTorrent’s
chunk swapping mechanisms and thus requires no modifica-
tions to existing BitTorrent protocols or software.
After presenting a brief overview of BitTorrent and related
work in Section 2, we present an overview of the BitStore
protocol in Section 3. Sections 4 and 5 describe the details
of storage management and incentives, respectively; we con-
clude in Section 6.
2. Background and Related Work
We describe the BitTorrent protocol and its desirable prop-
erties, as well as why BLP is common. (Section 2.1). Next,
we present relevant related work (Section 2.2).
2.1 BitTorrent Overview
Content is published using a .torrent file, a small (typ-
ically less than 1 MB) file that contains hashes of all chunks
of the content being distributed, as well as the domain name
and port of the tracker. A single machine typically tracks
multiple torrents, and busy trackers often track thousands of
torrents (and, hence, hundreds of thousands of clients). The
majority of public trackers are offered as a free service to
users, by a small set of organizations (e.g., Mininova [3],
The Pirate Bay [5], Demonoid [2], etc.); these organizations
also offer web-based interfaces for users to search, locate,
and obtain torrent files to start their downloads. We refer
the reader to Cohen’s original paper [13] and subsequent re-
search [18, 25, 8] for more details.
BitTorrent has many desirable properties, including: (1)
Scalability: A BitTorrent network’s capacity to serve con-
tent grows with more clients (“self scalable”); (2) Robust
Incentives: BitTorrent offers participants robust incentives
to contribute content to the swarm; and (3) Avoidance of the
Last-Block Problem: BitTorrent participants employ the Lo-
cal Rarest First (LRF) policy in choosing blocks to download
from peers, diminishing the effects of the last-block prob-
lem. Unfortunately, BitTorrent does not provide any incen-
tives for seeders to stay to contribute blocks after their down-
loads have completed, which can give rise to BLP, especially
for unpopular files.
2.2 Related Work
We briefly survey previous work on replicated systems and
incentive systems for peer-to-peer networks.
Replicated Systems. Replicated systems have been popu-
larly used for fault tolerance including byzantine fault toler-
ant [11] systems such as BAR [6] and quorum systems [22].
BitStore does not provide byzantine fault tolerant guaran-
tees, but instead uses cryptographic techniques to verify
chunks served by nodes. BitStore’s storage infrastructure is
based on the DHash [14] block storage system.
Incentives in P2P Networks. In contrast to barter systems
like BitTorrent [13], filesharing networks such as Kazaa [19]
and eMule [15] offer reputation-based incentive mechanisms
to reward altruistic peers. Reputation systems(e.g., [20]) are
susceptible to collusion and are not scalable; BitStore instead
uses pairwise currency exchanges to incent peers providing
service. Incentive mechanisms have also been proposed for
new [21] P2P content-distribution systems, media stream-
ing [17], and for the general case [16]. Recent research has
showed how BitTorrent’s incentive system may be exploited
by selfish peers to gain better performance [24].
3. The BLP and BitStore
We first describe the Blocked Leecher Problem (Sec-
tion 3.1) and discuss its prevalence in today’s BitTorrent
networks. We then present an overview of BitStore (Sec-
tion 3.2).
3.1 The Blocked Leecher Problem
The Blocked Leecher Problem (BLP) affects any peer-to-
peer network where files are divided into chunks and stored
across peers (BitTorrent is one example of such a network).
As a file decreases in popularity, the number of peers dis-
tributing chunks from that file also decreases, as does the
likelihood that the set of peers will collectively have all
chunks of the file.
The last seeder to leave a swarm might have left when
there were few leechers, but as more leechers join later, all of
them face BLP. Note, in particular, that while the last seeder
2