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

421–430 of 576 posts

Re: BitTorrent v2

#421

Post by xorcist »

nicbou wrote: post #257
dchuk wrote: post #208

Earlier quoted context omitted.

This is exactly the problem with all cryptocurrency currently. It’s a massive user experience issue, in the sense that users have to experience the technical bullshit of how the currencies work, completely missing the brilliant part of real money: it just works. I hand people money, they give me things. I swipe my credit card, I get things. I can’t remember who aid it originally, but there’s a great test you can give…

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…

Most people have no use for most currencies. I, for example, have no use for the Argentine peso.

That doesn't make it useless for someone else, who might for example live in Argentina.

The day you want to hire someone who wants their payment in Bitcoin for some reason, that's when you'll have use for it.

Re: BitTorrent v2

#422

Post by the8472 »

niklasrde wrote: post #402
the8472 wrote: post #206

Earlier quoted context omitted.

> Also, is is possible to add v2 to existing torrents "retroactively"? Who would do that? You would need the file data to do that, so torrent indexing sites could not do it. And since you need the full data you could only do it after downloading at which point it doesn't add that much value. > Or would this solely be for new torrents moving forwards? Indeed. v2 offers a few nice improvements but not world-changing on…

Could a client that has all the files just advertise a v2 version via DHT, even though the actual torrent was only a v1?

The issue is that there would be no way for clients which are currently downloading the v1 torrent to verify that the v2 matches. You could only do that after you have the data, at which point you could compute it yourself.

Re: BitTorrent v2

#423

Post by Muromec »

adwn wrote: post #404
Muromec wrote: post #396

Earlier quoted context omitted.

> Does this hypothetical situation you describe exist anywhere outside of the hypothetical situation posited by a character in a Neal Stephenson novel? That indeed is a bunch of real situations that have happened to me in 2014-2015 and some of that is still a thing. Check your privileges, sweet summer child. Like seriously — for the first 30 years of my life it was outright illegal to have a bank account in a foreign…

> Check your privileges, sweet summer child. Please don't do this here. It is needlessly condescending and insulting..

My bad. The comment I replied to was so tone-deaf, that I mistaken myself being on reddit.

Re: BitTorrent v2

#424

Post by indigochill »

X6S1x6Okd1st wrote: post #193
cercatrova wrote: post #144

Earlier quoted context omitted.

> It's a tool that doesn't pitch that it's a P2P tool - it doesn't try to convince you with sob stories in how using P2P helps fight against the big bad evil web. Instead, you use it because it's genuinely the best at what it does: it being P2P is not a selling point, it's just how it happens to work, and that is exactly what it should be. This should be something that every creator who markets or sells products shou…

>This should be something that every creator who markets or sells products should learn. Consumers don't care how it works. I distinctly remember being a teenager and learning how bittorrent worked, thinking it's the coolest thing I'd heard of and laboriously explaining how it worked to a friend that sounded interested. At the end of the explanation he asked "So how do you download music with it?" And I realized all…

There's a clip from the first episode of the show "Halt and Catch Fire" (which is a historical fiction show with each season hitting some breakthrough in personal computing, starting with IBM-compatible compact personal computers) where one character tells another, "Computer's aren't The Thing. They're the thing that gets us to The Thing."

I share it occasionally with friends to remind them of this. Computers are just tools. The really interesting question is what those tools can do for us.

Re: BitTorrent v2

#425

Post by dchest »

hinkley wrote: post #379
btschaegg wrote: post #372

Earlier quoted context omitted.

I think you misunderstood how the rolling hash is used in this context. It's not used to address a chunk; you'd use a plain old cryptographic hash function for that. The rolling hash is used to find the chunk boundary: Hash a window before every byte (which is cheap with a rolling hash) and compare it against a defined bit mask. For example: Check if the first 20 bytes are zero. If so, you'd get chunks with about 2^2…

I think they understood just fine. If I discover that the file I want to publish shares a range with an existing file, that does very little because the existing file has already chosen its chunk boundaries and I can’t influence those. That ship has sailed. I can only benefit if the a priori chunks are small enough that some subset of the identified match is still addressable. And then I may only get half of a two th…

that does very little because the existing file has already chosen its chunk boundaries

If they both used the same rolling hash function on the same or similar data, regardless of the initial and final boundary and regardless of when they chose the boundaries, they will share many chunks with high probability. That’s just how splitting with rolling hashes work. They produce variable-length chunks.

Re: BitTorrent v2

#426

Post by sagichmal »

chemmail wrote: post #231
dchuk wrote: post #208

Earlier quoted context omitted.

