[bittorrent] Why are blocks smaller than pieces?

Ryan Walklin ryanwalklin at gmail.com
Mon Sep 10 02:53:27 EDT 2007


The trouble with this suggestion is that you'd fragment the network unless
it was implemented with backward compatibility, ie with an extended message
of some sort. MSE works well because there's a spectrum of compatibility vs
security, and the user can choose what level of privacy they want.

I don't think that finding SHA1 collisions in 2^69 invalidate its use as a
simple data verification system, and as long as the only attack remains
brute-force, surely it's computationally infeasible to generate bad data
that passes hash checking, regardless of whether the piece comes from a
single peer or multiple peers.

On 9/10/07, Olaf van der Spek <olafvdspek at gmail.com> wrote:
>
> 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
> >
> _______________________________________________
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/bittorrent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20070910/b72939d8/attachment.html 


More information about the BitTorrent mailing list