Are there ideas to protect P2PK outputs from quantum computers (e.g. Hourglass)?

[d5000]

At a first glance, it seems impossible to protect P2PK (and P2MS, P2TR ...) addresses from quantum computer attacks. The public key is already known, so a quantum attacker could compute the private key only based on blockchain data and thus easily produce proofs about the knowledge of the private key.

But there may be data elements that only the original owners could know, at least in some cases. And these elements could then be additionally required to move P2PK funds.

For example, if a P2PKH address with still protected key is known, and that address can be safely attributed to a person which also has P2PK outputs, then one could require a signature from this non-vulnerable address to move the P2PK coins. Of course I'm thinking about Satoshi here. Is there a P2PKH address known that can be attributed to Satoshi but was not used, i.e. the public key is not known?

I also think the Hourglass idea presented in 2025 by Mike Casey is interesting: limit the BTC which can be transferred from P2PK addresses, for example to 1 BTC per block. This would be perhaps the most straightforward idea, although it doesn't provide 100% protection, it would take 50 blocks at minimum to steal a single Satoshi block reward and it would reduce the efficiency and privacy of the hackers (they would be detected very likely before they could transfer the whole output).

It could be elaborated further, e.g. that only 0.1 BTC from the same address can be moved per block. And that amount could reduce over time, e.g. per difficulty period to counter the improvements in quantum computing.

Of course that would also limit the capacity of the real owners of these BTC to react to a threat and to move the coins fastly. But for example I can imagine the following recovery protocol:

