[bittorrent] Why are blocks smaller than pieces?

Thad Ward coderjoe at grnet.com
Sun Sep 9 22:03:38 EDT 2007


The problem I see with this is that collisions on SHA1 are not that far
off, and you would be getting your verification hashes from an untrusted
source.

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
> 



More information about the BitTorrent mailing list