Live data from Hacker News

BitTorrent v2

blog.libtorrent.org

71–80 of 576 posts

Re: BitTorrent v2

#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?

Re: BitTorrent v2

#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 the file from scratch.

Re: BitTorrent v2

#73

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.

Re: BitTorrent v2

#74

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 don't ISPs bill by the gigabyte and be done with it?

Because their costs aren’t based on usage, but installing and maintaining the infrastructure then collecting rent on it. Actual usage is an exponential curve and if you bill on it you have a few angry users paying for everybody else’s infrastructure.

Re: BitTorrent v2

#75

Earlier quoted context omitted.

Why won't ISPs stop advertising 'unlimited' service that is actually limited to N gigabytes a month, where N is substantially lower than what's possible given the speeds they provide? Because they can get away with it.

Because it is insanely expensive to actually provide that. The nature of internet traffic is short bursts, not 100% utilization. In a commercial setting you can purchase fixed pipes that are entirely yours and they’re tens or hundreds of times more expensive. Why wouldn’t you want to pool bandwidth with your neighbors so you could all get faster speeds when you were using it instead of rate limiting everyone?

The issue is that there's no way to know what this limit is. I understand the cost, but then tell us exactly how many GB I can use at full speed and when does it start to throttle. Instead I have to rely on internet anecdotes.

Re: BitTorrent v2

#76
post #44
post #3

I've written a torrent client, and I'm skeptical than v2 will ever catch on. While it does solve some minor problems, it's not a large enough leap forward to justify the costs.

I don’t know much about protocol version pacing, but was lack of substantial changes part of the reason it has taken 12 full years to get a client to support v2? http://bittorrent.org/beps/bep_0052.html

No. It is still a draft proposal.

Re: BitTorrent v2

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

Re: BitTorrent v2

#78
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?

What if the hashes differ?

Re: BitTorrent v2

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

Re: BitTorrent v2

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

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