J. Lopp's Proposal for Bitcoin's Post-Quantum Upgrade

A group of authors has put together a BIP draft aimed at updating the Bitcoin network to a new cryptographic standard that can withstand quantum attacks. Here’s a quick rundown of what they’re suggesting. The authors include: Jameson Lopp Christian Papathanasiou Ian Smith Joe Ross Steve Vaile Pierre-Luc Dallaire-Demers They've laid out a three-phase plan to transition Bitcoin to this new post-quantum cryptography. Their idea is to adopt the proposed P2QRH output types and phase out ECDSA/Schnorr signatures. They believe it's crucial to switch to the new signature scheme because of the potential risks posed by future quantum computing. So, here’s the breakdown of the three phases: Phase A is a soft fork. - During this phase, Bitcoin will stop issuing new outputs using the current public key formats. - Payments will only be allowed to the new quantum-resistant P2QRH outputs. - Users need to start moving their funds to the newly proposed standard. - The plan is to activate this as soon as P2QRH outputs are live on the network. Phase B - There'll be a deadline set after which spending and signing with the old ECDSA/Schnorr signatures will be off the table. - This requires a change in consensus rules, and nodes will reject the outdated signature formats. - Any UTXOs that are vulnerable to quantum attacks won't be spendable anymore. - They’re suggesting this deadline should be around five years after Phase A kicks in. Phase C (Optional) - An option could be added to recover old legacy UTXOs that didn’t get migrated in time. - This would help users who still have the private keys and seeds for those UTXOs.

I think sending to old output types should be made non-standard, but not invalid. Because even now, you can send coins to "OP_TRUE", or to "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL". If every existing output type will be disabled, then it would simply mean, that we will no longer have any Script. Again: Non-standard? Sure, why not. But I don't think invalidating it is a good idea. Also because new, quantum-resistant addresses may be considered unsafe in the future, may be broken classically, may be used to post JPEGs on-chain, and so on. Later, if people will migrate, and if everyone will be sitting on a quantum boat, then we may consider invalidating things, but I think we should start from non-standardness first. Again, it is a good reason to never invalidate UTXOs, which were previously valid and spendable. If things will be harder to spend, but still spendable, then recovery could be still possible. Which means, that if someone wants to invalidate UTXOs, then instead, it is better to require additional proof from the very beginning. Which means, that to spend for example old P2PK output, a regular DER signature would be required, as it is today, and also, a new requirement can be added, to put some ZK-proof or something like that in the witness space, in the quantum-commitment space, or wherever it fits. It could bring us more features, than some people may expect. For example, if it would be possible to go from every existing public key, to every existing private key, then OP_CHECKSIG will become just some 256-bit calculator, with built-in addition and multiplication. And then, many interesting Scripts could be deployed on top of that, for example "<signature> <pubkey> OP_CHECKSIG" as the output Script can be spendable, and then it can be used instead of proposed OP_CHECKTEMPLATEVERIFY. Not only that. Also, the solution would then be more suited to the particular attack, which would materialize on-chain. When SHA-1 collisions were produced, hardened SHA-1 version was made, to block a particular attack, and not protect us from all possible collisions. Which means, that if some weakness in ECDSA will be published, then that particular weakness will be addressed by some source code, and not all cases, where ECDSA could be broken. In general, if OP_CHECKSIG will be fully broken, and if revealing any public key will be equivalent to sharing the private key, then still, there will be many scripts, which would still be unspendable, or hard to spend. For example: "OP_SIZE 10 OP_LESSTHAN OP_VERIFY <pubkey> OP_CHECKSIG". Even if public key is equal to the generator, then still, moving such output will probably require breaking SHA-256 as well. No hard-fork will be needed, if coins will be timelocked, instead of being burned. Also, outputs with zero satoshis can be used, and then, the whole implementation of coin amounts can be changed, while all old nodes will see every transaction moving zero coins in all inputs into zero coins in all outputs.

