Game theory involving Quantum Resistance protocol

[Carlton Banks]

is it not the case that Taproot/tapscripts output would expose it's public key in it's pubkey script on the chain before it is spent? I'm gonna have to check that out today, I'm not certain

So, it seems my recollection was right, but I got the implications wrong:

The public key is directly included in the output in contrast to typical earlier constructions which store a hash of the public key or script in the output.

...however, the whole point of Taproot is to make P2PKH and P2SH indistinguishable on the blockchain (at least in most typical cases?) And so the actual public key for the private key that can spend an output is either another hashed script, or is provided to taproot's compute pubkey function such that no script path can be used. This still permits using the underlying "real" pubkey (which I think is defined as internal_pubkey in the Taproot BIP docs) to execute a spend of the output.

So, the spending pubkey is actually redefined as a key internal to the taproot script, and the pubkey for the overall taproot script tree is the "real" pubkey, as it is now the key that's actually publicly available! The whole notion of what public key means is therefore not the same in taproot outputs...phew!


Anyone have any idea if this has any implications for QC resistance? My instinct is to say that the internal key is never revealed, because the taproot magic keeps it forever hidden. I expect to be wrong

[1714228695]

1714228695

[1714228695]

1714228695

[achow101]

So, the spending pubkey is actually redefined as a key internal to the taproot script, and the pubkey for the overall taproot script tree is the "real" pubkey, as it is now the key that's actually publicly available! The whole notion of what public key means is therefore not the same in taproot outputs...phew!

Anyone have any idea if this has any implications for QC resistance? My instinct is to say that the internal key is never revealed, because the taproot magic keeps it forever hidden. I expect to be wrong

No, that's wrong.

The public key you see in a taproot output is still a public key. It has a discrete logarithm (aka a private key) and anyone who is able to find it will be able to spend the coins regardless of any internal pubkey or script. The private key for a taproot pubkey (assuming a script) is the private key of the internal key + the hash of the script. The public key itself is computed by the sum of the internal pubkey and the "pubkey" of the hash of the script (i.e. multiply the hash by the curve generator).

For QC resistance and why hashing doesn't matter, see: https://bitcoin.stackexchange.com/questions/91049/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance

[Carlton Banks]

The public key you see in a taproot output is still a public key.

ok, it's a cryptographic key, and it's publicly exposed. But it's not the keypair counterpart to the private spending key, right? Or is "keypair" not meaningful in taproot?

The private key for a taproot pubkey (assuming a script) is the private key of the internal key + the hash of the script. The public key itself is computed by the sum of the internal pubkey and the "pubkey" of the hash of the script (i.e. multiply the hash by the curve generator).

Well when it's explained like that, it seems that I am at least understanding something: there are 2 keys related to the spending (private) key in taproot; the internal key and the "actual" pubkey (by "actual" I mean publicly exposed on the chain). I don't think about this kind of math often enough to really comprehend the relationships between them, despite you having just written it out I know the words, but I can't hear the music

For QC resistance and why hashing doesn't matter, see: https://bitcoin.stackexchange.com/questions/91049/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance

ah, now that's I was hoping for, something definitive

[satoshyknew]

Given that Satoshi's coins are in Pay to public key outputs, the pubkeys are publicly available already. So if we assume Satoshi is dead or otherwise gone, his coins moving would actually be an indication that Quantum computers exist because the only way for them to move (assuming he is no longer around) is for someone to have been able to compute the private keys to those exposed public keys, presumably via quantum computer. In general, it would mean that the ECDLP is has been broken in some way (regardless of QCs) and should no longer be relied upon (i.e. we should move off of ECDSA and Schnorr).

