[bittorrent] Friend-machines-assisted approach to boosting one's BT download
ehem at m5p.com
Mon Jun 12 00:14:44 EDT 2006
>From: Nikitas Liogkas <nikitas at CS.UCLA.EDU>
> ----- Original Message -----
> From: "Elliott Mitchell" <ehem at m5p.com>
> > >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.
No it doesn't. You were talking about a peer trying to get extra
download. I'm suggesting a peer that doesn't care about downloading,
merely destroying the swarm.
The difference in objective is 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.
> 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.
That would of been one of the original reasons, but the size of the
.torrent file was also a reason. I will agree that advertising posession
of every 32KB block would be a bad idea due to HAVE overhead, but this
does not mean you cannot have hashes for every 32KB. You simply have the
granularity that you can advertise at be distinct from the hash
granularity. There is no reason a protocol redesign couldn't make those
(\___(\___(\______ --=> 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