So we have Post Quantum signatures out there (like dilithium and falcon). A big reason I keep hearing for not using these signatures is their massive key sizes, which are about 20 times bigger than ECC keys.
But why don’t we just implement something like a P2PQPKH (Pay to Post Quantum Public Key Hash) opcode? It would give us a fixed size output through hashing, just like the P2PKH that we already have on the blockchain.
Plus, these PQ signature schemes could help tackle some issues from BIP360 related to those pesky "short exposure attacks". I get that we still have problems with signing and key storage on cold wallets, but honestly, that seems minor compared to fixing those bigger problems.
The "key size" objection is really a witness-size objection at spend time. This is the reason hashing isn't the solution. Witness data at spend time is where the cost is, and you can't resolve this by paying to hashes of pub keys instead of pub keys.
ECDSA is 32-byte pubkey + 72-byte sig. Falcon-512 is ~897-byte pubkey + ~666-byte sig. That's 15x. And at spend time, you have to reveal both pubkey and sig.
It's also worth to mention some QC-resistant signing cryptography require much much computation to sign, verity or both sign/verify.
I'm not sure if it can be considered as strong candidate, but both SHRMPS and SHRINCS sometimes mentioned as better choice than others. See,
https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158
https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-signatures-across-multiple-stateful-devices/2355
Because to implement a new signature algorithm, a new bech32 address type is required.
You can't just add a new algorithm to existing addresses, because the code for running the old signing function is already ubiquitous in legacy code.
This is the same procedure used by Taproot developers when they wanted to add Schnorr signatures.
How is this relevant to the question? A new bech32 address type is just a client-level thing, no consensus is required to add a new one. You would obviously not use the same bech32 address type for a new P2QRH script that would already imply a soft or hard fork.
I think almost all of them require hundreds of times more time to sign, which is really not the main problem. The main problem is verifying, which is not terrible for some algorithms.
I'm speaking from a user interface perspective. Of course, there are ways to add quantum signing algorithms for existing segwit and even legacy addresses, but I think it's fair to say that a good amount of end users and businesses would be confused if we did things like that.
There is no way to retrofit post-quantum (PQ) signatures into existing SegWit or legacy addresses. Their UTXOs are locked to scripts that explicitly require ECDSA or Schnorr, so they cannot be spent using a different signature scheme.
Yeah, the existing utxos cannot be changed, but I'm saying you could do something like define a new transaction version eg. 4, and then draft a BIP that defines outputs created by version 4 (hypothetically) transactions be required to use a scriptpubkey defined for quantum, while allowing both ecdsa/schnorr signatures in transaction inputs and whatever the new wuantum format would be.
The definition of a new version would be so that existing software works the same way.
Edit: and also make quantum v4 utxos unspendable in previous tx versions by throwing an error.
IMO signing could be problematic on slower device, especially on hardware wallet and really old phone/mini pc. I don't how long it would actually take for each signature on such device, but it would impact UX if it took longer than 10 second for average TX.
Your idea have some similarity with P2SH-P2WPKH. But i don't think it's worth it considering because,
1. Due to new QC-resistant cryptography, they still must do many other things including integrate new cryptography library on their wallet app.
2. Average people can't be sure whether the generated address is QC-resistant or not, since it's used for multiple purpose.