BitTorrent v2 (2020) • Hacker News Board

Re: BitTorrent v2 (2020)

#51

Post by WithinReason » Mon, Jan 10, 2022, 3:17 PM UTC

moolcool wrote: post #43

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.

Re: BitTorrent v2 (2020)

#52

Post by nudpiedo » Mon, Jan 10, 2022, 3:18 PM UTC

moolcool wrote: post #43

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.

The project it's still in pre-alpha, it even stopped paying rewards to its token stakers/seeders due some technical issues during the implementation. Perhaps it just rushed onto it too fast just to catch the hype.

Re: BitTorrent v2 (2020)

#53

Post by noodlesUK » Mon, Jan 10, 2022, 3:20 PM UTC

dennis-tra wrote: post #12

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/

Generally speaking this is called “cryptographic agility” and the security community has decided that it’s an antipattern. The alternative is to have a specified suite of security mechanisms pinned to each version. You can still have backwards compatibility, but it helps avoid downgrade attacks.

Re: BitTorrent v2 (2020)

#54

Post by pbronez » Mon, Jan 10, 2022, 3:27 PM UTC

banana_giraffe wrote: post #44

muldvarp wrote: post #42

Earlier quoted context omitted.

Which tracker is this data from?

It's from a DHT/BitTorrent crawler that runs around downloading all the torrent metadata it can find I've been running for ages.

cool. Did you write it yourself or are you using an open source project of some kind? Would be interested to run one of these myself.

Re: BitTorrent v2 (2020)

#55

Post by sitkack » Mon, Jan 10, 2022, 3:28 PM UTC

banana_giraffe wrote: post #44

muldvarp wrote: post #42

Earlier quoted context omitted.

Which tracker is this data from?

It's from a DHT/BitTorrent crawler that runs around downloading all the torrent metadata it can find I've been running for ages.

Do you make visualizations of the traffic?

Re: BitTorrent v2 (2020)

#56

Post by cyphar » Mon, Jan 10, 2022, 3:33 PM UTC

noodlesUK wrote: post #53

dennis-tra wrote: post #12

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/

Generally speaking this is called “cryptographic agility” and the security community has decided that it’s an antipattern. The alternative is to have a specified suite of security mechanisms pinned to each version. You can still have backwards compatibility, but it helps avoid downgrade attacks.

Multiformats is not really cryptographic agility, it's just adding a small tag that indicates what type of data something is (what kind of encoding, what kind of hash, what kind of binary payload, etc). The benefit is that the tags are standardised rather than being tied to a protocol version or some other out-of-band information. Whether or not you start making negotiation decisions based on that header is what determines whether you have cryptographic agility.

I'm also not sure I'd say the security community as a whole feels that cryptographic agility is an anti-pattern, there are plenty of vocal voices on all sides of that argument. I personally agree that you gain very little from cryptographic agility but have to pay a fair amount, but I don't think it's as settled as you make it out to be.

Re: BitTorrent v2 (2020)

#57

Post by iqanq » Mon, Jan 10, 2022, 3:33 PM UTC

hffftz wrote: post #47

digianarchist wrote: post #31

Earlier quoted context omitted.

That’s what the “past” button does.

Why are there always people linking to previous discussions then? Including dang himself...

They were doing it for you because you didn't know about that button. But now that you do, they will stop doing it.

Re: BitTorrent v2 (2020)

#58

Post by Stevvo » Mon, Jan 10, 2022, 3:33 PM UTC

dennis-tra wrote: post #12

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/

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

Re: BitTorrent v2 (2020)

#59

Post by wombat-man » Mon, Jan 10, 2022, 3:34 PM UTC

moolcool wrote: post #43

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.

This is part of why I'm a bit cynical about "web 3" in general. Bittorrent is terrific and yet the real money is streaming video/music platforms.

Re: BitTorrent v2 (2020)

#60

Post by XzetaU8 » Mon, Jan 10, 2022, 3:39 PM UTC

kzrdude wrote: post #3

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

BiglyBT was the first Torrent client with v2 support

[1] https://torrentfreak.com/biglybt-is-the-first-torrent-client...

[2] https://www.biglybt.com/