His coins or the 'Shalecoins' (coins with no owner ' https://bitcointalk.org/index.php?topic=5134441.0) moving would actually be an indication that

1. Quantum computers exist

2. ECDLP has been broken in some way

or

3. Satoshi created the greatest prize competition and the privatekeys are somehow within the blockchain. https://bitcointalk.org/index.php?topic=5150688.0 and someone solved it

Nobody is asking why he did not move and is not moving these early mined unmoved P2PK coins:
https://bitslog.com/2013/04/17/the-well-deserved-fortune-of-satoshi-nakamoto/
https://bitcointalk.org/index.php?topic=175996.0

Our guess is that he knew that the early mined coins will be moved one day. So he created a 'prize competition'. Otherwise he could move the coins to quantum resistant P2PKH addresses, but he did not and is not doing.

The only question is:

Who will win the race and get the early coins?

Quantum computing or solving the "Satoshi Prize Competition".

Nobody can stop that race.

[aliashraf]

For QC resistance and why hashing doesn't matter, see: https://bitcoin.stackexchange.com/questions/91049/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance

I afraid, what you have said there is not persuasive. It seems to me that you have chosen not to use hashed keys in taproot and you are just justifying it.

Besides the irrelevance of some points that you have made about the existing exposed public keys and your highly suspicious assumption about miners having mysterious privileges in the presence of QCs, the most confusing part is still your misrepresentation of the main problem.

At the time of this writing, QC is a very expensive technology and it is not scalable, i.e. costs grow exponentially by the scale of the system (number of qubits, number of gates and their resistance level to decoherence, ... ). We are not expecting large QCs showing up out of nowhere, breaking sec256k1 keys in few seconds. Rather there will be generations and development phases and it is highly expected that we will have machines that are able to break bitcoin public keys in feasible time but not in a glance or in few minutes.

Hashed public keys are safe in such a transient phase and what I absolutely don't understand is why we should include a proposal about public keys being exposed for an eternity waiting for their turn to be destroyed by any innovation or technology that shows up?

[squatter]

For QC resistance and why hashing doesn't matter, see: https://bitcoin.stackexchange.com/questions/91049/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance

I afraid, what you have said there is not persuasive. It seems to me that you have chosen not to use hashed keys in taproot and you are just justifying it.

Besides the irrelevance of some points that you have made about the existing exposed public keys and your highly suspicious assumption about miners having mysterious privileges in the presence of QCs, the most confusing part is still your misrepresentation of the main problem.

How is 30% of the existing supply irrelevant?

He didn't suggest miners had mysterious privileges, just that they could censor transactions that don't meet their criteria -- same as today.

At the time of this writing, QC is a very expensive technology and it is not scalable, i.e. costs grow exponentially by the scale of the system (number of qubits, number of gates and their resistance level to decoherence, ... ). We are not expecting large QCs showing up out of nowhere, breaking sec256k1 keys in few seconds. Rather there will be generations and development phases and it is highly expected that we will have machines that are able to break bitcoin public keys in feasible time but not in a glance or in few minutes.

These sorts of arrogant assumptions are dangerous. You have no idea what kind of breakthroughs could be made in the future.

[Carlton Banks]

We are not expecting large QCs showing up out of nowhere, breaking sec256k1 keys in few seconds.

That's not a reasonable expectation, when you consider the range of adversaries

Hashed public keys are safe in such a transient phase and what I absolutely don't understand is why we should include a proposal about public keys being exposed for an eternity waiting for their turn to be destroyed by any innovation or technology that shows up?

That depends massively on how long this transient phase lasts.

The safest thing to do is as suggested in the stackexchange article: soft fork to prevent ECDSA transfers, but invoke zero knowledge proofs of BIP32 seeds to indirectly spend them to QC resistant keys.

maybe if you find this so compelling, you could start working on the zero-knowledge proofs to spend ECDSA outputs to QC resistant keys? Like, today for instance? (you'll be busy a while hopefully ) Won't your super coin (or is it a Bitcoin fork, I forget) need it, or will you stick with hashed public keys? We don't want to hold you back, off you go...

[achow101]

At the time of this writing, QC is a very expensive technology and it is not scalable, i.e. costs grow exponentially by the scale of the system (number of qubits, number of gates and their resistance level to decoherence, ... ). We are not expecting large QCs showing up out of nowhere, breaking sec256k1 keys in few seconds. Rather there will be generations and development phases and it is highly expected that we will have machines that are able to break bitcoin public keys in feasible time but not in a glance or in few minutes.

I agree, and it is mentioned in the article that what is most likely to happen is that we see QCs evolve and get better and better over time. By watching their evolution and planning ahead, we can move to post quantum cryptography before quantum computers even get to the point that they can break ECDLP in feasible time. It is highly unlikely that a QC would show up overnight that can break ECDLP. However, the point of the article is to discuss hashing in the worst case scenario: QCs magically appear and can break ECDLP in feasible time (not minutes, seconds, or at a glance, feasible time is the worst case scenario).

Hashed public keys are safe in such a transient phase and what I absolutely don't understand is why we should include a proposal about public keys being exposed for an eternity waiting for their turn to be destroyed by any innovation or technology that shows up?

There won't be a transient phase. Either we have moved onto PQC by the time QCs can break ECDLP in feasible time, or Bitcoin is doomed.

The reason there is no transient phase and why "feasible time" is the worst case, we need to consider the fact that there are already millions of Bitcoin in outputs with their public keys exposed. They don't need to target new outputs with hashed pubkeys, there are millions of exposed pubkeys already in the blockchain that are with outputs that haven't been touched in years, such as Satoshi's outputs. They could just spend a lot of time cracking those keys, and then at some point in the future after the machine was created, they use all those private keys at once to move a bunch of coins. This would devastate the Bitcoin economy and kill it, unless we move to PQC before that happens (but the attacker would know, and could attack earlier). Either way, hashing did nothing.

If the attacker decides to just slowly steal old outputs that have had their pubkeys exposed, then he's slowly destroying Bitcoin and its value because people's money is being stolen. By the time it's realized, the damage would be done and people would probably panic to get out of Bitcoin before their coins are stolen too. It's extremely probably that the fear that a QC exists that can just steal millions of old coins would kill Bitcoin itself (cause the value to plummet, and people to rightfully no longer trust the cryptography). Either way, Bitcoin is killed.

And of course, in both of these, the attacker has time to just stockpile cracked private keys. During that time, QCs will also improve, so the attacker could get newer and better ones that crack even faster. Or he could just build more of them and crack in parallel. And so long as QCs can break ECDLP in reasonable time, it's only a matter of time before it gets to the point that they can break them very very quickly.

The point of the article is to say that while hashed public keys protects your coins specifically, they do nothing against the millions of already exposed public keys from which an attacker with an ECDLP break can use to wreak havoc and destroy the value of Bitcoin. Yes, your coins will be safe, but they won't have any value, so what's the point?

And all of this was just to say that there won't be a transient phase where hashing matters at all. The attacker will just target the already exposed pubkeys in outputs that haven' been touched in years.

Either we move to PQC before QCs can break ECDLP, and hashing didn't do anything. Or a QC comes along and can break ECDLP, and hashing did nothing because there are millions of available pubkeys with outputs that they can target, and hashing did nothing.


It would be a completely different story if Bitcoin had hashed pubkeys in everything since the beginning (but it did not, pay to pubkey was the expected method of usage) and no one ever reused addresses (so pubkeys were only exposed once and had no value afterwards). If those things were true, then I would say that there is a transient period and hashing does help protect against QCs. But that didn't happen.

[Carlton Banks]

while hashed public keys protects your coins specifically, they do nothing against the millions of already exposed public keys from which an attacker with an ECDLP break can use to wreak havoc and destroy the value of Bitcoin. Yes, your coins will be safe, but they won't have any value, so what's the point?

that's the killer argument

But it makes the case, IMO, for setting a long (several years perhaps) timescale for invalidating P2PK outputs, giving everyone holding BTC at those pubkeys a chance to move funds to hashed pubkeys.

If you believe that the salient factor is how high the proportion of the supply getting stolen by something (not necessarily a QC either) that can solve the discrete logarithm of an exposed public key, then surely if that vast percentage (is it ~20-25%?) of BTC could be encouraged into hashed public keys, then your argument that hashed public keys being safe does not hold, assuming that say 90-95% of public keys are kept safe till being spent? What is the real cost to not hashing taproot keys onchain, just saving space?

[achow101]

while hashed public keys protects your coins specifically, they do nothing against the millions of already exposed public keys from which an attacker with an ECDLP break can use to wreak havoc and destroy the value of Bitcoin. Yes, your coins will be safe, but they won't have any value, so what's the point?

that's the killer argument

But it makes the case, IMO, for setting a long (several years perhaps) timescale for invalidating P2PK outputs, giving everyone holding BTC at those pubkeys a chance to move funds to hashed pubkeys.

If you believe that the salient factor is how high the proportion of the supply getting stolen by something (not necessarily a QC either) that can solve the discrete logarithm of an exposed public key, then surely if that vast percentage (is it ~20-25%?) of BTC could be encouraged into hashed public keys, then your argument that hashed public keys being safe does not hold, assuming that say 90-95% of public keys are kept safe till being spent? What is the real cost to not hashing taproot keys onchain, just saving space?

It's not even just the high proportion, it's also the visibility of some of the coins. In particular, all coins suspected to be Satoshi's are in P2PK outputs. If those moved ever, even to a different sig algo, it would cause enormous chaos. If those are stolen, there would be even more chaos. And those coins are just ~4% of the final money supply. So even if everyone else moved to non-ECDLP keys, the fact that those high profile coins are still secured by ECDLP poses a huge problem.

[aliashraf]

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

The only argument against this strategy, from your side, would be the chaos thing:

It's not even just the high proportion, it's also the visibility of some of the coins. In particular, all coins suspected to be Satoshi's are in P2PK outputs. If those moved ever, even to a different sig algo, it would cause enormous chaos. If those are stolen, there would be even more chaos. And those coins are just ~4% of the final money supply. So even if everyone else moved to non-ECDLP keys, the fact that those high profile coins are still secured by ECDLP poses a huge problem.

While I agree there will be some turbulence but I think it is too much to consider it as chaos. Prices will fluctuate but game theory will work eventually and there will be no catastrophe.

Back to taproot proposal, how do you put it in the context of such a strategy? I'm assuring you right here, right now: this is a must-go strategy.

[aliashraf]

We are not expecting large QCs showing up out of nowhere, breaking sec256k1 keys in few seconds.

That's not a reasonable expectation, when you consider the range of adversaries

Yes, it is. It is how we do our job in technology fields: We study trends and speculate developments then decide. We don't take fiction about a monster that suddenly shows up with super-power, as being serious.

Hashed public keys are safe in such a transient phase and what I absolutely don't understand is why we should include a proposal about public keys being exposed for an eternity waiting for their turn to be destroyed by any innovation or technology that shows up?

That depends massively on how long this transient phase lasts.

It will be long enough: When a technology is in its infancy, i.e. it is not scalable, doubling the speed needs quadratic or higher costs, QC is in such a phase, it is definitively not scalable right now.
If a breakthrough happens in the future and scalable QC technology becomes available, it won't be commercialized for a long time because of governments and military and corporates who need it for their devious plans. It would be very unlikely to be used against the day to day bitcoin transactions. It is also worth mentioning that scalable technology needs time to mature. We are talking about a few years for the least, to be very paranoid.

The safest thing to do is as suggested in the stackexchange article: soft fork to prevent ECDSA transfers, but invoke zero knowledge proofs of BIP32 seeds to indirectly spend them to QC resistant keys.

You need a non-Interactive zero-knowledge proof protocol which is not a piece of cake, it is complicated and both time and space consuming. I don't think it will be ever used in a performance-hungry system like bitcoin. Forget about it.

maybe if you find this so compelling, you could start working on the zero-knowledge proofs to spend ECDSA outputs to QC resistant keys? Like, today for instance? (you'll be busy a while hopefully ) Won't your super coin (or is it a Bitcoin fork, I forget) need it, or will you stick with hashed public keys? We don't want to hold you back, off you go...

Why should you show your trolling face once a week to me?  

For my line of research, the main challenge, regarding this issue, is a time&space efficient QC resistant signature algorithm which is an open problem for the whole cryptography community. Although I don't think it would be a wise decision for me to focus on such an algorithm, I wouldn't hesitate to take part and implement it in my proposal, at any point that we might have become close enough to a consensus about a superior algorithm.

[Carlton Banks]

In particular, all coins suspected to be Satoshi's are in P2PK outputs. If those moved ever, even to a different sig algo, it would cause enormous chaos.

assuming satoshi can still move their/his coins, this is a likely reason why it's not happening. Although we shouldn't discount the most conservative thing that all 2009 era mined BTC key holders could do; start by moving their BTC with the highest block number, and do it very very slowly. Satoshi could potentially do so too (we have zero clue what's going on with satoshi in so many ways), so assuming that chaos was not the intention, I expect that if those coins ever did move, that's what would happen; starting at block ~50,000, then working backwards from there.

In such a sequence of events, it could be interpreted as a signal that those early miners are losing confidence in the safety of ECDLP protected coins. Of course, those people may have other reasons to not publicly announce why they're moving to different keys (which are not necessarily anything to do with the safety of the public key cryptography), so you are indeed correct; the lack of information will cause uncertainty, and the uncertainty will rock the Bitcoin ecosystem.

I hope such people (whether satoshi or not, there are others) are reading some of these discussions (it would surely be prudent to do so). If so, I also hope they will consider a slow and orderly move to new key types, and act sooner rather than later.

[hundredpercent]

assuming satoshi can still move their/his coins

He can but he will not. We think that the early mined coins of Satoshi are created as a prize competition (Re: Maybe Satoshi created the greatest prize competition https://bitcointalk.org/index.php?topic=5150688.0) and that Satoshi is waiting this coins to be moved. We also think that he will not respond when somebody moves the first coins but it will be a message to the Bitcoin community that the private keys are somehow on the blockchain. Satoshi could move the coins (2009/2010) to P2PKH addresses but did not.

[Carlton Banks]

assuming satoshi can still move their/his coins

He can

there is zero evidence of that

but he will not.

and there is also zero evidence of that

We think that the early mined coins of Satoshi are created as a prize competition (Re: Maybe Satoshi created the greatest prize competition https://bitcointalk.org/index.php?topic=5150688.0) and that Satoshi is waiting this coins to be moved. We also think that he will not respond when somebody moves the first coins but it will be a message to the Bitcoin community that the private keys are somehow on the blockchain. Satoshi could move the coins (2009/2010) to P2PKH addresses but did not.

and there is also zero evidence of any of that

in particular, all of the above would be crazy (assuming that satoshi is/was not crazy) if the intention was for Bitcoin to ever succeed. The uncertainty could potentially cause alot of chaos in the Bitcoin economy, it makes little sense to store up such a problem just so Bitcoin might one day catch on fire, for what reason? To enjoy watching it burn? (<--- rhetorical question, although I have this funny feeling some joker in the pack is going to try answering it anyway )

[achow101]

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

[aliashraf]

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

[achow101]

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

What is the point of that? Instead of having two forks, why not just have the one fork have the deadline be farther away so that people have more time to migrate. The point is that during the migration period, ECDLP is still not broken yet.

What is the point of burning the coins? Why would anyone even want to reveal their pubkeys to a miner just to gain nothing? Only the miners benefit from that, it's completely pointless to anyone else. it's the equivalent of just having a fork that completely disallows OP_CHECKSIG.

but we are dealing with a mess, aren't we?

I disagree. It isn't a mess until QCs actually show up. Migration to PQC is pretty straightforward and non-messy, just needs a lot of time and warning.

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

The two forks are just so much more complex than a single fork which disallows OP_CHECKSIG and OP_CHECKMULTISIG after a deadline. And I don't think they're any easier than they seem, consensus and the script interpreter and far more complicated than you think, especially with anything that requires storing state or remembering previously executed scripts.

[aliashraf]

What is the point of that?

Keeping bitcoin promise as far as it is possible and pushing to the limits, it is the point.
Disabling OP_CHECKSIG means destroying wallets that do not follow our orders, It wasn't part of the code, the contract bitcoin has "signed" with the user. You can't just show up with a new address scheme ordering people to migrate. They have a right not to follow, it is constitutional.

What is the point of burning the coins?

As of 2018 June 4, 19% of p2pkh addresses (4,204,148 of 22,275,753) holding 25% bitcoins (4,319,806 of 17,072,361) were revealing their public keys because of address-reuse.

Such addresses are in the most vulnerable state just like their p2pk counterparts and are indistinguishable from more secure p2pkh addresses with unexposed public keys. They should be blocked too but we want safer p2pkh addresses to be kept valid, burning such addresses by miners through an incentive mechanism is what I've recommended.

Why would anyone even want to reveal their pubkeys to a miner just to gain nothing? Only the miners benefit from that, it's completely pointless to anyone else. it's the equivalent of just having a fork that completely disallows OP_CHECKSIG.

It can be a service with a very low fee, centralized and based on trust. The owners of abandoned, expired p2pkh give both their public and private keys to a trusted solo-miner/pool to include it directly in the blocks. lease note that mining is permissionless in bitcoin and there is always a possibility for paranoid minted owners of very fat wallets to lease power and mine their transactions privately.

but we are dealing with a mess, aren't we?

I disagree. It isn't a mess until QCs actually show up. Migration to PQC is pretty straightforward and non-messy, just needs a lot of time and warning.

Forcing people to move their funds and threatening to announce those funds void otherwise? Believe me it is a mess.

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

The two forks are just so much more complex than a single fork which disallows OP_CHECKSIG and OP_CHECKMULTISIG after a deadline. And I don't think they're any easier than they seem, consensus and the script interpreter and far more complicated than you think, especially with anything that requires storing state or remembering previously executed scripts.

Disagree.
Storing state in a single thread of execution of a single script is required and it is nothing more than playing around with one or two booleans and I've explicitly described the rules. This is not dark magic.

[figmentofmyass]

Keeping bitcoin promise as far as it is possible and pushing to the limits, it is the point.
Disabling OP_CHECKSIG means destroying wallets that do not follow our orders, It wasn't part of the code, the contract bitcoin has "signed" with the user. You can't just show up with a new address scheme ordering people to migrate. They have a right not to follow, it is constitutional.

there is a dilemma here. firstly, this scheme of yours involves too much trust---in miners to privately mine transactions without stealing and in p2pkh holders to properly secure their coins. they are theoretically a threat to us all.

secondly, bitcoin's economic design implies what satoshi said explicitly---"Lost coins only make everyone else's coins worth slightly more.  Think of it as a donation to everyone."

so it becomes a point of contention. whose interests are more important---
a. people who want to keep their outputs in vulnerable format for eternity (despite safe alternatives) and who will require trusted/centralized solutions to spend them, or
b. the rest of the bitcoin economy?

even if we table the discussion about needless complexity, bitcoin holders will not be interested in your way. they will prefer a predictable outcome that more reliably ensures that bitcoin's value remains intact.