SO what's the deal with bittorrent v2? What are the core changes that make it an improvement? I haven't heard much mentioned of it cuz I don't get out much anymore, but what's the deal?
Printable View
SO what's the deal with bittorrent v2? What are the core changes that make it an improvement? I haven't heard much mentioned of it cuz I don't get out much anymore, but what's the deal?
I wrote this on another forum.
Quote:
Here's an easy to understand[citation needed] summary.
- All usage of the SHA-1 hash function is replaced by SHA-256, since a collision for the former was found three years ago, and therefore it is expected to become more insecure as the processing power available to potential adversaries (e.g. fake torrent uploaders) increases, even if no other vulnerabilities were discovered. Existing tracker and DHT implementations expect the 160-bit length of SHA-1, so the extra 96 bits are discarded to maintain compatibility with BitTorrent v1. Since its bigger digest size isn't the only factor making SHA-256 more secure, this is an acceptable compromise, and does not preclude the possibility of future extensions to accept full-length hashes.
- The use of hash trees makes .torrent files smaller (not life-changing, but nice), allows detecting bad data on a per-block basis (pieces are divided in 16 KB blocks irrespective of their size) which means faster detection of "bad" peers and less wasted bandwidth, and most importantly, since there's a hash tree for each file, it will now be possible to find and share identical files across different swarms with 100% reliability. This last bit of functionality has been attempted over the years, notably by BiglyBT's swarm merging but also in BitComet, Shareaza and TuoTu, yet since all we had to work with were (potentially non-unique) file names and sizes, it relied on assumptions and a little luck. This should improve retention by, in principle, allowing those who have the same files on different torrents to transparently cross-seed to each other, and is a very welcome change as far as I'm concerned. I'm not sure how much private trackers would like such a thing, as it would cause mismatched traffic reports on the torrents involved, similar to what occurs when people cross-seed incorrectly by adding multiple announce URLs and then get banned for "fake upload"... but clients could simply disallow it for torrents with the private flag set.
- Path names inside metadata are deduplicated. For torrents with tons of small files across many subdirectories (unpacked games, image sets) this should result in a big performance boost: smaller .torrent files and less stuff to parse.
- There will be much less leeway regarding non-standard piece sizes or representations of bencoded data, in the interest of following the specification as tightly as possible and avoiding undefined behavior (gray areas), but this is not something that most people will be affected by or even notice.
The bolded part is very exciting! One of my biggest pet peeves is massive amounts of wasted bandwidth on bad peers! Has v2 already been implemented in the big clients?Quote:
Originally Posted by anon
You must be unlucky, as hashfails are generally rare; my client says I've had 9 over 28 large torrents since this month started. Also, it should be noted that while my previous post uses "wasted" in the generic sense of the word, BitTorrent makes a distinction between hashfails and wasted data: the former includes pieces that don't pass the integrity check, and peers that send those too often get IP-banned, whereas the latter are blocks that arrived "too late" or had to be discarded due to poor connectivity (or because you closed your client), and bans are not issued for that.Quote:
Originally Posted by Intr4ns1t
Anyway, the most exciting part for me was "since there's a hash tree for each file, it will now be possible to find and share identical files across different swarms with 100% reliability". Imagine torrents that don't die despite technically having 0 seeders, because others are still seeding the same files in another release or pack. Feels like a feature that should have been there since the beginning :(
BiglyBT was the first to present a complete implementation. libtorrent-rasterbar also supports it, which means clients based on it can also do so when/if they choose to (the mere fact the underlying library supports it doesn't automatically accomplish that).Quote:
Has v2 already been implemented in the big clients?
As usual for backward-incompatible extensions to a very established protocol, I expect initial adoption to be slow, with a long transition phase (sort of like IPv6, but hopefully less long than that). Hybrid torrents help a great deal on this regard, but don't negate the fact v2 torrents have a different info_hash and therefore separate swarms. And don't forget the hardcore uTorrent 2.2.1 and qBittorrent 3.x.x crowd, I don't see them rushing to upgrade...
I managed to force myself up to the qbit 4.x.x series for my qbit instances, but I do have a couple instances of old utor too :P
To be fair, there are two areas uTorrent 2.2.1 excels at and newer versions don't: interface usability and being able to seed several thousand torrents without breaking. Still, I wouldn't feel comfortable exposing a program that's over a decade old and has known security vulnerabilities to the world. Also, no support for large pieces, large torrents or large .torrent files (but anyone who downloads that much is crazy anyway :P).
As a Windows user of a low-end computer, I find uTorrent 3.x to be the best or least bad choice available. Had high hopes for PicoTorrent, but given its current development pace, we may need to wait until 2028 until it has features beyond the bare essentials.