THE PROPOSAL FOR BITTORRENT PROTOCOL VERSION 2

>Moves from sha1 to sha256
>Instead of storing a sha1 hash for every single chunk in the .torrent file, it just stores the Merkle tree root hash for each file
>There is a protocol to request the rest of the Merkle tree from other peers, allowing the client to dynamically choose it's verification block size.
>Files are now block aligned, making it easy to download single files.
>File hashes are now globally unique, so it should be possible to scan torrent files to find duplicate files, and even download these duplicate files from multiple swarms.
>It's possible to create a backwards compatible .torrent file.

news.ycombinator.com/item?id=14951728

Other urls found in this thread:

news.ycombinator.com/item?id=14951728
twitter.com/AnonBabble

So solving problems that don't exist?

>moves from sha1 to sha256

6 months late

Is SHA-256 secure enough? There are tons of ASICs thanks to Bitcoin.

they do exist, you moron

>Is SHA-256 secure enough?

its just about avoiding collisions. sha256 is enough to keep bittorrent going for decades and by then there will be a better p2p protocol

when do they fix the bug that allows anyone to see your IP while you are downloading?

>not recommending SHA-512 with torrent-specific salt
It's like you don't want it to last forever.

that's not a bug and anonymity requires use of a VPN or tor network for this to happen

In theory, not in practice.

>he thinks Bittorrent will not be replaced by another p2p protocol a decade or 2 from now

Always ONE PERSON who takes the bait

>he thinks Bittorrent will not be deprecated by 2040

The next p2p protocol will show up any year now, anyway.

>he thinks I give a fuck that he trolled
>he's probably living with mom in his late 20s lol

>not realizing that people still use FTP
>a protocol that's been around since before 1972
Protocols never die, anons.

FTP is a basic file transfer protocol hence the name, user.

p2p is something that has to be replaced every few decades due to how its used and demand for more features

TCP & UDP are both protocols that are undergoing the same transformation, what with binary streams becoming the norm.
It's hard arguing about these things, because consumer computers have only been around since the 70's, and the internet's only been amazing from 2005 onwards.
Still though, a strong encryption now means down the line, that protocol can still stand up wit the new kids on the block, as a backup. That's the point I was trying to make with FTP (Most people just have web-based upload forms, who the fuck uses FTP anymore unless you're transferring many gigabytes of data or work at a big, old company like me?)

Really hoping WebRTC will take off, so we don't need apps like BT, we get real-time updates because it's all on the web.

What does this actually mean for the uploaders/downloaders?

Nothing because no one will adopt it. It offers no real benefit over the current system.

probably nothing much, a new version of your client will come out that's compatible with both versions.

Nothing, really. Smaller torrent files,.

Also, the second to last one; Say you have two torrent files, one with "Sasha grey XXX" and the other "Sasha Grey Porno XXX". If there are duplicate files between them, when you download "Sasha grey XXX", then seeders of "Sasha Grey Porno XXX" will be able to upload data to you even though you're downloading a different torrent, just because they're seeding the same file.

>Merkle tree

> 256^10e hashes
well...

And the stream encryption is still only rc4. That needs a nice upgrade to AES128, minimum.

So, are torrents IPFS now?
I'm ok with that.

>less porn going extinct
this sounds fucking great

How many hashes do these chinks go through?

No in practice. Ever download a movie out of a huge list of similar copies? This will reduce fracturing of similar files.

no it won't, because those are almost never identical copies

Except when they are

i've never seen that happen, even searching for popular movies on public trackers.

similar, sure - but every torrent is different enough to have a different hash. different subs, encoding, resolution, audio tracks, all of those will fuck up the hash and make it seem like a different file

>thing that never happened
the post

Happens more with porn.

So what it means in practice is that the MPAA can track you anywhere.

does anyone still use the official bittorrent client?

Call me when bittorrent supports pushing updates and adding new files to already existing torrents

because being able to surreptitiously change the contents of a torrent is exactly what you want

