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

491–500 of 576 posts

Re: BitTorrent v2

#491

Post by webmaven »

hysan wrote: post #343
gkfasdfasdf wrote: post #268

Earlier quoted context omitted.

I think the answer to most of these questions is, let the market decide. E.g. consider this: congestion during peak hours is bad now, but there is currently no penalty on an ISP for being slow. However if billing was based on bytes moved, for an ISP to underserve during times of demand means lost revenue. Thus ISPs would be incentivized to provide the best service.

With respect to the US, this answer is incomplete. The theory of letting the market decide only works when there is a free market. Most places I’ve lived has only had a single choice for ISP effectively making them monopolies.

> With respect to the US, this answer is incomplete. The theory of letting the market decide only works when there is a free market. Most places I’ve lived has only had a single choice for ISP effectively making them monopolies.

Furthermore, even in places where you do have some sort of choice for internet service, it is almost certainly limited to choosing between a cable monopoly and a phone monopoly as your ISP.

Re: BitTorrent v2

#492

Post by yyyk »

ronyfadel wrote: post #443

Won't the "per-file hash trees" make it easy to detect copyright infringement? (i.e. the same .txt signature file of a release group)

Adding noise and/or padding is trivial, it would just be done on a per-file basis. Of course, this would also lose the protocol's identical file feature, but that's not a regression vs v1.

Re: BitTorrent v2

#493

Post by GoblinSlayer »

Spivak wrote: post #471
rezeroed wrote: post #460

Earlier quoted context omitted.

Presumably this is changing somewhat with so many people working from home.

I doubt working from home changes all that much. The pattern for most office workloads is still almost all pull. More VoIP is a not insignificant change but it still isn't the same kind of traffic that torrents put down.

Zoom sends videos and some managers even ask to show faces.

Re: BitTorrent v2

#494

Post by johnisgood »

loeg wrote: post #363
johnisgood wrote: post #235

Earlier quoted context omitted.

I see. Thank you! By the way, I have not thought much about it, so in case you may know: would not it be possible to implement this in a way that allows swapping the hash function? So for example when we run into issues with SHA-256, change the hash function to something else.

We already can: the "swap" will just be a v3 along the same lines.

Yeah, but would not they have to create v4, v5 and so forth every N years, for different hash functions?

Re: BitTorrent v2

#495

Post by johnisgood »

somedude11 wrote: post #411
johnisgood wrote: post #151

Earlier quoted context omitted.

Why not BLAKE3? I am really curious. I mean, since it exists, why not that over SHA256? Because it is relatively new?

SHA2 is hardware accelerated on many new CPUs, Blake family not so much.

I know, but according to the graphs, it is much more faster than SHA, despite hardware acceleration, so I am not sure.

Re: BitTorrent v2

#496

Post by upofadown »

__s wrote: post #307
throwaway2048 wrote: post #213

Earlier quoted context omitted.

sha1 is not meaningfully broken for BitTorrent, It would require a second pre-image attack to meaningfully hurt it, you can not take an existing hash you don't control and synthesize a matching set of incorrect/malicious data. Second preimage attacks are MUCH harder to pull off, even md5 is still safe from them, many years after they were found to be broken in other contexts. The only thing that sha1's weakness would…

The writing is on the wall, no need to wait for these attacks to actually exist before beginning migration

Everyone thought that for MD5...

Re: BitTorrent v2

#497

Post by tikiman163 »

rolleiflex wrote: post #83

I make P2P tools too. [0] Let me tell you this: Bittorrent is one of the few things in the space that actually ... works. It works not in the sense that there is a white paper that should work. Not in the sense that there are a few company-made swarms hosted on industrial servers that keep everyone up and alive, so that the thing gives the impression the 'P2P' network does work. Not in the sense that there is a very-…

There is something of an unpopular ideology in Computer Science that suggests that you shouldn't build architure to use cool tools, you should build the cheapest easiest architecture that meets the user's needs. This ideology is unpopular because using cheap and easy tools isn't exciting,and we developers often can't stand writing boring applications.

Quite a few projects are using P2P, machine learning, Kubernetes, No-Sql or block-chain not because the project actually requires scalability, decentralization, advanced data analysis or responsive big data, but because somebody got excited and refused to accept that it was a waste of time and money to do so.

