Quote from: achow101 on October 25, 2019, 03:30:05 PM

Quote from: aliashraf on October 25, 2019, 05:48:03 AM

@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.

Oh, thank you for being so specific, it is what I always expected from you.

unlike what it looks like the strategy is not that complicated, it is about two deadlines instead of just one, this is it!

We need two deadlines because we should deal with three radically different cases:

Case #1: P2PK UTXOs (including multisigs); they are exposed to the first wave of commercially available QCs that are able to break ECDSA in feasible time.

Case #2: Compromised P2PKH and P2SH UTXO; they are compromised in the sense that their corresponding raw counterparts are leaked either because of address re-use or other reasons like transaction generation process, wallets being implemented with loose security considerations, ...

Case #3: Abandoned P2PKH and p2SH UTXos; they are wallets that do not follow the recommended practice of migrating to the new PQC scheme and are vulnerable to hijacking by scalable and commercialized QCs capable of breaking secp256k1 keys on the fly.

In the big picture, each of the above cases is radically different and deserves special treatment. My proposed strategy covers this situation by 2 soft forks or a two-phase fork.

Fork #1: Implement a PQC scheme, set a deadline for P2PK and multisigs to migrate, announce them void thereafter (kick them out of the UTXO set practically)

Fork #2: Up to a deadline, simulate an advanced zero-cost QC attack by letting any miner who has access to the corresponding public key of the address is authorized to spend it into a null address deducting a fixed fee. After the deadline, we are back to the normal situation.

As of implementation considerations:

I understand the second fork is messy but we are dealing with a mess, aren't we? Noways to minimize the damage unless you get hands dirty, no choice. And yet it is not too much, implementing both forks is easier than what they look like in the first glance:

Fork #1: besides the PQC scheme, the script processing engine should fail OP_CHECKSIG after the deadline whenever an OP_HASH160 or OP_HASH256 is not executed freshly and followed by an OP_EQUALVERIFY. Script processing engine can take care of this by maintaining a flag that is set with OP_HASHxxx and reset after the execution of any OP_CODE other than OP_EQUALVERIFY while OP_CHECKSIG checks whether this is flag is set before doing anything, easy.

Fork #2: Before the second deadline OP_CHECKSIG always pushes 1 (true) if a special flag is set. This flag is set if the transaction follows a defined format which guarantees that after deducting a predefined amount it is burning its (single) input to a specific (void) address. This behavior is reset to default after the deadline.

Interestingly, unlike what happens with your, rough approach, p2pkh legacy wallets that are not been moved for any reason are expendable for eternity as long as they are privately mined (not being relayed in the public network before being confirmed) in the presence of QC equipped thieves.