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