How can we shield P2PK outputs from quantum computer threats?

At first, it looks like there's no way to defend P2PK (and P2MS, P2TR, etc.) addresses from quantum attacks. Since the public key is already out there, a quantum hacker could easily figure out the private key using info from the blockchain, which means producing proof of knowing the private key would be a cakewalk. But, there might be some data points that only the original holder would know, at least in a few situations. These could be needed to access P2PK funds. Like, if there's a P2PKH address with a secured key that's definitely linked to a person who also has P2PK outputs, you could require a signature from that safe address to spend the P2PK coins. I mean, Satoshi comes to mind here. Is there a P2PKH address connected to Satoshi that hasn’t been used, meaning the public key isn’t out there? I also find the Hourglass concept brought up by Mike Casey in 2025 pretty intriguing: capping the BTC that can be moved from P2PK addresses, say to 1 BTC per block. This could be the simplest approach, although it won’t give complete protection. It would take a minimum of 50 blocks to swipe a single Satoshi block reward, and it would likely hinder the efficiency and anonymity of the hackers since they’d probably be caught before they can transfer all the outputs. This idea could be expanded, for example, allowing only 0.1 BTC from the same address to go per block. And this limit could decrease over time, maybe with each difficulty shift, to keep up with advancements in quantum tech.

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.

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.

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.

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

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. I don't like this. We should never be disabling specific address types for any reason.

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? 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 I'd also be interested in what experts will say.

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

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

https://github.com/cryptoquick/bips/blob/hourglass-v2/bip-hourglass-v2.mediawiki#specification 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?

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.

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.

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?

We are going to reach a point where private keys can be derived from those addresses, so it won't be the owners who are claiming them. Therefore, this post is false and unnecessary. What you imply will follow has nothing to do with this proposal, nobody is "recovering" anything. As I said, we should implement this right away and without this proposal -- this would make it a proposal that is not controversial, because the details of the hourglass proposal can always be debated on their merits and allegedly better variants of it can be proposed. What would tracking down do though if we are talking about dead addresses and addresses of people that have lost their keys or are deceased? In those cases, we can't really distinguish from the outside what has actually happened. Did the old owner wake up? Did they somehow find their lost keys? Or was this a compromise by quantum computers? We can calculate some probabilities but that is not irrefutable proof. It would be good for existing users and legal entities, but if those have not changed to updated and secure solutions in the meantime then they are just unprofessional. Yes, hence let's separate the P2PK banning from it. It is not a bad limit. Realistically speaking, one would be foolish to still use P2PK and even more foolish to not spend it before this proposal or one similar to it goes live. Therefore, in practice this is not going to harm anybody aside from a few foolish people or entities -- and it will be only their own fault. We should never refuse to apply such measures because there may be some idiot somewhere that for whatever reason insists on using P2PK or keeping P2PK outputs. In any case, this kind of solution is much better than not doing anything at all or worse freezing coins. Slow reintroduction back into the circulating supply, and then the problem will be officially solved forever.

Indeed, good observation. If it's implemented with covenants of course it depends on the specific covenant implementation, but I guess it would be for sure TapScript so the scriptpath would be hidden too. Of course a "hack" would be to simply publish the redeem script via OP_RETURN, so it can be instantly verified. I think this doesn't work because we'd need the signatures. Perhaps something like homomorphic encryption could help. I would agree with that, however I think even the P2PK restriction alone (see NotaTether's post above) would also not be totally uncontroversial. No, I meant the specific case if someone notices his P2PK coins have been stolen by a hacker (quantum or not) he would have time to track down the hacker with the help of chain analysis companies. That is, as far as I understand, one of the possible advantages of the Hourglass proposal. The possibility to be tracked down and jailed (if BTC is recognized as property) would lower the incentive to quantum hack coins (together with the other goal that you can only sell 1 BTC per day/week - depending on the specific implementation).