What needs to be changed when SHA-256 is broken?

[garlonicon]

I am trying to read the github thread but it is probably beyond my capabilities.

Everything is explained in that linked topic: https://bitcointalk.org/index.php?topic=5365359
Technical details are in this post: https://bitcointalk.org/index.php?topic=5365359.msg58166756#msg58166756

In other words - is it easily repairable for the next versions?

Yes, it can be fixed for Bitcoin Core. But: that version 22.0 and some versions around it are affected and will be affected. That means, those clients using these versions will crash in 2038.

(state of the UTXO set at some block height?)

Could be. If you start doing hard fork, then from that moment you can do everything, and build something that will not even be a blockchain at all. Because if that backward compatibility is broken, it does not matter if you cross that border by an inch or by a mile.

then the new nodes would sync only from the new Genesis Block?

I think they should check everything, but yes, if you freeze UTXO's in time, then you can skip it, because then they are hard-coded by consensus. Also, doing such freeze make things less resistant to chain reorgs. For that reason, I think we don't need any new Genesis Block. One is enough for everything we need.

[1715451954]

1715451954

[1715451954]

1715451954

[Adam_xx]

Thanks again, garlonicon, for all your answers!

[Adam_xx]

One more thing - could potentially extension blocks be a solution for this?

I mean to start a "new parallel" SHA-3 chain like an extension block chain, with interoperability (people can move coins from "old" to "new" and vice versa) which can last even for decades.
If SHA-256 is then dangerously close to being broken, could the original chain be somehow eliminated/merged into the extension block chain without the coins not moved to "new" being lost?

[vjudeu]

If SHA-256 will be fully broken, then the answer is no. Just because you can reach SHA-256 collision or SHA-256 preimage and include SHA-3 for something else.