Quote from: stwenhao on July 19, 2025, 09:46:38 AM

Quote

wouldn’t that make current ASIC miners obsolete, since they're all optimized for the current cryptographic assumptions?

No. If ECDSA will be fully broken, and SHA-256 will be still strong, then nothing will change from the miners' perspective. And if SHA-256 will be broken, then everything else will be broken too (including ECDSA), but in that case, re-hashing the whole chain will be needed. For SHA-256, there are no known shortcuts today, when it comes to post-quantum algorithms, which means, that mining is unaffected, as long as nobody invented any quantum attack on hash functions. Even MD5, which has trivial collisions, is still quantum-safe.

Also, even if no quantum-resistant addresses will be deployed, then still, OP_CHECKSIG alone can be used to require small DER signatures, which would make double-spending harder. For example: https://mempool.space/testnet4/tx/cc159432ffb7a166abeccc79800e9616a09ea9ac6937080c2ca37b38671970e5 (the private key is known, but because coins are protected by Proof of Work, they are still quantum-safe, even though I used OP_CHECKSIG).

Quote

Would such an upgrade render all existing mining equipment useless unless hardware is redesigned for the new algorithm?

No. Even when you have Proof of Work inside Script, then still, applying double SHA-256 on around 200 byte message is not that much different, than applying it on 80 byte block headers. Also, hashed transaction size can be made smaller, to fit on exactly 80 bytes, if needed. Raw Script of "OP_SIZE <difficulty> OP_LESSTHAN OP_VERIFY <templatePubKey> OP_CHECKSIG" can be used now (even if it is non-standard), to hash exactly 80 byte data chunks in legacy transactions, or a new witness can be made, like "<newSegwitVersion> <difficulty>", which would require grinding any message with Merged Mining, meeting a given difficulty.

Quote

How would manufacturers like Bitmain and the rest of the ecosystem adapt?

As long as SHA-256 is safe, no changes are needed. And as long as grinding nLockTime is similar to grinding nonces in block headers, there is not that much to change, so things can be tweaked quite easily. And if SHA-256 will be broken, then it will require re-hashing the whole chain, and re-signing every single message, which would be a huge earthquake everywhere, and in that case, Bitcoin will be the least important problem, if major network protocols, and half of the Internet will burn.

Quote

What would be the timeline for this transition if it ever happens? 5 years? 10?

If you are worried about SHA-256, then you can observe total chainwork. As soon as it starts getting close to 2^128, then upgrading SHA-256 to something else will be needed, because then, the whole effort of Bitcoin network from N years would be sufficient, to produce a single SHA-256 collision (and still: having 2^128 chainwork could mean for example 64k blocks with 2^112 chainwork each, which still means, that it will be rather "one collision per year" than "one collision per 10 minutes", and we will still have plenty of time to react, if it will happen gradually).

Quote

And finally, how would this affect small/retail miners who are still heavily investing in current-generation hardware?

In general, big miners push small ones away, and it is harder and harder to compete. As Satoshi said, there will be big server farms. And smaller ones will probably switch to something else, or will be focused on producing just enough Proof of Work, to protect single transactions from double-spending. Because in general, if you use "pay to Proof of Work" output types, then even if your private key is publicly known, you can safely run a second layer network on top of Bitcoin, because as long as double-spending your coins require re-mining them, and it takes more than 10 minutes, then you can adjust your difficulty, to finalize your transactions on-chain for example every three months (like proposed in sidechain BIPs), and then, no attacker will be strong enough, to compete with the whole, honest network, and produce a second double-spending version in 10 minutes.

Which means, that even if mining 80 bytes Bitcoin block headers will be too hard for smaller miners, then still, they can be used to protect second layers with their Proof of Work (which could be smaller than in Bitcoin, but still significant, and resistant to double-spend attempts from most attackers). Also, as long as mining template for "pay to Proof of Work" outputs will be unknown by the outside world, it is quite unlikely to see any double-spending attempts at all.

Quote

Is this a real threat we’re underestimating, or just distant speculation?

Just observe total chainwork, and you will know, how close we are. Or put your coins on "pay to Proof of Work" outputs, if you want to be sure, and observe, how many of them will be stolen, and how much time it will take. It is possible to make a mainnet puzzle, similar to what I made in testnet4, or even launch some decentralized sidechains on top of mainnet, and by putting coins in, it can be measured, how much Proof of Work is needed to be safe. So far, nobody took even a single test coin out of my addresses, so I think attacks are quite unlikely, because for now, nobody is interested in stealing my coins (but of course, mainnet test would be more bulletproof, than my testnet4 examples; but I don't have around 2k mainnet BTCs to replicate it there).

Thanks a lot for your detailed response — very informative and helpful! I appreciate you taking the time to clarify all these points.