[bittorrent] Friend-machines-assisted approach to boosting one's BT download

Thad Ward coderjoe at grnet.com
Wed Jun 14 17:47:23 EDT 2006

On Sun, Jun 11, 2006 at 06:12:47PM -0700, Elliott Mitchell wrote:
> >From: Nikitas Liogkas <nikitas at CS.UCLA.EDU>
> > I would agree with Harold on this matter. The described attack is not 
> > viable, since most modern clients will ban peers sending corrupt data. 
> > Even when subpieces of the same piece are downloaded from different 
> > peers, the culprit can still be identified by using statistical 
> > measures, e.g. i got this corrupt piece from peers foo and bar, and 
> > this corrupt piece from peers foo and baz, so peer foo is probably 
> > bad. The damage done will not be much, since the malicious peer will 
> > be banned pretty quickly and for a long time.
> > For more details, and an experimental validation of the 
> > non-effectiveness of this attack, see:
> > http://iptps06.cs.ucsb.edu/papers/Liogkas-BitTorrent06.pdf
> Nice paper, but the wrong one.
> You were evaluating peers intent on getting a better download rate than
> they should nominally get. You were not evaluating peers actively
> interested in *destroying* the swarm.

As has been pointed out, the goal of the peers sending garbage does not
matter. Once they get banned from a peer, that peer stops talking to
that garbage peer altogether, bot upload and download. This will stop
the garbage peer from inflicting any more damage on it. Once most of the
peers on the torrent reject the bad peer, its effect on the swarm will
be minimal.

> > As for the non-ability to verify a block, it is not IMHO a weakness, 
> > but rather a smart engineering trade-off between performance (due to 
> > pipelining) and security.
> There are more factors in the tradeoff though, not to mention those two
> do not interact with each other. With block-verifiability you can still
> pipeline requests.
> What does factor in this tradeoff is size of the .torrent file (smaller
> granularity would make this file large, with the current protocol
> design). Also the issue that larger pieces ensures better locality of
> reference. There is one obvious way to bypass the first, exchange most of
> the data now in the .torrent file via the swarm. For the second, I'd
> simply leave 256KB as the smallest advertisable unit.

Exchanging the data in the .torrent file via the swarm sounds like a
pretty bad idea. How will someone be able to verify that the metadata
they got from the swarm matches the original metadata created by the
originator of the torrent?

Thad Ward

More information about the BitTorrent mailing list