Should wallets warn if you re-use addresses due to quantum computers?
Yes, of course. And they should also warn about many other things, for example that a partially signed transaction, which is signed with something else than SIGHASH_ALL, can be modified by third parties.
Your public key will be revealed when you broadcast a transaction spending from that address, which means the quantum attacker can RBF and steal your funds even though you only used your address once.
Even if secp256k1 will be fully broken, it will be still possible to use OP_CHECKSIG in a safe way, as long as SHA-256 will still be safe, and Proof of Work will be enforced properly. Some example:
https://bitcointalk.org/index.php?topic=5551080.0If someone will break secp256k1, without breaking SHA-256, then that person could clear puzzles from 60 to 40, but going further will still require gradually breaking SHA-256.
Aren't we using public key in P2TR outputs as well?
Yes, we are. But P2TR can be spend by key, or by TapScript. Spending by key can be blocked in the future, if needed, and then, quantum-safe paths will be executed inside TapScript. As long as SHA-256 is strong, this approach would work. It is not yet decided, if quantum-safe addresses will be deployed inside TapScript, or if a new address type will be made.
the move to a new algorithm should be done through a hard fork with a deadline and any coins that don't move before that deadline should be considered unspendable
Making coins unspendable can be done as a soft-fork. Even invalidating all existing UTXOs is still a soft-fork, see here:
https://petertodd.org/2016/forced-soft-forks#radical-changesThis still makes me think that why was Taproot even created when we did not see its benefit than input consolidation.
Because it allows N-of-N multisig, which looks in exactly the same way, as a single user, spending things with a single signature.
Do you have an idea what an exchange could do instead of their current setups?
They could use HD wallets, and use a tree of public keys, to derive next addresses. Then, key derivation path could contain user ID, transaction ID, and other unique data. In this way, when each deposit will be done on a different address, they won't be broken all at once, as long as public keys, which are used to derive them, will remain hidden.
Multisignature helps but is that all that we have on the table right now?
No, Proof of Work can be used, too. But I guess not everyone wants to be a miner, and using optional Proof of Work to limit double-spending ability of some third parties also comes with a cost of grinding transaction hashes, which is huge, if there are many inputs and outputs.
Are you saying that simply not having a warning about address reuse makes using Bitcoin unsafe?
Well, if your coins are not KYCed, but you make a transaction on a chain, where everyone else went through KYC, then everyone knows, where you are. Which means, that by reusing your own address, you make everyone else's coins less private, because if you have a new key, then it introduces
deniability, and then, people are no longer sure, which coins are owned by whom. By reusing addresses, coins owned by the same party can be linked together.
This is why I don't believe there is a good and practical solution for exchanges and institutions.
It is all about not having all eggs in the same basket. Which simply means not having a single re-used address, but some HD wallet, where compromising a single key would compromise a single deposit, from a single user, and not everything, sent by everybody.
Of course, funds can be accumulated into bigger denominations, if needed. But in practice, quite often, they don't have to be. You don't need a huge transaction, collecting hundreds of satoshis into whole coins, and then another wave of transactions, splitting them back. If someone deposited 100k sats, and someone else requested a withdrawal of 99k sats, then that coin can be moved directly, with 1k sats in fees. Which means, that coins can be accumulated when needed, and a given coin doesn't have to be merged from 100k sats into 100 BTCs, and then splitted back into 99k sats.