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.
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.