4 ms·
Unless I'm mistaken, we'd need to settle on a "default" piece size[1] if we were to have automatic upgrading in a client. I learned recently[2] that there's no
by xd1936 5y ago
Unless I'm mistaken, we'd need to settle on a "default" piece size[1] if we were to have automatic upgrading in a client. I learned recently[2] that there's no standard set by the protocol, so Client A might choose a 16KiB piece size, and Client B might take the same files and choose a 64KiB piece size, resulting in two different hashes (v1 or v2!) and thus two peer pools for the same file set.
1. https://stackoverflow.com/a/65299426/2700296 https://stackoverflow.com/a/65299426/2700296
2. https://github.com/webtorrent/magnet-uri/pull/43#issuecomment-731381969 https://github.com/webtorrent/magnet-uri/pull/43#issuecommen...
- nodja 5y agoIf I read the article correctly in v2 each file will contain its own root hash, which is calculated by using 16KB "pieces", the piece size for the torrent creation is still used for data transmission between peers and integrity checks.
- chasil 5y agoI'm not sure if the the piece side continues to have bearing when the hashes are all in a Merkle tree on uniform 16k blocks. "Enforcing these encodings also help make it more likely that two people creating a torrent from the same files, end up with the same info-hash and the same torrent." In the discussion of backwards compatibility, it appears that v1 collections of identical content encoded with different piece sizes will all become the same v2 collection when upgraded.
- j16sdiz 5y agoIf you have a v1 torrent file, you can’t download from a upgraded client