Standards (was [BitTorrent] Back to Merkle Hash Trees...)

Justin Cormack justin at
Mon Feb 7 18:30:56 EST 2005

> > 
> > While you have a piece size on the torrent file, you have basically hard
> > coded 32k in in the protocol. Then you have limited the filesize by only using
> That's the chunk size, not the piece size.

Ah I understand now. See below.
> > 32 bits for the piece. I thought everyone had pretty much agreed that 1k/4k
> 2^47 bytes doesn't look like a 'big' limitation.

Its a bit too small, 128TB, as it is within range of the size of filesystems
people have now, let alone a few years in the future.
> > was a good size once we go Merkle?
> I can't remember any discussion about that.

It has come up a few times I think.
> > The description of chunk_have is very unclear and I dont understand it.
> It's like have, but for a chunk instead of for a piece.

Oh I see. See below.
> > Requiring clients to be able to read a gzipped torrent is really not necessary
> > just recommend/mandate that they support gzipped http.
> > 
> > your xbt url doesnt support a multifile torrent.
> Why not?
> It's the info_hash that's included, not the root hash of a single file.

But the info_hash isnt sufficient information to verify a torrent. Of course
one logical thing would be to Merkle hash the individual file hashes into
one hash...

ok re see belows above.

One of the points of Merkle hashes is that you dont really need the piece/chunk

I can see what you are doing, keeping the distinction means fewer have messages
(though you negate this somewhat as the chunk_have messages clearly have a
useful purpose, even if only at some times).

There are a lot of options available once one gets this flexibility, and it
is probably best to scrap the piece/chunk distinction.

Call the smallest verifiable unit SVU (say 4k).

One option would be that if have messages are a range of SVUs (or SVU + length)
and requests have lengths then you could have a standard algorithm to ramp
up request sizes as downloads progress, for example, or make this rarity
based. This would amortise the slightly large have and request messages for
small requests with those for larger requests later.

Yahoo! Groups Links

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

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

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

More information about the BitTorrent mailing list