how retarded do you have to be to think thats a good idea, or at all suitable for a p2p filesharing protocol

you'd be letting any 10 year old script kiddie change the contents or at least see the password hash

>adding new files to already existing torrents

this is fucking stupid

Yeah.. that's a great idea lmao what could go wrong

but, bittorrent sync exists

>Is SHA-256 secure enough
1208925819614629174706176

Not at all. Ipfs still has a lot of advantages, like basically having except not implemented in a retarded way.

Who uses torrent files? Magnet links are the way to torrent.

every private tracker

magnet clients are just a shorthand for getting the torrent file from other users instead of a server

I can count to that in a day you fuck

.torrent files are the extension of plain magnets.

I just want r torrent with colors and for the interface to refresh at 60hz

magnets are just links to the torrent file you loser

Another thing to add:
>A reply which is a clean cut, factual response
>baited

no

>File hashes are now globally unique, so it should be possible to scan torrent files to find duplicate files, and even download these duplicate files from multiple swarms.
So basically you can share the hash and that's enough to get your download. No magnet link no torrent file nothing.

Thats pretty amazing

>the has collides with cp
>gets busted by CIA
That's pretty amaring

>he thinks pedos use bittorrent

>news.ycombinator.com/item?id=14951728
Why would you link this instead of the actual link?

>AES128
Please no. We need an actual upgrade.

The attack was much older, from 2009 I think.

>torrent-specific salt
Why?

Only retards do. Sane people use http(s) or sftp.

>Merkle tree
Does that mean that it might be possible for seeding individual files to people with a different torrent?

>Really hoping WebRTC will take off
Hope not. These post-modern shitty web protocols need to die.

Holy shit, you are a fucking retard. Why would anyone want that?

more discussion

What about private tracker features

nothing. the only feature we need though is ensuring that the torrent we made can never be posted publicly.

>muh super seekrit club
go work for a company that only outputs proprietary patented garbage if you wanna walk that path

I was a public pleb like you but then I joined. I would never go back. Public is way too slow and way too shit at retention.

>Files are now block aligned, making it easy to download single files.
>File hashes are now globally unique, so it should be possible to scan torrent files to find duplicate files, and even download these duplicate files from multiple swarms.

These 2 were on my wish list of new features to add to bittorrent 2.0. But I also would love signed versioning of torrent files so a fansub group can release a 1.0 file with and push updates over peers for each new episode/chapter/tank (rewarding long term seeding and minimizing the need for index sites/rss) and then again with each bluray re-release. And cooked in xdelta for automatic patching would be also really useful as well (source code torrents that auto-update and compile anyone?).

Retards clinging onto ancient utorrent will be btfo

>nd push updates over peers for each new episode/chapter/tank
this sounds really nice.
Wish this were a thing.

This was published in 2008

just to check, will this also have the effect of helping to track down pirated movies? can you just trace duplicate files and start tagging torrents?

good

How difficult would it be to hash shit with modern tools to regenerate something like a missing 128k sector on a file when all you have is the resulting checksum of the correct data? What if there was a full file sha256 to go with?
How many possibilities of the file would you have to try to find the correct one?

the hash will be per file

Let's say I download a movie without substitles, and you download the same release with a sub, in this new protocol I will seed my file between many torrents that contain this file.
And in theory you could also contribute if someone reupload the same file with just a different name

its

Didn't even need to think to know you meant IPFS.

It's truncated to 160bits

ed2k and dc++ are still alive and older than bittorrent

dude, lmfao.

Wtf does all that shit mean? Can I still use thepiratebay and utorrent?

they have nothing

When are we gonna get an anonymous bittorrent network?

None of those things interest me.
Bittorrent itself is better off dead at this point. I don't know what they're planning to achieve by pushing out a v2 of the protocol.

you'd be surprised I've accidentally'd into zips of cheesey stuff before

