[bittorrent] Why are blocks smaller than pieces?

Olaf van der Spek olafvdspek at gmail.com
Mon Sep 10 02:45:39 EDT 2007


On 9/10/07, Thad Ward <coderjoe at grnet.com> wrote:
> The problem I see with this is that collisions on SHA1 are not that far
> off,

You can use a stronger hash.

> and you would be getting your verification hashes from an untrusted
> source.

But you can verify the verification hashes too. :)

> This is also another good argument for the transferred block size being
> smaller than the size of a piece. It prevents malicious peers from being
> able to send data which is different from the real piece, yet still
> hashes to the same hash, simply because you have to get all blocks of
> that piece from malicious peers sending the same collision.
>
> On Sun, Sep 09, 2007 at 10:52:58AM +0200, Ludvig Strigeus wrote:
> > Another alternative would be to use a hash tree like tiger tree
> > hashes. Then all the hashes in the torrent file would be replaced by a
> > single hash. The hash tree would then be sent out incrementally,
> > allowing each client to reconstruct its hash tree enough to be able to
> > verify the pieces it gets.
> >
> > This would allow a client to verify blocks at a block granularity, it
> > would decrease the size of a torrent file, for the cost of a slight
> > overhead in piece packets and a slight hashing CPU time increase
> > (<5%), and some added implementation complexity.
> >
> > /Ludvig
> >
> > On 9/9/07, Guido Seifert <tanuki64 at gmx.de> wrote:
> > > > Well, typically requests (and therefore blocks) are 16kb (so that slow peers
> > > > and high latency links don't cripple swams), compared to typical piece
> > > > sizes, which are between 128k to 4mb or more (no real limit).
> > > >
> > > > Consider a 20gb torrent with 16kb pieces, the consequent size of the
> > > > .torrent file, and more importantly, the protocol overhead required to send
> > > > massive bitfields and the numerous HAVE messages.
> > >
> > > Yeah, the reason for would be quite some overhead.
> > >
> > > [...]
> > >
> > > > Hope that's useful. Certainly that is a weakness neccessitated largely by
> > > > the dynamics of sending (very) large files over potentially slow links, but
> > > > it can be worked around.
> > >
> > > This sure is useful and not too difficult to implement. I am by far not that
> > > advanced with my client that I can yet use it, but the sooner one considers such
> > > problem in a new design, the better. :-)
> > >
> > > Guido
> > >
> > >
> > > _______________________________________________
> > > BitTorrent mailing list
> > > BitTorrent at lists.ibiblio.org
> > > http://lists.ibiblio.org/mailman/listinfo/bittorrent
> > >
> > _______________________________________________
> > BitTorrent mailing list
> > BitTorrent at lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/bittorrent
> >
> _______________________________________________
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/bittorrent
>



More information about the BitTorrent mailing list