From: Boris Nagaev <bnagaev@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A Post Quantum Migration Proposal
Date: Tue, 15 Jul 2025 07:13:38 -0700 (PDT) [thread overview]
Message-ID: <88a7b020-e84f-4052-9716-fb40b23f07ddn@googlegroups.com> (raw)
In-Reply-To: <W2O6Al4bdVzx1EkszgN5dhtSUD0GwRgwYcRSWlQzfsvZE0UN5f6HBGXB2zorkGOpdsbDAS_X6xcsrH6zBIeYbPY8MM_sPfeN9Wblts5Gcog=@proton.me>
[-- Attachment #1.1: Type: text/plain, Size: 16846 bytes --]
Hi Conduition, hi Jameson, hi all!
What if all vulnerable coins are temporarily locked during phase B, with a
clearly defined future block height X (e.g., in 5-10 years) at which point
these coins become EC-spendable again? This would give us time to develop
recovery mechanisms for phase C. It also wouldn't require a hard fork,
since the unlocking height X would already be part of the consensus rules
introduced in phase B. In this way, we avoid a hard fork altogether.
Instead of permanent freezing, a forced timelock would be applied to
vulnerable outputs.
Beyond merely avoiding a hard fork, this approach offers additional
benefits. It improves the situation for owners of vulnerable coins who
missed the initial deadline, since a timelock is preferable to permanent
freezing. To be clear, I am not advocating for locking the coins -- even
temporarily. However, if a choice must be made, temporary locking is
clearly preferable to permanent freezing. Developers working on recovery
mechanisms would have a clear timeline and incentive to deliver phase C as
a subsequent soft fork. At the same time, the community gains valuable time
for data-driven decision-making -- allowing us to adapt based on how events
unfold, including whether legitimate claims are made on locked coins, and
based on future developments in quantum computing.
This assumes that phases A and B are deployed before a real quantum threat
materializes. If, in the meantime, fundamental research concludes that
quantum computing will not break EC for the next 100 years, we can simply
do nothing -- and the coins will unlock automatically at height X. On the
other hand, if quantum computing advances significantly, we can respond
based on the availability and quality of recovery schemes: either deploy a
recovery soft fork at block X, or apply another soft fork to postpone
unlocking by another 5-10 years.
Best,
Boris
On Tuesday, July 15, 2025 at 8:36:33 AM UTC-3 conduition wrote:
Hi Jameson,
I like your proposal, and economically so should anyone who owns Bitcoin. I
don't see any solid incentive-based motivation to let QCs "free up"
vulnerable coins, other than maybe as an early-warning indicator. This is
impossible to prove, but I personally believe almost all dormant bitcoins
that would be locked by phase B are already permanently lost (dead
addresses, dead owners, etc).
I do think we should delay phase B as long as we can, to give as many
people time to upgrade as possible. The time horizons should be flexible
and allow us to react to changes, in case practical quantum computers take
much more/less time to arrive than we expect today.
Commit/reveal protocols described in other mailing list threads are a
tempting way to rescue some quantum-vulnerable funds, without the
complexity of zk-STARKs... but these protocols would be difficult to
explain to users, and they only work for addresses whose pubkeys haven't
been exposed yet. This makes implementation hard. It rules out many
existing UTXOs, and all P2TR UTXOs too. At this point I don't feel
commit/reveal is worth the engineering effort and research given those
limitations. It's reasonable that you left these out of your proposal.
It's true that phase C would require a hard fork if we first deploy phase
B, because phase B explicitly closes the door on spending from pre-quantum
addresses. However, I believe zk-STARK proof unlocking could be executed as
a soft fork if you combine phases B and C together into a single upgrade.
This way, there is never a delta in the consensus rules in which EC
spending rules need to be relaxed.
- *Before*: allow spending P2PKH if given a valid sig/pubkey.
- *After*: allow spending P2PKH if given a valid sig/pubkey AND a valid
ZK proof of seed-phrase-based key derivation (e.g. BIP39).
With this combined approach, we would never see a period of time in which
average users with mnemonic-seed wallets are locked out of their funds, and
we need no hard forks at all.
regards,
conduition
On Saturday, July 12th, 2025 at 5:46 PM, Jameson Lopp <jameso...@gmail•com>
wrote:
Building upon my earlier essay against allowing quantum recovery of bitcoin
<https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/6peEaa90AQAJ> I
wish to formalize a proposal after several months of discussions.
This proposal does not delve into the multitude of issues regarding post
quantum cryptography and trade-offs of different schemes, but rather is
meant to specifically address the issues of incentivizing adoption and
migration of funds *after* consensus is established that it is prudent to
do so.
As such, this proposal requires P2QRH as described in BIP-360 or potential
future proposals.
Abstract
This proposal follows the implementation of post-quantum (PQ) output type
(P2QRH) and introduces a pre-announced sunset of legacy ECDSA/Schnorr
signatures. It turns quantum security into a private incentive: fail to
upgrade and you will certainly lose access to your funds, creating a
certainty where none previously existed.
-
Phase A: Disallows sending of any funds to quantum-vulnerable addresses,
hastening the adoption of P2QRH address types.
-
Phase B: Renders ECDSA/Schnorr spends invalid, preventing all spending
of funds in quantum-vulnerable UTXOs. This is triggered by a
well-publicized flag-day roughly five years after activation.
-
Phase C (optional): Pending further research and demand, a separate BIP
proposing a fork to allow recovery of legacy UTXOs through ZK proof of
possession of BIP-39 seed phrase.
Motivation
We seek to secure the value of the UTXO set and minimize incentives for
quantum attacks. This proposal is radically different from any in Bitcoin’s
history just as the threat posed by quantum computing is radically
different from any other threat in Bitcoin’s history. Never before has
Bitcoin faced an existential threat to its cryptographic primitives. A
successful quantum attack on Bitcoin would result in significant economic
disruption and damage across the entire ecosystem. Beyond its impact on
price, the ability of miners to provide network security may be
significantly impacted.
-
Accelerating quantum progress.
-
NIST ratified three production-grade PQ signature schemes in 2024;
academic road-maps now estimate a cryptographically-relevant quantum
computer as early as 2027-2030. [McKinsey
<https://www.mckinsey.com/~/media/mckinsey/business%20functions/mckinsey%20digital/our%20insights/the%20year%20of%20quantum%20from%20concept%20to%20reality%20in%202025/quantum-monitor-2025.pdf?shouldIndex=false>
]
-
Quantum algorithms are rapidly improving
-
The safety envelope is shrinking by dramatic increases in algorithms
even if the pace of hardware improvements is slower. Algorithms are improving
up to 20X
<https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html>,
lowering the theoretical hardware requirements for breaking classical
encryption.
-
Bitcoin’s exposed public keys.
-
Roughly 25% of all bitcoin have revealed a public key on-chain; those
UTXOs could be stolen with sufficient quantum power.
-
We may not know the attack is underway.
-
Quantum attackers could compute the private key for known public keys
then transfer all funds weeks or months later, in a covert bleed to not
alert chain watchers. Q-Day may be only known much later if the attack
withholds broadcasting transactions in order to postpone revealing their
capabilities.
-
Private keys become public.
-
Assuming that quantum computers are able to maintain their current
trajectories and overcome existing engineering obstacles, there is a near
certain chance that all P2PK (and other outputs with exposed pubkeys)
private keys will be found and used to steal the funds.
-
Impossible to know motivations.
-
Prior to a quantum attack, it is impossible to know the motivations
of the attacker. An economically motivated attacker will try to remain
undetected for as long as possible, while a malicious attacker will attempt
to destroy as much value as possible.
-
Upgrade inertia.
-
Coordinating wallets, exchanges, miners and custodians historically
takes years.
-
The longer we postpone migration, the harder it becomes to coordinate
wallets, exchanges, miners, and custodians. A clear, time-boxed pathway is
the only credible defense.
-
Coordinating distributed groups is more prone to delay, even if
everyone has similar motivations. Historically, Bitcoin has been slow to
adopt code changes, often taking multiple years to be approved.
Benefits at a Glance
-
Resilience: Bitcoin protocol remains secure for the foreseeable future
without waiting for a last-minute emergency.
-
Certainty: Bitcoin users and stakeholders gain certainty that a plan is
both in place and being implemented to effectively deal with the threat of
quantum theft of bitcoin.
-
Clarity: A single, publicized timeline aligns the entire ecosystem
(wallets, exchanges, hardware vendors).
-
Supply Discipline: Abandoned keys that never migrate become unspendable,
reducing supply, as Satoshi described
<https://bitcointalk.org/index.php?topic=198.msg1647#msg1647>.
Specification
Phase
What Happens
Who Must Act
Time Horizon
Phase A - Disallow spends to legacy script types
Permitted sends are from legacy scripts to P2QRH scripts
Everyone holding or accepting BTC.
3 years after BIP-360 implementation
Phase B – Disallow spends from quantum vulnerable outputs
At a preset block-height, nodes reject transactions that rely on
ECDSA/Schnorr keys.
Everyone holding or accepting BTC.
2 years after Phase A activation.
Phase C – Re-enable spends from quantum vulnerable outputs via ZK Proof
Users with frozen quantum vulnerable funds and a HD wallet seed phrase can
construct a quantum safe ZK proof to recover funds.
Users who failed to migrate funds before Phase B.
TBD pending research, demand, and consensus.
Rationale
-
Even if Bitcoin is not a primary initial target of a cryptographically
relevant quantum computer, widespread knowledge that such a computer exists
and is capable of breaking Bitcoin’s cryptography will damage faith in the
network .
-
An attack on Bitcoin may not be economically motivated - an attacker may
be politically or maliciously motivated and may attempt to destroy value
and trust in Bitcoin rather than extract value. There is no way to know in
advance how, when, or why an attack may occur. A defensive position must be
taken well in advance of any attack.
-
Bitcoin’s current signatures (ECDSA/Schnorr) will be a tantalizing
target: any UTXO that has ever exposed its public key on-chain (roughly 25
% of all bitcoin) could be stolen by a cryptographically relevant quantum
computer.
-
Existing Proposals are Insufficient.
1.
Any proposal that allows for the quantum theft of “lost” bitcoin is
creating a redistribution dilemma. There are 3 types of proposals:
1.
Allow anyone to steal vulnerable coins, benefitting those who
reach quantum capability earliest.
2.
Allow throttled theft of coins, which leads to RBF battles and
ultimately miners subsidizing their revenue from lost coins.
3.
Allow no one to steal vulnerable coins.
-
Minimizes attack surface
1.
By disallowing new spends to quantum vulnerable script types, we
minimize the attack surface with each new UTXO.
2.
Upgrades to Bitcoin have historically taken many years; this will
hasten and speed up the adoption of new quantum resistant script types.
3.
With a clear deadline, industry stakeholders will more readily
upgrade existing infrastructure to ensure continuity of services.
-
Minimizes loss of access to funds
1.
If there is sufficient demand and research proves possible,
submitting a ZK proof of knowledge of a BIP-39 seed phrase corresponding to
a public key hash or script hash would provide a trustless means for legacy
outputs to be spent in a quantum resistant manner, even after the sunset.
Stakeholder
Incentive to Upgrade
Miners
• Larger size PQ signatures along with incentive for users to migrate will
create more demand for block space and thus higher fees collected by miners.
• Post-Phase B, non-upgraded miners produce invalid blocks.
• A quantum attack on Bitcoin will significantly devalue both their
hardware and Bitcoin as a whole.
Institutional Holders
• Fiduciary duty: failing to act to prevent a quantum attack on Bitcoin
would violate the fiduciary duty to shareholders.
• Demonstrating Bitcoin’s ability to effectively mitigate emerging threats
will prove Bitcoin to be an investment grade asset.
Exchanges & Custodians
• Concentrated risk: a quantum hack could bankrupt them overnight.
• Early migration is cheap relative to potential losses, potential lawsuits
over improper custody and reputational damage.
Everyday Users
• Self-sovereign peace of mind.
• Sunset date creates a clear deadline and incentive to improve their
security rather than an open-ended “some day” that invites procrastination.
Attackers
• Economic incentive diminishes as sunset nears, stolen coins cannot be
spent after Q-day.
Key Insight: As mentioned earlier, the proposal turns quantum security into
a private incentive to upgrade.
This is not an offensive attack, rather, it is defensive: our thesis is
that the Bitcoin ecosystem wishes to defend itself and its interests
against those who would prefer to do nothing and allow a malicious actor to
destroy both value and trust.
"Lost coins only make everyone else's coins worth slightly more. Think of
it as a donation to everyone." - Satoshi Nakamoto
If true, the corollary is:
"Quantum recovered coins only make everyone else's coins worth less. Think
of it as a theft from everyone."
The timelines that we are proposing are meant to find the best balance
between giving ample ability for account owners to migrate while
maintaining the integrity of the overall ecosystem to avoid catastrophic
attacks.
Backward Compatibility
As a series of soft forks, older nodes will continue to operate without
modification. Non-upgraded nodes, however, will consider all post-quantum
witness programs as anyone-can-spend scripts. They are strongly encouraged
to upgrade in order to fully validate the new programs.
Non-upgraded wallets can receive and send bitcoin from non-upgraded and
upgraded wallets until Phase A. After Phase A, they can no longer receive
from any other wallets and can only send to upgraded wallets. After Phase
B, both senders and receivers will require upgraded wallets. Phase C would
likely require a loosening of consensus rules (a hard fork) to allow
vulnerable funds recovery via ZK proofs.
--
You received this message because you are subscribed to the Google Groups
"Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to bitcoindev+...@googlegroups•com.
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/CADL_X_fpv-aXBxX%2BeJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q%40mail.gmail.com
.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/88a7b020-e84f-4052-9716-fb40b23f07ddn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 73683 bytes --]
next prev parent reply other threads:[~2025-07-15 18:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-12 21:36 Jameson Lopp
2025-07-13 23:19 ` [bitcoindev] " Tadge Dryja
2025-07-14 2:07 ` Antoine Riard
2025-07-14 16:08 ` Ethan Heilman
2025-07-15 2:50 ` Boris Nagaev
2025-07-14 18:52 ` Jameson Lopp
2025-07-14 13:50 ` Jameson Lopp
2025-07-15 2:32 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
2025-07-15 14:13 ` Boris Nagaev [this message]
2025-07-15 17:57 ` Ethan Heilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=88a7b020-e84f-4052-9716-fb40b23f07ddn@googlegroups.com \
--to=bnagaev@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox