Add support for BitTorrent Protocol Version 3 and 3.1

BitComet BitComet Feature Requests
1

Suggestion

Tixati’s developer has proposed updates to the BitTorrent protocol, starting with Version 3 and extended in Version 3.1.

Version 3 focuses on retiring SHA-1 and integrating modern hash algorithms (e.g., SHA2-256, SHA3-256).

Version 3.1 builds on this with proof-of-work for info integrity, protections against DHT metadata sniffing, and enforced encryption in peer connections. These are extensions of the existing protocol, maintaining full backward compatibility.

Implementing these updates in BitComet would enhance security and ensure compatibility with modern torrents.

Key specifications:

  1. Protocol Version 3

  2. Protocol Version 3.1

  3. Full BitTorrent Specification

If these changes align with BitComet’s scope, implementation in an upcoming release would be appreciated.

2

Are there any clients besides Tixati that support these new specifications?

3

GitHub issues are open for most torrent clients so we will see them in upcoming versions

4

I will try to pass on this suggestion, I am not a BitComet developer.

5

Re: Protocol Version 3 Proposal (SHA-1 mitigation)

This feels like a lot of added complexity just to keep a dead hash function on life support. If SHA-1 is broken—and we all agree it is—the solution is to move to a modern primitive, not to wrap it in Proof-of-Work and truncated side-hashes.

A few immediate concerns from an implementation perspective:

  • Solving the wrong problem: We already have BEP 52 (v2). It switches to SHA-256 and uses Merkle trees to solve the piece-layer issues. This “v3” proposal seems to be trying to reinvent the wheel but with more moving parts. Why should we support a PoW scheme ($info_pow$) just to validate a legacy info-hash?
  • Canonicalization nightmare: Allowing arbitrary truncation widths (like SHA3-256-32) is a recipe for disaster. In a decentralized network, “optional” parameters usually result in clients being unable to talk to each other because they didn’t implement the same specific flavor of a hash truncation. It makes the protocol fragile for zero real-world gain.
  • Barriers to entry: BitTorrent works because creating a torrent is “free.” Introducing a 20-bit PoW might be fine for your desktop, but it’s a pointless tax on low-power NAS boxes, embedded seed boxes, and mobile clients. We shouldn’t be adding CPU cycles to the metadata layer without a massive payoff.
  • Privacy vs. Overhead: The info_check in v3.1 basically forces encryption and adds extra round-trips to the handshake. We already have MSE (Message Stream Encryption) for this. Adding a custom nonce exchange here just breaks compatibility with existing proxy setups and adds bloat to the wire protocol.
  • Where are the implementations? At the end of the day, a spec isn’t a standard until multiple independent clients implement it. Right now, this looks like a Tixati-only extension. Without broad consensus from the major libtorrent or BiglyBT maintainers, this just fragments the swarm further.

Bottom line: We should be spending our energy on the v2 transition, not building elaborate scaffolds to prop up SHA-1. This is protocol bloat, plain and simple.

6

I am copy pasting from Tixati.

BEP XXXX: BitTorrent Protocol Version 3.0

Author:

Kevin Hearn <kh@tixati.com>

Status:

Draft

Type:

Standard

Created:

04-Jan-2026

Abstract

This proposal describes BitTorrent Protocol v3.0, a set of backward-compatible extensions designed to address cryptographic weaknesses in the SHA-1 algorithm. It introduces the piece_hashes multi-hash verification system and an info_pow (Proof of Work) mechanism to prevent info-hash collision attacks.

Rationale

The original BitTorrent protocol (v1) relies exclusively on SHA-1 for piece verification and the info_hash. Recent cryptographic advancements have made finding SHA-1 collisions practical.

While BEP 52 (v2) introduced SHA-256 via Merkle trees, its adoption has been hampered by high implementation complexity. BEP 52 requires a total departure from the flat pieces structure, which is cumbersome for developers to integrate into existing legacy engines. It also mandates padding files, which cause excessive overhead in torrents that contain a large number of files.

BitTorrent v3.0 prioritizes implementability. By using an additive approach, developers can provide modern cryptographic security (SHA-2/SHA-3) without the architectural overhead of Merkle trees or padding files. This ensures a faster, lower-friction path to securing the BitTorrent ecosystem.

Specification

1. The piece_hashes Dictionary

A new key, piece_hashes, is added to the info dictionary. This allows a torrent to include high-security hashes in a flat format similar to the original protocol.

  • Key: piece_hashes

  • Value: A dictionary where keys are algorithm specifiers and values are the concatenated binary hashes for each piece.

  • Algorithm Specifiers: Standard strings such as SHA2-256 or SHA3-256. Specifiers may include a bit-width (e.g., SHA3-256-32 for 32-bit truncation). The bit-width must be a multiple of 8.

2. The info_pow (Proof of Work)

To prevent an attacker from generating two different info dictionaries that result in the same SHA-1 info_hash, a Proof of Work is required.

  • Key: info_pow

  • Value: A dictionary where keys are algorithm specifiers and values are the found binary hash with nonce appended.

  • Algorithm Specifiers: Standard strings such as SHA2-256 or SHA3-256 with a difficulty bit-width appended (e.g., SHA3-256-18 for 18 bits of leading zeros).

  • Hash A hash of the base hash and the nonce. The base hash is of the entire BEncoded info dictionary, with all hash+nonce values within the info_pow key zeroed.

  • Nonce This is the nonce that is concatenated to the base hash, which is then hashed again to produce the final hash, which must have adequate zero bits. The nonce can be any length, but generally 8 bytes is sufficient.

To generate:

  1. Select algorithms and difficulty levels based on available CPU resources. A good choice is SHA3-256-20 as it will take under a second to compute on low-power hardware yet is strong enough to make finding collisions very impractical.

  2. Write the info_pow entry into the info dictionary, with a value is a dictionary, containing algorithm specifiers as keys and zerod-out strings of correct length (hash width + 8 bytes of nonce) as values.

  3. For each algorithm, calculate the base hash of the BEncoded info dictionary.

  4. For each algorithm, calculate the hash of the base hash (in binary format) with nonce appended. Keep incrementing the nonce until the calculated hash has the required number of leading zero bits.

  5. For each algorithm, fill in the hash+nonce value in its corresponding info_pow sub-key.

To verify:

  1. Store, then zero out all hash+nonce values for each sub-key in the info_pow dictionary.

  2. For each algorithm, hash the BEncoded info dictionary to create the base hash, append the specified nonce onto the base hash, then calculate the final hash.

  3. Verify that the final hash matches the one specified, and that it has the required number of leading zero bits.

Security Considerations

Collision Resistance

By adding piece_hashes, the protocol moves to multi-hash validation. An attacker attempting a SHA-1 collision for a file piece would simultaneously need to collide the modern hash (e.g., SHA3-256) provided in the piece_hashes map, which is computationally infeasible.

Even when using a truncated hash, such as SHA3-256-32, the collision resistance is substantially improved. To succeed, an attacker must find a data block that yields the identical 160-bit SHA-1 hash AND the identical 32-bit SHA-3 fragment. This “AND” constraint makes finding malicious collisions computationally impractical.

Targeted Info-Hash Attacks

The info_pow mechanism forces an attacker to spend significant CPU time for every attempt to spoof an info-hash. This makes brute-forcing a collision expensive for malicious actors while remaining trivial for legitimate creators to generate during the initial torrent creation.

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.

References

Copyright

This document has been placed in the public domain.

7

copy pasting here :

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.