Caveat: SHA256 broken==blockchain corrupted--your BTC transferred ta hax0r's wallet--irreversible. You can hardfork the ashes all you want, your money's gone. Poof! Fini.
You need to work in your FUD.Your scenario is less incorrect for ECDSA than it's incorrect for SHA256.
FUD? Simply replying to a
If you wish, I could bring up yet another catch: can't hardfork in real time. The most recent patch (can't remember, something about 7TPS limit or 21 mil. max coin limit) has been in the works for forever, the one addressing SHA256 haxoring might take a bit longer
Real problems tend to be resolved with remarkable speed. The BDB mis-config was a classic example and was actually quite impressive. How fast a similar thing would happen today is not clear, but it remains the case that genuine problems are rapidly addressable.
In the case of the transaction rate, things are much slower because a decent percent of the players (including myself) consider some of the leading proposals to address the 'problem' to be an attack on the system and one which will sink it. And we don't want to see that happen. WRT the 21 mil, even stating that as a problem demonstrates some combination of ignorance and deceit (and worse still, a lack of a developed sense of humor.) There is a real problem here, but if you don't mention undependable outputs it shows a lack of understanding and rigor.
Hopefully we can get to a point where core Bitcoin can simply freeze in a know working state and provide support to a multitude of sidechains. This will protect Bitcoin core against unintended development failures and preserve it in a form where hard-fork resolutions to severe problems are resolvable with similar effectiveness of the BDB issue. One of the many advantages of this would be that many sidechain economies could move on relatively unimpeded while any potential core Bitcoin issues were resolved. That is a key advantage of the right balance of abstraction in system design.