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

Harold Feit dwknight at depthstrike.com
Thu Jun 15 03:26:23 EDT 2006

Elliott Mitchell wrote:
>> From: coderjoe at grnet.com (Thad Ward)
>> 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.
> Yes, but someone merely out to get extra download will give out bad
> portions to whomever asks it for blocks, with no other cares. Someone out
> to destroy the torrent will strategically give bad portions (and may,
> potentially give out good portions for /some/ blocks). The difference is
> large enough to be crucial.
Shame that a piece is not retained for pieces that fail a hash check and
SHA1 still requires a supercluster to generate a collision for.

Again, the long-term effectiveness of such an attack is nonexistent due
to repeated-hashfail peer banning.

>>>> 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?
> Would require a rewrite of the protocol. Can be as simple as hashing the
> metadata and distributing that hash. That would ensure it was small
> enough to distribute similarly to URLs.
Look up Merkle Trees.

More information about the BitTorrent mailing list