Next scheduled rescrape ... never
Version 1
Last scraped
Scraped on 12/07/2025, 00:32:38 UTC
if I could crack btc sha-256

 I likely could crack crypto  used for banks.
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 Smiley, 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.

Once a transaction is made and the pubkey is on-chain (as happens with any spent P2PKH, P2SH, multisig, Lightning, etc.), the address becomes a permanent target. At that point, “not reusing” is no longer sufficient.
"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. Wink

As for the tech evolution: the jump from “breaking an old P2PK key in a year” to “doing it in 10 minutes” seems big, but progress in quantum computing is exponential, not linear.
"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.

That includes legacy multisig outputs, contracts, sidechains, and bridges.
Only if they use so outdated protocols that they have to re-use addresses.

Having a transition plan ready is essential.

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.
Original archived Re: Bitcoin must upgrade or fall victim to quantum computing in 5 years
Scraped on 12/07/2025, 00:27:49 UTC
if I could crack btc sha-256

 I likely could crack crypto  used for banks.
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 Smiley, 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.

Once a transaction is made and the pubkey is on-chain (as happens with any spent P2PKH, P2SH, multisig, Lightning, etc.), the address becomes a permanent target. At that point, “not reusing” is no longer sufficient.
"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. Wink

As for the tech evolution: the jump from “breaking an old P2PK key in a year” to “doing it in 10 minutes” seems big, but progress in quantum computing is exponential, not linear.
"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.

That includes legacy multisig outputs, contracts, sidechains, and bridges.
Only if they use so outdated protocols that they have to re-use addresses.

Having a transition plan ready is essential.

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.