prettyrandom100

Since IP filter will rule out many sensitive contents that is said about corporation, government, I'm fairly certain it can be ruled out as a good indicator of spam. If it is a spam, is it that hard to just look at the content, I think not!

shouldn't the spam filter be looking at content and not the IP from where it is posted ?

What's your idea of BIG ? This is not at all helpful if you don't state the amount.

I never said anything about the competence of the staff, it's just the politics. Also I'm not talking about insuring against the bug, but meriting a bug (or any work) based on the difficulty/impact.

Will definitely love to work with some people but think others are just bad influence. Also, the way I see it, the company burnt bridges. I will be polite, but I don't want to do anything with them anymore, product or employment wise

I fully agree with you. Will try my best to screen next time around.

What if the bug was severe security bugs, several of them which definitely helped make the software better ? I've been a firm believer that there are "million dollar bugs" that could destroy the product completely, shouldn't those be considered big problems for world's organizations ? I think I might have already learned these things you pointed out in the 1 year I spent, does adding one more year really help much ?

Or I could start my own company and see how that goes ? I really don't buy into 85% people succeed due to sycophancy and even if they do I don't think I want to be one.

There is just one 3MB file and we divide that file into 1000 parts. I agree there will be collision per hash (for each part). But I'm skeptical that all 1000 hashes will produce such bits so that the final file will cause collision on the hash of the original file (remember we do have hash of the original file). If the final hash does not match the hash of original file we would have to recompute all the hashes again by randomly generating the bits for each 1000 file-parts. Do you mean to say that the collisions are guaranteed and that the collision inside any file-part will also cause a collision in the original file hash when the parts are combined ?

Do you mean that there could be two 3K files with the same sha256 hash and the probability of hitting the collision is greater than the probability of finding the correct hash for the file ? Let's divide the 3 mb file into 1000 parts, each having a ~3k size. Take sha256 hash of all 1000 parts and sha256 hash of the actual file. The size of these hashes are less than the actual file + leaves ample room for a decompressor. Now start brute-forcing and assume we have all the run-time power and time. Would the probability of collision happening in all 1000 parts be very low then ? Given a good hashing function could it be so low that we can disregard it ? If 1000 is not enough, can we increase the splits to 2000 or 3000 ?

I didn't see anything that mentions run-time in the challenge. I think a good compression challenge should mention about run-time. Theoretically, it would be possible to hash parts of the file and then brute force the hash in the decompressor. This would take a lot of time but would work.