Does the block hash function need to be cryptographically secure?

[SapphireSpire]

Cryptographically secure hash functions are irreversible so that ciphertexts can't be decrypted by running the function in reverse. But none of the data in a block is encrypted. The block hash is just a checksum, so it shouldn't need to be cryptographically secure. Am I wrong?

[1714678374]

1714678374

[1714678374]

1714678374

[1714678374]

1714678374

[tromp]

Cryptographically secure hash functions are irreversible so that ciphertexts can't be decrypted by running the function in reverse. But none of the data in a block is secret, so the block hash is just a checksum, and shouldn't need to be cryptographically secure. Am I wrong?

If someone find SHA256 pre-images, i.e. given y, find an x with SHA256(x)=y, in time 2^240, i.e. 2^16 times faster than brute force, then SHA256 would be considered broken, and in need of replacement, although not urgently.

Such an attack need not have any bearing on the cost of bitcoin mining though.
The latter corresponds to find *partial* preimages.

As long as finding a preimage to n leading 0s, for n up to say 100, takes time roughly 2^n, then bitcoin mining is unaffected. If someone has a partial preimage attack where they can get by with say 2^{0.9n} then they get an unfair advantage at mining.

[odolvlobo]

Cryptographically secure hash functions are irreversible so that ciphertexts can't be decrypted by running the function in reverse. But none of the data in a block is encrypted, so the block hash is just a checksum, and shouldn't need to be cryptographically secure. Am I wrong?

A hash function does not do encryption, but still your question is valid. My understanding is that a secure hash function is not strictly necessary for mining because any flaw would presumably be exploited by all miners, and that would simply increase the difficulty.

Edit:

However, as Pooya87 points out below, a less-than-secure hash function introduces problems related to block chain integrity.

[vjudeu]

the block hash is just a checksum, and shouldn't need to be cryptographically secure

If so, then introduce a given weakness, for example in regtest, and then just write some tests to find out.

My understanding is that a secure hash function is not strictly necessary for mining because any flaw would presumably be exploited by all miners, and that would simply increase the difficulty.

You cannot increase difficulty "ad infinitum". There are cases, where things are so broken, that you need some additional "fix". For example: imagine that you replace regular SHA-256 with just SHA-256, reduced to the first 16 rounds. Then, you would need to change consensus rules, for example into "SHA-256 should give this hash, and SHA-3, applied on the same data, should give a number below given target". Because if you don't, then everyone will exploit that weakness. And there is always a limit, how "weak" you can make something, without making it "totally broken".

[pooya87]

You are confusing a lot of concepts. In your comment you are closer to the definition by calling it a "checksum" than calling it "encryption". We aren't doing any kind of encryption in Bitcoin and there is no ciphertext either.

What we have in hash functions is a digest, a fixed length result that is irreversible regardless of whether the function was cryptographically strong like SHA256 or not like Murmur3.

The reason why a cryptographically strong hash algorithm is needed in something like Bitcoin is their characteristics such as collision, pre-image and second-preimage resistance.

For example if a non-cryptographic hash were used for Bitcoin PoW the problem won't just be faster computation and higher difficulty. The problem will be the fact that anyone could easily change anything in the mined block and produce the same hash hence effectively nullify Bitcoin's blockchain's immutability since such functions lack resistance against attacks I mentioned.