- Instead of moving your P2PK funds, you can designate another address as a recovery address. This addresses private key must be used in the next transaction spending the P2PK output, and in the same tx, you have to designate a quantum-resistant address to be used in further transactions.
- This address must have received coins in the same year or at least the same halving period when your P2PK output was created, but its public key must not be known. (Yes, that's a difficult requirement, but otherwise the quantum attacker can designate any address.)
- The recovery address must be related in some way to your P2PK funds (e.g. there were some transactions between both addresses/keys, or they were related to the same mining pool ...).


These are of course stupid layman ideas, but I'd be interested if experts came up with something similar.

[goldkingcoiner]

I cannot think of anything that would not include rollbacks or softforks.

But this is a theoretical problem that might be moot, if true quantum computers turn out to be unachievable.
The closest we might get to a quantum computer is a clever algorithmic imitation.

[Donneski]

The uncomfortable reality is that once the public key is exposed (as in P2PK), there isn’t much you can really add later without effectively redefining ownership. Any extra requirement risks becoming subjective or socially enforced rather than purely cryptographic.

That’s why the hourglass idea feels more grounded to me. It doesn’t pretend to make exposed keys safe again, it just slows down a potential attacker at the consensus level. That seems more in line with how Bitcoin usually handles hard problems... mitigate the damage instead of trying to rewrite the past.

[NotATether]

Why not just send them to unspent P2WPKH addresses instead of discussing this via BIPs and mailing list emails for weeks and months?

Sure, that's not much better, but at least the hash160 step is not trivially breakable like public keys.

[d5000]

That’s why the hourglass idea feels more grounded to me. It doesn’t pretend to make exposed keys safe again, it just slows down a potential attacker at the consensus level. That seems more in line with how Bitcoin usually handles hard problems... mitigate the damage instead of trying to rewrite the past.

I tend to agree with this. The approach I presented in the previous post doesn't seem bulletproof.

Maybe Hourglass alone is enough. A multi phase Hourglass approach where the amount of BTC allowed to be spent from P2PK reduces over time, e.g. each difficulty period, could strengthen the incentive to transfer them as fast as possible. Each difficulty period change would work as a deadline and incentive the P2PK holders to finally transfer their coins to safer addresses.

There could even be an additional incentive for the P2PK key owners to transfer their coins before the Hourglass deadline: They could get a free transaction to either a P2PKH or a quantum safe address (if available), which would not be counted towards the block weight. This would not be easy to organize as a soft fork. At least it should be possible to create some kind of "bonus" for them.

To avoid a fork and possible volatility, miners could also operate in an altruistic manner including zero-fee P2PK to P2PKH/post-quantum transfers from now on. This would of course not be fully altruistic, because each P2PK to P2PKH transfer prevents a future dump. What do miners think about that?

Why not just send them to unspent P2WPKH addresses instead of discussing this via BIPs and mailing list emails for weeks and months?

Well, tell that Satoshi, and the other 2009 miners.

I think every 2009/2010 mining reward moved is actually good news, not bad news as some dumb bears want to interpret. It's only 50 coins per output, nothing compared to the hundreds of thousands of BTC traded on exchanges each day. It's possible that this even slows down the migration to P2WPKH, as these old hodlers could think they could dump the price if they move their coins.

PS: Hourglass BIP draft is here: https://github.com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki

[NotATether]

Well, tell that Satoshi, and the other 2009 miners.

I think every 2009/2010 mining reward moved is actually good news, not bad news as some dumb bears want to interpret. It's only 50 coins per output, nothing compared to the hundreds of thousands of BTC traded on exchanges each day. It's possible that this even slows down the migration to P2WPKH, as these old hodlers could think they could dump the price if they move their coins.

Abandoned coins are abandoned, we as developers shouldn't be trying to control whether users should send their coins to another address or not. That should be their responsibility.

PS: Hourglass BIP draft is here: https://github.com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki

I don't like this. We should never be disabling specific address types for any reason.

[MarryWithBTC]

For example, if a P2PKH address with still protected key is known, and that address can be safely attributed to a person which also has P2PK outputs, then one could require a signature from this non-vulnerable address to move the P2PK coins.

Remember that if a quantum computer can be able to break through, the private key can be derived from the exposed public key right? If this happens, it means that the attacker can be able to produce a signature. So, how will the network differentiate between the attacker and the original owner, since both can produce valid signatures?

I also think the Hourglass idea presented in 2025 by Mike Casey is interesting: limit the BTC which can be transferred from P2PK addresses, for example to 1 BTC per block. This would be perhaps the most straightforward idea, although it doesn't provide 100% protection, it would take 50 blocks at minimum to steal a single Satoshi block reward and it would reduce the efficiency and privacy of the hackers (they would be detected very likely before they could transfer the whole output).

This could be viable if it is only Satoshi's holding we are looking at. In general, active owners might be trapped from speedily moving their coins. But I prefer this to the first proposal.

But in all, it will be more realistic to consider total migration rather than protection, even if migration will be slow

These are of course stupid layman ideas, but I'd be interested if experts came up with something similar.

I'd also be interested in what experts will say.

[Satofan44]

PS: Hourglass BIP draft is here: https://github.com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki

I don't like this. We should never be disabling specific address types for any reason.

If security is not an adequate reason to disable something, that it not a characteristic of decentralized consensus -- it is a characteristic of decentralized consensus failure. Some decentralization idealism has corrupted the space whereas it is paraded as a zealot pseudo religion with some arbitrary rules and ideas that have nothing to do with decentralization. Given adequate necessity, one of which is security and a complete compromise -- you can disable and stop things in a decentralized system too. I might following your reasoning and introduce "we should never disable ECDSA for any reason", it sounds even more ridiculous.

Abandoned coins are abandoned, we as developers shouldn't be trying to control whether users should send their coins to another address or not. That should be their responsibility.

We are not developers, we are users in a decentralized system that has governance. Of course we should do things that are in our objective interest. This BIP does not do anything controversial at all. There is no freezing, there is no seizure, there is no expiration date, nothing. Stop finding useless reasoning against good ideas, this is one where you should help facilitate consensus rather than combat it.

There are roughly 34,000 P2PK addresses with an average balance of 50 coins each. Hourglass reduces the amount of P2PK coins that could hit the market to a maximum of roughly 7,200 coins per day.

Without a spending constraint, over 6,000 P2PK transactions could be executed per block-- potentially releasing more than 300,000 coins per block to the market. All remaining 1.7M P2PK coins could be spent in just a few hours if no mitigations are present.

It is not even that limiting, that is a lot of coin per day.

There is absolutely not a single valid reason not to disable the creation of new P2PK outputs. Therefore, I do not understand your concern on that point. Whether the limitation of spending is going to be effective or whether this is the right path to go is open for debate, disabling spending to P2PK addresses should not be. That is not a controversial change, Core should implement that as a policy rule first while we talk about consensus in the meantime.

[d5000]

Abandoned coins are abandoned, we as developers shouldn't be trying to control whether users should send their coins to another address or not. That should be their responsibility.

We should of course not control them in the sense to force them, but with the goal to incentive them to do so, I see no problem. Almost everything in Bitcoin is built on the incentive concept.

I don't like this. We should never be disabling specific address types for any reason.

But why? Nobody uses P2PK anymore (with the exception perhaps of fake public key NFT folks). Some opcodes like OP_CAT were disabled in the past and could have been used for different output scripts, which is almost the same thing than new address types.

P2PK has a slight security advantage over P2PKH when it comes to collissions in traditional computing but attacks on that "vulnerability" are in the "impossible" territory from today's point of view and the quantum risk seems much "realer". You could argue that you could also use P2PK for quantum puzzles. But you can do that also without P2PK (simply reuse any address, or put the pubkey in OP_RETURN, or whatever).

I believe it is more likely that P2PK outputs are created as a result of a mistake than for these few niche reasons. And thus new creations should not be needed.

By the way, I see I've misinterpreted the Hourglass proposal ... it's actually proposed that only one P2PK output should be able to be spent per block, not 1 BTC from P2PK outputs. This looks much cleaner technically, but would also be less effective in my opinion. Actually that would mostly be effective against a very large adversary with an extreme advantage with respect of the rest of the actors, who could hack several P2PK outputs per block. This scenario doesn't look very realistic in my opinion. And 50 BTC are still a quite good prize for a "puzzle".

[stwenhao]

it's actually proposed that only one P2PK output should be able to be spent per block, not 1 BTC from P2PK outputs

https://github.com/cryptoquick/bips/blob/hourglass-v2/bip-hourglass-v2.mediawiki#specification

Once activated:

1. Only one P2PK output may be included as a transaction input per block.

2. If the amount of the P2PK output being spent is greater than 1 bitcoin, the transaction must contain a single output to the scriptPubKey of the original P2PK output with an amount no less than the original P2PK output amount minus 1 bitcoin.

3. No P2PK outputs to any address not currently being spent from can be created.

4. No P2PK outputs can be created from other output types.

So, it is both: only one P2PK, and only 1 BTC from it.

Also, that means if some output has 50 BTC, then there will be 50 signatures needed to move it. Which also means, that with each and every signature, outside observers will have more and more clues, what the private key could be. A key itself may be random, but what if signatures are too weak, and will be vulnerable for example to lattice attacks?

I wonder, if it would be safer, when less signatures could be used, if more time passed. For example: instead of moving 1 BTC every block, what about getting all 50 BTC in one shot, after seeing 50 blocks with no other P2PK spends?

[mcdouglasx]

Those bitcoins could easily be moved. If Satoshi or any other owner holds the private keys, when they detect any kind of insecurity or risk, they'll move them to a more secure location. I think we shouldn't make any drastic changes to Bitcoin in that regard, otherwise imagine what would follow... someone important is hacked or loses their keys, do we implement something to recover the hacked or lost money? It would become an unnecessary chain of adjustments.

[d5000]

So, it is both: only one P2PK, and only 1 BTC from it.

Thanks! I think my confusion came from the two different versions of Hourglass that exist.

And I agree with your fear that the 50 signatures needed could be itself a security risk. For me still I'd prefer another approach.

Hourglass v3 could for example be based on the following new rules:

1) New P2PK outputs can't be created.
2) 1 BTC can be spent from existing P2PK outputs if the following format is respected:

