SHA-256 could be more broken than SHA-1 and it would still serve perfectly well for mining.
If you don't reuse addresses then even if ECDSA is broken then your coins are still safe. And ECDSA being broken is pretty much the darkest scenario. In which case it can simply be replaced with something else starting at specific block.
> SHA-256 could be more broken than SHA-1 and it would still serve perfectly well for mining.
Sure, but the block header only commits to the double-SHA256 hash tree of transactions. If SHA-2 was broken I could create a single block header that commits to two different valid histories, allowing arbitrary double-spends and irreconcilable divergent views of the network.
Not to mention being able to spend anyone's coins by finding alternate pub keys or hashes that collide with their committed p2pkh or p2sh outputs.
Transactions follow very specific binary format. I don't think it's even plausible that you could find collision within those constraints. Plus, as you said it is double hashed. So then you would have to find collision within small fixed amount 32 bytes. It's just not happening.
Regarding the second one, google bitcoin address collision, it was repeated so many times with great analogies that I'm not going to try to do it here yet another time.
The post I was responding to was the exact hypothetical “if SHA-2 were broken...”
All arguments about collision and preimage resistance are based on the assumption of SHA-2 doing what we think it does. A catastrophic break of SHA-2 would destroy the bitcoin ledger.
SHA-256 could be more broken than SHA-1 and it would still serve perfectly well for mining.
If you don't reuse addresses then even if ECDSA is broken then your coins are still safe. And ECDSA being broken is pretty much the darkest scenario. In which case it can simply be replaced with something else starting at specific block.
RIPEMD-160 just hides your public key.