Live data from Hacker News

BitTorrent v2 (2020)

blog.libtorrent.org

11–20 of 155 posts

Re: BitTorrent v2 (2020)

#11
post #3

The wikipedia page doesn't say - do clients generally support this protocol now? https://en.wikipedia.org/wiki/Comparison_of_BitTorrent_clien...

First bullet on qBittorent's changelog for v4.4.0 is that they do. So I'm sure it's rolling out quickly to others. v4.4.0 changelog: FEATURE: Support for v2 torrents along with libtorrent 2.0.x support (glassez, Chocobo1) - https://www.qbittorrent.org/news.php

[deleted]

Re: BitTorrent v2 (2020)

#13
post #4
post #2

https://news.ycombinator.com/item?id=24401999 - 2020, 1227 points, 562 comments

i do love that it immediately goes into yet another crypto bashing comment chain while not realising that a crypto company owns bittorrent: https://torrentfreak.com/bittorrent-inc-confirms-acquisition... and that after the creator of bittorrent left he created his own cryptocurrency: https://en.m.wikipedia.org/wiki/Chia_(cryptocurrency)

That “crypto bashing comment chain” is just as relevant today as it was when it was posted 16 months ago.

People are still struggling to articulate a legitimate use case for cryptocurrencies.

I made some money mining BTC way back in the day with a GPU. I bought a new computer for $1,900 last year and much more than paid for it mining ETH. I’ve spent years now listening to all the claims from BTC, BCH, BSV and a dozen more coins and web3 proponents. But I’ll be damned if I can articulate a legitimate use for it that is better than what we have today or that doesn’t fail to take human nature into consideration.

Re: BitTorrent v2 (2020)

#14

I‘m wondering if they could avoid yet another breaking protocol change if SHA256 proves to be insecure (at some point in the future) if they made use of Multiformats [0]. At least IPFS went this way (Multiformats grew out of the IPFS development). [0] https://multiformats.io/

>if SHA256 proves to be insecure

slight pedantism here, but "when" not "if"

Re: BitTorrent v2 (2020)

#15

I‘m wondering if they could avoid yet another breaking protocol change if SHA256 proves to be insecure (at some point in the future) if they made use of Multiformats [0]. At least IPFS went this way (Multiformats grew out of the IPFS development). [0] https://multiformats.io/

You're proposing to add extra complexity for some hypothetical scenario that is unlikely to happen. That's a bad tradeoff.

Re: BitTorrent v2 (2020)

#16
post #15

I‘m wondering if they could avoid yet another breaking protocol change if SHA256 proves to be insecure (at some point in the future) if they made use of Multiformats [0]. At least IPFS went this way (Multiformats grew out of the IPFS development). [0] https://multiformats.io/

You're proposing to add extra complexity for some hypothetical scenario that is unlikely to happen. That's a bad tradeoff.

unlikely ? all methods are broken eventualy when compute becomes faster

Re: BitTorrent v2 (2020)

#17

I‘m wondering if they could avoid yet another breaking protocol change if SHA256 proves to be insecure (at some point in the future) if they made use of Multiformats [0]. At least IPFS went this way (Multiformats grew out of the IPFS development). [0] https://multiformats.io/

>if SHA256 proves to be insecure slight pedantism here, but "when" not "if"

That's not a given. As far as I know, there is no proof of the security or lack thereof of this kind of function.

Increases in computing power alone can't render SHA256 insecure; that can be proven by thermodynamic/size-of-the-universe arguments. You need an actual cryptographic weakness.

Re: BitTorrent v2 (2020)

#18

I‘m wondering if they could avoid yet another breaking protocol change if SHA256 proves to be insecure (at some point in the future) if they made use of Multiformats [0]. At least IPFS went this way (Multiformats grew out of the IPFS development). [0] https://multiformats.io/

>if SHA256 proves to be insecure slight pedantism here, but "when" not "if"

There's no indication whatsoever of this happening.

In the time since SHA1 came under attack, a lot more research has happened on hash function security. If this has shown anything, it's that SHA256 is more secure than people used to think.

People seem to have this widely believed idea that "all crypto will be broken eventually". But in pretty much all cases you can trace back that broken crypto was known to be weak for a long time. SHA256 is not known to be weak (with the slight caveat that it doesn't protect against length extension attacks, but this is a known property that matters only in very rare circumstances).

Re: BitTorrent v2 (2020)

#19
post #16
post #15

Earlier quoted context omitted.

You're proposing to add extra complexity for some hypothetical scenario that is unlikely to happen. That's a bad tradeoff.

unlikely ? all methods are broken eventualy when compute becomes faster

All current methods. Isn’t sha256 an order of magnitude more complex than sha1? It’s not like cryptographers can’t learn from their mistakes.

Re: BitTorrent v2 (2020)

#20
post #16
post #15

Earlier quoted context omitted.

You're proposing to add extra complexity for some hypothetical scenario that is unlikely to happen. That's a bad tradeoff.

unlikely ? all methods are broken eventualy when compute becomes faster

Computers can only become faster within the limits of what humans are able to build and what physics allows.

You're not gonna break SHA256 with faster computers.

Post reply on HN