Topic: What needs to be changed when SHA-256 is broken? - page 3. (Read 478 times)

Let alone that if it hasn't even shown a sign of weakness, as ECDLP has, it won't do any good all. No one tells us that the new algorithm won't become weak in few decades, but the system will get less efficient. There's also the temporary community upheaval asides.

If there is a flaw found, then it's first come, first serve. You can't get around it because there isn't an unquestionable registry of attached names to all the addresses used, and there won't be.

As BHC suggests, it may be that addresses subject to the flaw will be locked, but it's the same effect as if they were not locked: the value goes down. If it becomes trivially easy to crack the hashes of old unused addresses, then all associated bitcoin will automatically become worth less and less in either case without a new solution. Locking them might actually cause a bigger crash then coming to a different solution.

Another solution rather than locking them is changing the fungibility between address types - like enforcing an additional (transaction?) cost with a new kind of address when coming from an older address.  Right now, all kinds of addresses can be traded to the other kinds of addresses, but if a critical flaw were discovered, that should not be the case. It would create multiple networks within a network, which I suspect is unavoidable over a very, very long period.

Because we don't know what the most severe flaws will exist yet, it's fine to have fungibility between address types. Having several strong hedges against flaws hopefully helps. Blindly discovering the key to any reasonably random address is costly and probably impossible right now, regardless of address type. Presently having multiple address types provides a protection against those unknowns, such that including even P2PK despite Pollard's kangaroo provides a protection, because the other addresses may have flaws yet undiscovered.

Bitcoin has proven itself against numerous flaws over the past 13 years, and so is reasonably well established. Moving to new types of hashes may present worse unknown flaws without as rigorous of testing.

Not that I'm a genius when it come to hash functions, but wouldn't it be much more likely to have 160-bit collisions (from RIPEMD-160) first? I remember reading that SHA2 is more computationally expensive than RIPEMD-160. That would mean drastic measures way before 256-bit hashing algorithms become weak.

Multi-sig Pay-to-Witness-Scripts are SHA256 encoded with bech32. SHA256 is also used in address generation of every other address type, although the 256-bit number that is resulted from it is then hashed with RIPEMD-160. This shouldn't change unless RIPEMD-160 became weak. Then, it's the Lightning Network.

I have a feeling that it won't be that hard. As far as I know, Bitcoin has had a hard fork only once, with the value overflow incident, but if it's a necessity (as it was in 2010), I believe consensus will be found.

In other words: If it's favoring every user, it's reasonable to assume that there won't to be a lot of noise. If we're bordering on benefits, such as back then with the block size war, it's going to be tough.

There are two choices.

• We leave them untouched, which means they can be taken by those who own the required computational power.
• We announce that SHA256 will not be recognizable by the hard-forked client after block x. This could leave few years for their owners to upgrade to a collision-safe algorithm. Those who had lost access to them or wouldn't want to upgrade for some reason, would have them removed from the hard-forked Bitcoin's circulation.

I have found a lot of threads about PoW but not much about other aspects of SHA-256 dependence so I hope this won't be a duplicate.

Assumptions:

1) Let's say we know that SHA-256 is weakened in every possible way (collisions/preimage attacks/second preimage attacks) and will become risky to use within 10 years.
2) We have 10 years to migrate (we know the attacks will be possible but will come gradually, not overnight)
3) Let's say we have a safe replacement in the form of, for example, SHA-3 (just theoretically, it can be any hash function of the future, it is not important for the following questions)

How critical do you think the situation would be for Bitcoin? Not particularly concerned about PoW at the moment.

Questions:

1) What would have to be upgraded in Bitcoin besides mining - txids, merkle trees, block headers, signature hashes?
2) How hard would be to migrate these parts of Bitcoin with a minimum damage?
3) What would happen to all the UTXOs in e.g. P2SH, P2WPKH, etc. - could they still be moved after the hash function change (which would be a hardfork probably)?

I know we probably won't have to deal with this in our lifetime, but again, in theory, I would like to know how you think about a similar emergency scenario.

Thanks a lot!