[HN Gopher] BitTorrent v2
___________________________________________________________________
BitTorrent v2
Author : jakobdabo
Score : 356 points
Date : 2020-09-07 19:33 UTC (3 hours ago)
(HTM) web link (blog.libtorrent.org)
(TXT) w3m dump (blog.libtorrent.org)
| mtgx wrote:
| Nothing about privacy improvements/encryption?
| rolleiflex wrote:
| 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-well oiled marketing
| machinery talking about Web 3.0 that allows its founder to go on
| TechCrunch and talk about the upcoming distributed paradise.
|
| Bittorrent works in the way you install it into your computer and
| it does something for you. And for that alone, it has my immense
| respect and attention.
|
| It's a tool that doesn't pitch that it's a P2P tool - it doesn't
| try to convince you with sob stories about 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.
|
| That is something all P2P developers should aspire towards.
|
| [0] Aether P2P: https://getaether.net
| cercatrova wrote:
| > 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 should learn. Consumers don't care how it works,
| it just has to be better than the solution before it. Appealing
| to how things ought to be moralistically doesn't work (for the
| vast majority of consumers). They just don't care, they want a
| solution to their problem.
| im3w1l wrote:
| I think everyone _aspires_ to this. They just fall short.
| cercatrova wrote:
| Perhaps. I see a lot of developers make stuff (non-dev
| related even) but then only list out their technical specs
| and features rather than benefits, as if the programming
| language its written in is supposed to entice (non-dev)
| consumers. A corollary is devs making software for their
| own enjoyment but that which doesn't solve an actual
| problem. I think it's more that they don't think in that
| entrepreneurial mindset yet, but once they realize no one
| is buying, they'll understand for the next time around.
| megameter wrote:
| It's a problem with the creative process itself, I've
| learned, and it isn't different in other mediums. It
| follows the McCloud "Six Steps to Art" - starting with
| surface changes, gradually learning the elements of the
| craft, and eventually settling on a purposeful idea in
| the medium or about the medium.
|
| Most developers, and therefore most projects, get stuck
| somewhere in the middle area, where there is enough skill
| to create features, but no direction or vision for those
| features, other than a basic template based on other
| software.
|
| Often, the project will be called "minimal" to excuse
| having few features, but only a few projects adhere to a
| genuine restriction like SLOC limits or eliminating
| dependencies.
|
| Appeals to commerce as the goal often have a further
| narrowing effect of making one anxious with thoughts like
| "project must moonshot on day 1", but then you look at
| Bittorrent, an all-time software success, and it's like,
| no, this probably wasn't ever going to create the next
| Microsoft. Funds were raised to have a Bittorrent
| company, but the market success it had was always modest
| at best. And yet it did and still does represent an idea
| that people can believe in.
|
| The actual thing that I see every great project do,
| whether it's defined artistically or not, is to define
| up-front some themes and principles that you believe
| cohere well, and then direct the specific elements around
| deeply studying and exploring them. This can manifest as
| a corporate mission statement, or as an artist's
| manifesto, or an academic research subject. In final
| form, it generally manifests as "do one thing
| exceptionally well", since if you have a very clear idea
| of the goal, you can direct all your energy upon it. But
| in the intermediate stages it is still trial and error to
| learn what fits the theme best, what the actual success
| metrics are.
|
| The thing is, if you have coherence in the abstract, it's
| way easier to explain the reason for being: "This is just
| a manifestation of the principles". Being easy to explain
| in turn makes it marketable without resorting to sales
| tricks. And because it deals with general concepts it
| taps into a breadth of appeal that can't be found just by
| looking at any one feature. So adhering to principle sets
| you up for success in a general sense.
| dchuk wrote:
| 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 to any statement or idea. Just immediately
| ask "who cares?" The best product demos I've ever seen answer
| who cares in each part of the pitch. The worst ones just
| rattle off mumbo jumbo forever.
| X6S1x6Okd1st wrote:
| >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 he cared about was using it to pirate
| music.
|
| It's really easy for programmers to get lost in how cool some
| code or technology is and lose sight of how the rest of the
| world views it.
| DevX101 wrote:
| BitTorrent was one of the few things that once I understood how
| it worked, I realized I was looking at the product of true
| genius.
| sneak wrote:
| The first time I ever felt that way was with the Gnutella
| network; I instantly wrote a client for it from scratch.
|
| Bittorrent only became that level of magical for me when the
| DHT got factored in some time later and magnet links became
| workable.
|
| The other time was Bitcoin.
|
| I'm a big fan of lack of centralized/coordination/tracker
| nodes.
| martinald wrote:
| Really? It's a just an iteration from how eDonkey2000/eMule
| worked, which actually also had a DHT based 'trackeless'
| mode, many years before BT came around.
| bawolff wrote:
| The tit-for-tat algorithm is what makes bit torrent special
| and solved a real problem with the previous gnutella-esque
| generation of p2p file sharing programs. As far as i know
| emule did not have that at the time.
| godzillabrennus wrote:
| Hacking around distributed hash table open source software gave
| me the utmost respect for the people who came up with this
| stuff.
|
| Crypto currencies owe a lot of their successes to the pioneers
| behind technologies that also power bit torrent.
| 1vuio0pswjnm7 wrote:
| Today's consumers and developers of "tech" have been trained
| and convinced to readily accept stuff that works "most of the
| time".
|
| It is the software I download for free that is the most
| reliable IME. Spending more money does not make today's
| consumer computers any more valuable. And that's how it should
| be. The price of hardware (and software) should continue to
| fall.
| tim333 wrote:
| >being P2P is not a selling point
|
| It is kind of a selling point with regards to what most people
| actually use it for. If not P2P the movie / record industries
| would shut down the servers.
| bawolff wrote:
| I think the point is its an implementation detail not an end
| in itself. Users care about the properties it provides, not
| the method (p2p) of obtaining then
| k__ wrote:
| _" 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"_
|
| What about the trackers?
| simple_phrases wrote:
| DHT makes trackers simply an aggregation and redundancy
| measure.
| joenathanone wrote:
| It should, but in practice it doesn't. I've had torrents
| that I left sitting for weeks not being able to complete,
| until I added a list of trackers to them and found some
| seeders with 100% of the torrent.
| k__ wrote:
| Same here.
|
| BT only worked for new popular stuff.
| Red_Leaves_Flyy wrote:
| I've yet to find something that's truly unavailable.
| Sometimes it takes a few different searches on different
| sites but I've always found the obscure Linux distros
| I've been looking for.
| ksec wrote:
| What is the current relationship between BitTorrent Inc, which I
| think developed the original BT v1 protocol and client, and
| Libtorrent? Which I think was a 3rd party BT Library written in
| C++ because the official version was in Python which was
| resources hungry.
| toyg wrote:
| You got your relationships wrong.
|
| Bram Cohen developed BitTorrent and released a (Python)
| reference implementation in the public domain (later under MIT
| and then GPL licenses); he later founded BitTorrent Inc. and
| assigned this implementation to the company to maintain.
| Eventually BitTorrent Inc dropped this codebase altogether and
| became closed-source with a completely separate project.
|
| Libtorrent is just one of many independent BT libraries that
| have been developed since Bram published the first BT client.
| ksec wrote:
| >You got your relationships wrong.
|
| ??
|
| So there are no relationship between the two?
|
| >Eventually BitTorrent Inc dropped this codebase altogether
| and became closed-source with a completely separate project.
|
| That was from the acquisition of utorrent.
| loeg wrote:
| Correct, no relation between the two.
| [deleted]
| coronadisaster wrote:
| It would be nice to have a torrent system where noone that is
| uploading has all the data for a specific torrent (or at least
| they arent uploading the whole file to any specfic person...
| probably would be harder to prosecute in the event that some
| files become illegal)... You could take 1% of the billonaire's
| fortune and give it to the "victims" and everyone would be happy.
| smabie wrote:
| No one can have all the files and BitTorrent works just fine.
| Though, I don't see why anyone wouldn't want the whole file.
| What's the point if you can't actually use what you downloaded?
| [deleted]
| coronadisaster wrote:
| You could or could not have all files, but you would never
| upload a whole file to a single user (ie: part of a file is
| possibly meaningless if you upload random chunks)
| anaganisk wrote:
| Im not sure how that would work technically speaking if there
| is just a single seeder and leecher, also don't you become an
| accomplice for helping?
| coronadisaster wrote:
| every seeder could technically have all the files but would
| only share random chunks with each user
| bakies wrote:
| Can't this already be true? You do not need the entire torrent
| in order to seed downloads. Clients leeching know which blocks
| seeders are providing and will download what's available.
| pgsandstrom wrote:
| Sounds a bit like freenet: https://freenetproject.org
| luckylion wrote:
| If you share significant parts of a copyright protected work,
| you're probably still on the hook. For most things, it's not
| actually the files that are copyrighted, it's the content
| encoded in them.
|
| At some point, I suppose things get very fuzzy, e.g. you're
| just uploading a single second of an album, but I don't know
| who practically useful that would be.
| sillysaurusx wrote:
| Uploading parts of illegal files is equivalent from a security
| perspective. It seems like there's no advantage to your
| proposal.
|
| The Whonix wiki has an incredible amount of information on
| topics such as this: https://www.whonix.org/wiki/Documentation
|
| Basically, it's very hard to protect the security of users when
| a government seeks to prosecute dissidents. There's a lot to
| take into account. A simple "we saw an upload from IP address
| x.y.z.w containing <illegal file>" will be enough to hang
| whoever it is.
|
| On second thought, I guess it would be a nice addition to let
| users control which files they're seeding, rather than the
| whole torrent. I'm just not sure it's enough to get them off
| the hook in the event of legal troubles.
| jayd16 wrote:
| Ideally, you'd want to come up with some way to pack files
| such that many files share the same chunks. Perhaps you could
| make the act of sharing (all or most of the) legal and
| illegal files indistinguishable.
| p1mrx wrote:
| You could have a protocol where every block of the file is
| actually two "random" blocks XOR'd together, but this
| doesn't really work. If you create a new 1GB torrent,
| you'll need 1GB of new (never seen before) blocks with
| ~100% probability, so it will be obvious who's seeding the
| data.
|
| Or you could make the block size smaller (e.g. 1 bit) and
| tell the lawyers to piss off because 0 and 1 are public
| domain.
| wmf wrote:
| See https://www.scs.stanford.edu/~dm/home/papers/waldman:
| tangler... and https://ansuz.sooke.bc.ca/entry/23
| draugadrotten wrote:
| One change in the v2 protocol stands out here. "Files that
| are identical can also more easily be identified across
| different swarms". Would this per file hash not make it
| easier for such a government to find illegal material shared
| by users. It appears v2 is not suitable for sharing of
| material which could get one in trouble.
| 0-_-0 wrote:
| .zip
| singron wrote:
| I don't think this really matters in practice. The DHT is
| public and you can already scan it to find all the public
| torrents, all the files they contain, and what IPs are
| sharing them.
| marcinzm wrote:
| >probably would be harder to prosecute in the event that some
| files become illegal
|
| Cynically I'd assume they'd just use it to add a conspiracy to
| commit a crime charge to the list since you technically need to
| coordinate with other people.
| AdamJacobMuller wrote:
| No reason you can't do this with the existing protocol. I'm not
| sure how much it helps from a legal POV and i suppose it
| depends upon your threat model, but, its fairly trivially
| doable.
| nabla9 wrote:
| If you want to circumvent the law, you must find a legal
| technicality, not a technical technicality.
|
| The key weakness in every smartass technical technicality to
| circumvent the law is forgetting that _intent_ is core concept
| when the law is interpreted in the court.
|
| Did the defendant have intent to do X? Did the defendant use
| some purpose build technique to avoid doing the most literal
| interpretation X ? .. Yeah, defendant is guilty of doing X.
| spockz wrote:
| IANAL, but afaik this depends on whether the legislation is
| English law or Latin law from origin. Where Latin law is more
| about the intent and english, and therefore US law, is more
| about the letter of the law. Perhaps the distinction is along
| a different axis but this is how I remember.
| nabla9 wrote:
| You are thinking about common law (originated in England)
| vs civil law (based on Roman law) In both systems intent is
| very important in criminal cases.
|
| The real difference is between criminal law and contract
| law. In contract law. In contract law the intention is
| fixed by the language of the contract document. It matters
| less if matter if one party didn't intent to violate the
| contract. It is what it is.
| smabie wrote:
| I've written a torrent client, and I'm skeptical than v2 will
| ever catch on. While it does solve some minor problems, it's not
| a large enough leap forward to justify the costs.
| wmf wrote:
| uTP seemed like a small improvement to me but it happened.
| IshKebab wrote:
| Yeah this definitely feels like a Python 2/3 type situation.
| They solved one minor issue but require the whole world to
| update.
|
| I'm not even convinced they couldn't have done it in a
| backwards compatible way. Why not stick with SHA-1 but _also_
| add SHA-256 for verification for clients that support it?
| userbinator wrote:
| That's an interesting comparison, given that the first
| BitTorrent client was written in Python (2).
| UncleEntity wrote:
| > Why not stick with SHA-1 but also add SHA-256 for
| verification for clients that support it?
|
| Apparently you can do that with 'hybrid' magnet links.
|
| The problem is the two swarms are different so as more people
| move over to v2 the v1 swarms will become smaller and smaller
| -- thus giving people an incentive to upgrade, I suppose.
|
| ...and they seem to have solved more than one minor issue
| since they were breaking things anyway...
| bredren wrote:
| I don't know much about protocol version pacing, but was lack
| of substantial changes part of the reason it has taken 12 full
| years to get a client to support v2?
|
| http://bittorrent.org/beps/bep_0052.html
| rhencke wrote:
| No. It is still a draft proposal.
| Mindless2112 wrote:
| 3 years, not 12. BEP 52 was based on BEP 3 and kept the same
| metadata, including the creation date.
|
| http://bittorrent.org/beps/bep_0003.html
| sedatk wrote:
| Minor problems? Isn't this a security issue? Somebody can
| modify a binary and still have it return the same hash and
| distribute it to people who think that they are receiving an
| authentic file. Is it even an option to keep going with SHA1?
| Even Git, which this is less of an issue, has a plan for
| migrating to SHA2. https://git-scm.com/docs/hash-function-
| transition/
| throwaway2048 wrote:
| This isn't really true, sha1's weakness would require you to
| be the creator of the torrent, which if you are, you can just
| make the binary malicious to begin with.
| Havoc wrote:
| If a couple major players adopt a hybrid system then it could
| perhaps
| loeg wrote:
| libtorrent backs a number of popular clients (Deluge,
| qBittorrent), so that's a good start.
| mhh__ wrote:
| From the perspective of the client would it be a drop in
| replacement like changing a static library or a from the ground
| up rework?
| smabie wrote:
| If they used libtorrent, then it would be easy. If they wrote
| their own system, then it would require a moderate amount of
| work to chance to v2.
| ksec wrote:
| I am going to take a guess, Most people on Mac would be
| using transmission, and People on Windows would be using
| Classic Utorrent.
|
| Both are not based on Libtorrent.
| ogogmad wrote:
| The use of SHA-1 in v1 seems like a major problem.
|
| [edit]
|
| That doesn't imply that BTv2 is the right successor protocol.
| akvadrako wrote:
| It's not currently - collisions are very expensive and only
| in limited contexts. If you wanted to distribute malware via
| torrents your efforts are better spent elsewhere.
| ogogmad wrote:
| Attacks only get better with time.
|
| Also, this seems quite bad:
| https://en.wikipedia.org/wiki/Collision_attack#Chosen-
| prefix...
| loeg wrote:
| That attack isn't relevant to bittorrent swarms. What you
| want is a preimage attack on SHA1.
| [deleted]
| PossiblyKyle wrote:
| Since we're on this topic, what's your torrent client of choice
| HN? I plainly use BitTorrent nowadays
| sp332 wrote:
| I use deluge just because it has a nice client and separate
| server which I leave running on another box.
| kuroguro wrote:
| qbittorrent, hands down :) Open source, cross platform and
| relatively small footprint (native), uTorrent-like UI.
|
| I believe it uses libtorrent under the hood, so this might be
| integrated soon.
| loeg wrote:
| > I believe it uses libtorrent under the hood
|
| Yep: https://www.libtorrent.org/projects.html
| jedberg wrote:
| I use it too, the main reason I switched is it seems to be
| the only one capable of maintaining line speed downloads on
| 100+ megabit links on a Mac.
| vermilingua wrote:
| uTorrent 2.2.1, which unfortunately seems like it won't be
| viable going forward if v2 adoption picks up.
| kuroguro wrote:
| Was using that for a very long time as it's the last version
| without ads. Unfortunately there were multiple
| vulnerabilities disclosed in 2018 and some private trackers
| started blacklisting it (workarounds for the vulns were
| discussed but not sure if any are confirmed as working).
|
| https://bugs.chromium.org/p/project-
| zero/issues/detail?id=15...
| vermilingua wrote:
| This is news to me, thanks for pointing that out. (Not sure
| why I find it surprising, it's a very old piece of software
| now.)
| bserge wrote:
| Why not 3.x?
| Dahoon wrote:
| It's basically malware.
| 0xdeadb00f wrote:
| Transmission. If you're looking for one on android,
| LibreTorrent looks absolutely amazing
| jug wrote:
| Deluge for a server/client model with optional web interface,
| if you for example want to command your Raspberry Pi to add som
| torrents. But for a more traditional one I prefer qBittorrent
| after Ludde abandoned uTorrent.
| bserge wrote:
| uTorrent, it has always been fast and stable.
| Hamuko wrote:
| Been a fan of Transmission on macOS for many years. I just wish
| I could install Transmission on a Linux box and still keep
| using the fantastic Cocoa interface it has on macOS.
| oauea wrote:
| You mean https://github.com/transmission-remote-gui/transgui
| or another gui? You should be able to connect remotely, that
| is pretty much the entire idea behind transmission. A torrent
| daemon with various UIs that use the API.
| martindale wrote:
| Has there been any progress on advancing BEP-46 (mutable
| torrents) [0] along the standards track? I didn't see any mention
| of it in this announcement, despite my hopes of seeing it as a
| flagship feature.
|
| [0]: http://www.bittorrent.org/beps/bep_0046.html
| the8472 wrote:
| The BEP itself is almost trivial. The difficult work is
| implementing it in a client that makes it useful for users and
| content providers.
|
| In the wild west of the internet "update" really only means
| "add" because you don't want the source you barely trust to
| provide some data to issue an update that deletes all the
| previous download from that source. But you also want to avoid
| wasting storage so some size caps and rehashing old data to see
| if it's an incremental update will also be needed.
| crazygringo wrote:
| Very interesting. But I'm not totally clear -- what does this
| mean for compatibility with v1?
|
| The article states that _hybrid_ torrents that support v1 and v2
| can be created. But what does this mean for end-users (clients)?
|
| Will most torrent software be upgraded to support both v1 and v2?
| And will a client be forced to choose from the v1 or v2 swarm, or
| will it be able to download from and seed to both?
|
| I mean it _seems_ like clients would participate in both swarms
| -- I 'd just like to know if that's confirmed.
|
| Also, is is possible to add v2 to existing torrents
| "retroactively"? Who would do that? Or would this solely be for
| new torrents moving forwards?
| the8472 wrote:
| > 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 ones. So there's no pressure to upgrade existing
| torrents. They'll keep working as-is.
| armitron wrote:
| A v2-aware client that also supported v1 and hybrid torrents
| would tick all boxes and be able to participate in multiple
| swarms (for the same torrent).
|
| The main issue that I see is the existence of millions of
| torrents in private trackers that would have to be manually
| updated for v2.
|
| Are people going to bother? I think not. So for me, v2 is
| practically a new-torrents-only affair.
| ehsankia wrote:
| I think this is fine. Slow migration is often the right
| choice. The important part is to start early, and in a decade
| maybe the vast majority of torrents will be V2.
| oauea wrote:
| The sites could perform a bulk update for all their torrents
| if they so chose.
| danarmak wrote:
| To update you need the data so you can rehash it. A typical
| tracker only has the torrent files and would take a very
| long time and spend a lot of possibly expensive bandwidth
| to download all the tracked torrents. And some torrents may
| not be seeded all the time.
| 22c wrote:
| If nobody has the data, the torrent is effectively dead
| and most private trackers will remove it in time. If it's
| not dead, they can incentivize seeders to re-hash/re-
| upload a v2 compatible torrent if they really wanted to.
|
| Private trackers tend to gamify quite a few aspects of
| their sites (obvious example being the seed ratio
| itself).
| bserge wrote:
| They often just have the magnet links. I haven't looked
| into how that works, but I think the complete data is
| only on the seeders' machines, and the torrent propagates
| through DHT.
| Cyph0n wrote:
| Private trackers do not use magnet links afaik.
| Hitton wrote:
| This is pretty cool. Per-file hash trees is something I've been
| missing for some time now.
| koeng wrote:
| > Identical files will always have the same hash and can more
| easily be moved from one torrent to another (when creating
| torrents) without having to re-hash anything. 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.
|
| As a question for someone who knows better - does this mean that
| you can download single files within torrents themselves? I
| imagine if each file is independently hashed, this should be
| possible.
| ColanR wrote:
| If I understand your question correctly, then yes, people do
| that all the time and most bittorrent clients make it super
| easy.
| M2Ys4U wrote:
| >As a question for someone who knows better - does this mean
| that you can download single files within torrents themselves?
|
| Most torrent clients can do this already, but depending on how
| the torrent was created and the size the files involved you
| might download a some of the files on either side.
| xibalba wrote:
| _To me, BitTorrent feels a lot like Blockchain: interesting tech
| that doesn 't seem to be able to find a practical and useful
| application (proportionate to the attendant hype). Which is not
| to say that either can't, they just haven't yet. Why?_
|
| EDIT: while I don't (yet) consider myself delirious, responses to
| this comment have illuminated how little I know about the
| influence and application of BitTorrent. In other words, I
| retract the above opinion.
| slim wrote:
| I estimate that thousands of people use torrent every day since
| 20 years. I use it very often. maybe it's just that nobody uses
| it in your close network
| mawalu wrote:
| You mean beside being responsible for ~50% of the global
| internet traffic in 2009?
| https://en.wikipedia.org/wiki/BitTorrent
| xibalba wrote:
| Insofar as the majority of that traffic is likely illegal (in
| terms of sharing pirated property) I would not consider it
| useful.
| [deleted]
| deathgrips wrote:
| This falls apart when you examine prohibited goods. Guns
| are illegal in most countries because they are _very_
| useful.
| liability wrote:
| It's not legal, therefore it's not practical? That doesn't
| make any sense at all.
| dtech wrote:
| useful != legal
| oblio wrote:
| Yeah, but what's the current number? I'd be surprised if it
| were more than 5-10% these days. 2009 was 11 years ago, the
| internet was a much smaller and less regulated place.
| CyberDildonics wrote:
| You think that if something once took up 50% of all traffic
| on the internet it never found a practical application?
| oblio wrote:
| > proportionate to the attendant hype
|
| From the original comment.
|
| Also, just because it was 50% at some point, it doesn't
| really matter today. Paraphrasing, a technology is only
| as good as it's latest match result.
|
| Perl was once powering the web, nowadays you have to look
| at the web with an electronic microscope to find it...
| bioipbiop wrote:
| Even if it were only 5-10% of internet traffic, that'd be
| huge! Think about how much the internet has exploded in use
| since 2009.
| ffpip wrote:
| Youtube is 37% of all mobile traffic. [1]
|
| [1]- https://www.statista.com/chart/17321/global-
| downstream-mobil...
| risho wrote:
| that is still way WAY more than enough to justify it's
| utility.
| luizfelberti wrote:
| You're delirious.
|
| Setting aside the fact that BitTorrent came about long before
| BitCoin was a glint in Satoshi's eye, it's still massively used
| for content distribution, on top of being a foundational
| technology to several industrial applications: Apache Spark,
| for example, uses BitTorrent to shuffle/broadcast data around
| cluster nodes.
|
| Even when BitTorrent alternatives are used in its place (such
| as IPFS, Dat, or Kademlia), BT was still a massive influence in
| all of their designs, and to the design of any other DHT that
| came about after its release.
|
| All of these, plus other systems that are (in abstract) similar
| constructions, have several industrial applications for asset
| distribution (Netflix uses IPFS to distribute container images
| internally [0], Uber and Alibaba do similar things) and network
| management (DNS for example, is really just a DHT, as are
| several other network protocols)
|
| Ever since BitTorrent came about, it has unequivocally been a
| resounding success. It never for a moment had to look for
| applications, there were already plenty since day one.
|
| [0] https://blog.ipfs.io/2020-02-14-improved-bitswap-for-
| contain...
| thawaway1837 wrote:
| Wasn't the original Skype that Microsoft paid billions for
| also based on BitTorrent technology?
|
| Not BitTorrent exactly, but close enough that if the
| blockchain spinoff was bought for that much the blockchain
| folks would certainly consider (rightfully IMO) a victory in
| the blockchain column.
| wmf wrote:
| Skype was based on JoltID/Kazaa.
| oblio wrote:
| > it's still massively used for content distribution
|
| Is it, though? Youtube doesn't use it, neither do Netflix,
| Hulu, Amazon Prime Video, Disney+, Spotify, etc. Does anybody
| (except for Blizzard) use it? I don't think Steam or the Epic
| store or the App Store or the Play Store use it, either.
|
| I'd be extremely glad to be proven wrong.
| FridgeSeal wrote:
| I remember reading about how Facebook uses it to distribute
| updates amongst servers.
| loeg wrote:
| Windows has some sort of P2P update distribution system,
| although (1) I don't know that it is bittorrent and (2) it
| seems to be massively slower than just using MSFT's servers
| directly, so I'd suggest disabling it. On the order of 100x
| slower.
| toyg wrote:
| I believe Steam uses it. The network graphs they spout show
| behaviours consistent with BT-like activity.
|
| I'm pretty sure the BBC iPlayer used it too, at some point
| (no idea if it's still the case).
|
| Most Linux projects use it.
|
| Any company offering a "download manager" for 1GB+ files,
| is likely to be implementing something similar to BT behind
| the scenes.
|
| The thing is: if bandwidth costs are a real problem for
| you, BT is a killer solution to offload some of those
| costs. If they are little more than a footnote (like for
| the mega-services you list), then BT is unnecessary and it
| will probably slow down overall performance too.
| M2Ys4U wrote:
| v1 of iPlayer used bittorrent, but these days it's all
| streaming.
| yepthatsreality wrote:
| Why...?
|
| BitTorrent has been influential in lots of applications. If you
| really need proof that BitTorrent can move milestones, it help
| perpetuate sites like thepiratebay.org and assisted in the
| advent of modern day streaming services that both the music and
| movie industry neglected for years. It is also a central
| influence for p2p networking and file sharing.
| oblio wrote:
| Yeah, but it's not used anymore, from what I know. Few places
| use it for distribution, I guess they don't consider it worth
| the hassle. Blizzard was using it to distribute binaries.
|
| I guess mobile internet was its downfall as few people want
| to seed from a mobile connection.
| armitron wrote:
| There are vast data archives exposed through private
| trackers that work on top of bittorrent. This isn't widely
| known due to their private, invite-only (and in some cases,
| entirely closed) nature but the fact remains that these
| exist and are fundamental in multiple, widely divergent
| communities.
| oblio wrote:
| Can you give some examples? It all sounds very...
| mysterious. At least, what kind of content are we talking
| about?
| bdekoz wrote:
| A public example is rutracker.org. Another is sci-hub.
| See Joe Karaganis for some cannonical info:
| http://piracy.americanassembly.org/shadow-libraries/
| M2Ys4U wrote:
| >I guess mobile internet was its downfall as few people
| want to seed from a mobile connection.
|
| CGNAT has a lot to answer for, too
| ajtulloch wrote:
| Lots of companies use BT in a datacenter environment to
| efficiently distribute binaries to a large number of hosts.
| oblio wrote:
| Again, this is in the context of the original BitTorrent
| hype. Which was huge. What you're mentioning is small
| potatoes.
| oblio wrote:
| Well, both threaten the establishment. Blockchain would
| basically upend states, with unclear benefits. BitTorrent would
| allow for very efficient distribution of a lot of data, which
| can conflict with copyright.
|
| At least BitTorrent is environment friendly :-)
| m3kw9 wrote:
| Talk about an un-mobile friendly website
| [deleted]
| risho wrote:
| works fine on my phone.
| Stratoscope wrote:
| It even manages to evade the usual "Show simplified view"
| bottom bar that Chrome mobile shows when it detects that a page
| is likely hard to read.
|
| Rather ironically, you get a much more readable view if you
| select "Desktop site" in the Chrome mobile menu and then
| double-tap the main text column.
| kasabali wrote:
| It works just fine on Opera on Android.
|
| Most of the time it's not web sites but browsers, who are
| unfriendly.
| tomxor wrote:
| > [...] 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, does this mean content addressed blobs across swarms...
| does that mean torrents made by completely different people that
| happen to contain one or more identical files can benefit from
| seeds of the other torrent?
| nurettin wrote:
| I remember one of the original bittorrent guys asking for
| help/recruiting on some IRC channel. He said it was a
| transformative project. He was laughed off as the next "wanna
| create mmorpg" guy. For once they were wrong.
| viktorelofsson wrote:
| If you want to try a client with v2 (and v1+v2 hybrid) support,
| I've just released PicoTorrent v0.20 [0] based on Rasterbar-
| libtorrent 2.0 :)
|
| [0]
| https://github.com/picotorrent/picotorrent/releases/tag/v0.2...
| m00dy wrote:
| hmm, looks like still no support for data streaming :(
| rwmj wrote:
| BitTorrent (v1) supports streaming if your client knows the
| appropriate way to prioritize packets. I've written a streaming
| client using libtorrent-rasterbar and it worked fine. What's
| the problem?
| armitron wrote:
| Nothing stops you from downloading pieces in a specific order
| that allows for streaming. It's the client that determines
| order, not the bittorrent protocol.
| m00dy wrote:
| well, I meant live streaming here.
| FridgeSeal wrote:
| That would require mutable torrents correct?
| lucb1e wrote:
| Um, now this is the third subcomment; you could have edited
| your original comment.
| m3kw9 wrote:
| I feel like a lot of the terms has blockchain in nature but they
| never specifically state it.
| Retr0spectrum wrote:
| Blockchains are just unbalanced merkle trees.
| doctoboggan wrote:
| Bittorrent was pioneering distributed architecture while
| bitcoin was still a future thought in Satoshi's mind.
| sleavey wrote:
| SHA1 has a collision, so now it uses SHA256. How long until a
| SHA256 collision? Shouldn't the new protocol just add support for
| many modern hash functions, and client updates can disable
| support for hashes that become insecure later? Or does this
| introduce its own headaches? That's what SSH does, right?
| armitron wrote:
| Collisions in the context of bittorrent are not a big deal. We
| could (and will, there are millions of torrents around that
| will never be updated) keep using SHA1 and the world is not
| going to end.
| frenchman99 wrote:
| It isn't? Is it not possible to be tricked into downloading a
| malicious binary that you then execute on your computer?
| loeg wrote:
| I don't think so.
|
| 1. The user trusts the source of the .torrent file.
|
| 2. A malicious peer makes a preimage attack in some block
| in an executable file with contents containing some
| malicious executable payload.
|
| 3. The executable wasn't signed, or the targeted block must
| include executable headers.
|
| 4. Some peers get the malicious exe, some don't.
|
| The (2) step is still hard -- preimage attacks on SHA1 are
| still expensive.
|
| And it is probably much easier to bypass SHA1/SHA256
| entirely by just uploading a malicious torrent directly and
| hoping (1) still applies.
| calvinmorrison wrote:
| Unlike the Photoshop 2020 WareZ Cracked Unlocked 2020 Xvid
| Torrentz WZ FUN.torrent, that I just downloaded
| vermilingua wrote:
| Yes, because warez is the only valid use of bittorrent.
|
| Most Linux distros offer an installation iso via torrent,
| large files with many blocks. If you can change just a
| small part of those files, you've got compromised
| machines before the install even begins.
| mlyle wrote:
| Most of the practical hash attacks we've seen allow one
| to create two chunks of data that hash to the same thing,
| not to collide with an arbitrary other block. This
| greatly limits the attack scenarios we need to worry
| about.
|
| (That is, we've got practical collision attacks emerging
| for SHA1, not pre-image attacks).
| flatline wrote:
| They aren't? So someone can craft a payload that contains a
| rootkit or similar and has the same name and hash as the
| thing you wanted, and this is okay? (Disclaimer: I don't know
| all that much about how hashes are used internal to the
| protocol)
| armitron wrote:
| The vast majority of data shared over bittorrent is not
| executable.
|
| So your scenario becomes an issue if you're downloading
| executable data that you deem :trusted: without any
| additional verification besides the hash itself. If that's
| the case, you have bigger worries than the hash.
| dmurray wrote:
| Or if there's a vulnerability in a popular media player.
| sp332 wrote:
| The weakness is a collision, not a pre-image attack. That
| means that a pair of payloads can be crafted together, one
| innocent and one malicious, that have the same hash. But it
| is not feasible to take a given file and make a new
| malicious payload with a matching hash.
|
| So if you get your hash from whoever made the original
| binary, you can know that any binary with a matching hash
| is fine. But it could be a problem if someone creates a new
| pair of binaries and uploads the hash to TPB. You might see
| lots of good reviews from people who got the innocent
| version, but then the peers you connect to send you a
| malicious version with a matching hash.
| heartbeats wrote:
| What if the hashes differ?
| sleavey wrote:
| I expect there would have to be other changes to allow this
| feature, such as the server advertising all the
| available/supported hashes for each chunk.
| Taek wrote:
| I don't think anyone is expecting a sha256 collision in the
| next 20 years. The crypto doesn't seem to leave much wiggle
| room for exploitation.
| noja wrote:
| Don't people always say exactly that? What are the chances of
| a collision if we simultaneously use multiple hashes, does it
| become significantly less likely?
| nemo1618 wrote:
| > don't people always say exactly that?
|
| This is an understandable reaction, but the security margin
| on new crypto is _way_ higher than old crypto. Roughly
| speaking, we went from "I guess if a state-level actor
| dedicated all their resources to this for a few decades,
| they could probably brute-force it" to "Even if you broke 9
| out of 10 rounds in this algorithm, you'd still need to
| harness the energy of every star in the universe for 10
| billion years to brute-force it."
|
| Most algorithms today have been "attacked" in the sense
| that there are tricks we can do that allow us to recover
| the key faster than a simple brute-force attack. But
| "faster" usually means doing something like 2^100
| operations instead of 2^128 -- still far beyond the realm
| of practicality.
|
| It's telling that cryptographers are now seriously
| discussing _reducing_ the security of various algorithms:
| https://eprint.iacr.org/2019/1492
| bamboozled wrote:
| In twenty years, So they have 10-15 years to safely do
| other things.
| toyg wrote:
| _> Don 't people always say exactly that?_
|
| No, "they" don't. SHA1 collisions had been "in the wind"
| for a while, they had been in sight ever since MD5 started
| showing signs of clear weakness in the early '00s.
| Wikipedia has a Rivest quote about it from 2005. There is
| nothing like that for SHA2, although attacks are improving.
|
| _> What are the chances of a collision if we
| simultaneously use multiple hashes_
|
| Define "simultaneous". Shipping twice the hashes for each
| piece seems a big waste of space. If you mean re-hashing
| hashes, it's just a waste of cpu power, since an attacker
| only has to break one or the other to get in a position to
| poison data.
| nabla9 wrote:
| > How long until a SHA256 collision
|
| Very unlikely that this is going to happen any time soon.
|
| Most modern symmetric cryptographic primitives with sizes >=256
| bits are considered safe even against quantum computers. SHA256
| turned out to be even stronger than expected. SHA-3 adoption is
| delayed in many protocols because there is no much need for it
| and hw implementations for SHA256 are commonplace.
| stingraycharles wrote:
| Isn't the fact that OpenSSL et al allow so many arbitrary
| ciphers the reason of a whole load of problems?
| user5994461 wrote:
| Nope, the problem is that software never upgrade their ssl
| stack to support the newer ciphers. Especially Microsoft
| that's easily 10 years behind on the current SSL version.
|
| Without the ability to support multiple versions, it would be
| impossible to upgrade anything at all. That would be a whole
| load of other problems.
| loeg wrote:
| Yep: https://en.wikipedia.org/wiki/Downgrade_attack
|
| > Downgrade attacks have been a consistent problem with the
| SSL/TLS family of protocols; examples of such attacks include
| the POODLE attack.
| johnisgood wrote:
| Why not BLAKE3? I am really curious. I mean, since it exists,
| why not that over SHA256? Because it is relatively new?
| loeg wrote:
| I would guess that the reasoning is similar to why Git is
| moving to SHA256 (from SHA1) rather than to BLAKE3 -- SHA256
| was around 5 years ago and the major design change has been
| in the works for a while (BEP 52 dates to 2017). BLAKE3
| (2019) would be a fine choice today.
| tekacs wrote:
| They use multi-hash [0] in magnet links, presumably for exactly
| this reason.
|
| ... but for consistency (like their narrowing of valid
| bencode), they've presumably chosen one main hash for now, so
| that every client and server doesn't have to handle all of
| these cases as people provide a million variants of the same
| torrent.
|
| [0]: https://github.com/multiformats/multihash
| d33 wrote:
| There are a few things I wish this addressed, but it doesn't. Off
| the top of my head:
|
| 1. the new hash function is going to be broken eventually - what
| happens then? 2. support for "remixes". It would be nice to
| reference pieces from another torrent. Example use case: adding
| subtitles for a movie. Right now it requires either downloading
| the "main" version of the movie and getting the subtitles
| externally, or sharing the file from scratch.
| heartbeats wrote:
| > Identical files will always have the same hash and can more
| easily be moved from one torrent to another (when creating
| torrents) without having to re-hash anything. 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.
| lucb1e wrote:
| > the new hash function is going to be broken eventually
|
| SHA-2 will not be broken as easily as SHA-1. This seems to be a
| common misconception in this thread.
|
| Wikipedia: "Since 2005, SHA-1 has not been considered secure
| against well-funded opponents".
|
| This was 10 years after its introduction (1995) and 15 years
| ago. We had 15 friggin' years and we're finally switching git
| and bittorrent around. It took 2017-2005=12 years to get from
| first serious signs of issues to https://shattered.io.
|
| SHA-2 is now 19 years old and the "uh oh, better switch before
| it's too late" recommendation has not come yet. It's
| withstanding the test of time better and there haven't been 12
| years to mature any weaknesses. The theoretically known attacks
| for SHA-2 are fairly insignificant.
|
| Since SHA-2 had a similar construction to SHA-1 (Merkle-
| Damgard), NIST figured they better launch the SHA-3 competition
| at the first sign of trouble and picked something with a very
| different operating principle. For now, however, it's still
| fine. Thomas Pornin put this a bit better than I can:
| https://security.stackexchange.com/a/21116/10863
|
| As for "what happens if/when it will be broken": we could make
| BitTorrentv2 another multi-crypto soup like with TLS, but then
| you open up a can of downgrade attacks, potential null ciphers
| or other such tricks simply due to increased complexity, and
| you still can't switch that quickly because everyone needs to
| take manual action in changing configuration files. Much better
| if we can instead do apt upgrade and let the software take care
| of making security decisions rather than those who install the
| software. (Remember that SSL was designed in 1994, when
| LiveScript/JavaScript didn't even exist yet, DES was state of
| the art, and we wrote books with algorithms because
| cryptography was ammunition. Having multiple options for
| strong/weak ciphers was not yet a crazy idea.)
| proverbialbunny wrote:
| It feels like this isn't a large enough leap forward. It would be
| nice if BitTorrent v2 made it harder for ISPs to identify what is
| bit torrent traffic. AT&T artificially slows down upload speeds.
| mac01021 wrote:
| Why don't ISPs bill by the gigabyte and be done with it?
| jbverschoor wrote:
| BC billshock scares people away. It would set us back to the
| early '90s
| wwwhizz wrote:
| So watching Netflix and YouTube gets more expensive? No,
| thanks. I'm fine with European net-neutrality and pay for
| bandwidth.
| 101008 wrote:
| It would be horrible to live in a world like that. Imagine
| deciding to watch a shorter film on Netflix because you will
| pay less.
| ffpip wrote:
| That's basically what happens with mobile data plans in
| India. Fixed speeds, pay X amount per 1 or 1.2 GB
| freedomben wrote:
| Because customers lose their minds with that model, largely
| as a result of conditioning that "internet" is an unlimited
| resource (which of course it is when instantaneous demand <=
| supply, but during high traffic periods that isn't the case).
|
| Personally I understand the economics around it, but still
| don't like the idea of paying per GB. I would end up skipping
| some Netflix and would get mad at kids for playing Netflix to
| an empty room (much like I currently get mad when they leave
| the lights on in an empty room). It's nice on a personal
| level to avoid that.
| [deleted]
| tyfon wrote:
| That kind of depends on the price pr gb.
|
| To use the power analogy, when I was young the price of
| power was relatively high but in recent times it has now
| dropped to 0.6 NOK / kWh so even charging the car from
| 10-80% (~61 kWh) cost 40 NOK or $4. I do not get mad at the
| kids leaving the light on like my mother did to me.
|
| I (or rather my job) currently pays about 1000 NOK/ month
| for unlimited 500 MBit synchronous fiber internet. I
| transfer maybe 500 GB/month so for it to be cheaper for me
| it would be under 2 NOK/GB or $.2 which sounds really high
| but that is what I currently pay with my usage.
| Dahoon wrote:
| I thought internet in Norway was cheaper than in Denmark.
| Interesting. For comparison I pay 449 DKR/month for
| 1000/1000 unlimited fiber with a guaranteed bandwidth of
| minimum 950 (they are upgrading the network atm. hence
| not a guarantee on the full 1000 yet as some customers
| equipment is too old).
|
| Is it a normal connection or a business connection
| perhaps?
| iso947 wrote:
| 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?
| wolco wrote:
| You pay for peace of mind that little Johnny doesn't
| download some crazy amount by accident. Now you don't
| have to monitor family usage so that makes things easier
| as well.
| bserge wrote:
| I _really_ don 't like the idea of limited bandwidth or
| charging per gigabyte because I know ISPs will rip people
| off and still not upgrade their networks to handle more
| traffic.
|
| But I think it would considerably change the Internet
| landscape. No more listening to the _same exact song_
| multiple times on Youtube or Spotify or whatever. No more
| downloading then deleting the same stuff over and over
| again. I think about it often, what a massive waste of
| bandwidth, I don 't even know why. It's a lot of
| electricity used, I guess?
|
| Even though I've got unlimited fiber, I'm looking for some
| sort of local "Internet cache" solution that would store
| _everything_ so it would be re-downloaded from my home
| instead of across the ocean. Would be great for outages,
| too.
| Hamuko wrote:
| > _It 's a lot of electricity used, I guess?_
|
| Is it though? How much electricity is used to serve a
| 1080p Netflix movie several times vs. playing the same
| movie from a local storage medium?
|
| If you asked me, I'd rather burn Bitcoin mining rigs if I
| wanted to get rid of electricity waste.
| bserge wrote:
| Yeah, I don't know. I just think about the bandwidth we
| all use sometimes and it seems extremely wasteful and it
| bothers me for some reason. I use around ~200-300
| GB/month, which I thought was a lot until I saw how much
| other people use :D
| Hamuko wrote:
| > _I use around ~200-300 GB /month_
|
| Pretty sure I use more than that in a day.
| wmf wrote:
| Wait until you hear how much CPU time and RAM is being
| wasted...
| bserge wrote:
| It's actually the reverse that bothers me in that case! I
| have more RAM and CPU time than I can possibly use :D
|
| Unless that's what you meant...
| Bnshsysjab wrote:
| Yeah but your hardware requirements are driven by
| software bloat.
| Red_Leaves_Flyy wrote:
| I think what they're getting is how bloated software has
| become. Some websites download several megabytes of data
| to display a kilobyte or less of actual content.
| liability wrote:
| Why won't ISPs stop advertising 'unlimited' service that is
| actually limited to N gigabytes a month, where N is
| substantially lower than what's possible given the speeds
| they provide?
|
| Because they can get away with it.
| colechristensen wrote:
| Because it is insanely expensive to actually provide that.
| The nature of internet traffic is short bursts, not 100%
| utilization. In a commercial setting you can purchase fixed
| pipes that are entirely yours and they're tens or hundreds
| of times more expensive.
|
| Why wouldn't you want to pool bandwidth with your neighbors
| so you could all get faster speeds when you were using it
| instead of rate limiting everyone?
| jeromegv wrote:
| The issue is that there's no way to know what this limit
| is. I understand the cost, but then tell us exactly how
| many GB I can use at full speed and when does it start to
| throttle. Instead I have to rely on internet anecdotes.
| selectodude wrote:
| They do. I'm pretty aware of what my data transfer limits
| are on both my home and wireless connections. Granted my
| new ISP has no data caps and symmetric gigabit speeds so
| I'm a bit spoiled.
| slyall wrote:
| Well in New Zealand we used to charge-per-byte but as things
| got cheaper this has largely gone away. Some of the cheaper
| how fibre accounts have something like a 100G/month limit but
| I guess it isn't worth the trouble to charge even here where
| bandwidth is much more expensive than the US.
| driverdan wrote:
| 100Gb/month is practically nothing. I primarily use a
| hotspot for internet access and routinely do way more
| traffic than that.
| slyall wrote:
| If you don't use video then it'll be plenty. Plenty of
| people get their TV the old-fashioned way but still want
| fast Internet.
|
| Looking at pricing for Spark (one of the
| largerproviders). [1]
|
| For each of the fibre speed plans you can get 60GB/month,
| for another $10 you get 120GB/month and for a further $10
| you get unlimited traffic.
|
| BTW: "Mb" = Megabits, "MB" = MegaBytes
|
| [1] https://www.spark.co.nz/shop/internet/plans-and-
| pricing/
| geoffmunn wrote:
| Flashback: I was on Actrix which charged $5 per megabyte.
| Downloading Netscape Navigator 2 nearly bankrupted me. I
| used to browse the internet with images disabled, which
| ironically gave me an appreciation for accessibility issues
| which served me well later in life.
|
| When Xtra came out at $2.50 per hour, it was a complete
| game changer.
| gkfasdfasdf wrote:
| Agreed, this would align incentives nicely. Maybe we would
| see more innovation in compression technology that way.
| Hamuko wrote:
| I imagine the data whales would not cover the loss revenue
| from people who just use online banking yet pay the same
| amount.
|
| I've used 15 TB in the last 5 weeks with my torrent client
| alone (and considering my Backblaze backup size, that's not
| nearly all of my traffic), but how many people like me are
| there in the general public?
| hysan wrote:
| Some thought experiments for you to try:
|
| - Does this guarantee that you get the speed that you pay
| for? If not, then should the price during heavy congestion
| cost less per GB? I've had the unfortunate luck of having
| lived in areas where the internet is unusable for anything
| other than email and light browsing during peak hours. Bonus:
| Do you know why this happens? If not, I encourage you to
| research this.
|
| - How will this affect the advertising model of the entire
| internet economy? If you, like me, have lived your whole life
| on a mobile data plan that is priced based on data usage,
| you'll realize just how much bandwidth is consumed by
| advertisements (worst are the video/audio types that auto
| play).
|
| - How will this affect "future" technology such at smart
| homes? Most devices send data back (Amazon Echo devices) and
| the growing security camera ecosystem that sends recordings
| to the cloud would suddenly cost users a ton more.
|
| - Speaking of cloud, what will happen to the gaming industry
| that is heavily cloud based? Many games don't even ship in a
| completed state anymore. Instead, part of the install
| requires downloading a ton of additional updates. Not to
| mention online play, DLC, etc.
|
| There a many many more everyday examples like this that would
| be heavily affected by pricing per GB. Your question sounds
| like a simple solution but like many things in life, that is
| rarely the case.
| colechristensen wrote:
| Because their costs aren't based on usage, but installing and
| maintaining the infrastructure then collecting rent on it.
| Actual usage is an exponential curve and if you bill on it
| you have a few angry users paying for everybody else's
| infrastructure.
| huhtenberg wrote:
| It's nearly impossible to obfuscate a protocol to work around
| filtering.
|
| You'd want to look like some other protocol and you want that
| protocol be encrypted by default. Otherwise yours _will_ get
| fingerprinted via the deep packet inspection.
|
| The most obvious choice is to run your protocol over TLS. But
| then they can just throttle long-lived bulky TLS connections
| where neither side is on 443.
|
| You can then require the responding side be on 443 (which is
| already a big hassle), but they will then throttle down TLS
| connections towards residential IPs or throttle them down
| cumulatively, as a group.
|
| Other choices here are OpenVPN, WireGuard and, possibly, IPsec.
| But, again, it will come down to defeating the throttling of
| multiple inbound bulky connections of the same type, which is
| doubly hard to bypass if you are on a residential IP and your
| ISP is really bent on throttling.
|
| Any successful obfuscation technique is short-lived, so it has
| no place in the protocol itself. Instead it should be delegated
| to a transport layer and the clients should be coded to support
| BT tunneling over X or over Y.
| richardwhiuk wrote:
| This is all true. The best way to make your application work
| now matter what filtering is in place is to disguise it as
| something which the ISP has to make work in order to get
| customers.
|
| Fundamentally, nothing has the same characteristics as
| BitTorrent - almost nothing has the same high uplink
| requirements, which is an absolute signature of BitTorrent
| traffic.
|
| Oh, also some of the shaping is implicit, not explicit. Most
| home internet connections are asymmetric - they dedicate more
| channels to downlink than uplink.
| TheRealPomax wrote:
| Why would the that be the protocol's responsibility?
| greycol wrote:
| I'd assume that a protocol that gets faster for files the
| more nodes who use it and the faster those nodes transmit
| would try to solve real world issues stopping more
| nodes/faster speeds from those nodes.
|
| The word 'responsibility' that you used is of course too
| strong a word, however the comment 'it would be nice' to have
| is definitely true assuming we want downloads to be faster.
| convery wrote:
| Maybe not 'responsibility', but I guess it'd be nice to have
| some kind of proxy protocol so that seeders can proxy
| requests for people with annoying ISPs.. or they could just
| use a VPN like everyone else =P
| kardos wrote:
| > It feels like this isn't a large enough leap forward.
|
| The hash it relies on is broken, so their hand has been forced.
| throwaway2048 wrote:
| 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 let you do in a
| bittorrent context is create a torrent, then let you send
| fake data for a chunk, which really does not seem very
| useful.
| jedberg wrote:
| > AT&T artificially slows down upload speeds
|
| Do you have a source on this? I believe you I just want to know
| more. It explains a lot.
|
| I have a gigabit link. I can download torrents at almost line
| speed. But I can barely get uploads past 5K/s. I spent hours at
| one point trying to tweak every possible setting and eliminate
| every bottleneck, and still couldn't get past 5K/s.
| toyg wrote:
| _> I just want to know more._
|
| There is little to know, it's largely a commercial preference
| (that has, over the years, driven technological research; see
| ADSL for example, the first A is for Asymmetric).
|
| Average consumers are precisely that, _consumers_ : they
| rarely upload anything, but they download tons of content
| (from webpages to streamed media). So it makes sense for
| residential ISPs to maximize downstream bandwidth, since it's
| what consumers will evaluate them on. One way to do that is
| to simply throttle upstream, to ensure resources stay
| available for downstream. (This has the side benefit of
| reducing headaches, i.e. less people distributing
| questionable material on your network...).
|
| If you need good upload speeds, you simply have to talk to
| your ISP.
| [deleted]
___________________________________________________________________
(page generated 2020-09-07 23:00 UTC)