Here's a thread where you can post retarded software/programming related ideas you read or saw on the internets. Retarded code from ENTERPRISE is fine too, but please don't turn this into “Retards writing Java” thread. You can think of it as /prog/'s own DailyWTF, only with less Java programmers and people laughing at stuff that they really don't understand. I'll start with a post from /a/:
I have been thinking about a P2P client which requests bytes from people who may not necessarily have the file they're downloading, but they have those specific bytes (which may be from another file), and the P2P client is designed to request the closed peer with those bytes, despite not having the file. So, it wouldn't matter if a torrent was dead, you'd just have to search other peers for those specific bytes.
It would have to be some sort of index of hashes of those bytes which would determine who sent them...
Name:
Anonymous2008-04-28 16:32
Here's a thread where you can post retarded software/programming related ideas you read or saw on the internets. Retarded code from ENTERPRISE is fine too, but please don't turn this into “Retards writing Java” thread. You can think of it as /prog/'s own DailyWTF, only with less Java programmers and people laughing at stuff that they really don't understand. I'll start with a post from /a/:
Name:
Anonymous2008-04-28 17:45
>>1
You mean that it's a bad/retarded idea, or are you referring to the fact that some networks already use divide files in fixed-size blocks (what the /a/ guy called "bytes") to transfer them?
But yeah, asking everyone in the network if they have "the block that matches this hash" is inefficient and won't help much.
Also, DailyWTF sucks
Name:
Anonymous2008-04-28 18:01
>>3
The functionality the cited person wants is already there and is like, the very reason you're using it in the first place.
>>4
Oh, a quite narrow interpretation, but good enough to troll both me and the /a/ guy. Fuck it.
Name:
Anonymous2008-04-28 18:13
Ok, this is from a friend of mine. Not a programmer, and I don't know who told him to try FIOC. He did some kind of rpg with raw_input(), without even using functions, everything in an infinte loop directly in the module. I lost that "game", but here's a similar script:
import sys
print 'Pink Floyd - If'
print 'Press c for Commands'
dic = {"were a swan":"I'd be gone", "were a train":"I'd be late", "were a good man":"I'd talk to you more often than I do", "were to sleep":"I could dream", "were afraid":"I could hide", "go insane":"Would you let me join in with the game?", "were the moon":"I'd be cool", "were a rule":"I would bend", "were alone":"I'd cry", "were with you":"I'd be home and dry"}
while True:
x = raw_input('If I... ')
if x in dic.keys():
print dic[ x ]
elif x == "c":
print "'c' = Commands \n'exit' = Exit the program\n'credits' = See credits"
elif x == "exit":
break
elif x == "credits":
print 'by Someguy\nspecial thanks to Someotherguy'
else:
print 'Error'
sys.exit(1)
Also, his code looks pretty much like BASIC code. Oh gawd
Name:
Anonymous2008-04-28 18:49
>>3
Assuming all files are random, which is a reasonable approximation as video, music and pictures are typically compressed, you get just as much information back as you put into it. Unless it's the same file of course, but he excludes that case, or if blocks from the wanted file are in another file like a .rar without compression or a slightly edited version, which is probably more rare than the file that has no seeders.
Name:
Anonymous2008-04-28 19:16
>>3
I'm saying it's completely retarded because flooding random people on the Internet with requests for a particular chunk from a file that they don't have is fucking retarded. This is completely different from DHT, (nice troll, >>4), which searches for people who are seeding the file you want.
Not to mention that the odds of one chunk of video being exactly the same as another chunk from a completely unrelated file is very, very low. Also, collisions. What that idiot on /a/ described could be accomplished by taking chunks out of /dev/random, hash them and see if they match the hash we're looking for.
Name:
Anonymous2008-04-28 19:26
Also, nobody has mentioned that the only way to get an arbitrary chunk of random bytes from somebody is to send an identifier of the exact same length or larger than said chunk.
Name:
Anonymous2008-04-28 20:14
>>9 >>7 did. you get just as much information back as you put into it
Name:
Anonymous2008-04-28 21:08
>>1
Uh guys, the funny part is that you can't request a particular sequence of bytes without already knowing which ones you want... in which case you have the file already.
I find it hilarious that 2/3 of the niggers here are trying to think of a way this can work.
The other 1/3 know it can't work.
And when I say "know it can't work" you niggers need to read it as "no it can't work."
Name:
Anonymous2008-04-29 1:11
Oh shit. I know how this could work.
The client sends out a hash for some arbitrary chuck of data on the network.
The recieving client responds after it has calculated the hash for every arbitrary chunk of data in all shared files. If it finds a match, it sends that first chunk of data. Then it stores which node it got this data from.
The sending client can just spam all nodes on the network until it fill up data for all the hashes it sent out.
Then it can calulate a checksum on this franken file(s) and compare it to the expected checksum.
If the checksum doesn't match, it just respams the network noting not to send requests to the ones it got bad chunks of data from. (which in this case is every node we just got data from since we can't verify if it really was correct.
Now with this second set of chunks it checkes the checksum again. If it doesn't match it will then try every valid combination of the 2 files checking the checksum each time.
If it still isn't valid it creates a 3rd file and so on increasing physical distance of nodes each time.
Eventually, it will get the correct file.
Most of the file will be from people who actually had the actual file, but it possible a couple of the chunks WOULN'T BE FROM THE ORIGINAL FILE.
Name:
Anonymous2008-04-29 1:18
>>18
You don't need to receive data from other people, just generate it randomly on your machine
This could be enterprise p2p software... to the patent office, /prog/
Name:
Anonymous2008-04-29 4:56
Oh great, we just found a way to build a 700MB file from its 128b hash (who uses SHA-1 anyway?). From the master has, you can build the sub-hashes you want (hash->bytes, 1st pass). For each of the sub-hashes, you can find sub-sub-hashes, which will in turn allow to find more hashes.
After enough iterations, you have enough hashes to build the entire file and you only downloaded 128b and used a few CPU cyles (much less than a bruteforcing the algorithm, which would also be a viable solution).
GREAT
Name:
Anonymous2008-04-29 7:43
>>1
There's this guy that wanted to write a program that puts the contents of a binary file in your paste buffer so you can paste it in MSN (and other similar faggot shit) and send it in an instant as text.
>>25
Yeah, I know that. The whole post was a troll: 128b is the size of a MD5 hash, which has been proved broken (if there are collisions, the whole idea of building a file from its hash is moot).
I thought the idea of bruteforce as a viable solution was a dead giveaway, too.
Faggot, I said its possible, not probable or even likely.
While my solution would fulfill /a/ guys requirements, if you found any part of that reasonable, you are just as retarded as he.
Name:
Anonymous2008-04-29 14:11
Do you guys know *anything* about hash functions? There can be more than one piece of data that matches a hash. Hence, having the hashes of the blocks doesn't give you any information about the data in the blocks. Unless the ammount of information in the hash is the same as the ammount of data. In which case you have the whole file already anyway.
>>13
Except the /a/ guy probably doesn't know what a hash is and is just throwing up words he read somewhere.
Name:
Anonymous2008-04-29 18:46
>>30
Did you even read this thread? Everything you said has been said already. You forget that this is /prog/, even if something is completely stupid or devoid of logic, we always make up a crazy possible scenario of success, where success is not very well defined, just for the hell of it. We're making a mockery of people who believe it's possible to “store” the entire contents of a DVD in a MD5 hash. Reread some of the posts, >>21 is my favorite, it describes the best compression method ever designed.
>>22
OH GOD I LOLLED. Base 64 + instant messaging = infinite bandwidth? GENIUS!
Name:
Anonymous2008-04-29 19:18
>>36 OH GOD I LOLLED. Base 64 + instant messaging = infinite bandwidth? GENIUS!
But nobody mentioned base 64. I think it's your own idea and you are trying to hide your shame by laughing like everybody else.
Name:
Anonymous2008-04-29 19:27
>>35
Anyone who's used torrents before should know what a hash is.
We're making a mockery of people who believe it's possible to “store” the entire contents of a DVD in a MD5 hash.
The joke's on you then. Give me any 700MB avi, and I will hash it to 128 bytes. Then I will extract the original file, using a constant amount of overhead.
>>40 Processing power is growing exponentially; soon we will be able to rebuild files based on its MD5 hashes and their size.
No, we wont. You can't use a 128-bit hash to completely characterize an input of arbitrary length. For a input of length n bits, you'd have 2n - 2128 hash collisions. Assuming an equally distributed hash, that means 2n - 2128 ----------- n
of the collision-causing inputs would be of length n. For any n > 128, this works out to a really fucking big number.
In other words, even if you had the computing power to enumerate all the files that hash to a particular value, you'd still have the problem of choosing the real original file among many plausible candidates, despite the fact that its length is known.
In other words, even if you had the computing power to enumerate all the files that hash to a particular value, you'd still have the problem of choosing the real original file among many plausible candidates, despite the fact that its length is known.
Are there any old, broken hashes or checksums for which you can iterate all possible inputs of a fixed length that fulfill them without going brute force? I'm thinking about small lengths, like 16 bytes with obviously a smaller hash.
Name:
Anonymous2008-04-30 5:46
>>47
there's md4, which is (obviously) like md5, except presumably shitter in some way i don't really know
Name:
Anonymous2008-04-30 5:49
>>44
Yes but you can trim those possibilities down for files that have a distinguishable file format, such as AVI and BMP.
Name:
Anonymous2008-04-30 21:12
>>47,48,49
I wouldn't use a hash algorithm designed for encryption. They are good for checksuming, though.
What we need is nearer to compression. A quick idea[1] i'm thinking: divide the file in 1KB blocks, and hash each one in 8 bits. Every few bytes, a short checksum is added. The decompressor would have many possibilities per block, but most should be discarded by the partial checksums. At the end, it checks every possible block combination againist a global, reliable hash, like SHA-1. The whole thing may be compressed recursively if it's >1kb, and block sizes may vary, but that would require a container format.
>>64
Hi, been a long time lurker on this board.. but I feel I have to speak out at this moment.
Never on The 4Chan Programming board have I seen someone be so funny and with no provocation, I lol'd.
that was amusing and just plain hilarious.
Name:
Anonymous2008-05-04 8:02
>>64
All it takes to crash his program is to call it like this:
./program
Awesome!
u_int8_t
bitcount(u_int8_t byte) {
u_int8_t bits = 0;
int bit;
for(bit = 0; bit < 8; bit++)
if (byte & (0x01 << bit))
bits++;
return bits;
}
Can be changed as
uint8_t bitcount(uint8_t byte) {
uint32_t tmp = byte;
tmp = tmp - ((tmp >> 1) & 033333333333) - ((tmp >> 2) & 011111111111);
return ((tmp + (tmp >> 3)) & 030707070707) & ((1<<6)-1);
}
And a shitload of mistakes and shit... fuck it. fuck that shit. rm -rf ./hzip-0.2; fortune
The bay-trees in our country are all wither'd
And meteors fright the fixed stars of heaven;
The pale-faced moon looks bloody on the earth
And lean-look'd prophets whisper fearful change.
These signs forerun the death or fall of kings.
-- Wm. Shakespeare, "Richard II"
>>63 I'd prefer to ban those who spam /prog/ with ``hacks'' and ``grabs'' first. Your request is completely arbitrary and nonsensical, since this is a worksafe textboard with no ``adult'' content or /b/ faggotry around. Also, there are no mods in /prog/. HYBTT?
>>53 8 bit hashes? for 1KB? that gives 255 possible hashes for about 10^300 inputs. Thats 10^298 for each hash. GB2 highschool
Actually 256 possible hashes.
>>78
considering that MD5 is entirely, completely broken, that's not far off.
Name:
Anonymous2009-07-21 2:48
>>21
I real numbers. and numbers about mention real Myspace. need for can command them has EMAACS mode. vim EMAACS mode. which is SD number in ) TYPE enter ud number UNICODE I ALL ARE I UNICODE SAID AND