Re: BitTorrent v2

#498

Post by ric2b »

porknubbins wrote: post #305
nicbou wrote: post #257

Earlier quoted context omitted.

It has been a few years, and despite a few attempts, I still don't really understand bitcoin. Yes yes ledgers and proof of work and yada yada, but I still don't know what I would need to do to buy something with bitcoin right now. As I understand I need to do something that's pretty much exactly like opening a bank account, but transactions take forever, they cost money, and the currency is not accepted by any busine…

The problem as I see it that it is nothing like opening a bank account... You don’t need to understand the banking system to use a bank account. Meanwhile normal people without a serious networking/distributed systems background will not really grasp what they are doing when using bitcoin and have to resort to googling steps and following them blindly. The fact that ETH gas prices are going through the roof because o…

> You don’t need to understand the banking system to use a bank account.

Same for Bitcoin, you install a wallet app and use it. It's actually much easier than opening a bank account.

> Meanwhile normal people without a serious networking/distributed systems background will not really grasp what they are doing

They won't grasp what they're doing on their bank account without a serious economic/financial/law background either.

Re: BitTorrent v2

#499

Post by the8472 »

Avamander wrote: post #457
samoa42 wrote: post #398

Earlier quoted context omitted.

why?

For multiple reasons. QUIC or HTTP/3 is going to be the next web standard widely deployed. Getting mandatory encrypted UDP traffic that looks like web is a big benefit. TFO recommendation primarily because torrenting is big, the feature is not super well-known, it would be a chance to increase its adoption, need for its support and that would benefit the web in general.

Bittorrent wouldn't benefit much from TFO because that would require a cookie from a previous connection to that remote client, which is unlikely to happen among random peers. Plus connection setup is not really a limiting factor for current use-cases. Some low-latency applications of bittorrent might benefit, but that requires specialized clients tuned for low latency throughout the stack, a single change won't do it. QUIC's encryption could be beneficial, but bittorrent-over-TLS would work equally well (not standardized, but libtorrent supports it). QUIC's stream multiplexing would not be all that useful either since bittorrent's maximum message size already is fairly small so clients can already interleave and prioritize control messages as needed. Bittorrent clients usually don't run on roaming (mobile) devices due to bandwidth limits, so QUIC's path migration probably doesn't provide much of a benefit either. Being UDP-based might make NAT-traversal a bit easier, but so does µTP.

If you want QUIC's congestion controller benefits then you can also get that with TCP if you're on linux. Set BBR as congestion controller and set the TCP_NOTSENT_LOWAT socket option and bittorrent should work well over long fat pipes (i.e. international peers).

I'm not saying QUIC is terrible, but it's mostly designed to improve web traffic. Bulk transfers à la bittorrent benefit only marginally if you have a modern TCP stack and use it properly.

Re: BitTorrent v2

#500

Post by oconnor663 »

johnisgood wrote: post #495
somedude11 wrote: post #411

Earlier quoted context omitted.

SHA2 is hardware accelerated on many new CPUs, Blake family not so much.

I know, but according to the graphs, it is much more faster than SHA, despite hardware acceleration, so I am not sure.

That depends on the platform, the size of the input, and whether multithreading is used.

On Ice Lake, where BLAKE3 benefits from AVX-512 and SHA-256 benefits from the SHA extensions, BLAKE3 seems to do better on both long and short messages. But maybe surprisingly, SHA-256 does better in a medium-length regime, where SHA-256's poorer startup time* has been mostly amortized out, but BLAKE3's chunk parallelism hasn't yet kicked in. See for example the 1536-byte results here: https://bench.cr.yp.to/results-hash.html#amd64-icelake . Using multithreading would exaggerate BLAKE3's advantage for very long messages (usually about 1 MiB and above), but it wouldn't improve the results for any of the message lengths measured there.

* I don't actually know where SHA-256's startup overhead comes from. Maybe someone who knows more could jump in here?

On ARM chips, the performance benefits of NEON are less dramatic than AVX-512, and the performance advantage of SHA-256 hardware acceleration is comparatively larger. I think it's rare for BLAKE3 to beat accelerated SHA-256 on ARM without at least some multithreading, but I've only personally benchmarked a few Raspberry Pis, and I want to be careful not to overgeneralize.

Post reply on HN