THE PROPOSAL FOR BITTORRENT PROTOCOL VERSION 2

>>61799024
So solving problems that don't exist?

>>61799024
>moves from sha1 to sha256

6 months late

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

>>61799079
they do exist, you moron

>>61799163
>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

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

File: 1500412558996.png (20KB, 240x281px) Image search: [Google]

20KB, 240x281px

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

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

>>61799201
In theory, not in practice.

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

>>61799461
Always ONE PERSON who takes the bait

>>61799451
>he thinks Bittorrent will not be deprecated by 2040

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

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

File: cocksucker.png (70KB, 446x427px) Image search: [Google]

70KB, 446x427px

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

>>61799529
FTP is a basic file transfer protocol hence the name, anon.

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

>>61799563
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?

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

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

>>61799669
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.

File: image-1147610-860_poster_16x9-uird-1147610.jpg (54KB, 860x484px) Image search: [Google]

54KB, 860x484px

>>61799024
>Merkle tree

>>61799163
> 256^10e hashes
well...

>>61799158
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.

>>61799760
>less porn going extinct
this sounds fucking great

>>61799163
How many hashes do these chinks go through?

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

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

>>61800567
Except when they are

>>61800591
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

>>61800591
>thing that never happened
the post

>>61800632
Happens more with porn.

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

File: btscrn.png (9KB, 310x253px) Image search: [Google]

9KB, 310x253px

does anyone still use the official bittorrent client?

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

>>61801114
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

>>61801114
>adding new files to already existing torrents

this is fucking stupid

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

but, bittorrent sync exists

>>61799163
>Is SHA-256 secure enough
1208925819614629174706176

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

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

>>61801720
every private tracker

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

>>61801429
I can count to that in a day you fuck

>>61801720
.torrent files are the extension of plain magnets.

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

>>61801720
magnets are just links to the torrent file you loser

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

>>61802630
no

>>61799024
>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.

>>61803896
Thats pretty amazing

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

>>61804001
>he thinks pedos use bittorrent

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

>>61800166
>AES128
Please no. We need an actual upgrade.

>>61799158
The attack was much older, from 2009 I think.

>>61799451
>torrent-specific salt
Why?

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

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

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

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

>>61804808
more discussion

What about private tracker features

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

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

>>61806263
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.

>>61799024
>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?).

>>61799669
Retards clinging onto ancient utorrent will be btfo

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

>>61799024
This was published in 2008

>>61799760
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?

>>61807707
good

File: 1498798957222.png (184KB, 500x500px) Image search: [Google]

184KB, 500x500px

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?

>>61800632
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

>>61799024
its

File: 1498860846963.jpg (13KB, 333x327px) Image search: [Google]

13KB, 333x327px

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

>>61800106
It's truncated to 160bits

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

>>61799024
dude, lmfao.

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

>>61810887
they have nothing

When are we gonna get an anonymous bittorrent network?

>>61799024
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.

>>61804721

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

>>61810756
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.

>>61801114
bittorrent sync

>>61814066
sure, "accidentally"

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

>>61801969

That has nothing to do with this thread.

>>61810662
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.

>>61815875
>>61810662
>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

>>61816015
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

>>61816264
>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

>>61816338
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.

>>61816340
Your assuming zero knowledge bruteforcing.
If you take anon'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.

>>61799481
>I was just pretending to be retarded

>>61817206
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

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

>>61818247
>1048576 bytes
1048576 bits*

>>61818438
>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

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

>>61818438
>102400
>1048576
"slightly bigger"
just slightly

OK, I'm stupid.
My point is it's a fuckload, and it would take infinite times the heat death of the Universe to brute-force a bunch of bits.

Just kidding. One more time. I hope I get it right this time.
Assuming 128k means 128000 bytes, that means 1024000 bits.

That means a key space of 2^1024000.
This is a number that has 308255 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.

>>61810662
>reversing a 128k block from a 256bit hash
top kek
there are 2^131072 possible 128KB blocks and only 2^256 possible hashes. this means that, on average, for every hash there are 2^130816 128KB blocks that could match it

