[bittorrent] Friend-machines-assisted approach to boosting one's BT download
ehem at m5p.com
Sun Jun 11 21:12:47 EDT 2006
>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:
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 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
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.
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | EHeM at gremlin.m5p.com PGP 8881EF59 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
\___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/
More information about the BitTorrent