I think it's sad that they're using SHA-1 for this. SHA-1 is a bit weak, and the hashes are too short. There's a reason that SHA-1 is deprecated for X.509 certificates.<p>At the very least, this should use SHA-256.<p>If they really did it right, though, the protocol would use a secure tree hash. The construction they're using has trivial collisions, which are only avoided because the size of the file comes from a trusted source. A good hash (e.g. the Sakura construction) doesn't have this problem. Fixing that would make the resulting torrent files or URLs a bit shorter, as the size could potentially be omitted.
Hash trees are pretty cool. For some fancier uses, see the Peer to Peer Streaming Protocol (PPSP), which is authored by the libswift/tribler guys.<p><a href="https://datatracker.ietf.org/wg/ppsp/documents/" rel="nofollow">https://datatracker.ietf.org/wg/ppsp/documents/</a><p>Basically, instead of the stream source having to sign every single new chunk (so peers can verify that they're getting the right data), the source signs subtree hashes of the new data and slowly builds up a larger hash tree. Once the stream is over, the complete hash tree is instantly seedable by anybody in the original stream.
Very similar to IPFS's merkle DAG and seems like a critical element of getting content centric networking projects like Bitorrent, Inc's Project Malestrom up and running
ipfs uses exactly the same strategy to distribute content via the hash of their root merkleDAG node. <a href="http://ipfs.io" rel="nofollow">http://ipfs.io</a>
"Large torrent files put a strain on the Web servers distributing them".<p>Finally! bittorrent designers are acknowledging the centralized deficiency in the torrent protocol and implementing Merkle / root hash distribution model, as eDonkey / eMule used since 2000's:<p><a href="https://en.wikipedia.org/wiki/Ed2k_URI_scheme#eD2k_hash_algorithm" rel="nofollow">https://en.wikipedia.org/wiki/Ed2k_URI_scheme#eD2k_hash_algo...</a><p>15 years later, everything old is new again.