This is exactly the problem with all cryptocurrency currently. It’s a massive user experience issue, in the sense that users have to experience the technical bullshit of how the currencies work, completely missing the brilliant part of real money: it just works. I hand people money, they give me things. I swipe my credit card, I get things. I can’t remember who aid it originally, but there’s a great test you can give…

Sound like someone who drives a gas car and doesn't want to move into the future. I'm not saying bitcoin is the future per se, but the rest of the world i moving on from standard monies.

There is no universe, neither real nor imagined, where the statement "the rest of the world is moving on from standard [fiat] money" does now or will forseeably parse as true.

Re: BitTorrent v2

#427

Post by iso947 »

ShroudedNight wrote: post #275
iso947 wrote: post #181

Earlier quoted context omitted.

Bandwidth to where? Do they really have 1gbit per customer peering with say level3? And with cogent, and telia? And a full non blocking internal network? And enough packet buffers to ensure that microbursts don’t saturate any link?

Depending on the SLA, or lack thereof, they could have enough peering for a sustained +(x = 3?)σ demand spike without having a full dedicated peering for each customer, and still reasonably guarantee throughput availability.

Even ignoring peering, I’m still trying to picture the non blocking network. An Arista 7368X4 isn’t cheap, but will cope with 12,000 customers with appropriate switches downstream (128x100G ports with each port breaking out to 96 customers. Not sure how you’d scale beyond that without blocking.

Your peering will only scale to your (combined) interface speed regardless of your SLA. Our 2x 40G peer with level 3 serve far more than 40 1G devices (I personally have 600 in one building alone, and that sets aside the rest of the users), but it’s rare it’s more than 30% utilised.

Clearly that’s not going to be a domestic isp architecture, so a reasonable question is what does uncontended actually mean.

I very much doubt an isp with 10,000 customers has 10TB of peering physically available. Linx public peering is less than half that for the entire UK, and while private peering will likely increase that, the suggest is it’s welll under tenfold, so the 50 million plus internet users in the UK only use at peak times 1M each, and that ignores all the non-domestic use.

Even a 100:1 contention ratio seems enough at a core level, so any isp spending money on improving on 10:1 ratios seems that they are just burning cash.

Clearly as you go the the edge contention ratio needs to drop - but 40G, or maybe even 20G uplink for 48x1G users would be reasonable to me.

Re: BitTorrent v2

#428

Post by imtringued »

empthought wrote: post #240
easymovet wrote: post #229

Earlier quoted context omitted.

UX has been a main focus of Bitcoin ever since Lightning made scaling possible. Checkout out the Strike app for seamless bitcoin (lightning) payments https://strike.zaphq.io/ Who cares? Anyone who feels like their purchasing power isn't where it should be is either underpaid, or a victim of central banks diluting their dollars with printing.

> victim of central banks diluting their dollars with printing. So, nobody in the EU or North America, then.

Well, I think diluting is actually a pretty good word to describe what is happening. It's not really inflation. It's more about rising inequality. Money arrives on the stock market but it doesn't arrive in the job market. The result is an increasingly growing imbalance. Publicly traded companies and their owners greatly benefit meanwhile everyone else is being left behind.

Re: BitTorrent v2

#429

Post by abluecloud »

knodi123 wrote: post #375
tomxor wrote: post #215

> not only uses a hash tree, but it forms a hash tree for every file in the torrent [...] > Files that are identical can also more easily be identified across different swarms, since their root hash only depends on the content of the file. Wait, content addressed blobs across swarms... does that mean torrents made by completely different people at different times that happen to contain one or more identical files can…

> this feels like a significant feature that would boost the long term health of a lot of torrents Except for so many that are a single archive file. It seems logical that you'd want to compress what you're sending as much as possible before uploading... but in today's bandwidth environment, it actually makes sense to leave certain things uncompressed so you can benefit from swarm overlaps?!? Wild!

do two identical compressions produce the same output? if so, wouldn't the same thing happened just against the compressed files?

It's not uncommon to see multiple .torrent files with the same content FYI.

Re: BitTorrent v2

#430

Post by mratsim »

xvilka wrote: post #269
dane-pgp wrote: post #266

Earlier quoted context omitted.

It was good design to decouple the transfer protocol from the search protocol, to allow different technologies to be explored, but in practice people ended up relying on the "good enough" solution of using the web for search. Setting the precedent that media companies can seize domain names and force ISPs to block access to search engines if they don't like some of the search results (while ruining the lives of the p…

Can it be solved with IPFS-based trackers?

IPFS has an incentivization problem just like torrents.

The main reward for torrent uploaders is fame, would that translate well in IPFS?

Post reply on HN