An Easy Update for Quantum Resistance

So, real upgrades to fight quantum threats have a lot of issues to deal with. Should we just ban address reuse right in the protocol? Every transaction could use a fresh change address. Wallets could be updated to automatically create new change addresses for users, plus show the balance of that new address right after the transaction. I mean, most wallets these days are HD wallets, so they can generate endless addresses without messing with the user's mnemonic. And while we’re at it, let’s switch out P2TR addresses for P2MR addresses. This way, the public key would only be out in the open for about 10 minutes, making it way tougher for quantum computers to break into the BTC network.

How do you want to do that in practice? If public key Q could be used only once, then people will use Q+1, Q+2, and so on. There are many ways to connect public keys in patterns, which would be easy to recognize, but hard to block. Also note, that even if you have coins like Monero, then still: some people can use weak private keys or signatures, for example equal to one, and weaken everyone else's privacy by doing so. And there is no way to fully block it. Not all transactions have a change address. Sometimes, it is simply not needed. Also, it is good for privacy to pretend, that you used a change address, while in practice, you sent everything to multiple recipients. Which means, that if you want to avoid address reuse, then just use a wallet, which can support Silent Payments correctly. It will take some time, to introduce it through a new soft-fork.

Not reusing addresses is already normal, wallets do it by default. Forcing it in the protocol feels kinda unnecessary. The idea about hiding the public key longer sounds nice, but quantum isn’t really a real threat yet.

If you disable address reuse at the protocol level, then using the network for recurring payments, for example for services, would be very difficult, if not impossible.  Also, for example, donations.  Any business with a "Donate here" QR code or a subscription model would have to generate a unique, one-time link for every single customer interaction.  It would be a logistical nightmare.

Or just share a single Silent Payment address. In general, the problem with address reuse, is that initial rules allow it. Which means, that it is hard to block, because there is a risk, that there are for example two different timelocked transactions, sending coins to the same destination. But if something would be created from scratch, then it could have built-in rule, to disallow address reuse, just like txid-reuse is disallowed. When public keys are forced to have a particular offset, for example like it is in TapScript, then you won't have that problem. Because it is hard to have txid, txid+1, txid+2.

I was thinking the main problem with the reuse of address in the context  of quantum resistance was just the public key vulnerabilities to attacks as its being exposed. Because I know for a fact that when someone send you funds /coin to your address, it is only the hash that is on chain, the actual  public key always stays hidden.  that’s why unspent UTXO are always considered safe from the quantum threats. Or am I getting it wrong?

As long as all public keys in use are based on secp256k1, it doesn't matter. When there will be something else, then Silent Payments could be updated accordingly. Well, for secp256k1, you currently need around 2^128 operations to break a public key. For 160-bit hashes, you need around 2^81 computations, to find a collision, and move coins from identical addresses in at least two different ways, which will undermine trust in all 160-bit addresses, and push people to move to longer hashes, or different output types. https://groups.google.com/g/bitcoindev/c/M1mh66rmI1c/m/24JXJsEICQAJ Which means, that P2PKH, P2SH, and P2WPKH can be potentially attacked in practice, if someone would build some ASICs, and use some storage for lookup tables. It is doable, but costly. While breaking arbitrary public keys is still more theoretical, than practical, at least for now. In the famous puzzle with weak public keys, 71-bit hashed key is still unsolved. And for public keys, there is 135-bit key. Assuming by the current progress, people are closer to reaching 81-bit hashed key, and having enough power for making 160-bit collisions, than they are to breaking 256-bit random public keys (the puzzle ends on 160-bit public key, but to make things practical, the range of public keys from 161 to 256 bits have to be considered as well; it makes more sense, when keys are not hashed). Of course, quantum progress can change these things, but currently, we have, what we have. And even if someone thinks, that hashing is enough to protect public keys from quantum attacks, then still: 160-bit hashes may be too short for that.