[BitTorrent] hash-based requests

Elliott Mitchell ehem at m5p.com
Tue Feb 15 16:28:02 EST 2005

>From: Justin Cormack <justin at street-vision.com>
> Have been thinking about the idea of making all requests and have messages
> refer to hashes rather than block offsets.

Makes a lot of sense for REQUEST and PIECE messages, turns out to make
a lot less sense for HAVE. BITFIELD/HAVE are about maintaining a bitmap,
a data structure almost completely unrelated to large blobs of data
indexed by a 20 byte string.

> It all works pretty well except that at the beginning when you only have the
> root hash, you can be sent a have message for a block you know nothing about
> because you dont yet have the tree (you dont even know which torrent it is
> from yet). Has anyone thought of a solution to this yet? You could store them
> but this gives a potential DoS by just making up random numbers and saying you
> have those pieces.

If HAVE messages are somehow indexed to tree location, then it works
pretty well.

> The other alternative is a two-phase protocol where you first obtain the Merkle
> tree before you can do anything else.

I'm working on a sample implementation which computes the hashes, and
uses a midsize branching factor. Turns out working with n-ary trees isn't
always easy.  %-)

(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EHeM at gremlin.m5p.com PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

Yahoo! Groups Links

<*> To visit your group on the web, go to:

<*> To unsubscribe from this group, send an email to:
    BitTorrent-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:

More information about the BitTorrent mailing list