Pity we will never see a genuine version of uTorrent that will support it. That was a real loss.
The BitTorrent Protocol Specification v2
31–40 of 114 posts
Re: The BitTorrent Protocol Specification v2
#32Earlier quoted context omitted.
Huh, I didn't know that's the case for x86. My quick search suggests that support is still quite limited though, and none of my HW (1~4 yrs old) support it. I suppose by the time the spec is finalized and widely adopted HW-accelerated SHA256 would be, too (and I should switch my zfs checksum back from SHA512/256 to SHA256).
I haven't found any Intel hardware with the SHA extensions actually implemented. I was expecting it in Skylake but apparently that's not the case... Not sure when we can expect to see them.
Right now the most common x86 CPU which implements the SHA instructions is AMD's Ryzen. The only available Intel CPU which supports them is Goldmont, the latest generation of Atom CPU. It seems likely that Cannon Lake and possibly Coffee Lake will also implement them, but I haven't seen any rumors pointing one way or the other.
Re: The BitTorrent Protocol Specification v2
#33Pity we will never see a genuine version of uTorrent that will support it. That was a real loss.
We have plenty of good open source alternatives now. qTorrent works fine
Re: The BitTorrent Protocol Specification v2
#34Pity we will never see a genuine version of uTorrent that will support it. That was a real loss.
We have plenty of good open source alternatives now. qTorrent works fine
Thanks I haven't hear of that. And it is written in C++ which is nice.
Is it considered the spiritual successor to the original uTorrent?
Re: The BitTorrent Protocol Specification v2
#35This update to the spec is a modest change that's largely a preemptive reaction to SHA1 being broken; large portions of BitTorrent are designed around the 20-byte length of a SHA1 checksum. They've decided to move forward with SHA256 truncated to 20 bytes to avoid incompatibilities with existing infrastructure such as the Mainline DHT. Beyond the hashing algorithm, some important additions that were previously propos…
The DHT BEPs specify a network that is only barely related to the bittorrent core protocol, they can already be used independently, and some people do. > I feel like trackers were largely overlooked in this update, but I'm biased because I work on a popular tracker. Yes, we did not pay much attention to trackers, but BEP52 basically seized the opportunity to do some incompatible changes we always wanted to do anyway…
How do you intend to handle incompatibilities in the tracker protocol that are introduced by BEP52?
In particular, I note that there's nothing in there regarding which infohash should be used in the tracker updates. Should traffic with v1/v2 clients be reported separately, or should it be consolidated under the v2 infohash?
Re: The BitTorrent Protocol Specification v2
#36Earlier quoted context omitted.
We have plenty of good open source alternatives now. qTorrent works fine
Thanks I haven't hear of that. And it is written in C++ which is nice. Is it considered the spiritual successor to the original uTorrent?
it is:
>The qBittorrent project aims to provide an open-source software alternative to µTorrent.
though in my experience it is more of a memory hog and buggier than utorrent. but that doesn't stop me from using it
Re: The BitTorrent Protocol Specification v2
#37Earlier quoted context omitted.
We have plenty of good open source alternatives now. qTorrent works fine
Thanks I haven't hear of that. And it is written in C++ which is nice. Is it considered the spiritual successor to the original uTorrent?
I love qtorrent. They even have built in torrents search for various sites like TPB and Linux isos ;)
Re: The BitTorrent Protocol Specification v2
#38This update to the spec is a modest change that's largely a preemptive reaction to SHA1 being broken; large portions of BitTorrent are designed around the 20-byte length of a SHA1 checksum. They've decided to move forward with SHA256 truncated to 20 bytes to avoid incompatibilities with existing infrastructure such as the Mainline DHT. Beyond the hashing algorithm, some important additions that were previously propos…
SHA256 truncated to 20 bytes What are the security implications of doing this? It seems it wouldn't increase the strength beyond the original 160 bits, no? Was there anything preventing redesigning the protocol to use full 32-byte SHA256 hashes throughout?
Actually you do get some added security, because it prevents the length extension attacks sha-2 and related hash functions have thanks to the Merkle-Damgard construction [0]. Specifically, by truncating the hash, the output no longer contains enough state to perform the attack.
Re: The BitTorrent Protocol Specification v2
#391) Chunks don't span files . Each file is validated by the hash of its merkle tree. This is the biggest user-visible change, since it means you can download one file without downloading others. 2) SHA1 is replaced with SHA2-256 (2x longer hashes and not broken). 3) Files are represented by a tree structure instead of a list of dictionaries with paths-- this reduces duplication in deeply-nested hierarchies. 4) Backwar…
Per-file metadata increases significantly, but it gets rid of the per piece data (which in bittorrent v1 is 20 bytes of sha1 hash per piece and made up the bulk of the .torrent file). The .torrent file only stores the merkle tree's root hash for each file, and the torrent client will query it's peers to get the rest of the merkle tree (verifiable against the root hash). The leafs of the merkle tree are the hash of ea…
Right, in BitTorrent v1 the size of the .torrent file is O(number of files) + O(number of bytes), but with this it's just O(number of files) with a higher constant factor.
Piece size is still baked into the file (as piece length), and is used for presence bitsets, which are a crucial part of the swarm algorithm. Clients download the rarest pieces first to boost efficiency, and this information is handled as bitsets shared between clients indicating "I have chunk {1, 2, 3, ... 50, 52, ... }".
Merkle tree roots will only be unique for each piece length. Piece length should still correlate with total size, to prevent huge bitsets-- a 16KB piece length on a 64GB torrent would have a 4 million item / 500KB bitset (!), so it could take 500KB of RAM per connected peer to maintain state-- or maybe compressed bitsets make this problem irrelevant in practice?
Re: The BitTorrent Protocol Specification v2
#40This update to the spec is a modest change that's largely a preemptive reaction to SHA1 being broken; large portions of BitTorrent are designed around the 20-byte length of a SHA1 checksum. They've decided to move forward with SHA256 truncated to 20 bytes to avoid incompatibilities with existing infrastructure such as the Mainline DHT. Beyond the hashing algorithm, some important additions that were previously propos…
The word encryption doesn't even seem to be mentioned there. At the very least it would help against traffic shaping, which you know is coming once net neutrality rules are dead.