Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The BitTorrent Protocol Specification v2

bittorrent.org

Post reply on HN
Print view View original

91–100 of 114 posts

Re: The BitTorrent Protocol Specification v2

#91

Post by boyce »

wongarsu wrote: post #87
boyce wrote: post #68

Earlier quoted context omitted.

I think there's still potential to steer BT in a more exciting direction if there was the will to from those involved. More quality software projects using it to download by default. Bring the trust back, shake off the reputation for just being trojan-infested cracks. There's plenty of things besides piracy people could be doing with torrents and related tech and it seems like such a waste of an idea. A Linux package…

Updates for large software (mostly games) is often distributed via BT. But it's mostly invisible to the end user because the client just does it transparently.

Well there's a start (but the bittorrent people should shout about those sorts of uses)

Re: The BitTorrent Protocol Specification v2

#92

Post by pwg »

kyberias wrote: post #61
StreamBright wrote: post #47

Earlier quoted context omitted.

Sorry I am not sure why is that. Would you mind explaining?

uTorrent used to be really efficient, small memory-footprint, full featured bittorrent-client. One of the best software I've ever used to download... perfectly legal content [1] from the internets. Now it's full of ads and performs poorly. [1] Like all the different Linux distro install images over and over again.

Take a look at rtorrent: https://github.com/rakshasa/rtorrent

It fits the efficient, small memory-footprint and no ads requirements. "Full Featured" is subjective as it depends upon what you consider "Full Featured".

Re: The BitTorrent Protocol Specification v2

#93

Post by snakeanus »

baby wrote: post #65
mtgx wrote: post #41

Earlier quoted context omitted.

Intel has recently implemented SHA1 in hardware. So give it another decade or so.

hopefully SHA-3 (or better, the Keccak permutation) is implemented in hardware first.

> SHA-3 (or better, the Keccak permutation)

SHA-3 is just Keccak with specific capacities. If you mean that they should not implement only the standard SHA-3 functions then I agree, having c/raw/SHAKE256 as well would be nice.

Re: The BitTorrent Protocol Specification v2

#94

Post by snakeanus »

Scaevolus wrote: post #16

1) 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…

Since support for Merkle trees is being added, does that mean that it could allow for someone who seeds a torrent to also seed a shared file of a peer that leeches a different torrent?

Re: The BitTorrent Protocol Specification v2

#95

Post by snakeanus »

redm wrote: post #81

I just don't see this technology ever going mainstream. I first deployed this type of application in 2003. It was named Redswoosh and did effectively the same thing as BitTorrent, just in a closed client. I was also a very early adopter of BitTorrent using it personally. Users hated it for general use, even when downloading big files. 1) They didn't like having to install/run some special software to download a file.…

> I just don't see this technology ever going mainstream

It already is though.

Re: The BitTorrent Protocol Specification v2

#96

Post by snakeanus »

the8472 wrote: post #57
nenreme wrote: post #55

Earlier quoted context omitted.

You download 32 bytes hash and check it using 20 byte hash from the magnet link.

http://bittorrent.org/beps/bep_0009.html#magnet-uri-format

Is there any plan to allow base64, longer hashes and selecting the hash algorithm in the magnet uri format?

Re: The BitTorrent Protocol Specification v2

#97

Post by snakeanus »

sha2throwaway wrote: post #38
userbinator wrote: post #15

Earlier quoted context omitted.

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. [0] https://en.wikipedia.org/wiki/Length_extension_attack

Length extension attacks are a non-issue for torrents.

Re: The BitTorrent Protocol Specification v2

#98

Post by the8472 »

snakeanus wrote: post #96
the8472 wrote: post #57

Earlier quoted context omitted.

http://bittorrent.org/beps/bep_0009.html#magnet-uri-format

Is there any plan to allow base64, longer hashes and selecting the hash algorithm in the magnet uri format?

No such plans. What would be the motivation anyway? A different hash function for the infohash calculation wouldn't change anything since other parts of the protocol would still use sha256 (v2) or sha1 (v1). So if this is about security, you wouldn't be changing the weakest link.

Not to mention that this would not be compatible with other peers, there is no algorithm-negotiation in the network protocols, so how would they know which hash you're using? The magnet link is pretty much the far end of the process, you'd have to change a lot of other things first.

Re: The BitTorrent Protocol Specification v2

#99

Post by Scaevolus »

the8472 wrote: post #56
Scaevolus wrote: post #39

Earlier quoted context omitted.

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 s…

v1: O(path-depth * number of files + number of bytes) v2: O(log(path-depth) * number of files) that is assuming some constantish branching factor in your directory structure > Merkle tree roots will only be unique for each piece length. Merkle trees are independent of piece size, which means you can use them to dedup across torrents.

Oh, neat! I missed the part where larger piece sizes correspond to higher layers of the tree.

Presumably clients still reconstruct (and store, somewhere) the full Merkle tree to do incremental validation and support queries.

Re: The BitTorrent Protocol Specification v2

#100

Post by dandelion_lover »

boyce wrote: post #46
jzelinskie wrote: post #6

This 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…

I'd love to see a p2p wikipedia and a p2p twitter alternative Moving bittorrent away from it's present image could be achieved by making p2p useful beyond bluray rips

> p2p twitter alternative

here you go https://en.wikipedia.org/wiki/Twister_%28software%29

Post reply on HN