Live data from Hacker News

BitTorrent v2 (2020)

blog.libtorrent.org

101–110 of 155 posts

Re: BitTorrent v2 (2020)

#101
post #85

From a technical perspective, I love BitTorrent. I remember reading about it years ago and being amazed at the bandwidth efficiency and robustness it had. It still had some centralization (ie trackers) but they themselves could be duplicated (ie you could set up a tracker for an existing torrent). The part that surprises me from reading this is the issues raised from moving from SHA1 to SHA256, specifically because t…

The choice to use SHA256 is surprising to me given that there are a number of other hash functions such as the BLAKE family that are explicitly designed to have arbitrary output sizes.

Re: BitTorrent v2 (2020)

#102

BitTorrent slaps so hard as a protocol, and DHTs are absolutely brilliant. With all of the recent hype about decentralization with the rise of crypto, I'm surprised BitTorrent hasn't seen much hype or revitalization as well.

Now that I think about it, BitTorrent is the best example of how well decentralisation can work, and basically the only reason I believe that a decentralised web is possible.

Unfortunately BitTorrent is still heavily centralized when it comes to discoverability. Without a website hosting .torrent files or magnet links, it's very limited.

Re: BitTorrent v2 (2020)

#103
post #58

Earlier quoted context omitted.

SHA1 collision was never much of a reason to change it in the first place; there is no practical attack that arises from it.

1) Take a popular game torrent 2) add crypto mining code 3) pad it so the SHA1 stays the same 4) seed it, the magnet links will pick up your version 5) profit!

Except that this is not how collision attacks work.

Re: BitTorrent v2 (2020)

#104

Earlier quoted context omitted.

A bunch of open-source projects would like to use v2 torrents, but because Transmission is so popular and has zero support for v2, nobody can use them. Transmission's dev team hasn't said a word on the matter, ever, in four years: https://github.com/transmission/transmission/issues/458 Elsewhere someone quipped: > That transmission bug is 4 years old and they've never announced plans to prioritize it (granted the eff…

In the beginning I used µTorrent, until it got fucked by whatever company that bought it. It was easily the fastest and most resource-smart client I've ever used. After that I tried a bunch, Deluge, Transmission, Azure and plenty more, but only qBittorrent seems to be a suitable replacement (and is open source as well). Now it has BitTorrent V2 support too :) You should really give it a try.

I just use the version of µTorrent before the company was sold.

Re: BitTorrent v2 (2020)

#105
post #39

Earlier quoted context omitted.

> My take from reading that is in 2016 there was practical collision attacks demonstrated No such thing happened. You're likely referring to this paper quoted in Wikipedia: https://eprint.iacr.org/2016/374.pdf This is 1. not about SHA256, but about the truncated sha2 algorithms and, more important, 2. it's an attack on reduced-round versions of these algorithms. That's a common thing in cryptoanalysis to do. You're b…

Absolutely, you are correct - the papers does not describe SHA256 as broken, but it is one step of many on the path for SHA256 to become broken in the future - which is in reply to your earlier comment: > You're proposing to add extra complexity for some hypothetical scenario that is unlikely to happen

I do not believe that the practical demonstration of a sha1 collision by google contributed at all to any potential future break of sha256.

Re: BitTorrent v2 (2020)

#106
post #101
post #85

From a technical perspective, I love BitTorrent. I remember reading about it years ago and being amazed at the bandwidth efficiency and robustness it had. It still had some centralization (ie trackers) but they themselves could be duplicated (ie you could set up a tracker for an existing torrent). The part that surprises me from reading this is the issues raised from moving from SHA1 to SHA256, specifically because t…

The choice to use SHA256 is surprising to me given that there are a number of other hash functions such as the BLAKE family that are explicitly designed to have arbitrary output sizes.

This feature of the (newer?) members of the BLAKE family would not help at all in this case.

Re: BitTorrent v2 (2020)

#107

BitTorrent slaps so hard as a protocol, and DHTs are absolutely brilliant. With all of the recent hype about decentralization with the rise of crypto, I'm surprised BitTorrent hasn't seen much hype or revitalization as well.

I'm not surprised. BitTorrent just works, and doesn't provide any opportunity to separate people from their money.

It kind of does if you choose to seed stuff that is ripe for DMCA takedowns/copyright infringement, right?

That's not the protocol's fault, but it's pretty much one of the biggest reasons most common people use the protocol: to pirate.

Get caught pirating? Probably get some fines, right?

Re: BitTorrent v2 (2020)

#108

The per file hash to assist in deduplication is pretty neat. Wonder if it could be taken a step further by chunking files into blocks based on a rolling hash, so that it can dedup portions of a file as well (a la lbfs https://pdos.csail.mit.edu/archive/lbfs/ ). Or does anyone know if it already does that?

It is highly unlikely that the duplicate portions of the file will have an offset that's a multiple of 2^16 which would be required for chunks to have matching hashes. On the client side you could theoretically run lbfs over your files but on the swarm side this isn't going to happen

Re: BitTorrent v2 (2020)

#110
post #85

From a technical perspective, I love BitTorrent. I remember reading about it years ago and being amazed at the bandwidth efficiency and robustness it had. It still had some centralization (ie trackers) but they themselves could be duplicated (ie you could set up a tracker for an existing torrent). The part that surprises me from reading this is the issues raised from moving from SHA1 to SHA256, specifically because t…

BitTorrent isn't particularly efficient; a well-designed CDN beats it every time, and is pretty cheap these days. (Generally, you get random peers, not peers that are particularly close to you. You could try to fix that, but you'd quickly end up with second-order problems around e.g. which peers have which chunks.) Which is precisely why you're not seeing much adoption outside the warez scene—they're the only ones for which that kind of decentralization is more important than reliable, fast downloads.
Post reply on HN