Let's say you have a torrent stuck at 99,99%
Would it be possible to get the missing 0,01% by guessing it and then hashing until it verifies?
>>54907990
I guess, but depending on the size of the torrent that could take longer than the age of the universe. Brute forcing is never a good idea.
Theoretically possible, yes. But it'd require highly sophisticated neural network algorithms to determine the final hash.
instead of downloading the torrent, could I just randomly arrange bits and then hash until it verifies?
>>54908364
I don't thing it would work.
There are many more than 1 possible file that gives out the same hash.
>>54907990
You could do that. While you are at it, you can check whether Taylor Swift's nudes are among the bytes you are testing, I'm really interested in those.
let's assume you have a standard chunk size of 512KB.
This give you 2^(512*1000*8) possibilities.
Going further if you would have 1 second to do both the file hash verification and modification of the file this would be the possibilities=time in seconds.
Have fun trying - you've got no chance unless you are really missing only a very few bytes.
>>54908731
>1000
>not 1024
>>54908812
>being a retard
>not knowing what kilo means
>>54908884
Yes, 1 kilo is 2.2 pounds.
>>54908812
torrent protocol describes it accordingly to the SI. so regardles if windblows or master BSD*kernel.
>>54908908
>>54908917
Oh, I didn't know that.
>>54908025
Even then there's a significant possibility of collision. With the 512KB example, I get 1.69 possible files per SHA-1 hash.
http://m.wolframalpha.com/input/?i=%282%5E%28512*1000*8%29%29%2F%2840%5E16%29&x=0&y=0
>>54908993
1.69*10^(huge number) so there's almost certainly be a collision.
>still falling for the "standard" definitions thanks to greedy fucking HDD makers that want to fool people about the capacity of their drives and thus fucked up the entire computing world by making this shitty split between true 1024b=1k because that's how the fucking computing world goddamn works and their greedy fucking 1000b=1k bullshit "LOL BC THATS HOW IT IS EVERYWHERE ELSE YO".
Idiots.
>>54909030
Thanks for your invaluable input to this thread,
>>54908993
excluding the fact SHA1 would not work like this.
You are not calculating only that part but the whole file and SHA1 is broken by design because how it's done (read similiar to EBC/CBC. etc. are not the same).
And because OP did not include all the details (read: the torrent file itself) we cannot provide more details.
anyway just saying we are not having an issue with the hash we are using - the number is to big and OP is dead before 1% is done of the "brute-force"guessing.
>>54907990
>by guessing it
HAHAHAHAHA!!
>>54909071
Thanks for your stupidity that continues to support greedy fucking companies that work to fuck up standards.
You won't guess data which checksums OK but depending on the data format(s), you might be able to fill the rest of the data file with NUL bytes and get a (mostly) working file
>>54909157
Do you even kibi bro?
>>54909030
>>54909157
>muh greed lelele
prefix kilo means 1000.
no excuses.
kys
Just because some faggot engineer in the 50s had no imagination to come up with a proper factual term for his magic 1024 doesn't mean everyone should be as retarded as him
>>54909157
>that work to fuck up standards.
Nice to see you mouthbreathers retarded as always, since you're the one working to "fuck up the standards"
https://en.wikipedia.org/wiki/ISO/IEC_80000#Units_of_ISO.2FIEC_80000
They figured this out back on usenet. Quickpar is one of the many programs that does this, you just need a longer hash/checksum depending upon how much of the file is missing. But that hash/checksum also has to be slightly larger than the missing percentage, but it can repair any percentage. It's also quite CPU/drive intensive.
of course you need someone with the full torrent to generate that hash for you with a compatible program, send those files to you, and then repair it, but since its all freeware, this could be integrated into a torrent client to basically guarantee there will never be situations where multiple people are stuck at 99.9%. But instead it'll cause situations where multiple people are stuck at 90% or 80%, depending on how large the repair hashes are.
>>54909599
computers operate off base 2, yo. 1000 doesn't work cleanly in base 2.
>>54909925
Hmm. Distribute all this processing among the peers. What happens?
>>54910074
you get a botnet
>>54909925
it uses parity information/data to repair the file. it does not use hash to repair files.
>>54909925
If generate special hashes for pieces distribute it over clients and stuff, you're just converging back to distributing the data over the network from the clients who have the data to clients who don't.
>>54913281
*If you generate special hashes for pieces and then distribute it over clients and stuff
My brain melted because I decided to change the first sentence after writing everything
>>54909925
I'm going to go ahead and warn you that Microsoft Research have a relevant software patent in this area: if you were thinking of using a plain parity block to solve the "last block problem" so you don't need the last block, you might want to change strategy. It doesn't work well anyway.
Better: consider modelling the whole swarm as a multi-agent system. Use a technique which doesn't have a last block bottleneck: dynamic block octree, for example? (Have fun implementing that with high latency, because your requests won't get through fast enough. The trick is to try to make it stateless so you don't have to transmit a state, but there are various complications with that, especially when the swarm changes size and would desync.)
Also, making each large chunk, say, 256MB, out of, say, a Raptor code on the other hand, that's fine. Work it into the way you work a tree hash - BLAKE2 root, leaves (maybe Sakura padded, or maybe a BLAKE2 tree construct? Whichever is convenient), and then down into Raptor codes.
That uses about the same CPU time as Bittorrent's SHA-1, is more secure, is a little bit larger, but parallelises very well... in a swarm of like 5 people. I haven't tested it with bigger things yet. It will very definitely need tuning, and possibly redesigning.
You'll still get fucked by people leaving and joining the swarm; you'll still need some way of overcoming the upload::download asymmetry of most home connections (BT uses seeding; that doesn't deal with older archives so well).
>>54910074
They all need to do it themselves. Until they do it they don't know they have the right data.