Yes, I know that, and that's only how it works if the subs are only included as separate files, something that I've seen maybe once or twice in the past five years. If the subs are muxed into the container, they won't hash the same.

bittorrent sync

sure, "accidentally"

They forgot to implement a simple takedown procedure for copyright holders. I hope this mistake will soon be corrected.

That has nothing to do with this thread.

So much this. I want to be able to download the torrent file only and then offline "reverse" the hashes to generate the whole file.

Presumably you would average half of the 128k guesses unless you knew something about the file format. Videos have B frames and delta so if you had the b frame before the missing sector you might be able to guess the next few will be deltas and are likely to be a subset of possible bytes. Or if you have deltas after the sector you can assume those pixels are different from the B frame.

>How difficult would it be to hash shit with modern tools to regenerate something like a missing 128k sector on a file when all you have is the resulting checksum of the correct data?
>So much this. I want to be able to download the torrent file only and then offline "reverse" the hashes to generate the whole file.
the whole point of SHA algorithms is that it's enormously difficult to reverse the hsah. pretty much the only feasible way to do what you want is with rainbow tables for certain tractable cases like passwords

Of course sha are difficult to reverse as data is lost through each round. Passwords are somewhat reasonable to find a match due to the comparitively small corpus and codespace. You might assume ascii characters between 0x20 and 0x7F so about 100 different characters per password character.
Could you not make somewhat similar assumptions about say a video file for reduce the problem space?

All the bittotrent protocol needs is some sort of built in way to hide your IP, like Tor

>Could you not make somewhat similar assumptions about say a video file for reduce the problem space?
as an exercise for the reader, calculate the number of unique 15x15 pixel bitmaps

the search space for images is at minimum several orders of magnitude bigger than for passwords

wont happen. not feasible the way it works.

a new protocol would have to be made, probably like IPFS but with encryption and onion routing.

Your assuming zero knowledge bruteforcing.
If you take user's original missing 128k and make the additional assumption that it is a video file. 128k will be less than a second of anyting but ultralow quality. And would likely be in the order of 2-10 frames. Depending on whether the missing chunk is frame aligned or contains a key frame there maybe addition information in the before and after frames to guess the likely content. Video also contains other data like audio or metadata which may not be as easy to guess.
Mutating the content, similar to the way fuzzers A do it might be possible to recover that chunk.
A whole file despite how cool it would be probably next to impossible, a single chunk maybe.

>I was just pretending to be retarded

I still think you're grossly underestimating the difficulty. Even if you can constrict the search space for video, like you said the audio and metadata portions alone are going to blow up your search space.

i'd rather see IPFS being used for what bittorrent is currently used for
deduplication is a HUGE advantage
think about how many of the same files are being distributed via different torrents, peers on one torrent can't use the peers on another torrent, even if they contain (some of) the same files
and think about batches, ipfs makes batches /free/, a new ipfs address describing a folder containing previous releases, simply links to the individual release addresses, no need to start yet another swarm just for the batch

Assuming 128k means 128000 bytes, that means 16000 bits

That means a key space of 2^16000.
This is a number that has 4817 decimal digits.
To put things in perspective, the estimated number of atoms in our Universe has only 80 decimal digits.

Assuming you can apply some magic heuristics by knowing it's a video to correctly fill 99,99% of those original 128 kB, living off a mere 16 bytes (2^128 key space) to brute-force, and ignoring the fact that sha256 is a cryptographic hash function, that is, by design, really costly to calculate, and you were using the best supercomputer we have today, it would still take 232 quintillion years to guess the rest of the file.

usually "128k" would be referring to 128KiB, or 131072 bytes (1048576 bytes, aka, 1Mib)

>1048576 bytes
1048576 bits*

>Assuming 128k means 128000 bytes, that means 102400 bits
1 byte = 8 bits
you need to multiply the bytes by 8 to get the number of bits

>he internet's only been amazing from 2005 onwards.
off yourself kiddo

>102400
>1048576
"slightly bigger"
just slightly