@achow101,
Above thread, I've suggested a strategy for different stages of the QC evolution it includes measures and actions to be taken:
1- Implement a new QC resistant signature and install/promote it in bitcoin.
2- starting from the p2pk group of the UTXOs, because they are the most vulnerable segment. It is mandatory for this group to migrate, If they wouldn't, their coins will be announced void after a deadline. More propaganda for convincing p2pkh owners to take actions, no obligations tho.
3- When we are closer to the doomsday, we give anybody with access to the public key behind a hashed address, a right to claim a very tiny and fixed portion of the UTXO just like a txn fee, destroying the remainder. Practically it may be just miners who take advantage of this feature, we don't care.
4- After the QC apocalyptus, we will have a percentage of untouched p2pkh addresses that their public keys are not exposed to the public. For the owners of such UTXOs, there will be still a chance to privately mine their transactions or buying such a service from a trusted pool or mining farm.
There's no reason to take so many steps and add even more special cases to the scripting system. To allow P2PKH but not P2PK requires adding special cases to OP_CHECKSIG which then needs to inspect the script to check whether it was P2PKH. And then you aren't covering things like multisigs or any complex script that uses OP_CHECKSIG. What about if the P2PK was nested inside of P2SH (because that's allowed)? Or people using bare multisig? So now we need to have tons more logic to handle all the weird things people can do with scripts? That's completely unnecessary.
The simpler and easier, and just as safe solution is to soft fork in a hard deadline (that can be several years in the future) where OP_CHECKSIG and OP_CHECKMULTISIG both become immediate script failures thus outlawing ECDSA. People can move their coins to whatever PQC signature scheme is introduced up until that deadline, regardless of script type, and then after the deadline, any usage of OP_CHECKSIG and OP_CHECKMULTISIG is disallowed.
I don't see why it is necessary at all to roll out such a migration so slowly with different script types getting different treatment. And it really doesn't generalize at all.