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

Nikitas Liogkas nikitas at CS.UCLA.EDU
Sun Jun 11 23:34:05 EDT 2006

----- Original Message ----- 
From: "Elliott Mitchell" <ehem at m5p.com>
To: "Nikitas Liogkas" <nikitas at CS.UCLA.EDU>
Cc: <bittorrent at lists.ibiblio.org>
Sent: Sunday, June 11, 2006 6:12 PM
Subject: Re: [bittorrent] Friend-machines-assisted approach to 
boosting one's BT download

> >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.

The objective of selfish peers is irrelevant to the matter at hand. 
What the paper shows is that the attack you described is infeasible.

>> 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.

The main reason for the distinction between pieces and blocks is the 
number of new piece HAVE messages that would be required if the blocks 
were verifiable. The increase in the size of the .torrent file would 
not be a problem for hosting servers.


More information about the BitTorrent mailing list