Are there ideas how to protect P2PK outputs from quantum computers?

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