[bittorrent] Friend-machines-assisted approach to boosting one's BT download
ehem at m5p.com
Wed Jun 14 23:12:16 EDT 2006
>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.
> > > 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.
(\___(\___(\______ --=> 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