Hybrid Torrents Are Not "Bloated v1" — Here's Why

[ezhouwei]

Hybrid Torrents Are Not "Bloated v1" — Here's Why

This post is based on a detailed discussion in the libtorrent repository:
arvidn/libtorrent#8940

Core point: A hybrid torrent's v2 capability is negotiated at the connection layer and is independent of whether you connect to the v2 Swarm.

1. What Is a Hybrid Torrent?

A Hybrid Torrent is a torrent file that contains both BitTorrent v1 (SHA-1) and BitTorrent v2 (SHA-256) metadata.

• It has two Info Hashes:
  • v1: 20-byte SHA-1
  • v2: 32-byte SHA-256
• It therefore corresponds to two Swarms: Trackers and DHT index by Info Hash separately, so a hybrid torrent forms two independent peer discovery pools on the network: a v1 Swarm and a v2 Swarm.
• At the client level, libtorrent manages it as one task, uniformly maintaining the file list, progress, and resume data.

2. A Hybrid Torrent Is Not a Bloated v1 Torrent

Many community discussions describe a hybrid torrent as “just a more bloated v1 torrent.” This is wrong.

The fact is: a hybrid torrent has full v2 capability at the connection layer.

As long as two clients both support v2 during the handshake (negotiated via the 0x10 bit in the reserved[7] byte), the connection automatically upgrades to a v2 connection:

• It uses 16 KiB block-level SHA-256 verification instead of v1's SHA-1 piece verification.
• It supports Hash Request (BEP 52), which can request Merkle tree levels to speed up verification.
• Corruption recovery only requires redownloading a 16 KiB block, not an entire piece.

This upgrade happens after the connection is established and is unrelated to the Swarm. Even if you found the peer through the v1 Swarm, as long as both sides support v2, this connection will use v2 verification. A Tracker not supporting v2 does not affect this, because the Tracker is only responsible for peer discovery and does not participate in post-connection protocol negotiation.

3. The Real Relationship Between the Two Swarms

A hybrid torrent does have two Swarms, but the client's default behavior is:

• Announce to both v1 and v2 Trackers (if the Tracker supports v2).
• Connect to peers in both Swarms at the same time.

So by default, you are active in the intersection of the two Swarms and can reach as many peers as possible.

Why does "prioritize v2 Swarm" split the network?

Because it means letting the client participate only in the v2 Swarm and abandon the v1 Swarm. At the current stage, when v2 peer density is still very low, this puts the client into a smaller, quieter Swarm, reducing connection count and download speed. libtorrent author Arvid Norberg explicitly questioned the necessity of this approach.

4. Local Optimization: disable_v1_hashes

libtorrent 2.1.0 introduced an option: disable_v1_hashes.

• It only affects local computation: it lets the client skip v1 SHA-1 hash calculation and verification in a hybrid torrent, relying only on v2's 16 KiB block-level SHA-256 verification.
• It does not change any network behavior: the client still announces to v1 Trackers, still connects to v1 peers, and still participates in the v1 Swarm.
• Its benefits are: saving CPU and reducing disk reads.

This is the optimization direction that should be promoted for hybrid torrents, not "prioritize v2 Swarm."

5. Limitations of Pure v2 and Advantages of Hybrid Torrents

Problems with pure v2 torrents at the current stage

• Most Trackers do not support v2, so pure v2 torrents are hard to discover.
• Pure v2 clients are extremely rare; publishing pure v2 means giving up the vast majority of peers.
• The exclusive value of pure v2 currently consists only of SHA-256 (plus smaller metadata and no padding files).

Advantages of hybrid torrents

• v1 compatibility: all old clients can download.
• v2 verification: clients that support v2 automatically upgrade connections between themselves, gaining SHA-256 and 16 KiB block-level verification.
• Root Hash retention: lays the foundation for future content addressing and cross-torrent deduplication, as detailed later.
• Paving the way for the future: even if the v1 ecosystem shrinks in the future, the v2 part of a hybrid torrent can still be discovered in the v2 Swarm and will not be lost.

6. Padding Files

Hybrid torrents generate padding files (BEP 47) to maintain compatibility with v1 piece alignment.

• Modern clients (qBittorrent 4.2+, etc.) automatically hide these padding files; they do not appear in the file list and are not downloaded or written to disk.
• Therefore, for ordinary users, padding files are basically unnoticeable.
• Only in old clients or certain online parsing tools might .pad files be visible.

7. Summary of Common Misconceptions

Misconception	Fact
A hybrid torrent is just a bloated v1 torrent	It has full v2 verification capability at the connection level
You must connect to the v2 Swarm to use v2	v2 capability is negotiated at the connection layer and is unrelated to the Swarm
Prioritizing the v2 Swarm is a good way to promote v2	It splits the network, reduces connection count, and is harmful at the current stage
The v2 part of a hybrid torrent is unused	As long as both sides support v2, the connection will use v2 verification
Pure v2 is the future, and hybrid torrents are only a transition	Hybrid torrents balance the present and the future and are the optimal solution at this stage

8. The Difference Between Private Trackers and Public BT Determines Promotion Priorities

Public BT: the main battlefield for hybrid torrents at the current stage

Public BT has higher acceptance of hybrid torrents, and size issues can be solved by adjusting piece size.

