If it takes 1.5-3 years to get the entire ecosystem of software updated, tested, implemented and then allow users to migrate to quantum safety, then Bitcoin code is future proofed. It will still require months (if BTC blocks normal transactions) to years (as a supported address type but not required) in order to migrate the wallets to safety. The longer the quantum resistant upgrade is delayed, the harsher the migration will need to become.

Alice and Bob recently announced a new algorithm that breaks ECC-256 in 9 hours with 127k qubits. https://alice-bob.com/blog/computing-256-bit-elliptic-curve-logarithm-in-9-hours-with-126133-cat-qubits/ The algorithms will continue to improve and the costs will continue to go down. While some people are very confident what the quantum hardware will look like in 3 years, can they be so confident about the algorithms? We have switched from supercomputer to network node method of growing quantum calculations. Parallel instead of Serial. Fault tolerant algorithms that prefetch results. Can we really be as confident about the algorithms as people seem to be about the hardware not being ready? Most people in quantum computing aren't aware of how much their competition has progressed, how can devs who don't read 10 or 50 new quantum computing papers per week be more confident than the people who do?

On Wednesday, January 1, 2025 at 1:25:24 PM UTC+1 David A. Harding wrote:

On 2024-12-16 12:20, Tadge Dryja wrote:
> An on-chain proof of quantum computer (PoQC I guess :) ) would be a
> way to reduce the damage of activation forks. One way to build it:
> Create a NUMS point pubkey - something like described in BIP341. Send
> some coins to that address, then watch if it gets spent. [...]
> Nodes can then have code which
> watches for such a proof and changes consensus rules based on it.

I think this could be even more useful if combined with a previous idea
far creating a NUMS[1][3] (or trust minimized[2]) pubkey compatible with
Bitcoin but with a security strength less than 128 bits. That way
someone might claim the bounty of the key with (say) 96 bits security
potentially months or years before QC advances made regular keys
insecure and tempted operators of QCs into stealing from regular user
addresses.

-Dave

[1]
https://gnusha.org/pi/bitcoindev/CAH5Bsr20n2T7KRTYqycSUx0i...@mail.gmail.com/
[2]
https://gnusha.org/pi/bitcoindev/aRiFFJKz5wyHFDi2dXcGbNEHZD2nIwDRk7gaXIte-N1BoOEOQ-ySYRnk0P70S5igANSr2iqF2ZKV1dWvipaQHK4fJSv9A61-uH7w4pzxKRE=@protonmail.com/
[3]
https://gnusha.org/pi/bitcoindev/CAH5Bsr39kw08ki76aezJ1EM9...@mail.gmail.com/