Live data from Hacker News

BitTorrent v2

blog.libtorrent.org

81–90 of 576 posts

Re: BitTorrent v2

#81

It feels like this isn't a large enough leap forward. It would be nice if BitTorrent v2 made it harder for ISPs to identify what is bit torrent traffic. AT&T artificially slows down upload speeds.

Why would the that be the protocol's responsibility?

I'd assume that a protocol that gets faster for files the more nodes who use it and the faster those nodes transmit would try to solve real world issues stopping more nodes/faster speeds from those nodes.

The word 'responsibility' that you used is of course too strong a word, however the comment 'it would be nice' to have is definitely true assuming we want downloads to be faster.

Re: BitTorrent v2

#82
post #79
post #71

SHA1 has a collision, so now it uses SHA256. How long until a SHA256 collision? Shouldn't the new protocol just add support for many modern hash functions, and client updates can disable support for hashes that become insecure later? Or does this introduce its own headaches? That's what SSH does, right?

I don't think anyone is expecting a sha256 collision in the next 20 years. The crypto doesn't seem to leave much wiggle room for exploitation.

Don't people always say exactly that? What are the chances of a collision if we simultaneously use multiple hashes, does it become significantly less likely?

Re: BitTorrent v2

#83
I make P2P tools too. [0] Let me tell you this: Bittorrent is one of the few things in the space that actually ... works.

It works not in the sense that there is a white paper that should work. Not in the sense that there are a few company-made swarms hosted on industrial servers that keep everyone up and alive, so that the thing gives the impression the 'P2P' network does work. Not in the sense that there is a very-well oiled marketing machinery talking about Web 3.0 that allows its founder to go on TechCrunch and talk about the upcoming distributed paradise.

Bittorrent works in the way you install it into your computer and it does something for you. And for that alone, it has my immense respect and attention.

It's a tool that doesn't pitch that it's a P2P tool - it doesn't try to convince you with sob stories about how using P2P helps fight against the big bad evil web. Instead, you use it because it's genuinely the best at what it does: it being P2P is not a selling point, it's just how it happens to work, and that is exactly what it should be.

That is something all P2P developers should aspire towards.

[0] Aether P2P: https://getaether.net

Re: BitTorrent v2

#84

Earlier quoted context omitted.

Collisions in the context of bittorrent are not a big deal. We could (and will, there are millions of torrents around that will never be updated) keep using SHA1 and the world is not going to end.

It isn't? Is it not possible to be tricked into downloading a malicious binary that you then execute on your computer?

Unlike the Photoshop 2020 WareZ Cracked Unlocked 2020 Xvid Torrentz WZ FUN.torrent, that I just downloaded

Re: BitTorrent v2

#85
post #71

SHA1 has a collision, so now it uses SHA256. How long until a SHA256 collision? Shouldn't the new protocol just add support for many modern hash functions, and client updates can disable support for hashes that become insecure later? Or does this introduce its own headaches? That's what SSH does, right?

Collisions in the context of bittorrent are not a big deal. We could (and will, there are millions of torrents around that will never be updated) keep using SHA1 and the world is not going to end.

They aren’t? So someone can craft a payload that contains a rootkit or similar and has the same name and hash as the thing you wanted, and this is okay? (Disclaimer: I don’t know all that much about how hashes are used internal to the protocol)

Re: BitTorrent v2

#86
post #72

There are a few things I wish this addressed, but it doesn't. Off the top of my head: 1. the new hash function is going to be broken eventually - what happens then? 2. support for "remixes". It would be nice to reference pieces from another torrent. Example use case: adding subtitles for a movie. Right now it requires either downloading the "main" version of the movie and getting the subtitles externally, or sharing…

> Identical files will always have the same hash and can more easily be moved from one torrent to another (when creating torrents) without having to re-hash anything. Files that are identical can also more easily be identified across different swarms, since their root hash only depends on the content of the file.

Re: BitTorrent v2

#87

Earlier quoted context omitted.

Uploading parts of illegal files is equivalent from a security perspective. It seems like there's no advantage to your proposal. The Whonix wiki has an incredible amount of information on topics such as this: https://www.whonix.org/wiki/Documentation Basically, it's very hard to protect the security of users when a government seeks to prosecute dissidents. There's a lot to take into account. A simple "we saw an uploa…

One change in the v2 protocol stands out here. "Files that are identical can also more easily be identified across different swarms". Would this per file hash not make it easier for such a government to find illegal material shared by users. It appears v2 is not suitable for sharing of material which could get one in trouble.

.zip

Re: BitTorrent v2

#88

Very interesting. But I'm not totally clear -- what does this mean for compatibility with v1? The article states that hybrid torrents that support v1 and v2 can be created. But what does this mean for end-users (clients)? Will most torrent software be upgraded to support both v1 and v2? And will a client be forced to choose from the v1 or v2 swarm, or will it be able to download from and seed to both? I mean it seems…

A v2-aware client that also supported v1 and hybrid torrents would tick all boxes and be able to participate in multiple swarms (for the same torrent). The main issue that I see is the existence of millions of torrents in private trackers that would have to be manually updated for v2. Are people going to bother? I think not. So for me, v2 is practically a new-torrents-only affair.

I think this is fine. Slow migration is often the right choice. The important part is to start early, and in a decade maybe the vast majority of torrents will be V2.

Re: BitTorrent v2

#89
post #71

SHA1 has a collision, so now it uses SHA256. How long until a SHA256 collision? Shouldn't the new protocol just add support for many modern hash functions, and client updates can disable support for hashes that become insecure later? Or does this introduce its own headaches? That's what SSH does, right?

> How long until a SHA256 collision

Very unlikely that this is going to happen any time soon.

Most modern symmetric cryptographic primitives with sizes >=256 bits are considered safe even against quantum computers. SHA256 turned out to be even stronger than expected. SHA-3 adoption is delayed in many protocols because there is no much need for it and hw implementations for SHA256 are commonplace.

Re: BitTorrent v2

#90
What is the current relationship between BitTorrent Inc, which I think developed the original BT v1 protocol and client, and Libtorrent? Which I think was a 3rd party BT Library written in C++ because the official version was in Python which was resources hungry.
Post reply on HN