Add support for BitTorrent Protocol Version 3 and 3.1

deekerman commented

2026-02-22 03:45:17 -05:00

Owner

Originally created by @absolutep on GitHub (Oct 24, 2025).

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 qBittorrent would enhance security and compatibility with modern torrents.

Key specifications:

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

Upstream link with libtorrent = https://github.com/arvidn/libtorrent/issues/8047

Use case

No response

Extra info/examples/attachments

No response

Originally created by @absolutep on GitHub (Oct 24, 2025). ### 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 qBittorrent would enhance security and compatibility with modern torrents. ### Key specifications: 1. [Protocol Version 3](https://tixati.com/specs/bittorrent/v3) 2. [Protocol Version 3.1](https://tixati.com/specs/bittorrent/v3.1) 3. [Full BitTorrent Specification](https://tixati.com/specs/bittorrent) If these changes align with qBittorrent's scope, implementation in an upcoming release would be appreciated. Upstream link with libtorrent = https://github.com/arvidn/libtorrent/issues/8047 ### Use case _No response_ ### Extra info/examples/attachments _No response_

deekerman added the

Feature request

Waiting upstream

labels

2026-02-22 03:45:17 -05:00

deekerman commented

2026-02-22 03:45:20 -05:00

Author

Owner

@glassez commented on GitHub (Oct 24, 2025):

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

AFAIK, official BitTorrent specification proposals are placed on https://bittorrent.org/beps/bep_0000.html and there are no such proposals there. So it seems that they are Tixati's private stuff for now.
Anyway it is responsibility of libtorrent to implement it first.

@glassez commented on GitHub (Oct 24, 2025): > Tixati's developer has proposed updates to the BitTorrent protocol, starting with Version 3 and extended in Version 3.1. AFAIK, official BitTorrent specification proposals are placed on https://bittorrent.org/beps/bep_0000.html and there are no such proposals there. So it seems that they are Tixati's private stuff for now. Anyway it is responsibility of libtorrent to implement it first.

deekerman commented

2026-02-22 03:45:21 -05:00

Author

Owner

@absolutep commented on GitHub (Nov 8, 2025):

Tixati has implemented version 3 and version 3.1 in their new release v3.39.
Please, check If these changes align with qBittorrent's scope, implementation etc, Thank you.

