Topic: Why rely on a single hash function? - page 3. (Read 607 times)

Thank you, I will now spend a few days learning the concepts required to understand your response

Yes true, there doesn't seem to be any possible immunity from someone using a break for adding blocks very profitably.

However, they could only add *new* transactions, and not rewrite the entire blockchain from genesis to suit their fancy.

The crux idea is about pre-image resistance of SHA256 but a bigger issue would be a collision resistance, which is weaker than the pre-image.

Any breaks in a pre-image resistance is incremental and slow over time it is simply too difficult and unrealistic to expect the entire algorithm to be broken overnight. In addition, because we require the inputs to be a specific format and also ensures that it is valid at the current state, it wouldn't be a stretch to think that the pre-image wouldn't necessarily result in a valid Bitcoin block.

Having alternate PoW schemes would provide no additional tangible security benefits while making it more complicated.

Hmm... Doesn't the danger remain?

Alright, so let's say we used SHA-256 for even blocks and Keccak-256 for odd blocks. Now let's assume SHA-256 is broken. Now all the even blocks can be generated at will, without (the same) work. The attacker can still use half of his computational power to reverse transactions. In fact, he can still cheat the entire bitcoin economy by solving blocks within seconds, censoring/emptying the block's content.

Edit: He can actually reverse transactions with much less hashrate than half of it. If he's broken SHA-256, he can create one block whose work equals thousands'.

Dear Bitcointalkers,

I apologize if this question has been dealt with, but I haven't found a good answer to it:

Why is it not a terrible idea to rely on a single hash function (i.e. SHA256)?

Supposing that SHA256 was broken, wouldn't the entire accumulated Proof-of-Work become irrelevant all at once? And thus, wouldn't the entire transaction history be at immediate risk of being replaced by a longer chain?

I am sure there must be a good reason, but why not use at least two hash functions? Say, using function 1 for even numbered blocks, and function 2 for odd numbered blocks. That way, if function 1 is broken, it can be switched out with a better one, and during this time the transaction history is still protected by the accumulated PoW of function 2. I can see a drawback with this scheme: specialized hardware for function 1 may be utilized only 50% of the time, likewise for function 2. Perhaps a scheme in which two chains are constructed in parallel, one chain per function, but 'braided' together (a new block referring to the latest block of each chain) could avoid this problem.

I can certainly see potential issues in either case, it would complicate the design, and KISS is a good principle in general. However, what of the fundamental danger? Am I missing something? (Probably).

Humbly,
LH