And one can also argue that the existing P2PK/P2MS etc. UTXOs shouldn't be touched at all.
Some people disagree with that:
Against Allowing Quantum Recovery of BitcoinI guess that means that arbitrary data could be stuffed into these signatures?
Yes. For example, in the current secp256k1 implementation, when you have a Schnorr signature, it can take 64 bytes. If quantum-resistant signature would take for example 64 kB (completely broken image resistance), or maybe even 64 MB (completely broken video resistance), then it could be used not only to protect users from quantum computers, but also to store a lot of arbitrary data on-chain. Which means, that the new scheme should not require significantly more resources from node runners.
Also, someone already shared, how different models can affect block sizes:
Is there any alternatives to replace ECC?
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
| Name | PrivK | PubK | Sig | Security | PubK | Sig | block | average |
| | bytes | bytes | bytes | bits | *secp | *secp | *secp | block MB |
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
| secp256k1 | 32 | 32 | 64 | 128 | 1.0 | 1.0 | 1.0 | 1.3 |
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
| RSA 2048 | 512 | 256 | 256 | 112 | 8.0 | 4.0 | 6.0 | 7.8 |
| RSA 3072 | 768 | 384 | 384 | 128 | 12.0 | 6.0 | 9.0 | 11.7 |
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
| Dilithium2 | 2528 | 1312 | 2420 | 128 | 41.0 | 37.8 | 39.4 | 51.2 |
| Dilithium3 | 4000 | 1952 | 3293 | 192 | 61.0 | 51.5 | 56.2 | 73.1 |
| Dilithium5 | 4864 | 2592 | 4595 | 256 | 81.0 | 71.8 | 76.4 | 99.3 |
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
| Falcon-512 | 1281 | 897 | 666 | 128 | 28.0 | 10.4 | 19.2 | 25.0 |
| Falcon-1024 | 2305 | 1793 | 1280 | 256 | 56.0 | 20.0 | 38.0 | 49.4 |
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
| Sphincs+ | 64 | 32 | 7856 | 128 | 1.0 | 122.8 | 61.9 | 80.5 |
| Sphincs+ | 96 | 48 | 16224 | 192 | 1.5 | 253.5 | 127.5 | 165.8 |
| Sphincs+ | 128 | 64 | 29792 | 256 | 2.0 | 465.5 | 233.8 | 303.9 |
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
Looks also interesting but wouldn't this make transactions even heavier?
Well, that way is compatible with scripts. If we would have only "pay-to-quantum-resistant" addresses, spendable with just a single signature, then it would be similar, as if we would have only P2PK, and nothing else. Which means, that if instead of OP_CHECKSIG, there would be OP_CHECK_QUANTUM, then it would be needed to handle more than a single signature, or to combine some signatures in a "OP_CHECKSIGADD"-ish way, and turn N quantum-resistant signatures into a single one, equivalent to executing N heavy, separated signatures in a sequence, and checking if M of N of them are valid. In other words: people would also need multisig in post-quantum world. And they would probably also need scripts.