[bittorrent] Why are blocks smaller than pieces?

Ryan Walklin ryanwalklin at gmail.com
Sun Sep 9 23:23:13 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, 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.


Would it be feasible to generate same-length blocks that had the same SHA-1
hash? I thought the collision rate was still around 10^69?

I had an idea tiger-tree hashes were being raised as a "Bittorrent 2"
protocol, rather than an extension to the current protocol.

Ryan


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20070910/ad44f9e9/attachment.html 


More information about the BitTorrent mailing list