I do not follow much about P2QRH but with what I have read, probably it will have larger signature than the current one which are not resistant to quantum computing. I mean both ECDSA and Schnorr. Hope it will not have significant effect on the mempool? I like the proposal if the Phase C is part of it.

depends on the signature weight. is we go from a few bytes to a KB or more it bottlenecks the pool , very quickly. SPHINCS+ for example is stateless but takes up like ~70k bytes.

The signature size explosion is perhaps the most underappreciated challenge here. P2QRH's SPHINCS+-128s signatures are 7,856 bytes - that's 164x larger than current ECDSA signatures. Even the more efficient FALCON-512 at 690 bytes represents a 15x increase. This isn't just a storage problem - it fundamentally alters Bitcoin's economic model. Transaction fees calculated by size would increase proportionally, potentially making small-value transactions economically unfeasible. We could see Bitcoin's throughput drop from ~7 TPS to less than 1 TPS with SPHINCS+. The quantum threat timeline adds urgency that the BIP doesn't fully capture. IonQ's roadmap targets 1,600 logical qubits by 2028, potentially sufficient for breaking secp256k1. Google's Willow chip demonstrates exponential error reduction with scale. We're not looking at a distant theoretical threat - we're potentially 3-5 years away from cryptographically relevant quantum computers. The 5-year Phase B timeline might already be too generous. If ECDSA is fully broken - this is actually a fascinating observation. However, the security implications go deeper. Approximately 25% of Bitcoin's supply sits in quantum-vulnerable addresses, including Satoshi's ~1 million BTC in P2PK outputs. If quantum computers emerge before migration completes, we could see a race condition where quantum-capable actors attempt to sweep these vulnerable funds, potentially causing massive market disruption. The ZK-proof recovery mechanism in Phase C is technically ambitious to the point of being speculative. Proving knowledge of a BIP-39 seed phrase that generates a specific address through HD derivation, all while maintaining zero-knowledge properties, requires cryptographic constructions we haven't fully developed for Bitcoin's context. This isn't just a implementation detail - it's a fundamental research problem that could take years to solve properly. What's particularly concerning is the minimum 76.16 days of continuous processing time required for network-wide upgrade under optimal conditions. This assumes perfect coordination and no complications - historically, Bitcoin upgrades like SegWit took years to achieve meaningful adoption. The mandatory nature of this migration creates an unprecedented coordination challenge. Alternative approaches from other projects offer interesting perspectives: QRL's use of stateful XMSS signatures works but requires careful key management that doesn't align with Bitcoin's address reuse patterns. Ethereum's planned integration of zk-STARKs provides quantum resistance while maintaining better performance characteristics, but requires more complex cryptographic assumptions. The suggestion to use timelocking instead of burning funds is excellent - it maintains optionality while avoiding the philosophical issues of mandatory fund forfeiture. However, this still doesn't solve the fundamental dilemma: how do we coordinate a global, mandatory cryptographic migration in a decentralized system designed to resist exactly this type of coordinated change? The real challenge isn't technical - it's game theoretical. Early migrants pay higher fees for larger transactions while gaining quantum security. Late migrants risk fund loss but enjoy cheaper transactions longer. This creates a complex prisoner's dilemma that could fragment the network.

This is not a good thing at all. This will destroy all really long term cold storage setups, cause a lot of congestion and security risk. The rest of the proposal is fine with me. What is the benefit of keeping useless and vulnerable features? We should clean up everything that poses a risk and not create technical debt when there are no clear benefits for it. If they want to block spending of the legacy UTXOs, this is not optional this is a must.

