Quote from: znort987 on June 11, 2012, 12:36:08 PM

Quote from: Meni Rosenfeld on June 11, 2012, 12:15:53 PM

I did a calculation which says that every application of SHA-256 reduces entropy by about 0.5734 bits. I have no idea if that's correct.

Mmmh.

Does that mean that sha256 ^N(some 256bit input) for N sufficiently large
would always converge to the same value, independent of the actual input.

No, because the assumptions I made become less true the more rounds are done (maybe they're not even accurate enough after one round). The set of all possible images of SHA256^N becomes smaller for larger N until it converges to a fixed set (which is probably very large). Then SHA-256 is a permutation (one-to-one mapping) on this set. (This is true for every function from a space to itself).

Quote from: znort987 on June 11, 2012, 12:36:08 PM

Quote

Quote from: znort987 on June 11, 2012, 11:12:00 AM

First, do we actually *know* that sha-256 is *not* a one to one mapping on the 256 bit space ?
If it turns out to be, then you've got nothing. I don't know the answer, I'm not a professional cryptographer,
but looking at the code for SHA-256, there doesn't seem to be an obvious dropping of bits within
the transform step itself, but then I am too lazy to analyze it in-depth.

SHA-256, as a cryptographic hash function, aspires to be indistinguishable from random. If it was in fact random, the number of preimages for every 256-bit element would follow the Poisson distribution - about 36% would have no preimage, 36% would have one, 18% two, 6% three and so on. So I'd say it's almost certain that it's not a 1-1 mapping.

Very interesting observation, and you're probably correct.
Even more interesting would be to find a way to measure if that
is indeed the case (even if the verification is in a monte-carlo sense)

That's probably as hard as determining whether the function is broken.

Quote from: znort987 on June 11, 2012, 12:36:08 PM

Quote

Quote from: znort987 on June 11, 2012, 11:12:00 AM

Finally, what someone said: the likely intent of the team who designed bitcoin was to slow mining down, not to
add a layer of security there.

What could that mean? The difficulty controls the mining rate. If a hash function half as hard would be chosen, the difficulty would double and you'd have the same generation rate.

You're right, but then I'm not entirely convinced by the 'this buys use time the day sha-256 gets cracked' either.
If that was their concern, why not combine two wildly differing 256-bit hash algorithm and XOR the result ?

That probably could work too, but that also doesn't guarantee improves security. Maybe the two hash functions are actually connected in some unexpected way and the XOR is actually weaker than either.

SHA-256 itself is multiple iterations of a basic function. I'm guessing it is assumed that the basic function itself is ok and that the more times you apply it, the harder it is to attack.