you cannot store something in less bits than the amount of informational entropy it has. compared to files we use today, hashes have a very tiny amount of entropy. and that's ok because hashes aren't supposed to store data, but to determine the similarity of data with a chance of 1/2^n where n is the number of bits in the hash

>>61818710
1048576 not 131072, and 1048320 not 130816
I forgot to transform bytes to bits, but the point is the same

>>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.


Couldn't you in theory just make a torrent file with just hashes of files from other torrents then ?
Without you having any of the files yourself.

>>61818805
>in theory
m8, that's literally just making a torrent of .torrent files

>>61818710
now that sparked a question for me

same-hash chunks will only be shared if they're part of files with the same per-file hash, right? we won't run into a weird case where hash collision results in you downloading the wrong chunk, right?

>>61818860
no, no.
I don't want every file inside each torrent

but what I am talking about is, providing the globally unique hashes from say 5 or more files , each coming from a different torrent.

Honestly, if the hashes are globally unique, why not have a way to just provide the hash and search for it ?
What is stopping clients from having a giant mesh network of file sharing ?

>>61818879
hash collisions (different data having the same hash) are possible, of course, only a hash the same size as the data (aka, the data) can be collision-free
the point of a hash is that it should be unique /enough/ such that the /likelyhood/ of an collision is so remote as to be of no or little concern

>>61818930
>What is stopping clients from having a giant mesh network of file sharing
are you a time traveler from before magnet links existed?

>>61818930
that's what IPFS does
files are addressed by hash, so the same file always has the same address, no matter who makes it

>>61818959
well yeah, i knew in practice the probability is super low, but i was more interested in whether there were any safeguards in place against the theoretical possibility

>>61818979
if a particular hash algorithm is found to have a weakness, that is, something about it that makes it possible to generate a collision intentionally with relatively little effort, then the solution is to simply move to a stronger algorithm
for example, md5 is no longer considered safe to use, for this reason

>>61819040
i wasn't worried about intentional collisions either

>>61819066
that's all you really should be worried about, unless you're talking about algorithms with very small hash sizes, where the potential for accidental collisions is much higher, these tend to be used only in a limited scope

>>61819066
>>61819145
to be clear, running into an accidental/natural collision by chance with something like sha512 is so mindblowingly unlikely that it might as well not be possible
this isn't "one in a million", or "once in a blue moon" or even "chance of everyone in your town winning lotto" tier shit (i didn't actually look up the last one, but i'm pretty sure it's still more likely)

>>61819145
well i dont know the specific hash algorithm that bittorrent uses under the hood to verify chunks, my question was a bit more abstract

given the volume of torrent traffic flying around, my assumption was that there would be an extraordinary number of possible chunk hash comparisons. even if the per-comparison probability is low, the probability of getting at least one collision event at all would start to increase

i guess my real question was, when bt2 goes to grab a chunk from someone else,what's the order of operations? does it just check that the chunk hash is the same, or does it start with checking the torrent/file hash?

>>61818879
I'm not sure but I understand your concern.

The chance for 2 blocks to have the same hash is 1/2^256. If we have N blocks on the p2p network, the chance for at least one collision to exists is around N/2^256. Let's consider that a chance of 1/2^64 (one in 18 billions billions) is low enough to not worry about collisions in practice. This means that N can be at most 2^192. 2^129 * 128 KB = 8 * 10^50 TB, or 8 * 10^41 zettabytes. To put things into perspective, we create globally only a few tens of zettabytes every year. Of cores, this amount grows exponentially but most of it is duplicate so I wouldn't worry right now.

And as always, thanks for watching.

>>61819255
it's true there's a metric fuckton of traffic flowing through the internet nowadays, but they still only count for a drop in the proverbial bucket of possible hashes for the common hash types

>>61807771
It already exists. You're looking for syncthing.

>>61819364
>>61819364
>I'm not sure but I understand your concern.
i wouldn't say it's a concern, more a curiosity

File: 1460966780850.jpg (225KB, 627x502px) Image search: [Google]

225KB, 627x502px

>>61819397
put simply, number of possible hashes (for common types, usually 128bit+) = a number far, far too big to wrap your head around, don't even try to think about it

if you still want to know more, try looking up things about cryptography