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

Elliott Mitchell ehem at m5p.com
Fri Jun 16 00:15:22 EDT 2006

>From: Harold Feit <dwknight at depthstrike.com>
> Elliott Mitchell wrote:
> >> From: coderjoe at grnet.com (Thad Ward)
> >>> 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.

True, but if one manages to extinguish a piece in the short term then the
attack suceeds and the long term doesn't matter.

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

Precisely, though I'd tend to deviate some from the precise definition of
a Merkle tree (general idea is good in the general term, but it needs to
be adjusted to fit BT).

(\___(\___(\______          --=> 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 mailing list