Backward Compatibility This protocol is fully backward compatible. V1-only clients: Ignore piece_hashes and info_pow as unknown keys, continuing to use SHA-1 for all operations. V3-aware clients: Verify info_pow first. Then use both the original SHA-1 hashes in pieces AND the hashes in piece_hashes for data integrity checks on each piece. Frequently Asked Questions Why not just use BEP 52 (v2) "Hybrid" torrents? Hybrid v1+v2 torrents still require "padding files" to align file boundaries with the Merkle tree structure. This complicates the torrent creation process and creates massive overhead in torrents that have a large number of small files. Also, to implement a client that correctly manages a v1 AND v2 swarm simultaneously, while keeping file data and state synchronized, is extremely difficult. V3.0 requires zero changes to underlying file data or alignment and is very easy to add to any existing client, without any major changes to program architecture. Does info_pow make torrent creation too slow for users? No. A typical difficulty of 20 bits takes less than a second on a modern CPU, but creates a massive cumulative barrier for an attacker. ===================================================================================================== 1. Hybrid v1+v2 torrents do create fragmented swarms This is a real, under-acknowledged problem, What actually happens with BEP-52 hybrids v1 peers discover each other via the v1 info-hash v2 peers discover each other via the v2 info-hash These swarms are logically distinct Data sharing between them is indirect at best and depends on a client acting as a bridge So in practice: A v2-only seeder cannot seed to v1-only leechers A v1-only seeder cannot seed to v2-only leechers Availability and swarm health are split : This is especially painful during long transition periods (which BitTorrent is famous for). Why v3 improves this v3 uses one v1-looking info-hash v1, v3, and v3-enhanced clients all participate in the same swarm No parallel DHTs, no duplicate trackers, no split peer sets ====================================================================================================== 2. v3 enables true simultaneous seeding across versions This is another legitimate advantage. With hybrid v1+v2 A client must: Track two info-hashes Maintain separate peer sets Translate piece state across two validation systems That’s hard, fragile, and easy to get wrong. With v3 v1 clients seed v3 data naturally v3 clients seed v1 data naturally No dual bookkeeping, no dual swarm logic This reinforces earlier point that: v3 is architecturally easy to add to existing clients related to swarm health, not just developer convenience. ============================================================================================ 3. Tracker and website reality (this one matters socially) This point is not theoretical — it’s about how BitTorrent is actually used today. Current ecosystem reality Many torrent websites: Accept only v1 torrents Index only the v1 info-hash Ignore or reject v2-only torrents Hybrid torrent downside The v2 info-hash is effectively invisible Users downloading via v2 rely on bridging behavior Tooling and moderation pipelines remain v1-centric v3’s advantage Single info-hash Fully compatible with existing websites, trackers, moderation tools No ecosystem-wide coordination required This addresses a practical deployment concern that protocol purists often ignore