In a test, an 8 GB / 50-file hybrid torrent had an automatic piece size of 473 KB; when manually set to 2 MiB, it dropped to 245 KB. Mainstream public BT release sites (such as 1337x and TorrentGalaxy) generally tolerate .torrent files above 1 MB, so adjusting the piece size is usually enough to upload successfully.

Some public sites abroad already explicitly support hybrid torrents. Domestic public sites in China currently have relatively low acceptance, but there is no technical barrier.

PT: the barrier is not size, but whether it is allowed

At present, the adoption rate of pure v2 torrents on PT sites is almost zero, and hybrid torrents are also generally strictly restricted or even banned.

PT's core concerns are passkey authentication, traffic statistics, cross-seeding rules, and cheating detection—the dual Info Hash and two Swarms of a hybrid torrent interfere with these mechanisms.

So for PT, the problem is not "the torrent is too large to upload," but "the rules simply do not accept this format."

The focus of promotion should be on public BT

Public BT has higher acceptance of hybrid torrents, and size issues can also be solved by increasing the piece size. As long as hybrid torrents and v2 resources on public BT accumulate to a certain scale, the content stock of Root Hashes will grow, and only then will there be a foundation for a future content-addressing ecosystem.

PT can wait and see for now; after the public ecosystem matures and PT rules gradually adapt, it can then discuss following up.

Aspect	Public BT	Private Tracker (PT)
Acceptance of hybrid torrents	Relatively high	Generally restricted or banned
Main barrier	.torrent size, solvable by piece size	Rules: passkey, traffic statistics, cross-seeding, cheating detection
Current strategy	Prioritize promotion	Wait and see, follow existing rules

9. Info Hash Is the Shell, Root Hash Is the Core

Info Hash: metadata hash

Info Hash is a hash of the torrent's info dictionary, including fields such as name, piece length, pieces, and files.

As long as the top-level folder name, file order, or piece size differs even slightly, the Info Hash changes. It identifies "this torrent file," not "this file content."

Root Hash: content hash

Root Hash is the root hash of each file's independent Merkle tree, determined only by the file's own binary content.

The same file, no matter which torrent it appears in or what its Info Hash is, has exactly the same Root Hash.

Fundamental difference

• Info Hash era: resource discovery relies on the shell of the "torrent"; Swarms are divided by Info Hash, and cross-torrent data reuse is almost impossible.
• Root Hash era: resource discovery can rely directly on the "content" itself. Query DHT with a Root Hash and you can find all peers holding that file without knowing which torrent it belongs to.

The community proposed the idea of "using Root Hash as a DHT key for discovery" as early as 2018, but it has not been implemented to this day because the entire discovery layer (DHT, Trackers, client protocols) has been built around Info Hash for decades, and migration costs are high.

10. Longer Term: Torrent Containers Weaken, Content Hashes Dominate

Following this logic, the later it gets, the weaker the "torrent" becomes as a discovery entry point. More precisely, it is not that torrents no longer matter, but that torrents degrade from the core of discovery into a manifest container and compatibility shell.

This can be viewed in three layers:

• Discovery layer: the main method will shift from "finding a Swarm by Info Hash" to "finding content by Root Hash." If DHT, indexers, and content-addressing networks use Root Hash as the key directly, they can find the same file across torrents, releases, and Swarms.
• Manifest layer: some kind of manifest is still needed to describe the file list, directory structure, piece parameters, and which Root Hashes are included. It may no longer be a traditional .torrent, but the "manifest" itself will not disappear.
• Compatibility layer: Info Hash will exist for a long time, serving old clients, Trackers, DHT nodes, PT passkeys, traffic statistics, and cross-seeding rules. It is just that the main discovery and deduplication in the new ecosystem will no longer rely on it.

Therefore, the future division of labor is more likely to be:

Root Hash is responsible for "who the content is," the manifest is responsible for "how the content is organized," and Info Hash is responsible for "compatibility with the old world."

By then, the format war between hybrid torrents and pure v2 torrents will no longer matter. What truly matters is whether the content carries a Root Hash and whether the discovery layer can query it directly.

Hybrid torrents at the current stage are precisely accumulating content stock for this future.

Layer	Role in the future	Key
Discovery	Find content by Root Hash	Root Hash
Manifest	Describe how content is organized	Manifest
Compatibility	Serve old clients and PT rules	Info Hash

11. Conclusions and Recommendations

For content publishers

• At the current stage, publishing hybrid torrents is the most correct approach. It is compatible with all users while paving the way for v2 in the future.
• Do not publish only pure v1, as that loses v2 capability; do not publish only pure v2, as that loses most peers.
• Do not use a "prioritize v2 Swarm" strategy; keep the default behavior of participating in both Swarms.
• Prioritize hybrid torrents on public BT; on PT, follow existing rules and wait and see for now.

For ordinary users

• When you download a hybrid torrent, if you use a client that supports v2, you are already enjoying v2 verification capability, even if the connection was established through the v1 Swarm.
• Padding files are invisible to you; there is no need to worry about disk usage.
• You can pay attention to the disable_v1_hashes option, which can further optimize performance locally.

For the community

• It is necessary to clarify the fact that "hybrid torrent v2 capability takes effect at the connection layer" and eliminate the misconception that "you must connect to the v2 Swarm."
• Recommend publishing hybrid torrents rather than falling back to pure v1.
• Promote the accumulation of hybrid torrents and Root Hash content stock on public BT to lay the foundation for a future content-addressing ecosystem.

[KasperRavn]

Very interesting.