@absolutep commented on GitHub (Nov 8, 2025): Tixati has implemented version 3 and version 3.1 in [their new release v3.39](https://tixati.com/news). Please, check If these changes align with qBittorrent's scope, implementation etc, Thank you.

deekerman commented

2026-02-22 03:45:21 -05:00

Author

Owner

@xavier2k6 commented on GitHub (Nov 8, 2025):

@absolutep https://github.com/qbittorrent/qBittorrent/issues/23421#issuecomment-3442247581 & indeed https://github.com/arvidn/libtorrent/issues/8047#issuecomment-3456269551 still hold weight here.

Until the proposed/proprietary protocols implemented by Tixati become "OFFICIALLY ACCEPTED BEP STANDARD(S)/RECEIVE DRAFT STATUS" it's highly unlikely that support for same will be implemented any time soon.

EDIT:
I suggest that you make contact with Tixati's maintainers to suggest the they formally propose these protocols through the correct channels.

@xavier2k6 commented on GitHub (Nov 8, 2025): @absolutep https://github.com/qbittorrent/qBittorrent/issues/23421#issuecomment-3442247581 & indeed https://github.com/arvidn/libtorrent/issues/8047#issuecomment-3456269551 still hold weight here. Until the proposed/proprietary protocols implemented by `Tixati` become **"OFFICIALLY ACCEPTED BEP STANDARD(S)/RECEIVE DRAFT STATUS"** it's highly unlikely that support for same will be implemented any time soon. EDIT: I suggest that you make contact with `Tixati's` maintainers to suggest the they formally propose these protocols through the correct channels.

deekerman commented

2026-02-22 03:45:21 -05:00

Author

Owner

@absolutep commented on GitHub (Nov 8, 2025):

@absolutep #23421 (comment) & indeed arvidn/libtorrent#8047 (comment) still hold weight here.

Until the proposed/proprietary protocols implemented by Tixati become "OFFICIALLY ACCEPTED BEP STANDARD(S)/RECEIVE DRAFT STATUS" it's highly unlikely that support for same will be implemented any time soon.

EDIT: I suggest that you make contact with Tixati's maintainers to suggest the they formally propose these protocols through the correct channels.

DONE

@absolutep commented on GitHub (Nov 8, 2025): > [@absolutep](https://github.com/absolutep) [#23421 (comment)](https://github.com/qbittorrent/qBittorrent/issues/23421#issuecomment-3442247581) & indeed [arvidn/libtorrent#8047 (comment)](https://github.com/arvidn/libtorrent/issues/8047#issuecomment-3456269551) still hold weight here. > > Until the proposed/proprietary protocols implemented by `Tixati` become **"OFFICIALLY ACCEPTED BEP STANDARD(S)/RECEIVE DRAFT STATUS"** it's highly unlikely that support for same will be implemented any time soon. > > EDIT: I suggest that you make contact with `Tixati's` maintainers to suggest the they formally propose these protocols through the correct channels. **DONE** <img width="1673" height="617" alt="Image" src="https://github.com/user-attachments/assets/2cc31803-1853-448d-9592-fcd70edd3db0" />

deekerman commented

2026-02-22 03:45:21 -05:00

Author

Owner

@i990049 commented on GitHub (Nov 9, 2025):

I suggest to add libp2p protocol and BTFS 4.0 to encry the transfer, media library app support it. libtorrent won't accept and enable new protocol as default, such as webtorrent/webRTC protocol is still disable in libtorrent 2.x. May be libp2p protocol can be install as option just like uTP.

@i990049 commented on GitHub (Nov 9, 2025): I suggest to add libp2p protocol and BTFS 4.0 to encry the transfer, media library app support it. libtorrent won't accept and enable new protocol as default, such as webtorrent/webRTC protocol is still disable in libtorrent 2.x. May be libp2p protocol can be install as option just like uTP.

deekerman commented

2026-02-22 03:45:21 -05:00

Author

Owner

@absolutep commented on GitHub (Nov 9, 2025):

I suggest to add libp2p protocol and BTFS 4.0 to encry the transfer, media library app support it. libtorrent won't accept and enable new protocol as default, such as webtorrent/webRTC protocol is still disable in libtorrent 2.x. May be libp2p protocol can be install as option just like uTP.

@i990049 I think you are looking for something similar to Fopnu [alive & maintained], RetroShare [alive & maintained] or MuWire [defunct] - all three of which are not exactly torrent clients but contain whole suite of things, that are completely unrelated to torrents and not really in the scope of/functinality/aim of torrent clients..

@absolutep commented on GitHub (Nov 9, 2025): > I suggest to add libp2p protocol and BTFS 4.0 to encry the transfer, media library app support it. libtorrent won't accept and enable new protocol as default, such as webtorrent/webRTC protocol is still disable in libtorrent 2.x. May be libp2p protocol can be install as option just like uTP. @i990049 I think you are looking for something similar to [Fopnu](https://www.fopnu.com/) [alive & maintained], [RetroShare](https://github.com/RetroShare/RetroShare) [alive & maintained] or MuWire [defunct] - all three of which are not exactly torrent clients but contain whole suite of things, that are completely unrelated to torrents and not really in the scope of/functinality/aim of torrent clients..

deekerman commented

2026-02-22 03:45:21 -05:00

Author

Owner

@i990049 commented on GitHub (Nov 9, 2025):

@absolutep Bittorrent is constantly evolving. Initially, the creator of bittorrent did not have the PEX LSD uTP protocol. In the past years, bittorrent has incorporated these protocols, including webRTC. Since some people feel that RC4 is outdated and libtorrent doesn't want to adopt the AES protocol, and some people feel that qb still does not support NAT 4 symmetric punching, why not use BTFS 4.0 and lipp2p?
https://github.com/Mythologyli/qBittorrent-NAT-TCP-Hole-Punching

i990049
@.***

@i990049 commented on GitHub (Nov 9, 2025): @absolutep Bittorrent is constantly evolving. Initially, the creator of bittorrent did not have the PEX LSD uTP protocol. In the past years, bittorrent has incorporated these protocols, including webRTC. Since some people feel that RC4 is outdated and libtorrent doesn't want to adopt the AES protocol, and some people feel that qb still does not support NAT 4 symmetric punching, why not use BTFS 4.0 and lipp2p? https://github.com/Mythologyli/qBittorrent-NAT-TCP-Hole-Punching i990049 ***@***.***

deekerman commented

2026-02-22 03:45:21 -05:00

Author

Owner

@absolutep commented on GitHub (Jan 6, 2026):

Update = https://forum.tixati.com/support/8586

@absolutep commented on GitHub (Jan 6, 2026): Update = https://forum.tixati.com/support/8586 <img width="1833" height="429" alt="Image" src="https://github.com/user-attachments/assets/76f81b34-0e52-489c-a442-a244a0183f47" />

deekerman commented

2026-02-22 03:45:22 -05:00

Author

Owner

@absolutep commented on GitHub (Feb 4, 2026):

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:

============================================================================================

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.

@absolutep commented on GitHub (Feb 4, 2026): 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.

deekerman commented

2026-02-22 03:45:22 -05:00

Author

Owner

@xavier2k6 commented on GitHub (Feb 4, 2026):

@absolutep Please provide the source for the info in https://github.com/qbittorrent/qBittorrent/issues/23421#issuecomment-3846138699

Also, there's no BEP/Draft BEP officially submitted for consideration.

@xavier2k6 commented on GitHub (Feb 4, 2026): @absolutep Please provide the source for the info in https://github.com/qbittorrent/qBittorrent/issues/23421#issuecomment-3846138699 Also, there's no BEP/Draft BEP officially submitted for consideration.

deekerman commented

2026-02-22 03:45:22 -05:00

Author

Owner

@absolutep commented on GitHub (Feb 5, 2026):

@absolutep Please provide the source for the info in #23421 (comment)

Also, there's no BEP/Draft BEP officially submitted for consideration.

BEP = https://tixati.com/specs/bittorrent/bep-v3.html

Documentation = https://tixati.com/specs/bittorrent/v3

Public Forum Discussion = https://forum.tixati.com/support/8586

@absolutep commented on GitHub (Feb 5, 2026): > [@absolutep](https://github.com/absolutep) Please provide the source for the info in [#23421 (comment)](https://github.com/qbittorrent/qBittorrent/issues/23421#issuecomment-3846138699) > > Also, there's no BEP/Draft BEP officially submitted for consideration. **BEP** = https://tixati.com/specs/bittorrent/bep-v3.html **Documentation** = https://tixati.com/specs/bittorrent/v3 **Public Forum Discussion** = https://forum.tixati.com/support/8586

deekerman commented

2026-02-22 03:45:22 -05:00

Author

Owner

@xavier2k6 commented on GitHub (Feb 5, 2026):

None of those have been formally submitted through the proper channels.

https://bittorrent.org/beps/bep_0000.html

@xavier2k6 commented on GitHub (Feb 5, 2026): None of those have been formally submitted through the proper channels. https://bittorrent.org/beps/bep_0000.html

Rows
Columns

Add support for BitTorrent Protocol Version 3 and 3.1 #17259

Suggestion

Key specifications:

Use case

Extra info/examples/attachments

Backward Compatibility

Frequently Asked Questions

Why not just use BEP 52 (v2) "Hybrid" torrents?

Does info_pow make torrent creation too slow for users?

1. Hybrid v1+v2 torrents do create fragmented swarms

So in practice:

Why v3 improves this

2. v3 enables true simultaneous seeding across versions

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)

Current ecosystem reality

v3’s advantage

This addresses a practical deployment concern that protocol purists often ignore.