SHA256 isn't the biggest problem. Grover's algorithm can speed up brute force attacks but even with quantum computers it would still take a very long time to find a collission for keys with correct entropy.
You probably mean ECDSA though , which can be "cracked" using Shor's algorithm if the public key is exposed.

Just in another discussion I mentioned that Bitcoin indeed should be prepared a bit earlier than banks. Banks can update the software relatively fast, they often use cloud banking platforms today, so a centralized update providing post quantum cryptography would take at most a couple of days up to weeks. In the bank use case, it would also not be problematic to provide several algorithms (e.g. FALCON and SPHINCS+) at once, as storage size is not so much an issue, and if vulnerabilities are found they can kept secret and the algo can be changed to another one.

Bitcoin's problem is its slowness: it takes a lot of time to move all coins to post-quantum cryptography. Thus, to ensure a gradual update, the necessary algorithms should be provided when it could be estimated that in the next 3-5 years a quantum threat could emerge, even if the probability isn't that high (let's say 5%).

There are however also emergency measures which could be taken if the threat comes earlier than expected. For example, it could be an idea to temporarily increase the block size to allow people to transfer the coins to post-quantum addresses. Only in the most extreme worst case scenario (out of nowhere a quantum attacker is able to attack addresses "on the fly" in <10 minutes while they spend coins and reveal the public key) Bitcoin would run into real difficulties. Of course it shouldn't be relied upon.

"Not reusing" means that if you make a transaction, you transact all coins to other addresses, including the "change" which will be transferred to a change address, just like most Bitcoin clients do it by default. So the scenario you're trying to install here doesn't make sense. Not reusing means not reusing.

"Exponential" doesn't mean "fast". If quantum computers now have 1000 qubits (most have less), and the progress is 5% per year, you have still way more than 100 years until you get to a million qubits. With 10%, you have 70 years., and even with 20% increase per year (which would be incredibly fast!) you still have almost 40 years.

Only if they use so outdated protocols that they have to re-use addresses.


I agree here, see above. But the post-quantum cryptosystems should also be mature. If you're not ChatGPT, then please read @achow101's post about that issue and provide solid arguments why it's better to deploy untested cryptography NOW instead of waiting let's say 3-5 times more, to be able to make a better decision.

SHA256 isn't the biggest problem. Grover's algorithm can speed up brute force attacks but even with quantum computers it would still take a very long time to find a collission for keys with correct entropy.
You probably mean ECDSA though , which can be "cracked" using Shor's algorithm if the public key is exposed.

Just in another discussion I mentioned that Bitcoin indeed should be prepared a bit earlier than banks. Banks can update the software relatively fast, they often use cloud banking platforms today, so a centralized update providing post quantum cryptography would take at most a couple of days up to weeks. In the bank use case, it would also not be problematic to provide several algorithms (e.g. FALCON and SPHINCS+) at once, as storage size is not so much an issue, and if vulnerabilities are found they can kept secret and the algo can be changed to another one.

Bitcoin's problem is its slowness: it takes a lot of time to move all coins to post-quantum cryptography. Thus, to ensure a gradual update, the necessary algorithms should be provided when it could be estimated that in the next 3-5 years a quantum threat could emerge, even if the probability isn't that high (let's say 5%).

There are however also emergency measures which could be taken if the threat comes earlier than expected. For example, it could be an idea to temporarily increase the block size. Only in the most extreme worst case scenario (out of nowhere a quantum attacker is able to attack addresses "on the fly" in <10 minutes while they spend coins and reveal the public key) Bitcoin would run into real difficulties. Of course it shouldn't be relied upon.

"Not reusing" means that if you make a transaction, you transact all coins to other addresses, including the "change" which will be transferred to a change address, just like most Bitcoin clients do it by default. So the scenario you're trying to install here doesn't make sense. Not reusing means not reusing.

"Exponential" doesn't mean "fast". If quantum computers now have 1000 qubits (most have less), and the progress is 5% per year, you have still way more than 100 years until you get to a million qubits. With 10%, you have 70 years., and even with 20% increase per year (which would be incredibly fast!) you still have almost 40 years.

Only if they use so outdated protocols that they have to re-use addresses.


I agree here, see above. But the post-quantum cryptosystems should also be mature. If you're not ChatGPT, then please read @achow101's post about that issue and provide solid arguments why it's better to deploy untested cryptography NOW instead of waiting let's say 3-5 times more, to be able to make a better decision.