I think other torrent developers will be more kind towards Tixati's new protocols if he renames them to

v3 = v1.5 and

v3.1 = v1.8

I mean this is the best way to put it considering the documentations presented by Tixati itself.

I followed up on your earlier point about how the newer protocol versions are classified and asked a Tribler developer, and their view seems to line up with what you said.

From what I understand, Tixati protocols v3 and v3.1 are more like extensions or iterative updates to protocol v1, rather than completely new protocol frameworks like BEP52 ( https://bittorrent.org/beps/bep_0052.html  ).

So from that perspective, it might be more accurate, at least in terms of naming and documentation, to treat them as incremental updates, like part of a v1.x series, instead of calling them entirely new versions.

I2P developer confirms they will not move forward with this implementation until and unless a BEP is submitted via official https://bittorrent.org/beps/bep_0000.html  or https://github.com/bittorrent/bittorrent.org/pulls

Well, the ball in now in Tixati developer's court, if he wants this feature adopted widely or not.

One thing I don't like about "v3" is how it is presented in the Tixati client.
Calling v2 "old" and hiding it is a bit disingenuous, especially since "v3" is just v1 with extra steps.

Backwards compatibility is one thing, but it changes the infohash anyway.

My man, as a layman, I did whatever I could do to convince all torrent developers to implement v3. Now, it is your turn to explain to developers. I think they need some developer talks to understand the things that a layman cannot tell them or layman does not understand itself.
You need to now, take up the mantle and come out to solve developer's confusion or doubts or whatever they have. https://github.com/arvidn/libtorrent/issues/8047#issuecomment-4105702173

BEP v3.1 still not avaialble and neither is BEP v3, on BitTorrent GitHub.

My opinion as a normal user (quick thoughts, hopefully I'm not wrong about anything): I think both the v3 and v3.1 protocols are brilliant, but should be done and named differently. I think the security improvement in v3 and v3.1 is critical, so the approach of implementing it in a backwards-compatible way is correct compared to the approach of waiting for v2 to be adopted more broadly. I like that there's a way to specify the cryptographic hash algorithms, instead of having a hardcoded algorithm. I think v2's property of allowing recognizing identical files across different torrents is a groundbreaker for potentially better longevity for torrents and saving disk space for users.

I think v3 should be called an extension of v1, or call it v1.5 (because of the major improvement it brings, rather than v1.1 for example which doesn't do justice with the improvement). When creating a new seed, it could show as a sub-checkbox under v1 saying something like "Augment with secure metadata (fully backwards compatible). Exclusive to Tixati." The latter comment could be dropped when it would become an official standard.

Since v3.1 is incompatible with v1 and v2, and seems to me on a quick read to be incompatible with v3 too, I don't understand why it was built on top of v3/v1, instead of v2. Furthermore, since it's incompatible with the other protocols, and I suggest renaming the current v3 protocol away to another name/number, I think it makes sense to add all the innovations from the current v3.1 on top of v2, and call the result v3.

Ignoring hybrid torrents, this would result in having:
1. Insecure v1 (current v1, hidden by default for security)
2. v1 with security (current v3)
3. v2 (current v2)
4. v3 (a result of taking current v2 and adding current v3.1 innovations (including those also of current v3, e.g. cryptographic agility) on top).

Since neither v3 nor v3.1 are standardized yet, it isn't too late to rename them.

In any case, thank you

Has this project been abandoned??

No, this has not been abandoned. The Dev is just busy right now getting the new version ready for release.

@janet
Is this a new version of the protocol, torrent client, or BEP proposal?

-TLTMAA

A new version of the program. The Dev is still planning on submitting the BEP for v3 and v3.1, but Tixati v3.43 will be released first.

v3 torrent works fine on private trackers by many other bt client. many pt sites prohibit v2 torrent only allow v1 torrent

v3 works because it is built on top of v1, so there is only one info-hash, which is v1-only.

Problem is that nobody in bittorrent, libtorrent, qbittorrent, biglybt, trasnmission. i2psnark, tribler etc.. nobody is willing to implement it.

First of all, NO BEP on GitHub or BitTorrent website. DEveloper is not at all interested in creating a BEP in GitHub there have been many holidays and free time developer has had since the day this issue was created and up until 11 june 2026. He did not do it because he does not want to, as simple as that.

SEcondly, NAMING SCHEME. Libtorrent developer has mentioned that it is not entirely new technology like v2 torrent is, so basically it is v1 and therefore, there is no need to complicate of increase bytesize or some other technical word he used . So, he says instead of adding two three things which differentiates between v1 and v3, why not just use v1 as there have been no known cases of publicly clashing Info-hashes in torrenting world, especially that of public trackers.

I think as users have said and pointed out that since BEP has not been submitted this gives Developer opportunity to rename it to something like v1.5 or something along the lines of this, rather than claiming entirely new version.

In the end, I just want the developer to have some serious thoughts about it. Even if he does not want to change the naming scheme he has to sublit BEP or atleast talk to other torrent client or torrent library developers to mass adopt v3 or it is just an obscure torrent client with not much userbase to make any dent whatsoever in the world of v1 or v2 protocol.

I've posted here before as a Guest but wanted to provide this comment without hiding behind anonymity.

My three comments:

2026/02/24 06:26:55 PM
2026/03/31 07:37:34 PM
2026/05/23 01:25:57 AM (TLTMAA/Too Lazy To Make An Account)

-----------------------------------------

@KH
I just wanted to say that I appreciate the work you and your team put into this project because this is what decentralization is all about. Even if these protocols never become part of the official BEP, you still have a working product and people are using it.

If you wouldn't mind a little constructive criticism, these are my concerns.

The framing
In the Tixati client (v3.44) the description for BitTorrent v2 is "This is an old protocol that is not in common use and is not recommended".
The description is a little dishonest given v2 was first implemented in 2020, and v1 was implemented in 2001. While true that it is not in common use, calling it old is factually incorrect.

The option to create v2 is hidden by default, that is your UX choice which is fine but the framing makes it feel like your "v3" is new architecture when it isn't.
New hashing algorithms aside, it's the same data layout as v1 which uses flat pieces and not merkle roots or something else.

The version number
I've seen various posts that github user @absolutep, who appears to be a guest in this thread, created about implementing these protocols and a fair few reclassify it as a v1 extension rather than a protocol evolution. It doesn't seem like you are willing to have a conversation around changing the name, but it is a conversation that is needed.

Internally in my project, I call them tx3 and tx3.1, but I'm not ready to talk about it yet. I classify them that way because they are third-party protocols at the moment, so I will refer to them as such going forward unless you have another version tag.
Personally, I suggest calling your "v3" => v1.4 and "v3.1" => v1.5 as v1.5 adds hashing agility to v1 style torrents while removing sha1, and v1.4 is the bridge.
I also recommend separating the DHT privacy into it's own proposal. Keeping it mandatory for tx3.1 but allowing it to be used with any BitTorrent protocol version would be quite handy.

Dictionary names
Nit-pick (can't be changed now) but using uppercase for the algorithm specifiers is going against the grain when everything else in a torrent is often lower case.
Ex. SHA3-256 instead of sha3-256.

Conclusion
At the end of the day, I don't think you need the support of other clients because yours works.
I can create a tx3 or tx3.1 torrent and connect to peers right now. So take a round of applause because not everybody pulls through!

However, if you DO want others to implement it, or even just talk about it, then we need a BEP or at least something in the pull request list, even if that's where it lives. I know it's difficult when people are having a hard time accepting it, but if we don't have a proposal then it will forever be third party.

And even if it stays third party, that doesn't stop others from implementing it themselves. I certainly am.

Also, the last Guest that posted (2026/06/11 08:02:29 AM) is a little dramatic. I'm sure that was very encouraging and boosted your confidence. /s

---------------------------------------------------------------------------

For reference, these were my previous comments in this thread:

-----------------------------------------
by Guest on 2026/02/24 06:26:55 PM

Are you doing a pull request?

-----------------------------------------
by Guest on 2026/03/31 07:37:34 PM

One thing I don't like about "v3" is how it is presented in the Tixati client.
Calling v2 "old" and hiding it is a bit disingenuous, especially since "v3" is just v1 with extra steps.

Backwards compatibility is one thing, but it changes the infohash anyway.

-----------------------------------------
by Guest on 2026/05/23 01:25:57 AM

@janet
Is this a new version of the protocol, torrent client, or BEP proposal?

-TLTMAA

-----------------------------------------

I'm one of the people that commented in this thread. I wrote my comment after reviewing both the v3 and v3.1 specs of Tixati. While reviewing them, I thought of the possible reasons for the design choices in them. The specs don't specify the reasons, but after reviewing them, I came to conclusion that their design is solid (but I'm not a cryptographer). As part of reviewing them, I understood something that I see misunderstood in this thread by other people:

(Note that the following explanations may contain inaccuracies.)

For everyone suggesting DHT privacy to be split away from the protocol into an optional extension, please understand that that would defeat the purpose of having DHT privacy. This is why: When you connect to other peers, which you don't have any way to authenticate in advance (they're complete strangers to you), how would you know if they support DHT privacy— ask them and trust their answer? So obviously, DHT privacy cannot be enabled opportunistically (so if a peer says they don't support DHT privacy, then stop the connection instead of continuing without DHT privacy), as that would defeat the purpose of having DHT privacy. It should also be possible to prevent downgrade attacks (so when you fetch the info-map for a torrent which should hypothetically have DHT privacy working for it, your client should be able to detect when the peers/trackers you communicate with are giving you info-map that was stripped of the DHT privacy enablement bit). All of this can be achieved by a client feature that enforces DHT privacy extension to be supported when connecting to peers/trackers/etc, but it still gives them the ability to plausibly deny that the torrent ever had DHT privacy enabled in the first place, or deny that they received the torrent with DHT privacy enabled (and thus plausibly deny that they stripped it out because they lack proper support for the DHT privacy extension). If this wasn't prevented, users who enable the optional enforcement of DHT privacy and see no peers would ask themselves “what if this torrent never had DHT privacy enabled for it, and I'm isolating myself from the peers seeding it now?”, and they'd simply disable the feature. To prevent this, enabling DHT privacy must affect the torrent's info-map, and therefore its infohash, which means enabling DHT privacy must result in a new torrent that's not backwards compatible. This means that it must be implemented as part of a new protocol version that isn't backwards compatible; a benign v1-only client seeing the infohash of a torrent that has DHT privacy enabled would (and must) be unable to load it. Users encountering a torrent or a magnet link that have DHT privacy enabled will know for sure that it was created with DHT privacy enabled, and its seeders can be confidently expected to support DHT privacy, or confidently not establish connection with them. (DHT privacy must assume that clients/users are benign, because a malicious client/user that knows the full infohash intending to violate DHT privacy of a torrent with DHT privacy enabled can just publicize the torrent somewhere, e.g. on a popular publicly viewable website. Backwards compatibility must be broken with v1 to prevent users from accidentally loading a torrent with DHT privacy enabled in an old client that would then transmit/expose the true infohash just like v1 does.)

This is also why double hashing & truncation of the infohash in most places is mandatory in v3.1 (which doesn't reduce security), unlike in v3 where the additional v3-added strong hash can optionally be truncated (the infohash being used is still the v1-compatible SHA1 hash, so v1-only clients could load v3 torrents successfully, and the v1 and v3 swarms could cooperate).
It works because:
1. If the user already has the full info-map of the torrent, they have all necessary info to calculate the full infohash from it.
2. If the user has a magnet link without having the full info-map of the torrent, the magnet link is required to have non-double hashed non-truncated infohash, so the client has the necessary full infohash to securely recognize the full info-map of the torrent (robust against maliciously tampered info-map that matches only a truncated infohash but not the full one).

All BitTorrent traffic in v3.1 seems to never transmit the full secure infohash of a torrent, it requires the client to already know either it (e.g. from a magnet link) or the full info-map (e.g. from a .torrent file) from another place. The “double hashing” seems to be really just a hashed infohash, it's only “double” because the infohash is itself a hash of something, and that's only because that's what BitTorrent works with. Hashing the infohash is done because v3.1 treats the infohash as a secret piece of data that shouldn't be exposed in raw form, similar to how (generally speaking) computer/network passwords are hashed because passwords are considered secret. All connections are required in v3.1 to be encrypted; it seems that the encryption is authenticated based on a hash of the non-truncated infohash (so the result retains the security of the full infohash because of the lack of truncation), to prevent an attacker who doesn't already know the full infohash (which is considered secret) from doing a Man-in-the-Middle attack to decrypt the connection, without exposing the true infohash. It's also unseparably mixed with a random nonce, to prevent replay attacks where an attacker listens on the outside of a proper encrypted connection being established between two peers who know the true infohash, and then later replays one of the peer's messages to the other peer in a Man-in-the-Middle attack between them and successfully establishes the connection.