Just tossing this out here:
The only option is to introduce a new quantum resistant address type and give everybody plenty of time to move across to it (in the order of several years). What happens with coins that don't move becomes the real issue here - do we either decide as a community to permanently lock them* so they can never be moved again, or do we just ignore them and let them be stolen by whoever manages to first and then re-enter the general circulation. I am in favor of the latter option.
*Perhaps the best option, but one which would need a lot more work to be viable, would be to lock all these coins but provide a mechanism to unlock them if the real owner can provide some quantum-resistant proof that they are indeed the real owner. An example would be if I could prove that I owned the seed phrase which generated a given wallet or address. Such a mechanism (if developed) would only solve this issue for seed phrase generated addresses though, and there are a lot of vulnerable coins in P2PK address and other non HD wallets that this does not address.
In theory, this could be done without revealing the seed, using a zero-knowledge proof: In theory, any operation that can be performed by a computer can have its correct performance proved in zero knowledge. In practice, I think that running BIP39 (replete with 2048 iterations of PBKDF2-HMAC-SHA512!)
and BIP32 inside an arithmetic circuit would be obscenely expensive. Zero-knowledge proof coins go to great lengths to design protocols that are efficient inside a ZK arithmetic circuit—sometimes even inventing their own cryptographic primitives. SHA2 functions are bad mojo here.
In an emergency, for a one-time movement of vulnerable coins, perhaps it may be feasible even to do some expensive operations.
Furthermore,
zero-knowledge proofs would allow secure spending of coins from some keypool keys, etc. It seems impossible to provide any help there: If the public key has been exposed, then the only secret information can be deduced by an attacker with a large quantum computer. But
if the public key has never been revealed, then you can reduce this to the security of the hash. Anything that can be reduced to the security of a hash smells good!
Perhaps Greg Maxwell’s later-regretted meme about the safety of not revealing public keys may have some merit, after all. Racing a quantum attacker to spend your coins is a bad idea, when you need to reveal the public key to spend your coins.
But a ZK proof could let you never reveal the public key! Prove in zero knowledge that you know a private key, which produces an undisclosed public key, which has the publicly known hash.Caveat: I had the idea for how to do this about three seconds ago. The idea may be broken or infeasible.
And in all of the above, I won’t go beyond handwaving. We would anyway need to see what the future state of the art is in post-quantum ZK proof systems. Current systems are a mixed bag. zk-SNARKs seem to have
some limited resistance to
some quantum computing attacks, but are probably not useful here; zk-STARKs are fully post-quantum. This is a hot research area, and the state of the art has advanced very rapidly in the past 9 years. IMO, as of 2022, zk-SNARKs have only just reached maturity for the current generation of deployed use cases. Given that PQ crypto is itself a hot research area, I would expect that researchers should be interested in advancing the state of the art for PQ ZK proofs.
On a related note, I have some clever ideas for how at least a little bit of PQ crypto could be kludged into Bitcoin right now—to let people
efficiently record in the blockchain a PQ way to claim their coins in this type of scenario. (There are obviously some inefficient ways to spam the blockchain for this; don’t do it!) Will not yet discuss: I usually try to break the security of my own oh-so-clever ideas, before I foist them on others. If more people did that, there would be less noise on this forum.
Yesterday, I began to write a reply to some of the other above posts re the titular topic of “burner addresses”, i.e.
trap addresses. I need to learn to write terser, less detailed technical posts.