If everybody did it, that would be a big problem.
More to the original poster's point, my post answer's the posters question of "why doesn't YouTube just offer file downloads like Bittorrent?"
There are many clear reasons why; my post gave one of the more prominent ones.
You're the seeder. Initially you're the only one with all 100. And everybody's gonna download things sequentially.
Imagine 300 peers grab block 1 from you. Gonna be pretty slow, each peer gets 1/300th of your bandwidth.
Imagine those 300 peers finish block 1 and move onto block 2. Same bandwidth crunch. Although new peers can at least get block 1 from that initial cohort of 300 peers. But nobody can blocks 2 through 100 from anybody but you. Not ideal.
Now repeat the process for 3 through 100. You're gonna be the bottleneck for a loooooooong time for those remaining pieces.
...
...
...now imagine we do it differently. Those 300 peers each grab a random block. This part's just as slow.
But once they have their initial randomly-chosen blocks, our bandwidth explodes. Each of those 100 blocks is now available from ~4 sources (you, and roughly 3 others). And you could even log off at this point, since there is a complete (distributed) copy of your file out there.
As more blocks are exchanged, the effective aggregate bandwidth rapidly increases even farther.
not saying it would not work, I actually like the idea of more peer to peer networking. But as the market is clearly focused on low consumption user devices with commonly little drive capacity seeding would be a damage to UX.
i.e. I'll send block 1 to one peer, block 2 to another peer. Then I can send blocks 3 and 4 to them (respectively), while they each send each other blocks 1 and 2.
That's just not true.
I've used uTorrent, and I recall deciding whether I wanted to stream or not. It worked well too.
(In the case of ZIP archives, 7-Zip can't open partial files, but bsdtar can. Although in my case it was from a damaged floppy disk rather than torrent, but the same thing would do, if you are downloading ZIP files from torrent. But if you are downloading music, then presumably bsdtar is irrelevant.)
Theoretically, yes. But in practice, especially with "modern"/high-speed internet, I can open my torrent in VLC after the first few MB are present on my computer and read the entire file as it comes in, without me the user encountering stuttering or buffering of any kind.
In effect, from the user's perspective, you're streaming the torrent - without running into the often present decrease in quality from the "traditional" stream's encoding.
1. You can't play a torrented file until the download is 100% complete. (Well, maybe 95% complete, depending on how tolerant you and your software are when it comes to malformed files)
That's the way it was designed to work. Otherwise, the bits at the beginning of the file would be much more common amongst your non-seeding peers and the bits at the end would be much rarer amongst your non-seeding peers. Your downloads would start crazy fast and would get progressively slower.
Some clients let you abuse the protocol and "stream" torrents sequentially, but if significant percentages of torrenters (such as literally every Netflix user, in an imaginary world where Netflix simply served everything via torrents) did that it would be an issue.
That's a great way to deliver big files in their entirety via P2P, but that is pretty much the pathological opposite of what is requred for streaming.
For streaming you obviously need that sequential access. You need to optimize for the beginning of the file, since people want to start watching right away. People do not want to wait 60 or 30 or even 10 seconds for a YouTube vid to start streaming.
2. Think about your actual viewing habits. How many times have you watched the first 1% of a video on YouTube or Netflix, and then decided to watch something else instead? Even if we (probably generously) assume most users watch an average of 50% of a given video (I suspect it's much less) that's still 2x wasted bandwidth per video, on average, if video providers blasted out entire files. Netflix's infrastructure (or rather, their AWS monthly bill) is massive already. Imagine it being asked to blast out 2 or 5 or 10x as much data per video as it's already doing.
3. There's also the rather important matter of many (most?) playback devices not having huge gobs of local storage with which to hold complete movie downloads. I've got probably 20TB of hard drives scattered around this place, but that's not the norm.
4. Can't adapt to changing bandwidth conditions by scaling video quality up and down midstream. Personally, I wish I had more control over this as a customer, as sometimes I'd rather just wait than watch a compromised stream, but Average Joe is not going to want to muck around with that sort of choice, or even understand what it means.