- output 1 contains up to 1 BTC and can go to any address.
- output 2 contains the remaining coins but locked in a contract which impedes immediate spending for a long time (e.g. several weeks). This could be either a CLTV/CSV script, or even better: a covenant (if available) which determines that the following transactions also have to follow a similar format (1 BTC freely spendable, the rest locked for a long time).

This could be actually a very interesting use case for covenants. The effect desired is that there cannot be a mass sale of "quantum hacked" coins, and quantum hackers maybe could be tracked down until they can spend the coins. Thus, if we rely on CLTV/CSV, the period of locking would have to be very long because the typical 50 coin output would allow 49 coins to be spent in the second step, and thus we'd have to delay that step as long as possible. Covenants could reduce this time, it could be as short as a day or so if we can make sure the subsequent transactions can also only spend 1 BTC.

Alternatively, without covenant, one could also allow a "cascade of CSV contracts" with 1 BTC on each output, for example with the first output freely spendable, the second output locked for 100 blocks, the third one for 200, the fourth one for 300 and so on.

Even if this is probably a very amateurish proposal I believe there's much room for improvement for Hourglass.

[nc50lc]

- output 2 contains the remaining coins but locked in a contract which impedes immediate spending for a long time (e.g. several weeks). This could be either a CLTV/CSV script, or even better: a covenant (if available) which determines that the following transactions also have to follow a similar format (1 BTC freely spendable, the rest locked for a long time).

I wonder how this can be implemented.
Because to the network, "output 2" looks like just another P2TR/P2WSH scriptPubkey unless the redeem script is exposed to verify that it follows those requirements.
The original proposal requires it to send the change to the same scriptPubKey which can be easily verified but indeed has those mentioned issues above.

Maybe a new distinguishable scriptPubKey that can only be spent with a specific script containing those requirements?