Because otherwise, you need 100% of the coin holders to move to new address types. As long as you don't have 100% users on your side, if you disable OP_CHECKSIG, then you risk burning someone's coins. Also, it is needed to make Phase C a soft-fork, instead of a hard-fork. Another thing is quantum downgrade: if "quantum-safe" algorithms will be broken classically (some of them were), then a downgrade may be needed. And then, it will be much easier, if the old way will not be fully disabled. Having a general-purpose 256-bit calculator is a useful feature, which existed in the past, and was based on BigNum implementation, but was disabled in early network upgrade. Maybe enabling any BigNum operations is too big change, but limiting it to 256-bit numbers can be useful for many reasons. And as long as ECDSA-only will be broken, but not SHA-256 at the same time, then still, some scripts with OP_CHECKSIG can be difficult to move, even if you will know the private key. For example: "OP_SIZE <difficulty> OP_LESSTHAN OP_VERIFY <generator> OP_CHECKSIG". Even if you know, that the private key is equal to one, it won't help you, if you don't have any shortcuts for SHA-256.

The migration to quantum-resistant cryptography would only make sense if everyone was in on it. If you have half the Bitcoin ecosystem using old output types, then half of the bitcoin within the ecosystem remains vulnerable and that isn't good for anyone. I am sure that if a strong-enough quantum computer was invented today, we would still have many bitcoin users who wouldn't be aware of what is going on even five years into the future. I am pretty sure that is going to be the case, yes. I don't think there is a way around that.

I am of the same opinion.  It would be a disaster to all of us who have cold wallets.  After all, in my opinion the legacy UTXOs should not be blocked but instead the responsibility should fall on our own shoulders.  Much like it is when you choose a password, it is your responsibility to pick one that is secure. This kind of blockage reminds me of all the other shitcoins that 'progress' from V1 to V2, leaving behind everybody who purchased the shitcoin and decided to not check out the charts or the Cryptocurrency news for an year.  You get wrecked and you have no idea. It could also be a disaster if a relative passes away and although it is known who the heirs are, they did not find a way to enter the cold storage and finally get their hands onto the keys in time. What about collectibles with Bitcoin on them?  All of them will have to be either peeled away or kept intact but unusable.  Bad idea!

How satoshi bitcoin are at risk if he never spent them? I thought that u are at quantum risk if you spend your coins, maybe im missing something

The quantum risk is that it could become viable to derive the private key of an address from its public key. Whereas current address formats hash the public key and only expose it once a transaction has been made, the earliest Bitcoin addresses use a format that exposes the public key from the get-go (P2PK).

The newer types of Segwit addresses we use today don't reveal public keys on the blockchain until you spend from them. The blockchain only shows a hashed format of the public key. These hashed keys could in theory also become vulnerable one day but you would need to have much, much, much... more computing power to brute force those hashes than P2PK addresses that expose the entire public key. That's why satoshi's stash and coins on old P2PK addresses are in greater danger than those in modern addresses.

The moment i see Jameson Lopp as one of the BIP author, i'm not surprised about details of the phase B. After all, he already wrote blog post Against Allowing Quantum Recovery of Bitcoin. In addition, older version of Bitcoin Core (it was called "Bitcoin" back then) was programmed to use P2PK to receive mining reward.

He is one of the authors of the BIP proposal but there are five more. So they all agree on those points in Phase B. I don't know what to think. It feels like choosing between two evils, hoping you picked the lesser one. Allow satoshi-era coins to be stolen if a strong-enough quantum computer becomes a reality. That would cause a devastating affect on the network. The alternative looks even worse: freeze the coins and effectively take them out of circulation for the greater good of the network and again destroying trust in Bitcoin and censoring it.

I think everyone is overestimating the effect of this. All it does is reintroduce some more supply into circulation, it does not change the total coin count or anything else. Once it happens, it is done and the network has swallowed the solution to the problem. We are not talking about something that will kill Bitcoin for example by completely breaking it. One of the reasons why people are exaggerating this is because everyone has been writing about this in a very negative way for a long time. If it is something that is an expected progression of the network's evolution, and if we start talking about it as something that must happen and something that is normal then the fears will lower over time. A smart attacker would not dump compromised coins fast, it is actually a very good way to build a country reserve.   Shitcoin people inflate both their circulating and total supply all the time in many ways, relax. You can reframe it to something more normal such as "some satoshi-era Bitcoin finally mined using quantum computers".

