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

BitTorrent v2

blog.libtorrent.org

Post reply on HN
Print view View original

91–100 of 576 posts

Re: BitTorrent v2

#91

Post by selectodude »

jeromegv wrote: post #75
colechristensen wrote: post #64

Earlier quoted context omitted.

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.

They do. I'm pretty aware of what my data transfer limits are on both my home and wireless connections. Granted my new ISP has no data caps and symmetric gigabit speeds so I'm a bit spoiled.

Re: BitTorrent v2

#92

Post by CyberDildonics »

oblio wrote: post #26
mawalu wrote: post #19

Earlier quoted context omitted.

You mean beside being responsible for ~50% of the global internet traffic in 2009? https://en.wikipedia.org/wiki/BitTorrent

Yeah, but what's the current number? I'd be surprised if it were more than 5-10% these days. 2009 was 11 years ago, the internet was a much smaller and less regulated place.

You think that if something once took up 50% of all traffic on the internet it never found a practical application?

Re: BitTorrent v2

#93

Post by wmf »

smabie wrote: 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.

uTP seemed like a small improvement to me but it happened.

Re: BitTorrent v2

#94

Post by stingraycharles »

sleavey wrote: 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?

Isn’t the fact that OpenSSL et al allow so many arbitrary ciphers the reason of a whole load of problems?

Re: BitTorrent v2

#95

Post by singron »

draugadrotten wrote: post #27
sillysaurusx wrote: post #13

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.

I don't think this really matters in practice. The DHT is public and you can already scan it to find all the public torrents, all the files they contain, and what IPs are sharing them.

Re: BitTorrent v2

#97

Post by userbinator »

IshKebab wrote: post #42
smabie wrote: 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.

Yeah this definitely feels like a Python 2/3 type situation. They solved one minor issue but require the whole world to update. I'm not even convinced they couldn't have done it in a backwards compatible way. Why not stick with SHA-1 but also add SHA-256 for verification for clients that support it?

That's an interesting comparison, given that the first BitTorrent client was written in Python (2).

Re: BitTorrent v2

#98

Post by oauea »

armitron wrote: post #73
crazygringo wrote: post #47

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.

The sites could perform a bulk update for all their torrents if they so chose.

Re: BitTorrent v2

#99

Post by ksec »

smabie wrote: post #17
mhh__ wrote: post #12

Earlier quoted context omitted.

From the perspective of the client would it be a drop in replacement like changing a static library or a from the ground up rework?

If they used libtorrent, then it would be easy. If they wrote their own system, then it would require a moderate amount of work to chance to v2.

I am going to take a guess, Most people on Mac would be using transmission, and People on Windows would be using Classic Utorrent.

Both are not based on Libtorrent.

Re: BitTorrent v2

#100

Post by wmf »

p1mrx wrote: post #70
jayd16 wrote: post #24

Earlier quoted context omitted.

Ideally, you'd want to come up with some way to pack files such that many files share the same chunks. Perhaps you could make the act of sharing (all or most of the) legal and illegal files indistinguishable.

You could have a protocol where every block of the file is actually two "random" blocks XOR'd together, but this doesn't really work. If you create a new 1GB torrent, you'll need 1GB of new (never seen before) blocks with ~100% probability, so it will be obvious who's seeding the data. Or you could make the block size smaller (e.g. 1 bit) and tell the lawyers to piss off because 0 and 1 are public domain.

See https://www.scs.stanford.edu/~dm/home/papers/waldman:tangler... and https://ansuz.sooke.bc.ca/entry/23
Post reply on HN