100% NACK from my part, I've already mentioned it in another thread. I welcome the addition of post-quantum schemes as soon as there's a battle tested and future-proof option available. But it does not make sense to make the usage of PQ cryptography mandatory, and much less from phase A on. The PQ option should be optional at least until there are already ongoing attacks. If 25% of the coins are vulnerable, what has to be done is to educate people that they should not re-use addresses. Satoshi's coins and other "lost coins" where this is perhaps not possible are only 5%. And these 5% won't be cracked instantly by quantum computing, it will take time. So it's not that we'll have 1 million BTC of new market orders on exchanges in one single day (which could be disruptive). In our chainanalysis-plagued world it is even possible that the quantum hackers would have a difficult time sending these coins to CEX exchanges. They would have to sell them via P2P or OTC for a much lower price probably. Of course there could be a disruption due to panic, but once the coins are sold or exchanged for goods, the threat is gone forever, and there will be no more "Satoshi's Coins Are Moved!!!! FUD".

In a way satoshi's stash and other old "lost coins" will serve as a canary given that they will likely be the first target. That is to say, even with this milestone reached QC will in all likelyhood still take years if not a decade or so to reach the point where it can feasibly snatch coins mid-transaction.

Fair point. Some people would mention that they don't want 1 million BTC mined by Satoshi getting stolen. But they don't realize 1 million BTC is an estimation[1] and IIRC each 50 mined BTC was mined into different P2PK "address". While the effect probably isn't devastating on Bitcoin network, it definitely will have impact on Bitcoin price and easily turned into FUD. You've probably read it, but Jameson Lopp write interesting argument about this viewpoint. Here's a part of his argument. [1] https://bitcointalk.org/index.php?topic=175996.0

My two sats on this: Satoshi-era coins are not lost coins, and the fact that we, bitcoiners as majority, have passively accepted them as lost is something that is worth examination.  We have seen some of those coins being spent after more than 10 years of inactivity, and yet we still treat them as "lost".  If "price stability" is what we truly wanted, then why not freezing them at the present?  In the end, it'd be within the realms of possibility that Patoshi woke up and spent his coins.  I think you understand how this opens a can of worms.  FALCON-512 seems the best solution, at the moment, but the block size has to increase, otherwise the throughput would dramatically decrease.  My thought is that we should increase the block size by the same order as a regular transaction size is increased.  FALCON's signature verification is also a lot faster than currently, so the idea that the block size increase would result in slower block sync and verification does not hold entirely.  I don't like phase C's zero knowledge recovery as a concept.  Based on which standard do we accept zk?  BIP39, Electrum, something else?  It can be very complicated.  Also, Satoshi-era coins are sitting on public keys, and there is no more knowledge the true owner can provide than the quantum attacker.I think that finding consensus for this issue should be the highest priority right now.

He makes a few fair arguments in there. This is true, and many other points raised are good. However, there is a existential level risk of establishing any precedent of freezing any kind of UTXOs. A much bigger risk than most people are able to understand. If the solutions to this problem all remain controversial, and many users do not support them, then what? Try to force the update, which would significantly aggravate the negative impact from this precedent?   This is why I am not necessarily trying to say that I don't want them to be frozen under any conditions. I am trying to say that if they do get compromised eventually, that it is not as bad as many parties try to make it seem and that we need to work on reframing this problem. How different in practice is this from someone's key being compromised because their source of entropy was bad? Very little. Keys do and will get hacked all the time in one way or another. Not in the quantity that is talked about here but it does happen relatively often and we are fine. It would be easy if we could reach strong consensus, but this is not going to happen with proposals that involve freezing. How we approach this lack of consensus will have a bigger impact on Bitcoin's future than any amount of "stolen coins" could ever have.