Against Allowing Quantum Recovery of Bitcoin

[Jameson Lopp]

The quantum computing debate is heating up. There are many controversial aspects to this debate, including whether or not quantum computers will ever actually become a practical threat.

I won't tread into the unanswerable question of how worried we should be about quantum computers. I think it's far from a crisis, but given the difficulty in changing Bitcoin it's worth starting to seriously discuss. Today I wish to focus on a philosophical quandary related to one of the decisions that would need to be made if and when we implement a quantum safe signature scheme.

Several Scenarios
Because this essay will reference game theory a fair amount, and there are many variables at play that could change the nature of the game, I think it's important to clarify the possible scenarios up front.

1. Quantum computing never materializes, never becomes a threat, and thus everything discussed in this essay is moot.
2. A quantum computing threat materializes suddenly and Bitcoin does not have quantum safe signatures as part of the protocol. In this scenario it would likely make the points below moot because Bitcoin would be fundamentally broken and it would take far too long to upgrade the protocol, wallet software, and migrate user funds in order to restore confidence in the network.
3. Quantum computing advances slowly enough that we come to consensus about how to upgrade Bitcoin and post quantum security has been minimally adopted by the time an attacker appears.
4. Quantum computing advances slowly enough that we come to consensus about how to upgrade Bitcoin and post quantum security has been highly adopted by the time an attacker appears.

For the purposes of this post, I'm envisioning being in situation 3 or 4.

To Freeze or not to Freeze?
I've started seeing more people weighing in on what is likely the most contentious aspect of how a quantum resistance upgrade should be handled in terms of migrating user funds. Should quantum vulnerable funds be left open to be swept by anyone with a sufficiently powerful quantum computer OR should they be permanently locked?

"I don't see why old coins should be confiscated. The better option is to let those with quantum computers free up old coins. While this might have an inflationary impact on bitcoin's price, to use a turn of phrase, the inflation is transitory. Those with low time preference should support returning lost coins to circulation." 

- Hunter Beast

On the other hand:

"Of course they have to be confiscated. If and when (and that's a big if) the existence of a cryptography-breaking QC becomes a credible threat, the Bitcoin ecosystem has no other option than softforking out the ability to spend from signature schemes (including ECDSA and BIP340) that are vulnerable to QCs. The alternative is that millions of BTC become vulnerable to theft; I cannot see how the currency can maintain any value at all in such a setting. And this affects everyone; even those which diligently moved their coins to PQC-protected schemes."
- Pieter Wuille

I don't think "confiscation" is the most precise term to use, as the funds are not being seized and reassigned. Rather, what we're really discussing would be better described as "burning" - placing the funds out of reach of everyone.

Not freezing user funds is one of Bitcoin's inviolable properties. However, if quantum computing becomes a threat to Bitcoin's elliptic curve cryptography, an inviolable property of Bitcoin will be violated one way or another.

Fundamental Properties at Risk
5 years ago I attempted to comprehensively categorize all of Bitcoin's fundamental properties that give it value. https://nakamoto.com/what-are-the-key-properties-of-bitcoin/

The particular properties in play with regard to this issue seem to be:

Censorship Resistance - No one should have the power to prevent others from using their bitcoin or interacting with the network.

Forward Compatibility - changing the rules such that certain valid transactions become invalid could undermine confidence in the protocol.

Conservatism - Users should not be expected to be highly responsive to system issues.

As a result of the above principles, we have developed a strong meme (kudos to Andreas Antonopoulos) that goes as follows:

Not your keys, not your coins.

I posit that the corollary to this principle is:

Your keys, only your coins.

A quantum capable entity breaks the corollary of this foundational principle. We secure our bitcoin with the mathematical probabilities related to extremely large random numbers. Your funds are only secure because truly random large numbers should not be guessable or discoverable by anyone else in the world.

This is the principle behind the motto vires in numeris - strength in numbers. In a world with quantum enabled adversaries, this principle is null and void for many types of cryptography, including the elliptic curve digital signatures used in Bitcoin.

Who is at Risk?
There has long been a narrative that Satoshi's coins and others from the Satoshi era of P2PK locking scripts that exposed the public key directly on the blockchain will be those that get scooped up by a quantum "miner." But unfortunately it's not that simple. If I had a powerful quantum computer, which coins would I target? I'd go to the Bitcoin rich list and find the wallets that have exposed their public keys due to re-using addresses that have previously been spent from. You can easily find them at https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html

Note that a few of these wallets, like Bitfinex / Kraken / Tether, would be slightly harder to crack because they are multisig wallets. So a quantum attacker would need to reverse engineer 2 keys for Kraken or 3 for Bitfinex / Tether in order to spend funds. But many are single signature.

Point being, it's not only the really old lost BTC that are at risk to a quantum enabled adversary, at least at time of writing. If we add a quantum safe signature scheme, we should expect those wallets to be some of the first to upgrade given their incentives.

The Ethical Dilemma: Quantifying Harm
Which decision results in the most harm?

By making quantum vulnerable funds unspendable we potentially harm some Bitcoin users who were not paying attention and neglected to migrate their funds to a quantum safe locking script. This violates the "conservativism" principle stated earlier. On the flip side, we prevent those funds plus far more lost funds from falling into the hands of the few privileged folks who gain early access to quantum computers.

By leaving quantum vulnerable funds available to spend, the same set of users who would otherwise have funds frozen are likely to see them stolen. And many early adopters who lost their keys will eventually see their unreachable funds scooped up by a quantum enabled adversary.

Imagine, for example, being James Howells, who accidentally threw away a hard drive with 8,000 BTC on it, currently worth over $600M USD. He has spent a decade trying to retrieve it from the landfill where he knows it's buried, but can't get permission to excavate. I suspect that, given the choice, he'd prefer those funds be permanently frozen rather than fall into someone else's possession - I know I would.

Allowing a quantum computer to access lost funds doesn't make those users any worse off than they were before, however it would have a negative impact upon everyone who is currently holding bitcoin.

It's prudent to expect significant economic disruption if large amounts of coins fall into new hands. Since a quantum computer is going to have a massive up front cost, expect those behind it to desire to recoup their investment. We also know from experience that when someone suddenly finds themselves in possession of 9+ figures worth of highly liquid assets, they tend to diversify into other things by selling.

Allowing quantum recovery of bitcoin is tantamount to wealth redistribution. What we'd be allowing is for bitcoin to be redistributed from those who are ignorant of quantum computers to those who have won the technological race to acquire quantum computers. It's hard to see a bright side to that scenario.

Is Quantum Recovery Good for Anyone?

Does quantum recovery HELP anyone? I've yet to come across an argument that it's a net positive in any way. It certainly doesn't add any security to the network. If anything, it greatly decreases the security of the network by allowing funds to be claimed by those who did not earn them.

But wait, you may be thinking, wouldn't quantum "miners" have earned their coins by all the work and resources invested in building a quantum computer? I suppose, in the same sense that a burglar earns their spoils by the resources they invest into surveilling targets and learning the skills needed to break into buildings. What I say "earned" I mean through productive mutual trade.

For example:

* Investors earn BTC by trading for other currencies.
* Merchants earn BTC by trading for goods and services.
* Miners earn BTC by trading thermodynamic security.
* Quantum miners don't trade anything, they are vampires feeding upon the system.

There's no reason to believe that allowing quantum adversaries to recover vulnerable bitcoin will be of benefit to anyone other than the select few organizations that win the technological arms race to build the first such computers. Probably nation states and/or the top few largest tech companies.

One could certainly hope that an organization with quantum supremacy is benevolent and acts in a "white hat" manner to return lost coins to their owners, but that's incredibly optimistic and foolish to rely upon. Such a situation creates an insurmountable ethical dilemma of only recovering lost bitcoin rather than currently owned bitcoin. There's no way to precisely differentiate between the two; anyone can claim to have lost their bitcoin but if they have lost their keys then proving they ever had the keys becomes rather difficult. I imagine that any such white hat recovery efforts would have to rely upon attestations from trusted third parties like exchanges.

Even if the first actor with quantum supremacy is benevolent, we must assume the technology could fall into adversarial hands and thus think adversarially about the potential worst case outcomes. Imagine, for example, that North Korea continues scooping up billions of dollars from hacking crypto exchanges and decides to invest some of those proceeds into building a quantum computer for the biggest payday ever...

Downsides to Allowing Quantum Recovery
Let's think through an exhaustive list of pros and cons for allowing or preventing the seizure of funds by a quantum adversary.

Historical Precedent
Previous protocol vulnerabilities weren’t celebrated as "fair game" but rather were treated as failures to be remediated. Treating quantum theft differently risks rewriting Bitcoin’s history as a free-for-all rather than a system that seeks to protect its users.

Violation of Property Rights
Allowing a quantum adversary to take control of funds undermines the fundamental principle of cryptocurrency - if you keep your keys in your possession, only you should be able to access your money. Bitcoin is built on the idea that private keys secure an individual’s assets, and unauthorized access (even via advanced tech) is theft, not a legitimate transfer.

Erosion of Trust in Bitcoin
If quantum attackers can exploit vulnerable addresses, confidence in Bitcoin as a secure store of value would collapse. Users and investors rely on cryptographic integrity, and widespread theft could drive adoption away from Bitcoin, destabilizing its ecosystem.

This is essentially the counterpoint to claiming the burning of vulnerable funds is a violation of property rights. While some will certainly see it as such, others will find the apathy toward stopping quantum theft to be similarly concerning.

Unfair Advantage
Quantum attackers, likely equipped with rare and expensive technology, would have an unjust edge over regular users who lack access to such tools. This creates an inequitable system where only the technologically elite can exploit others, contradicting Bitcoin’s ethos of decentralized power.

Bitcoin is designed to create an asymmetric advantage for DEFENDING one's wealth. It's supposed to be impractically expensive for attackers to crack the entropy and cryptography protecting one's coins. But now we find ourselves discussing a situation where this asymmetric advantage is compromised in favor of a specific class of attackers.

Economic Disruption
Large-scale theft from vulnerable addresses could crash Bitcoin’s price as quantum recovered funds are dumped on exchanges. This would harm all holders, not just those directly targeted, leading to broader financial chaos in the markets.

Moral Responsibility
Permitting theft via quantum computing sets a precedent that technological superiority justifies unethical behavior. This is essentially taking a "code is law" stance in which we refuse to admit that both code and laws can be modified to adapt to previously unforeseen situations.

Burning of coins can certainly be considered a form of theft, thus I think it's worth differentiating the two different thefts being discussed:

1. self-enriching & likely malicious
2. harm prevention & not necessarily malicious

Both options lack the consent of the party whose coins are being burnt or transferred, thus I think the simple argument that theft is immoral becomes a wash and it's important to drill down into the details of each.

Incentives Drive Security
I can tell you from a decade of working in Bitcoin security - the average user is lazy and is a procrastinator. If Bitcoiners are given a "drop dead date" after which they know vulnerable funds will be burned, this pressure accelerates the adoption of post-quantum cryptography and strengthens Bitcoin long-term. Allowing vulnerable users to delay upgrading indefinitely will result in more laggards, leaving the network more exposed when quantum tech becomes available.

Steel Manning
Clearly this is a complex and controversial topic, thus it's worth thinking through the opposing arguments.

Protecting Property Rights
Allowing quantum computers to take vulnerable bitcoin could potentially be spun as a hard money narrative - we care so greatly about not violating someone's access to their coins that we allow them to be stolen!

But I think the flip side to the property rights narrative is that burning vulnerable coins prevents said property from falling into undeserving hands. If the entire Bitcoin ecosystem just stands around and allows quantum adversaries to claim funds that rightfully belong to other users, is that really a "win" in the "protecting property rights" category? It feels more like apathy to me.

As such, I think the "protecting property rights" argument is a wash.

Quantum Computers Won't Attack Bitcoin
There is a great deal of skepticism that sufficiently powerful quantum computers will ever exist, so we shouldn't bother preparing for a non-existent threat. Others have argued that even if such a computer was built, a quantum attacker would not go after bitcoin because they wouldn't want to reveal their hand by doing so, and would instead attack other infrastructure.

It's quite difficult to quantify exactly how valuable attacking other infrastructure would be. It also really depends upon when an entity gains quantum supremacy and thus if by that time most of the world's systems have already been upgraded. While I think you could argue that certain entities gaining quantum capability might not attack Bitcoin, it would only delay the inevitable - eventually somebody will achieve the capability who decides to use it for such an attack.

Quantum Attackers Would Only Steal Small Amounts
Some have argued that even if a quantum attacker targeted bitcoin, they'd only go after old, likely lost P2PK outputs so as to not arouse suspicion and cause a market panic.

I'm not so sure about that; why go after 50 BTC at a time when you could take 250,000 BTC with the same effort as 50 BTC? This is a classic "zero day exploit" game theory in which an attacker knows they have a limited amount of time before someone else discovers the exploit and either benefits from it or patches it. Take, for example, the recent ByBit attack - the highest value crypto hack of all time. Lazarus Group had compromised the Safe wallet front end JavaScript app and they could have simply had it reassign ownership of everyone's Safe wallets as they were interacting with their wallet. But instead they chose to only specifically target ByBit's wallet with $1.5 billion in it because they wanted to maximize their extractable value. If Lazarus had started stealing from every wallet, they would have been discovered quickly and the Safe web app would likely have been patched well before any billion dollar wallets executed the malicious code.

I think the "only stealing small amounts" argument is strongest for Situation #2 described earlier, where a quantum attacker arrives before quantum safe cryptography has been deployed across the Bitcoin ecosystem. Because if it became clear that Bitcoin's cryptography was broken AND there was nowhere safe for vulnerable users to migrate, the only logical option would be for everyone to liquidate their bitcoin as quickly as possible. As such, I don't think it applies as strongly for situations in which we have a migration path available.

The 21 Million Coin Supply Should be in Circulation
Some folks are arguing that it's important for the "circulating / spendable" supply to be as close to 21M as possible and that having a significant portion of the supply out of circulation is somehow undesirable.

While the "21M BTC" attribute is a strong memetic narrative, I don't think anyone has ever expected that it would all be in circulation. It has always been understood that many coins will be lost, and that's actually part of the game theory of owning bitcoin!

And remember, the 21M number in and of itself is not a particularly important detail - it's not even mentioned in the whitepaper. What's important is that the supply is well known and not subject to change.

Self-Sovereignty and Personal Responsibility
Bitcoin’s design empowers individuals to control their own wealth, free from centralized intervention. This freedom comes with the burden of securing one's private keys. If quantum computing can break obsolete cryptography, the fault lies with users who didn't move their funds to quantum safe locking scripts. Expecting the network to shield users from their own negligence undermines the principle that you, and not a third party, are accountable for your assets.

I think this is generally a fair point that "the community" doesn't owe you anything in terms of helping you. I think that we do, however, need to consider the incentives and game theory in play with regard to quantum safe Bitcoiners vs quantum vulnerable Bitcoiners. More on that later.

Code is Law
Bitcoin operates on transparent, immutable rules embedded in its protocol. If a quantum attacker uses superior technology to derive private keys from public keys, they’re not "hacking" the system - they're simply following what's mathematically permissible within the current code. Altering the protocol to stop this introduces subjective human intervention, which clashes with the objective, deterministic nature of blockchain.

While I tend to agree that code is law, one of the entire points of laws is that they can be amended to improve their efficacy in reducing harm. Leaning on this point seems more like a pro-ossification stance that it's better to do nothing and allow harm to occur rather than take action to stop an attack that was foreseen far in advance.

Technological Evolution as a Feature, Not a Bug
It's well known that cryptography tends to weaken over time and eventually break. Quantum computing is just the next step in this progression. Users who fail to adapt (e.g., by adopting quantum-resistant wallets when available) are akin to those who ignored technological advancements like multisig or hardware wallets. Allowing quantum theft incentivizes innovation and keeps Bitcoin’s ecosystem dynamic, punishing complacency while rewarding vigilance.

Market Signals Drive Security
If quantum attackers start stealing funds, it sends a clear signal to the market: upgrade your security or lose everything. This pressure accelerates the adoption of post-quantum cryptography and strengthens Bitcoin long-term. Coddling vulnerable users delays this necessary evolution, potentially leaving the network more exposed when quantum tech becomes widely accessible. Theft is a brutal but effective teacher.

Centralized Blacklisting Power
Burning vulnerable funds requires centralized decision-making - a soft fork to invalidate certain transactions. This sets a dangerous precedent for future interventions, eroding Bitcoin’s decentralization. If quantum theft is blocked, what’s next - reversing exchange hacks? The system must remain neutral, even if it means some lose out.

I think this could be a potential slippery slope if the proposal was to only burn specific addresses. Rather, I'd expect a neutral proposal to burn all funds in locking script types that are known to be quantum vulnerable. Thus, we could eliminate any subjectivity from the code.

Fairness in Competition
Quantum attackers aren't cheating; they're using publicly available physics and math. Anyone with the resources and foresight can build or access quantum tech, just as anyone could mine Bitcoin in 2009 with a CPU. Early adopters took risks and reaped rewards; quantum innovators are doing the same. Calling it “unfair” ignores that Bitcoin has never promised equality of outcome - only equality of opportunity within its rules.

I find this argument to be a mischaracterization because we're not talking about CPUs. This is more akin to talking about ASICs, except each ASIC costs millions if not billions of dollars. This is out of reach from all but the wealthiest organizations.

Economic Resilience
Bitcoin has weathered thefts before (MTGOX, Bitfinex, FTX, etc) and emerged stronger. The market can absorb quantum losses, with unaffected users continuing to hold and new entrants buying in at lower prices. Fear of economic collapse overestimates the impact - the network’s antifragility thrives on such challenges.

This is a big grey area because we don't know when a quantum computer will come online and we don't know how quickly said computers would be able to steal bitcoin. If, for example, the first generation of sufficiently powerful quantum computers were stealing less volume than the current block reward then of course it will have minimal economic impact. But if they're taking thousands of BTC per day and bringing them back into circulation, there will likely be a noticeable market impact as it absorbs the new supply.

This is where the circumstances will really matter. If a quantum attacker appears AFTER the Bitcoin protocol has been upgraded to support quantum resistant cryptography then we should expect the most valuable active wallets will have upgraded and the juiciest target would be the 31,000 BTC in the address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which has been dormant since 2010. In general I'd expect that the amount of BTC re-entering the circulating supply would look somewhat similar to the mining emission curve: volume would start off very high as the most valuable addresses are drained and then it would fall off as quantum computers went down the list targeting addresses with less and less BTC.

Why is economic impact a factor worth considering? Miners and businesses in general. More coins being liquidated will push down the price, which will negatively impact miner revenue. Similarly, I can attest from working in the industry for a decade, that lower prices result in less demand from businesses across the entire industry. As such, burning quantum vulnerable bitcoin is good for the entire industry.

Practicality & Neutrality of Non-Intervention
There’s no reliable way to distinguish “theft” from legitimate "white hat" key recovery. If someone loses their private key and a quantum computer recovers it, is that stealing or reclaiming? Policing quantum actions requires invasive assumptions about intent, which Bitcoin’s trustless design can’t accommodate. Letting the chips fall where they may avoids this mess.

Philosophical Purity
Bitcoin rejects bailouts. It’s a cold, hard system where outcomes reflect preparation and skill, not sentimentality. If quantum computing upends the game, that’s the point - Bitcoin isn’t meant to be safe or fair in a nanny-state sense; it’s meant to be free. Users who lose funds to quantum attacks are casualties of liberty and their own ignorance, not victims of injustice.

Bitcoin's DAO Moment
This situation has some similarities to The DAO hack of an Ethereum smart contract in 2016, which resulted in a fork to stop the attacker and return funds to their original owners. The game theory is similar because it's a situation where a threat is known but there's some period of time before the attacker can actually execute the theft. As such, there's time to mitigate the attack by changing the protocol.

It also created a schism in the community around the true meaning of "code is law," resulting in Ethereum Classic, which decided to allow the attacker to retain control of the stolen funds.

A soft fork to burn vulnerable bitcoin could certainly result in a hard fork if there are enough miners who reject the soft fork and continue including transactions.

Incentives Matter
We can wax philosophical until the cows come home, but what are the actual incentives for existing Bitcoin holders regarding this decision?

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

Thus, assuming we get to a point where quantum resistant signatures are supported within the Bitcoin protocol, what's the incentive to let vulnerable coins remain spendable?

* It's not good for the actual owners of those coins. It disincentivizes owners from upgrading until perhaps it's too late.
* It's not good for the more attentive / responsible owners of coins who have quantum secured their stash. Allowing the circulating supply to balloon will assuredly reduce the purchasing power of all bitcoin holders.

Forking Game Theory
From a game theory point of view, I see this as incentivizing users to upgrade their wallets. If you disagree with the burning of vulnerable coins, all you have to do is move your funds to a quantum safe signature scheme. Point being, I don't see there being an economic majority (or even more than a tiny minority) of users who would fight such a soft fork. Why expend significant resources fighting a fork when you can just move your coins to a new address?

Remember that blocking spending of certain classes of locking scripts is a tightening of the rules - a soft fork. As such, it can be meaningfully enacted and enforced by a mere majority of hashpower. If miners generally agree that it's in their best interest to burn vulnerable coins, are other users going to care enough to put in the effort to run new node software that resists the soft fork? Seems unlikely to me.

How to Execute Burning
In order to be as objective as possible, the goal would be to announce to the world that after a specific block height / timestamp, Bitcoin nodes will no longer accept transactions (or blocks containing such transactions) that spend funds from any scripts other than the newly instituted quantum safe schemes.

It could take a staggered approach to first freeze funds that are susceptible to long-range attacks such as those in P2PK scripts or those that exposed their public keys due to previously re-using addresses, but I expect the additional complexity would drive further controversy.

How long should the grace period be in order to give the ecosystem time to upgrade? I'd say a minimum of 1 year for software wallets to upgrade. We can only hope that hardware wallet manufacturers are able to implement post quantum cryptography on their existing hardware with only a firmware update.

Beyond that, it will take at least 6 months worth of block space for all users to migrate their funds, even in a best case scenario. Though if you exclude dust UTXOs you could probably get 95% of BTC value migrated in 1 month. Of course this is a highly optimistic situation where everyone is completely focused on migrations - in reality it will take far longer.

Regardless, I'd think that in order to reasonably uphold Bitcoin's conservatism it would be preferable to allow a 4 year migration window. In the meantime, mining pools could coordinate emergency soft forking logic such that if quantum attackers materialized, they could accelerate the countdown to the quantum vulnerable funds burn.

Random Tangential Benefits
On the plus side, burning all quantum vulnerable bitcoin would allow us to prune all of those UTXOs out of the UTXO set, which would also clean up a lot of dust. Dust UTXOs are a bit of an annoyance and there has even been a recent proposal for how to incentivize cleaning them up.

We should also expect that incentivizing migration of the entire UTXO set will create substantial demand for block space that will sustain a fee market for a fairly lengthy amount of time.

In Summary
While the moral quandary of violating any of Bitcoin's inviolable properties can make this a very complex issue to discuss, the game theory and incentives between burning vulnerable coins versus allowing them to be claimed by entities with quantum supremacy appears to be a much simpler issue.

I, for one, am not interested in rewarding quantum capable entities by inflating the circulating money supply just because some people lost their keys long ago and some laggards are not upgrading their bitcoin wallet's security.

We can hope that this scenario never comes to pass, but hope is not a strategy.

I welcome your feedback upon any of the above points, and contribution of any arguments I failed to consider.

[Jameson Lopp]

It's certainly an edge case worth considering. If timelocked coins are being spent that haven't previously exposed their public keys, it could be considered safe to allow them to be spent. Quantum computers would have to become extremely powerful in order to reverse engineer a key and RBF a transaction just during the time it's in the mempool.

I think this does bring up an often overlooked aspect of extremely long time locks: preventing yourself from spending funds does expose you to edge case protocol weaknesses that require migration of funds. Personally I'd get a bit nervous locking funds for more than a year or two.

Another downside to long timelocks is that you could potentially miss out on the ability to economically "vote with your feet" in the case of a controversial chain fork.

On Sun, Mar 16, 2025 at 3:45 PM Nagaev Boris <bna...@gmail.com> wrote:

Hi!

What is your perspective on time-locked coins that become spendable
only after a set deadline? Unlike regular holders who can migrate
their funds in advance, owners of time-locked coins, such as those set
to unlock through an inheritance or a smart contract, have no way to
react before the deadline. Imagine you received an inheritance set to
unlock in 2030, only to find that the deadline for migration is set
for 2029. Would such cases be considered an acceptable loss, or is
there a way to account for them without violating Bitcoin’s
principles?

Boris

> --
> 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_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com.



--
Best regards,
Boris Nagaev

[IdeA]

Hi Jameson, Could those who, for whatever reason, do not want to migrate to secure addresses be allowed to do so if they sign with their keys, thus providing proof of life and possession, and not participating in this update scheme? This could be a way to not violate the principle of freedom and sovereignty of each individual over their addresses. 

Very interesting article, I completely agree.

Sincerely, Fedebuyito. -

--

[Matt Corallo]

Thanks for posting this Jameson,

I think this is a strong motivation to do "simple PQC" today - while we don't need to decide on the
tough question of seizing non-PQC coins today, we want to have the option to do so in the future.

In order for that option to be practical, wallets need to be embedding PQC public keys in their
outputs probably at least a decade before the seizure occurs, with any additional time giving us an
important safety margin.

Thus it seems like time we add the simplest form of PQC we can - a trivial OP_HASHBASEDSIG (probably
SPHINCS+) to tapscript to enable wallets to have hidden PQC keys (including multisig) in their taptrees.

Matt

> the funds *out of reach of everyone*.

>
> Not freezing user funds is one of Bitcoin's inviolable properties. However, if quantum computing

> becomes a threat to Bitcoin's elliptic curve cryptography, *an inviolable property of Bitcoin will
> be violated one way or another*.

>
> Fundamental Properties at Risk
> 5 years ago I attempted to comprehensively categorize all of Bitcoin's fundamental properties that
> give it value. https://nakamoto.com/what-are-the-key-properties-of-bitcoin/
> <https://nakamoto.com/what-are-the-key-properties-of-bitcoin/>
> The particular properties in play with regard to this issue seem to be:
>

> *Censorship Resistance* - No one should have the power to prevent others from using their bitcoin or
> interacting with the network.
>
> *Forward Compatibility* - changing the rules such that certain valid transactions become invalid

> could undermine confidence in the protocol.
>

> *Conservatism* - Users should not be expected to be highly responsive to system issues.

>
> As a result of the above principles, we have developed a strong meme (kudos to Andreas Antonopoulos)
> that goes as follows:
>
> Not your keys, not your coins.
>
>
> I posit that the corollary to this principle is:
>
> Your keys, only your coins.
>
>
> A quantum capable entity breaks the corollary of this foundational principle. We secure our bitcoin
> with the mathematical probabilities related to extremely large random numbers. Your funds are only
> secure because truly random large numbers should not be guessable or discoverable by anyone else in
> the world.
>

> This is the principle behind the motto /vires in numeris/ - strength in numbers. In a world with

> quantum enabled adversaries, this principle is null and void for many types of cryptography,
> including the elliptic curve digital signatures used in Bitcoin.
>
> Who is at Risk?
> There has long been a narrative that Satoshi's coins and others from the Satoshi era of P2PK locking
> scripts that exposed the public key directly on the blockchain will be those that get scooped up by
> a quantum "miner." But unfortunately it's not that simple. If I had a powerful quantum computer,
> which coins would I target? I'd go to the Bitcoin rich list and find the wallets that have exposed
> their public keys due to re-using addresses that have previously been spent from. You can easily

> find them at https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html <https://
> bitinfocharts.com/top-100-richest-bitcoin-addresses.html>

>
> Note that a few of these wallets, like Bitfinex / Kraken / Tether, would be slightly harder to crack
> because they are multisig wallets. So a quantum attacker would need to reverse engineer 2 keys for
> Kraken or 3 for Bitfinex / Tether in order to spend funds. But many are single signature.
>
> Point being, it's not only the really old lost BTC that are at risk to a quantum enabled adversary,
> at least at time of writing. If we add a quantum safe signature scheme, we should expect those
> wallets to be some of the first to upgrade given their incentives.
>
> The Ethical Dilemma: Quantifying Harm
> Which decision results in the most harm?
>
> By making quantum vulnerable funds unspendable we potentially harm some Bitcoin users who were not
> paying attention and neglected to migrate their funds to a quantum safe locking script. This
> violates the "conservativism" principle stated earlier. On the flip side, we prevent those funds
> plus far more lost funds from falling into the hands of the few privileged folks who gain early
> access to quantum computers.
>
> By leaving quantum vulnerable funds available to spend, the same set of users who would otherwise
> have funds frozen are likely to see them stolen. And many early adopters who lost their keys will
> eventually see their unreachable funds scooped up by a quantum enabled adversary.
>
> Imagine, for example, being James Howells, who accidentally threw away a hard drive with 8,000 BTC
> on it, currently worth over $600M USD. He has spent a decade trying to retrieve it from the landfill
> where he knows it's buried, but can't get permission to excavate. I suspect that, given the choice,
> he'd prefer those funds be permanently frozen rather than fall into someone else's possession - I
> know I would.
>
> Allowing a quantum computer to access lost funds doesn't make those users any worse off than they

> were before, however it /would/ have a negative impact upon everyone who is currently holding bitcoin.

>
> It's prudent to expect significant economic disruption if large amounts of coins fall into new
> hands. Since a quantum computer is going to have a massive up front cost, expect those behind it to
> desire to recoup their investment. We also know from experience that when someone suddenly finds
> themselves in possession of 9+ figures worth of highly liquid assets, they tend to diversify into
> other things by selling.
>

> Allowing quantum recovery of bitcoin is /tantamount to wealth redistribution/. What we'd be allowing

> --
> 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 <mailto:bitcoindev+...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/

> CADL_X_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com <https://
> groups.google.com/d/msgid/bitcoindev/
> CADL_X_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Jameson Lopp]

> Could those who, for whatever reason, do not want to migrate to secure addresses be allowed to do so if they sign with their keys, thus providing proof of life and possession, and not participating in this update scheme?

While nearly anything is technically possible, I'm skeptical that folks would be sufficiently motivated to build this functionality.

Ceasing support for vulnerable software and systems is a common concept. For example, IIRC, Bitcoin Core provides support for 18 months, Ubuntu provides long-term support for 5 years, Windows provides unpaid support for 5 years, etc. https://endoflife.date/

[Nagaev Boris]

Hi!

What is your perspective on time-locked coins that become spendable
only after a set deadline? Unlike regular holders who can migrate
their funds in advance, owners of time-locked coins, such as those set
to unlock through an inheritance or a smart contract, have no way to
react before the deadline. Imagine you received an inheritance set to
unlock in 2030, only to find that the deadline for migration is set
for 2029. Would such cases be considered an acceptable loss, or is
there a way to account for them without violating Bitcoin’s
principles?

Boris

On Sun, Mar 16, 2025 at 12:22 PM Jameson Lopp <jameso...@gmail.com> wrote:
>

> --
> 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_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com.

[Sjors Provoost]

> Op 17 mrt 2025, om 13:00 heeft Matt Corallo <lf-l...@mattcorallo.com> het volgende geschreven:
>
> I think this is a strong motivation to do "simple PQC" today - while we don't need to decide on the tough question of seizing non-PQC coins today, we want to have the option to do so in the future.
>
> In order for that option to be practical, wallets need to be embedding PQC public keys in their outputs probably at least a decade before the seizure occurs, with any additional time giving us an important safety margin.

I don't think that in practice we can deploy a PCQ scheme without at the same time making a decision with regards to burn vs free-for-all. The best we can do is to have all that stuff well researched and tested long before on a signet.

Let's say the burn consensus rule is that no pk(), bare multisig, pkh()*, wpkhk() output can be spent, in addition to any tr() key path.
To be triggered at some point far enough in the future that people can migrate, but not too late. Let's ignore for now that this will be very hard to agree on, because people will disagree on the nature and timing of the threat until it's undeniable.

In principe a PQC (Post-quantum cryptography) tap leaf scheme could be proposed in a BIP and activated in a soft-fork, without having to decide on the burn issue. Any time your wallet needs to generate a new address, it could add such a tap leaf just in case.
But this adds a bunch of complexity to wallets, makes descriptor backups longer, etc. So adoption might be minimal. And since no sane person spends from the PQC path, we'd have no idea how much adoption there is.

More importantly, the activation of a PQC tapleaf soft fork would not be sufficient to permanently migrate coins. That's because in a free-for-all quantum scenario it's the wrong approach. The quantum attacker would just spend from your key path.

In that scenario you'd need to use a NUMS point for the key path. Or maybe that's unsafe, in which case we'd need a new Taproot version without key path support (or BIP360). That's also not a difficult soft fork, but now again you have something that only a small set of users will want to use.

This new address type is only suitable for very long term storage since it's more expensive to use in a pre-quantum world (using the a regular Schnorr signature in a script path).

So now we'd have two soft forks that ~nobody uses, because it's a bunch of extra wallet complexity and you don't know if you should use the tapleaf or the taproot-without-keypath address for your cold storage.

I doubt that soft forks which nobody intends to use will be activated anytime soon.

- Sjors

---
*

See appendix B of BIP380 for notation: https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki#appendix-b-index-of-script-expressions

Since we don't know which public keys are reused, the pkh() underlying public key can be brute force guessed by trying all known keys. There is also no alternative spending path. So it should be included in the burn.

sh() and wsh() would not be frozen. Some scripts may be guessable from context, but imo that doesn't outweigh the possibly that someone designed a quantum proof script - even a bad one.

Neither would any scriptPubKey that's different from the above standard templates. This allows implementing the freeze rule in a way that doesn't require deep / complicated inspection of the script

[Chris Riley]

This makes a lot of sense.  One would think that prior to an attack on bitcoin other coins would be attacked first, e.g. Ethereum given the way I understand that public keys are exposed vs bitcoin, so there could be some warning from softer, vulnerable and valuable targets to attack such as alt coins, governments, and financial institutions.  

However, none of this changes the points you made and the importance of looking at the issue sooner versus later given the long lead time that will be necessary since there could be little warning.  I have seen estimates in the 2030-2035 range for a potential attack and the US Federal government tells agencies they must transition by 2035 to a quantum safe scheme further emphasizing the potential urgency.

Of course, some argue it could take "decades" or even longer—if it ever happens at all—so there is significant uncertainty about when a successful attack might occur. To me, this is a "prepare for the worst and hope for the best" scenario. As you noted, whether coins are "burned" or "stolen," the outcome is the same for their owners: they lose control of their assets. Logically, they might even prefer for their coins to be burned rather than stolen, as it would prevent dilution of any remaining holdings and help mitigate systemic damage to the ecosystem.

Thanks :-)

--

[AstroTown]

I believe that having some entity announce the decision to freeze old UTXOs would be more damaging to Bitcoin’s image (and its value) than having them gathered by QC. This would create another version of Bitcoin, similar to Ethereum Classic, causing confusion in the market.

It would be better to simply implement the possibility of moving funds to a PQC address without a deadline, allowing those who fail to do so to rely on luck to avoid having their coins stolen. Most coins would be migrated to PQC anyway, and in most cases, only the lost ones would remain vulnerable. This is the free-market way to solve problems without imposing rules on everyone.

Saulo Fonseca

Allowing a quantum computer to access lost funds doesn't make those users any worse off than they were before, however it wouldhave a negative impact upon everyone who is currently holding bitcoin.

[Agustin Cruz]

I’m against letting quantum computers scoop up funds from addresses that don’t upgrade to quantum-resistant. 
Saulo’s idea of a free-market approach, leaving old coins up for grabs if people don’t move them, sounds fair at first. Let luck decide, right? But I worry it’d turn into a mess. If quantum machines start cracking keys and snagging coins, it’s not just lost Satoshi-era stuff at risk. Plenty of active wallets, like those on the rich list Jameson mentioned, could get hit too. Imagine millions of BTC flooding the market. Prices tank, trust in Bitcoin takes a dive, and we all feel the pain. Freezing those vulnerable funds keeps that chaos in check.
Plus, “your keys, your coins” is Bitcoin’s heart. If quantum tech can steal from you just because you didn’t upgrade fast enough, that promise feels shaky. Freezing funds after a heads-up period (say, four years) protects that idea better than letting tech giants or rogue states play vampire with our network. It also nudges people to get their act together and move to safer addresses, which strengthens Bitcoin long-term.
Saulo’s right that freezing coins could confuse folks or spark a split like Ethereum Classic. But I’d argue quantum theft would look worse. Bitcoin would seem broken, not just strict. A clear plan and enough time to migrate could smooth things over. History’s on our side too. Bitcoin’s fixed bugs before, like SegWit. This feels like that, not a bailout.
So yeah, I’d rather see vulnerable coins locked than handed to whoever builds the first quantum rig. It’s less about coddling people and more about keeping Bitcoin solid for everyone. What do you all think?
Cheers,
Agustín

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/E8269A1A-1899-46D2-A7CD-4D9D2B732364%40astrotown.de.

[Murch]

Thanks for the comprehensive collection of the arguments for and against.

I was wondering whether a single block height at which all vulnerable
coins become frozen would lead to a bidding war close to the deadline.
Perhaps it would be worth considering whether vulnerable UTXO types (or
even all UTXOs) should instead be removed from the UTXO set in a
staggered fashion. E.g., if P2PK or bare multisig UTXOs are not spent
within five epochs (1,050,000 blocks, about 20 years) after being
created, they become unspendable after that. This could be potentially
combined with a soft fork that prevents creation of new vulnerable UTXOs.

> *out of reach of everyone*.
>

> Not freezing user funds is one of Bitcoin's inviolable properties.
> However, if quantum computing becomes a threat to Bitcoin's elliptic

> curve cryptography, *an inviolable property of Bitcoin will be violated
> one way or another*.

>
> Fundamental Properties at Risk
> 5 years ago I attempted to comprehensively categorize all of Bitcoin's
> fundamental properties that give it value. https://nakamoto.com/what-
> are-the-key-properties-of-bitcoin/
> <https://nakamoto.com/what-are-the-key-properties-of-bitcoin/>
> The particular properties in play with regard to this issue seem to be:
>

> *Censorship Resistance* - No one should have the power to prevent others

> from using their bitcoin or interacting with the network.
>

> *Forward Compatibility* - changing the rules such that certain valid

> transactions become invalid could undermine confidence in the protocol.
>

> *Conservatism* - Users should not be expected to be highly responsive to

> system issues.
>
> As a result of the above principles, we have developed a strong meme
> (kudos to Andreas Antonopoulos) that goes as follows:
>
> Not your keys, not your coins.
>
>
> I posit that the corollary to this principle is:
>
> Your keys, only your coins.
>
>
> A quantum capable entity breaks the corollary of this foundational
> principle. We secure our bitcoin with the mathematical probabilities
> related to extremely large random numbers. Your funds are only secure
> because truly random large numbers should not be guessable or
> discoverable by anyone else in the world.
>

> This is the principle behind the motto /vires in numeris/ - strength in

> numbers. In a world with quantum enabled adversaries, this principle is
> null and void for many types of cryptography, including the elliptic
> curve digital signatures used in Bitcoin.
>
> Who is at Risk?
> There has long been a narrative that Satoshi's coins and others from the
> Satoshi era of P2PK locking scripts that exposed the public key directly
> on the blockchain will be those that get scooped up by a quantum
> "miner." But unfortunately it's not that simple. If I had a powerful
> quantum computer, which coins would I target? I'd go to the Bitcoin rich
> list and find the wallets that have exposed their public keys due to re-
> using addresses that have previously been spent from. You can easily
> find them at https://bitinfocharts.com/top-100-richest-bitcoin-

> addresses.html <https://bitinfocharts.com/top-100-richest-bitcoin-
> addresses.html>

> users any worse off than they were before, however it /would/ have a

> negative impact upon everyone who is currently holding bitcoin.
>
> It's prudent to expect significant economic disruption if large amounts
> of coins fall into new hands. Since a quantum computer is going to have
> a massive up front cost, expect those behind it to desire to recoup
> their investment. We also know from experience that when someone
> suddenly finds themselves in possession of 9+ figures worth of highly
> liquid assets, they tend to diversify into other things by selling.
>

> Allowing quantum recovery of bitcoin is /tantamount to wealth
> redistribution/. What we'd be allowing is for bitcoin to be

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

> <mailto:bitcoindev+...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/
> bitcoindev/

> CADL_X_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CADL_X_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Matt Corallo]

On 3/18/25 8:48 AM, Sjors Provoost wrote:
>
>> Op 17 mrt 2025, om 13:00 heeft Matt Corallo <lf-l...@mattcorallo.com> het volgende geschreven:
>>
>> I think this is a strong motivation to do "simple PQC" today - while we don't need to decide on the tough question of seizing non-PQC coins today, we want to have the option to do so in the future.
>>
>> In order for that option to be practical, wallets need to be embedding PQC public keys in their outputs probably at least a decade before the seizure occurs, with any additional time giving us an important safety margin.
>
> I don't think that in practice we can deploy a PCQ scheme without at the same time making a decision with regards to burn vs free-for-all. The best we can do is to have all that stuff well researched and tested long before on a signet.

As Jameson describes, I don't think there's a decision to be made here. If, at some point, a QC
becomes undeniable reality (or near-term reality), *not* doing a freeze fork is to allow Bitcoin to
simply die. The only thing we can do is set ourselves up for success such that that freeze freezes
the minimum possible number coins.

> Let's say the burn consensus rule is that no pk(), bare multisig, pkh()*, wpkhk() output can be spent, in addition to any tr() key path.
> To be triggered at some point far enough in the future that people can migrate, but not too late. Let's ignore for now that this will be very hard to agree on, because people will disagree on the nature and timing of the threat until it's undeniable.
>
> In principe a PQC (Post-quantum cryptography) tap leaf scheme could be proposed in a BIP and activated in a soft-fork, without having to decide on the burn issue. Any time your wallet needs to generate a new address, it could add such a tap leaf just in case.
> But this adds a bunch of complexity to wallets, makes descriptor backups longer, etc. So adoption might be minimal. And since no sane person spends from the PQC path, we'd have no idea how much adoption there is.

Indeed, adoption is a challenge. This is true for any PQ scheme, however. Still, I'm dubious that
simply no wallets would actually do that - there is material dramaz over PQ Bitcoin these days, and
for (somewhat) good reason. Those selecting a wallet for short-term use of course have no need to do
this, but those selecting a long-term storage wallet might see PQC as a feature they want, and
select a wallet accordingly.

> More importantly, the activation of a PQC tapleaf soft fork would not be sufficient to permanently migrate coins. That's because in a free-for-all quantum scenario it's the wrong approach. The quantum attacker would just spend from your key path.

As noted above I don't buy that this is a possible outcome.

> In that scenario you'd need to use a NUMS point for the key path. Or maybe that's unsafe, in which case we'd need a new Taproot version without key path support (or BIP360). That's also not a difficult soft fork, but now again you have something that only a small set of users will want to use.

A NUMS point does not suffice unless we explicitly soft-fork out spending from that NUMS point
(which is, of course, doable).

> This new address type is only suitable for very long term storage since it's more expensive to use in a pre-quantum world (using the a regular Schnorr signature in a script path).
>
> So now we'd have two soft forks that ~nobody uses, because it's a bunch of extra wallet complexity and you don't know if you should use the tapleaf or the taproot-without-keypath address for your cold storage.
>
> I doubt that soft forks which nobody intends to use will be activated anytime soon.

There is nontrivial demand (again, for (somewhat) good reason) for PQC on bitcoin today. Suggesting
that no one intends to use such a thing I find incredibly dubious.

Matt

[Sjors Provoost]

Matt Corallo wrote:

>> In that scenario you'd need to use a NUMS point for the key path. Or maybe that's unsafe, in which case we'd need a new Taproot version without key path support (or BIP360). That's also not a difficult soft fork, but now again you have something that only a small set of users will want to use.
>>>
>>>
> A NUMS point does not suffice unless we explicitly soft-fork out spending from that NUMS point (which is, of course, doable).

This could be a solution to the sequencing conundrum that I tried to explain.

Along with the first PCQ scheme for tapscript (script path), we could have a soft that disables one or more NUMS points. The latter has zero effect under the current cryptographic assumptions, so it's not confiscatory.

That way people can start using the scheme without having to worry about whether the community decides to freeze key path spending in time. They'll still worry about the market value of their coins, but not about whether they're going to be the first victim (or the umpteenth victim while everyone is in denial and blames them for poor key management).

- Sjors

[Matt Corallo]

Mmm, yea, fair enough, that seems perfectly reasonable to include.

Matt

[Javier Mateos]

Hi everyone!

Seeing the discussions about transitioning to quantum-resistant signatures, I notice three main concerns:

• What should be done with vulnerable funds? Freeze them or leave them exposed?

• How can the transition be made without affecting Bitcoin’s stability or dividing the community?

• How can we avoid market chaos if the transition is disorderly?

Personally, I believe the key is a gradual, well-planned transition based on incentives rather than abrupt changes that create uncertainty.

I can think of a three-phase approach:

🔹 First, allow users to add optional PQC keys to their Taproot addresses starting now.
🔹 Then, before the quantum threat becomes real, introduce a soft fork that disables vulnerable signatures, but with a long migration period (at least four years).
🔹 Finally, when the threat is imminent, gradually phase out old signatures instead of forcing a sudden change.

For this to work, adoption should be incentivized—for example, with lower fees for secure transactions and wallet tools that facilitate a smooth transition. Additionally, real-time monitoring of vulnerable addresses would help mitigate risks.

Another key point is to avoid panic. Instead of a sudden "D-Day" where everything changes at once, the deactivation of old UTXOs should be gradual, with clear communication so no one feels forced or disadvantaged.

In summary, this is not about imposing rules or confiscating anything, but about providing options for an orderly transition that doesn’t compromise Bitcoin’s philosophy.

-Javier Mateos

[Ben Sigman]

Considering the information presented by Jameson, it's difficult to see a solution to the quantum attack question other than some form of freeze.

Murch’s idea of a rolling timeout sounds elegant from one perspective, but also more difficult to calculate or understand for an average user. The quantum doomsday clock is simpler - albeit, there would be a bidding war…

That being said, the first step seems to be that Bitcoin needs a path to having post-quantum signatures / addresses as an option.

I’d advocate that the developer community focus resources on implementing a path forward with at least some version of this - either BIP 360 or some form of Taproot PQC.

[Nadav Ivgi]

One possible alternative to freezing/burning the coins entirely is letting quantum attackers keep some small percent as a reward, but force them to stage the rest to future miners as an additional security budget subsidy.

This can be implemented as a soft fork, by requiring transactions spending QC-vulnerable coins to allocate some funds to an OP_CLTV[0]-only encumbered output timelocked far into the future. Miners would then monitor these outputs and claim them as they become available.

For example, allow a 1% reward to be spent freely to any address but require 99% to be sent to an OP_CLTV output timelocked to a deterministically random height between 10-100 years from now.

The 1% reward could also be required to be sent to a script that enforces a timelock (in addition to other conditions), to avoid flooding the markets with the rewarded coins all at once. Probably a shorter timelock duration though, say picked randomly between 10-30 months.

To further smooth out variance in the release schedule, coins could be split into up-to-N-BTC outputs, each staggered with a different deterministic timelock. So for example, a single tx spending 10,000 BTC won't release 9,900 BTC to the miners in a single far-future block (which may cause chain instability if the miners get into a reorg war over it), but rather as 9,900 separate outputs of 1 BTC each released gradually time.[1]

I'm still not sure what I think about this. This is not necessarily an endorsement, just a thought. :)

- shesek

[0] OP_CSV only supports relative timelocks of up to 65535 blocks (~15 months), which is too short for that purpose. OP_CLTV supports longer (absolute) timelocks.

[1] This can be made more efficient with CTV, by having a single UTXO carrying the full amount that slowly unrolls rather than 9,900 separate UTXO entries.

--

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_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com.

[Michael Tidwell]

I'm late, but want to share thoughts. I gathered from this thread the way more pertinent and prerequisite idea is to formulate some idea for pqc safe schemes, before the idea of burning/freezing/other becomes actionable.
Originally I thought Matt's idea of a secure leaf that could be enabled to be the only spend path seemed clever, but after thinking about it more, I think it would be better to cleanly have a new address/ taproot version.

1. We get public data to know how many coins are using the post-quantum secured scheme. Allow better informed decisions on adoptions, planning, and understanding sentiment on the perceived threat.
2. would have clean separation for users to know whether or not their address is PQC secured.
3. for people not worried about it, they wouldn't feel arm-bar'd into having longer descriptors and an unnecessary leaf.
4. *unsure here*, but possible that library and wallet developers could treat this with cleaner separation uX, UI and not worry about (legacy-tr) vs (pqc-tr) descriptions and script code. (To help users differentiate)
5. We wouldn't need to worry about some roll out period or flag day where the leafs become necessary or an enabled spend path.

Given that pqc transactions will likely require additional space and computational resources, we should be cautious about heavily incentivizing uncertain approaches (i.e. it may be advantageous to decide on something before having certainty about the optimal approach). Significant fee discounts may be needed once there's high confidence on the approach/method. However, enhanced security itself inherently serves as part of the explicit incentive, and maybe should be part of the incentive calculation.

[conduition]

Hey Saulo,

You're right about the possibility of an ugly split. Laggards who don't move coins to PQ address schemes will be incentivized to follow any chain where they keep their coins. But those who do migrate will be incentivized to follow the chain where unmigrated pre-quantum coins are frozen. 

While you're comparing this event to the ETH/ETC split, we should remember that ETH remained the dominant chain despite their heavy-handed rollback. Just goes to show, confusion and face-loss is a lesser evil than allowing an adversary to pwn the network. 

This is the free-market way to solve problems without imposing rules on everyone.

It'd still be a free market even if quantum-vulnerable coins are frozen. The only way to test the relative value of quantum-safe vs quantum-vulnerable coins is to split the chain and see how the market reacts. 

IMO, the "free market way" is to give people options and let their money flow to where it works best. That means people should be able to choose whether they want their money to be part of a system that allows quantum attack, or part of one which does not. I know which I would choose, but neither you nor I can make that choice for everyone.

regards,

conduition

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAJDmzYxw%2BmXQKjS%2Bh%2Br6mCoe1rwWUpa_yZDwmwx6U_eO5JhZLg%40mail.gmail.com.

[Dustin Ray]

The difference between the ETH/ETC split though was that no one had anything confiscated except the DAO hacker, everyone retained an identical number of tokens on each chain. The proposal for BTC is very different in that some holders will lose access to their coins during the PQ migration under the confiscation approach. Just wanted to point that out.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/zyx7G6H1TyB2sWVEKAfIYmCCvfXniazvrhGlaZuGLeFtjL3Ky7B-9nBptC0GCxuHMjjw8RasO7c3ZX46_6Nerv0SgCP0vOi5_nAXLmiCJOY%3D%40proton.me.

[Agustin Cruz]

Hi everyone,

QRAMP proposal aims to manage the quantum transition responsibly without disrupting Bitcoin’s core principles.

QRAMP has three phases:

1. Allow wallets to optionally include PQC keys in Taproot outputs. This enables early adoption without forcing anyone.

2. Announce a soft fork to disable vulnerable scripts, with a long (~4-year) grace period. This gives ample time to migrate and avoids sudden shocks.

3. Gradually deactivate vulnerable outputs based on age or inactivity. This avoids a harsh cutoff and gives time for adaptation.

We can also allow exceptions via proof-of-possession, and delay restrictions on timelocked outputs to avoid harming future spenders.

QRAMP is not about confiscation or control. It’s about aligning incentives, maintaining security, and offering a clear, non-coercive upgrade path.

Best,

Agustin Cruz

[waxwing/ AdamISZ]

Hi all,

I'd like to point out that the worst case scenarios here might be even worse than one naturally thinks.

(1) The first part is obvious: even though unlikely, it's possible that a certain group gains access to this functionality well in advance of the general state of the art, and not only that, but decides to steal coins only surreptitiously. This may be economically optimal for the thieves, but may also be negative-optimal (pessimal?) for the rest of us: because there will be continuous controversy about whether the theft happened, which relates to the unobvious point:

(2) The second part is somehow even way worse: that a well funded (but not having to spend money) attacker (not thief) on the system creates panic by pretending to have its coins stolen, even though it does not have access to an ECDLP break. This would be most likely in taproot, because they cannot prepare this attack in advance on coins created in 2009-10. Their only task is to create credibility amongst the general Bitcoin public, and thus force sufficient controversy for perhaps a chain split based on disagreeing with how to deal with the threat. I admit this is fairly fanciful, but imagine it occurring in combination with a heavily pushed proposal for a technically unsound solution to the problem which actually undermines Bitcoin's safety.

Notice that this second observation illustrates the sense in which this is crucially very different from the DAO as Jameson suggests: the act of theft is not unambiguously visible. (well to be fair the phrase was "*some* similarities" ! :) ).

Two more observations:

(3) I do really like the "disabled NUMS" concept in regard to taproot external keys, for paving the way to PQC in tapleaf. This is one kind of censorship that cannot be controversial.

(4) (in this I agree with Saulo Fonseca): my second observation might be unpopular but I think that a burning coins softfork will be appallingly hard to come to consensus on, and probably shouldn't even be attempted ((2) is relevant here). I don't think it's going to happen. I think we need some cryptographic chicanery that allows spending currently-hashed utxos safely, along the lines of what Tim Ruffing, Adam Back and others have discussed in the past, and that P2PK that is untouched even during a transition is just a lost cause. (I also think that this is very very far in the future but that is 100% opinion, not fact).

[Sjors Provoost]

Op 28 mei 2025, om 03:07 heeft waxwing/ AdamISZ <ekag...@gmail.com> het volgende geschreven:

Hi all,

I'd like to point out that the worst case scenarios here might be even worse than one naturally thinks.

Good morning! :-)

Two more observations:

(3) I do really like the "disabled NUMS" concept in regard to taproot external keys, for paving the way to PQC in tapleaf. This is one kind of censorship that cannot be controversial.

I brought this up [0], but it was later pointed out to me that it doesn't work.

The scriptPubKey that you see on chain is not the NUMS point itself. The internal key is a NUMS point, but it's tweaked. When this tweaked key is spent, the tweak itself is not revealed, so the blockchain can't tell if a NUMS was involved, and can't block the spend.

- Sjors

https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/bQk2v0E5BQAJ

[waxwing/ AdamISZ]

Sorry looks like I forgot to crosspost this reply to list:

Hi Sjors, list:

> I brought this up [0], but it was later pointed out to me that it doesn't work
 

Oh yes, doh. That's most unfortunate. While this is getting silly, I can't help wondering what happens, in the presence of an ECDLP breaker, to a botched version of taproot that requires script-path spending and doesn't allow key-path.

It's interesting, imagine: honest keyholder creates Q = P_N + H(P_N||S)G where P_N means NUMS internal key. ECDLP breaker can just find DL of Q but if we disallow key-path spend they have to open a hash commitment to a tweak as per usual taproot rules.

So they need: Q = P_2 +H(P_2||S_2)G now, they know the full private key x_N + H(P_N||S) for Q (and they may or may not know S, or be able to guess it, to get all the variables in that expression), but it seems to not help them given the commitment to P_2 in the hash, requiring them to choose P_2 before the hash.

They could of course do it with P_N itself, if that were allowed, hence the "disable NUMS" might make sense, in this scenario. Can't say I'm 100% sure of myself here, but it looks like that works.

Even if I'm right, it's not so interesting; we already are assuming that a quantum attacker can't break hashes, that's behind a lot of the discussion here, so of course it would make sense if we broke taproot to require it only to use hashes (script path only), then it might come back to the same security situation (which of course, is not actual security, since keys are always revealed in spending). Or maybe we should start to think of really, really worst case scenarios: what if a new quantum algorithm actually does efficiently find SHA2 preimages? :)

Thanks, AdamISZ/waxwing

[ArmchairCryptologist]

Hi,

With the longer grace period and selective deactivation, this seems more sensible, but there is one elephant in the room that I haven't seen mentioned here - namely, the legal aspect. (If it was, sorry I missed it.)

I'm not a lawyer, but if developers make a conscious decision to make a code change that confiscates funds, even with a reasonable heads-up, I feel like some lawyers might be tempted to make an argument that those developers should be held responsible for any losses. As everyone knows, Bitcoin has been under legal attacks before, and I'm not sure that anyone would (or should) be willing to sign off on a change that might potentially open them up to several billion dollars worth of personal responsibility - especially if the "bonded courier" actually shows up and reveals a private key that would have unlocked funds under the pre-QC scheme.

The only safe-ish way I can see to do this is to have it only affect funds that are very likely to be lost in the first place. So at the very least, it could not affect UTXOs that could potentially be encumbered with a timelock (i.e. P2SH/P2WSH), and it could only affect UTXOs that have not moved for a very long time (say 15-20 years).

If quantum computers capable of practical attacks against Bitcoin are ever known to actually exist, sending​ to non-PQC addresses should of course be disabled immediately. But I feel that the nature of a permissionless system implies a large degree of self-responsibility, so if someone chooses to keep using non-PQC addresses even after PQC addresses have become available and practical quantum attacks are suspected to be an imminent danger, it's not necessarily up to the developers to tell them they can't, only that they really shouldn't.

--

Regards,

ArmchairCryptologist

Sent with Proton Mail secure email.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAJDmzYycnXODG_e9ATqTkooUu3C-RS703P1-RQLW5CdcCehsqg%40mail.gmail.com.

[waxwing/ AdamISZ]

> I'm not a lawyer, but if developers make a conscious decision to make a code change that confiscates funds, even with a reasonable heads-up, I feel like some lawyers might be tempted to make an argument that those developers should be held responsible for any losses. As everyone knows, Bitcoin has been under legal attacks before, and I'm not sure that anyone would (or should) be willing to sign off on a change that might potentially open them up to several billion dollars worth of personal responsibility - especially if the "bonded courier" actually shows up and reveals a private key that would have unlocked funds under the pre-QC scheme.

Coincidentally, Peter Todd has just made the same point in another (apparently unrelated) thread, here: https://groups.google.com/g/bitcoindev/c/bmV1QwYEN4k/m/kkHQZd_BAwAJ

For me it's very clear, that it's not an accident that such "unexpected" side effects exist. It's a feature that I'd whimsically call "ethical impedance-mismatch" (the term impedance mismatch has been used in computing/programming, which itself borrowed it from the real meaning, in physics). People have a moral/ethical desire to make bitcoin function as well as possible, and see a failure mode in those using it for other purposes, but that line of thought clashes with the essential, basic principle of censorship-resistance.

So we see technical borked-ness like failure to get accurate fee rates and the like, from doing something (attempting to filter at p2p level) that it is intrinsically counter to the foundational ethical, functional purpose of the system: censorship-resistance. And then we see "cascading failures" of the type discussed here: if the devs are working to break bitcoin's ethical promise of censorship-resistance, then thugs^H^H politicians and lawyers, will seek to take control of that "break" for their own purposes.

That's why I'm not against "quantum recovery" as per the title of this thread. Recovery, independent of outside control, *is* bitcoin's function. If half a million btc get spent by someone who has "recovered" in an unexpected way, tough titties. If the entire system collapses because we can't get our act together before 2085 (OK I know some think it's 2035, I don't, but whatever), then it is what it is. That is a huge unknown. But Bitcoin will 100% fail if confiscation of *any* type becomes a thing.

Cheers,

AdamISZ/waxwing

[Jameson Lopp]

> if developers make a conscious decision to make a code change that confiscates funds, even with a reasonable heads-up, I feel like some lawyers might be tempted to make an argument that those developers should be held responsible for any losses.

Anyone can sue anyone for anything, so the mere potential for a lawsuit isn't something that I believe should be taken into consideration with regard to protocol changes.

But such an argument would be fundamentally flawed, because developers don't actually enforce changes to the protocol. Enforcement must be performed by miners and node operators. I suspect lawyers would have a tough time finding and suing all of them. Suing someone for running software you dislike also sounds like a pretty weak position; at least in America I'd expect to be protected by freedom of speech. Remember that anyone who might desire to do so is still free to write and run software that rejects those changes.

Bitcoin is "trustless" if you validate the state of the network with your own independently controlled full node. But, on the flip side, you must "trust" the rest of the network not to coordinate changes to the network that are to your personal detriment. If a supermajority of sovereign actors decide they need to protect themselves from negative consequences of quantum capable adversaries, I wouldn't expect the threat of lawsuits to stop them.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/893891ea-34ec-4d60-9941-9f636be0d747n%40googlegroups.com.

[Boris Nagaev]

> If a supermajority of sovereign actors decide they need to protect themselves from negative consequences of quantum capable adversaries, I wouldn't expect the threat of lawsuits to stop them.

Given that a PQ address type exists, individuals forming such a supermajority are free to move their funds to PQ addresses. At that point, the remaining minority of vulnerable funds no longer poses a systemic risk.

That said, I believe it would be better to first implement a PQ address type and evaluate its fee costs. Current NIST-approved schemes are quite expensive in terms of block space. Whether a broad adoption of PQ addresses is justified depends on trade-offs users face. Without concrete data on those trade-offs, it's premature to discuss enforcing such a move.

Even if PQ addresses turn out to be as space-efficient as P2TR, enforcing their use would still constitute a form of central planning, imposing a particular choice on all users. The situation becomes even more problematic if these addresses are more expensive. It risks resembling scenarios where governments mandate actions like mandatory insurance in the name of collective safety. In this case, users who don't view quantum computing as a credible threat would be compelled not only to move their funds (at some cost) but also to pay more for each subsequent transaction. That feels contrary to Bitcoin's foundational principles.

If a secure and efficient PQ address format becomes available, I will personally move my funds to it. But I don't believe I (or anyone else) have the right to force others to do the same. A group of individuals has no more rights than the sum of the individuals within it. This is a fundamental principle of individual liberty and runs counter to collectivism. Even a majority shouldn't be able to impose such a requirement. What we can do is offer tools and economic incentives (like the segwit discount) to encourage voluntary adoption.

[Jameson Lopp]

On Sat, Jul 12, 2025 at 9:48 PM Boris Nagaev <bna...@gmail.com> wrote:

> If a supermajority of sovereign actors decide they need to protect themselves from negative consequences of quantum capable adversaries, I wouldn't expect the threat of lawsuits to stop them.

Given that a PQ address type exists, individuals forming such a supermajority are free to move their funds to PQ addresses. At that point, the remaining minority of vulnerable funds no longer poses a systemic risk.

That said, I believe it would be better to first implement a PQ address type and evaluate its fee costs. Current NIST-approved schemes are quite expensive in terms of block space. Whether a broad adoption of PQ addresses is justified depends on trade-offs users face. Without concrete data on those trade-offs, it's premature to discuss enforcing such a move.

Quite true; there are a variety of issues such as block space availability and cost that need to be resolved. I freely admit that I'm focusing on a problem that is irrelevant until it's unblocked via resolution of other problems. But I don't think it's "too early" to start discussing long-term issues of this magnitude, as it's a rather complex issue that will need a great deal of discussion.

Even if PQ addresses turn out to be as space-efficient as P2TR, enforcing their use would still constitute a form of central planning, imposing a particular choice on all users. The situation becomes even more problematic if these addresses are more expensive. It risks resembling scenarios where governments mandate actions like mandatory insurance in the name of collective safety. In this case, users who don't view quantum computing as a credible threat would be compelled not only to move their funds (at some cost) but also to pay more for each subsequent transaction. That feels contrary to Bitcoin's foundational principles.

Disagree on the characterization of central planning. Just because something is proposed by a single person or small group does not make it "centrally planned" when consensus requires widespread voluntary adoption.

No one can be compelled to do anything, and this voluntary aspect of Bitcoin cuts both ways. While no one can be compelled to move funds from quantum vulnerable to quantum safe locking scripts, neither can a set of users who are sufficiently concerned about the value of their holdings being debased be compelled to continue using a network that allows for vulnerable funds to be scooped up by quantum capable adversaries.

 

If a secure and efficient PQ address format becomes available, I will personally move my funds to it. But I don't believe I (or anyone else) have the right to force others to do the same. A group of individuals has no more rights than the sum of the individuals within it. This is a fundamental principle of individual liberty and runs counter to collectivism. Even a majority shouldn't be able to impose such a requirement. What we can do is offer tools and economic incentives (like the segwit discount) to encourage voluntary adoption.

I attempted to make it clear in my original post that the incentives of individual holders, miners, businesses, etc appear to align and give them logical reasons to desire NOT operating on a network that allows for massive redistribution of wealth via theft and effective inflation of the circulating money supply via resurrection of lost coins. If a wide swath of diverse individuals happens to agree upon something, they may choose to take action as a "collective" of sorts, but I don't find that to be the same as "collectivism" in which a small group tells a large group "this is what's good for you, so you'd better do it."

Bitcoin is ultimately crypto anarchy, thus I think it's more appropriate to analyze the incentives and game theory of everyone involved rather than to attempt to project political theory and governance models onto a system that fundamentally eschews such things.

 

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1ae281cd-20a8-4b50-98b7-c228f090ad7an%40googlegroups.com.

[Boris Nagaev]

> I attempted to make it clear in my original post that the incentives of individual holders, miners, businesses, etc appear to align and give them logical reasons to desire NOT operating on a network that allows for massive redistribution of wealth via theft and effective inflation of the circulating money supply via resurrection of lost coins. If a wide swath of diverse individuals happens to agree upon something, they may choose to take action as a "collective" of sorts, but I don't find that to be the same as "collectivism" in which a small group tells a large group "this is what's good for you, so you'd better do it."

The Migration Proposal outlines incentives for different actors. Your reasoning seems valid for miners, exchanges, and institutions, but does it truly apply to everyday users? You mention "self-sovereign peace of mind." I would respectfully disagree here. To maintain self-sovereignty, it is sufficient for an individual to move their own funds to a PQ address.

A fork that involves confiscating funds, even if well-intentioned, would set a dangerous precedent, one that reduces everyone's self-sovereignty. From that point on, it would be seen as acceptable to seize funds in the name of system-wide safety.

Consider a related example: the freezing of stolen funds on blockchain level (e.g., AML enforcement via smart contracts). This practice exists in many crypto projects, though never in Bitcoin. One could argue that holders of such tokens have voluntarily given up part of their self-sovereignty for collective protection. The very act of using those tokens may imply acceptance of that trade-off.

Is the approach taken by Bitcoiners fundamentally different?

To me, the possibility of confiscating funds from legitimate owners crosses a critical line. A system that permits such actions doesn't prevent theft -- it institutionalizes it. Mass confiscation is organized theft.

[Or Sattath]

Hi,

Jameson Lopp presented the freeze/not-freeze dilemma. I would like to point out that there’s a third approach. The main insight is that even though the quantum attacker knows the digital signature private key, the attacker and the owner are not symmetric: the owner, in most cases, knows the seed (master secret key), whereas the quantum attacker does not. This approach, which was done in collaboration with Shai Wyborski, is available here: https://eprint.iacr.org/2023/362 (our work was peer reviewed and presented here: https://www.qsmc.org/pqcsm-workshop-2023).

Our main technique is called “signature lifting”: it’s a way to transform an existing quantum-insecure signature scheme into a quantum-secure signature scheme, while still using the old keys. This is possible whenever the function that maps the secret key to the public key is a quantum-secure one-way function. Informally (and there are some details under the rug that I’m not getting into), the quantum-secure one-way function maps the seed to the public key. (Of course, the function that maps the ECDSA signing key to the public key is not a quantum-secure one-way function. Therefore, our approach does not apply to pre-2013 wallets, which did not use BIP-38.) We use Picnic (https://dl.acm.org/doi/abs/10.1145/3133956.3133997) as the underlying primitive that enables signature lifting.

The main drawback of signature lifting is that the signatures are extremely long. To address this, we also designed an interactive way to transact, using a commit-wait-reveal approach, which we called “Lifted FawkesCoin" (our main contribution over the original FawkesCoin approach by Bonneau and Miller in https://jbonneau.com/doc/BM14-SPW-fawkescoin.pdf is that we resolve the issue of transaction fees, using lifted signatures). When the spender and the miner are honest, a transaction is roughly the same size as today; only if one of the parties deviates from the honest protocol must the long signature be added to the blockchain, and the cheating party is financially penalized. The main burden of Lifted FawkesCoin is that users who haven’t transitioned to quantum-secure signatures yet need to occasionally (e.g., once a year) come online and check for fraud attempts. I believe that even though this burden exists, it is a Pareto improvement over both the “freeze” and “not-freeze” approaches. 

Best,
Or

Allowing a quantum computer to access lost funds doesn't make those users any worse off than they were before, however it would have a negative impact upon everyone who is currently holding bitcoin.

[Ethan Heilman]

>  Is the approach taken by Bitcoiners fundamentally different?

I do not yet have an opinion here on burn vs. not-burning but I wanted to present a thought experiment about why freezing is not the same as confiscation:

Let's say instead of freezing vulnerable outputs we simply limited them to only be spent to vulnerable outputs, e.g., a txn with a P2PK input can only produce P2PK outputs, etc... Nothing has been confiscated. After this change, if you want to live in the quantum vulnerable world you can, you are just prevented from harming the rest of Bitcoin.

In practice, what miner would accept quantum vulnerable fees? What exchange would accept coins which could be stolen at any time? Would you accept coins as payment that could be stolen back later? Such a change would create two classes of Bitcoin outputs: worthless quantum vulnerable coins and actually valuable quantum resistant coins.

That is, quantum vulnerable outputs, in the presence of a quantum computer, have already had their value destroyed. They no longer function as property, but instead function as an inflationary reward for owning a quantum computer. Freezing them simply reflects this reality and protects quantum resistant coins from the inflation caused by quantum attacks.

As Jameson has pointed out elsewhere some of these outputs may be able to prove ownership via BIP-39 HD Seed proofs. Protecting these outputs from theft by freezing them is probably the least confiscatory since it prevents theft.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ba994ea8-b089-4f0d-a7a3-e5845d2890ean%40googlegroups.com.

[Boris Nagaev]

On Sunday, July 13, 2025 at 1:09:01 PM UTC-3 Ethan Heilman wrote:

>  Is the approach taken by Bitcoiners fundamentally different?

I do not yet have an opinion here on burn vs. not-burning but I wanted to present a thought experiment about why freezing is not the same as confiscation:

Let's say instead of freezing vulnerable outputs we simply limited them to only be spent to vulnerable outputs, e.g., a txn with a P2PK input can only produce P2PK outputs, etc... Nothing has been confiscated. After this change, if you want to live in the quantum vulnerable world you can, you are just prevented from harming the rest of Bitcoin.

That's a very interesting thought experiment. Thank you!

However, I disagree that this restriction is fundamentally different from freezing. Imagine a fiat bank saying you can only send money to other clients of the same bank. That would clearly be seen as a restriction on property rights. Similarly, limiting how Bitcoin users can spend their coins undermines the idea of ownership itself. A sovereign owner must be able to send funds to anyone. If quantum-vulnerable coins become non-fungible, that's already a partial confiscation -- a loss of some of the owner's rights.

 

In practice, what miner would accept quantum vulnerable fees? What exchange would accept coins which could be stolen at any time? Would you accept coins as payment that could be stolen back later? Such a change would create two classes of Bitcoin outputs: worthless quantum vulnerable coins and actually valuable quantum resistant coins.

 

It depends on whether miners can convert vulnerable fees into safe outputs. If they can, I believe many would accept them. Today, miners already accept stolen funds as fees -- they are economically motivated and generally indifferent to origin. One could even imagine a business that specializes in converting vulnerable coins into secure ones for a fee. If there is profit to be made, actors will find a way to take a cut.

That is, quantum vulnerable outputs, in the presence of a quantum computer, have already had their value destroyed. They no longer function as property, but instead function as an inflationary reward for owning a quantum computer. Freezing them simply reflects this reality and protects quantum resistant coins from the inflation caused by quantum attacks.

The key issue is that we don't know whether the quantum threat will materialize. It's an open question. Jameson's proposal requires taking action before such a threat actually exists. But without knowing if or when it will happen, it's hard to justify such a significant change.

There is a clear conflict of interest here: between those who can move their coins and those who cannot do it before the deadline. The proposal benefits the first group, but at the expense of the second. Imagine someone serving a 10 years sentence in prison or an inheritance with 20 years timelock. If the quantum threat never materializes, they will have lost Bitcoin for nothing. That is not a win for everyone -- it's redistribution.

There is no question that anyone is free to run a node that enforces these rules. But the more important question is: should they? If we normalize selective invalidation of funds, even with good intentions, we risk undermining the very foundation of Bitcoin. Once that door is open, it becomes easier to justify future confiscations for other "good" reasons.

 

As Jameson has pointed out elsewhere some of these outputs may be able to prove ownership via BIP-39 HD Seed proofs. Protecting these outputs from theft by freezing them is probably the least confiscatory since it prevents theft.

There have been non-confiscatory approaches proposed, for example this one: https://groups.google.com/g/bitcoindev/c/LpWOcXMcvk8
Some variants of this approach would even allow Satoshi to recover his plain pubkey funds in the event of a quantum emergency -- without having to reveal himself beforehand.

I understand that it's inconvenient that recovering vulnerable funds requires access to non-vulnerable funds. But when choosing between two evils, what is better for a person who cannot move their coins before the deadline? A person who can move their coins is almost indifferent -- the main difference is that abandoned funds with known pubkeys might eventually be taken. But some of the funds belonging to those who can't move yet may still be recovered by their rightful owners.

We are looking at a clear conflict of interest: on one side, the ability of legitimate but temporarily inactive holders to recover their coins; on the other, the desire of active holders to reduce the monetary base below 21 million in order to extract value from frozen coins.

[Pieter Wuille]

On Sunday, July 13th, 2025 at 2:01 PM, Boris Nagaev <bna...@gmail.com> wrote:

> On Sunday, July 13, 2025 at 1:09:01 PM UTC-3 Ethan Heilman wrote:
>
>
> > That is, quantum vulnerable outputs, in the presence of a quantum computer, have already had their value destroyed. They no longer function as property, but instead function as an inflationary reward for owning a quantum computer. Freezing them simply reflects this reality and protects quantum resistant coins from the inflation caused by quantum attacks.
>
>
> The key issue is that we don't know whether the quantum threat will materialize. It's an open question. Jameson's proposal requires taking action before such a threat actually exists. But without knowing if or when it will happen, it's hard to justify such a significant change.

I want to make a perhaps controversial nuance here.


I believe the the main quantum-related threat to bitcoin, at least in the medium term, is not the actual materialization of a cryptographically-relevant quantum computer (CRQC), but **the belief** whether one may exist soon after. I don't mean to imply that such a machine won't ever appear, but I believe the fear that one may exist will likely have a more meaningful impact, and come much earlier.

Furthermore, I don't think the availability of quantum-safe output types will be sufficient to mitigate this fear-threat, because I don't see how the mere existence of quantum-safe outputs will be sufficient to incentivize the vast majority of coin holders to move their coins. Some may not believe a CRQC will ever exist. Some may have use cases that are incompatible with them (e.g. nothing BIP32-like for them, no key aggregation/thresholds, or they're too large for certain use cases). Some may simply not bother to implement whatever is required, because they're busy building altcoin infrastructure[1] that's more profitable (there are still major ecosystem players that cannot even *send* to taproot outputs...). And all of that is ignoring coins which have simply been lost, which will definitely not move.

All of that together means that the mere existence of quantum-safe outputs will not be sufficient to largely remove the presence of CRQC-vulnerable coins from the system. And without that, the fear of the existence of a CRQC may remain an existential threat due to the sell pressure it may cause. Even those who have moved their coins to quantum-safe outputs may worry about an exchange-rate crash caused by a QRQC operator selling stolen coins, which may fuel even more sell pressure.

It's quite possible I'm wrong here, about sentiment, or about what happens in what order. But I think it's worth considering. And if so, then I think the conclusion is that the actual mitigation to (the fear of) a quantum threat is (the prospect of) freezing CRQC-vulnerable coins. Everything else, up to and including investigating, proposing, activating, and advocating for usage, of quantum-safe outputs, is just be preparatory. Those would be necessary first steps of course, but absent a subsequent prospect of actually disabling quantum-vulnerable outputs, they may be irrelevant in the grand scheme of things.

To be clear, I am not advocating for any specific cause of action here. Not on BIPs, timelines, approach, or even whether something should be done at all. However, I do consider it naive to say that simply making post-quantum output types available is a solution.

[1] https://rusty.ozlabs.org/2020/05/27/bitcoin-exchanges-are-now-the-enemy.html

Cheers,

--
Pieter

[Jameson Lopp]

On Sun, Jul 13, 2025 at 11:22 AM Boris Nagaev <bna...@gmail.com> wrote:

> I attempted to make it clear in my original post that the incentives of individual holders, miners, businesses, etc appear to align and give them logical reasons to desire NOT operating on a network that allows for massive redistribution of wealth via theft and effective inflation of the circulating money supply via resurrection of lost coins. If a wide swath of diverse individuals happens to agree upon something, they may choose to take action as a "collective" of sorts, but I don't find that to be the same as "collectivism" in which a small group tells a large group "this is what's good for you, so you'd better do it."

The Migration Proposal outlines incentives for different actors. Your reasoning seems valid for miners, exchanges, and institutions, but does it truly apply to everyday users? You mention "self-sovereign peace of mind." I would respectfully disagree here. To maintain self-sovereignty, it is sufficient for an individual to move their own funds to a PQ address.

As Pieter mentioned, your quantum sovereignty won't be worth much if the whole ecosystem is rekt. 

A fork that involves confiscating funds, even if well-intentioned, would set a dangerous precedent, one that reduces everyone's self-sovereignty. From that point on, it would be seen as acceptable to seize funds in the name of system-wide safety.

Consider a related example: the freezing of stolen funds on blockchain level (e.g., AML enforcement via smart contracts). This practice exists in many crypto projects, though never in Bitcoin. One could argue that holders of such tokens have voluntarily given up part of their self-sovereignty for collective protection. The very act of using those tokens may imply acceptance of that trade-off.

Is the approach taken by Bitcoiners fundamentally different?

Of course I consider my proposal fundamentally different because the intention is to give everyone multiple years with concrete timelines to incentivize them to take action. Confiscation by centralized authorities and theft by bad actors don't tend to give you a heads up that you should secure your funds, they just swipe them without warning. 

 

To me, the possibility of confiscating funds from legitimate owners crosses a critical line. A system that permits such actions doesn't prevent theft -- it institutionalizes it. Mass confiscation is organized theft.

Alternatively, mass prevention of quantum theft is organized security. Once again, it cuts both ways. In this particular scenario I think the argument that "you can't do ____ because it's theft" is moot because the real question is "what flavor do you want your theft?"

By freezing vulnerable funds you certainly risk locking some people out. But it doesn't have to be permanent; there are clearly a multitude of potential quantum safe recovery schemes that can be designed. Hopefully we'll be seeing more research in that area and discussion to compare the trade-offs of different proposals. My main drive behind exploring this scenario is that doing nothing seems insanely naive and it's preferable to be prepared given how slowly Bitcoin consensus evolves.

In general I think it would be optimal to incentivize the entire ecosystem to migrate so that we don't also have to come to consensus on a quantum safe recovery scheme, but it's difficult to say at this point in time whether or not such a recovery scheme will be a necessary precondition in order to gain consensus on preventing funds from being spent in a manner vulnerable to quantum attackers.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ba994ea8-b089-4f0d-a7a3-e5845d2890ean%40googlegroups.com.

[conduition]

Thanks for pointing this out Or. For those not familiar with Or's approach, it would share many of the same properties as the folklore BIP39 zk-STARK approach discussed elsewhere. It uses Picnic in the same way, to prove (in zero-knowledge) either:

• (For UTXOs whose pubkeys are exposed) I know a BIP39 seed that derives an EC secret key such that hash160(pubkey(ec_secret)) == <hash>
• (For UTXOs whose pubkeys are still secret) I know a public key such that hash160(pubkey) == <hash>​
  

From Or's paper, section 2.5:

Spending Hashed UTXOs: To spend a hashed UTXO, the user signs it with a key-lifted signature (see Section 2.2).

Spending Derived UTXOs: To spend a derived UTXO, the user signs it with a seed-lifted signature (see Section 2.3).

I see a couple problems with this. We won't be able to straight-up replace the EC signature with a Picnic signature without a hard fork. Old Bitcoin clients will still need to see a valid EC signature and verify hash160(pubkey) == <hash>​ by classical re-computation. This exposes the EC pubkey, which would let a QC attacker forge new key-lifted signatures. Thus, sadly, we can't rely on key-lifted signatures.

That said, we don't always require a hard fork as you note in the paper. It's totally fine to expose the EC signature and pubkey if we also have a way to prove honest derivation of the EC secret key from a seed, and as long as that proof commits to the same transaction. Either seed-lifted Picnic signatures or ZK-STARKs could satisfy this. To get soft-fork backwards-compatibility, we'd introduce a new transaction data field to carry the proof, much like segwit added the witness data field. Then we require new clients to reject any EC signatures unless accompanied by this "proof-of-seed-derivation". Old clients still see valid EC spend TXs. Soft fork achieved.

As for the "Lifted FawkesCoin" commit/reveal protocol, it has some issues. I think it'd require a hard fork to implement as there are some properties of the protocol which we can't enforce without relaxing consensus rules. For example, letting miners claim UTXOs using the post-quantum proofs of ownership:

After the commitment has been posted, the spender has a limited time to post a reveal of the commitment to the blockchain. If they fail to do so, the miner can post the proof of ownershipto claim the entire UTXO, making spam attempts costly 

This is impossible without relaxing consensus rules on existing UTXOs' script pubkeys. Donating half of a TX's mining fees to an unrelated miner would also need a hard fork:

The fee paid for including tx is split equally between the miner who included tx and the miner who included (H(tx))

(though this might be fixable if you modify the protocol to instead require direct payment to the address of the miner who mined the H(tx) commitment.)

The other problem is incentives. Why would miners ever mine a Lifted FawkesCoin reveal​ TX if they could simply wait and claim the pre-quantum UTXO themselves using the proof of ownership? The protocol seems to rely on miners ignoring this opportunity, or at least that the major mining pools won't collude to exploit it. The "Restrictive FawkesCoin" protocol would seem to fix this problem though.

Finally, the consensus implementation complexity for any Fawkescoin implementation would be enormous. There are so many context-specific validation steps. The modifications described in section 3.3 and section 4 only further exacerbate this. Sections 3 thru 5 describe all the various Fawkescoin protocols and modifications, and in total they are 16 pages long. I don't expect anyone could push that much protocol complexity into consensus in the next decade.

We're having a hard enough time coming to consensus on the "to freeze or not to freeze" debate, the OP_CTV debate, the OP_CAT debate, etc. I don't see a future where Bitcoin users can even comprehend all the rules and parameters included in the final FawkesCoin-driven protocol, let alone a world where we can all agree on them. We need something simpler, more closely aligned with existing consensus rules, that can be implemented and slotted into existing BIPs and UX neatly.

Personally I think the answer is to require a proof-of-seed-knowledge to spend any EC-signature-locked UTXO, and to implement it as a soft fork. It'd be expensive, and throughput would be low, but it'd also be far better than the bikeshed hell which we'd doubtless find ourselves in if we try to push the hulking mass of Fawkescoin into consensus. There'd be no complex timelock conditions, no commit/reveal protocols; just one new encumbrance added to old EC script pubkeys. Existing wallets can be upgraded without any time-sensitive migration procedures.

So then we're left with this question: What primitive should we use to prove seed knowledge: Seed-lifted Picnic signatures or zk-STARKs? 

Cards on the table: I'm not very familiar with Picnic, but I am with zk-STARKs. I know zk-STARKs would be very useful to have on-hand as a primitive available to consensus, especially in a post-quantum world. They work for any general computation, with arbitrary private and public inputs. They are quick to verify but take a lot of work to produce. They are usually large, measured in tens of kilobytes, but that's similar to Picnic. 

Maybe it'd be worthwhile for someone to do some quantitative benchmarking and qualitative compare/contrast research between zk-STARKs and Picnic signatures (and maybe other alternatives too?), specifically for the case of BIP39 seed derivation proofs. I'm especially curious if an optimized zk-STARK circuit for BIP39/BIP32 derivation can be designed to reduce proving runtime and proof size. I'd also love to know if Picnic signatures could be reused for other things like rollups, IBD speedup, etc, as I know zk-STARKs could be used for.

In any case, while I don't think commit/reveal protocols like Lifted FawkesCoin or its variants are appropriate for a bitcoin consensus upgrade, I do really appreciate all the research that went into your paper Or. It is a perfect resource for anyone interested in PQ commit/reveal protocols and contains many nuggets of wisdom in that realm.

regards,

conduition

--

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/f17de19d-a6f5-46b3-abcd-09c056d9bd64n%40googlegroups.com.

[Or Sattath]

Dear conduition,

On Tuesday, July 15, 2025 at 4:57:23 PM UTC+3 conduition wrote:

Thanks for pointing this out Or. For those not familiar with Or's approach, it would share many of the same properties as the folklore BIP39 zk-STARK approach discussed elsewhere. It uses Picnic in the same way, to prove (in zero-knowledge) either:

• (For UTXOs whose pubkeys are exposed) I know a BIP39 seed that derives an EC secret key such that hash160(pubkey(ec_secret)) == <hash>
• (For UTXOs whose pubkeys are still secret) I know a public key such that hash160(pubkey) == <hash>​
  

From Or's paper, section 2.5:

Spending Hashed UTXOs: To spend a hashed UTXO, the user signs it with a key-lifted signature (see Section 2.2).

Spending Derived UTXOs: To spend a derived UTXO, the user signs it with a seed-lifted signature (see Section 2.3).

I see a couple problems with this. We won't be able to straight-up replace the EC signature with a Picnic signature without a hard fork. Old Bitcoin clients will still need to see a valid EC signature and verify hash160(pubkey) == <hash>​ by classical re-computation. This exposes the EC pubkey, which would let a QC attacker forge new key-lifted signatures. Thus, sadly, we can't rely on key-lifted signatures.

That said, we don't always require a hard fork as you note in the paper. It's totally fine to expose the EC signature and pubkey if we also have a way to prove honest derivation of the EC secret key from a seed, and as long as that proof commits to the same transaction. Either seed-lifted Picnic signatures or ZK-STARKs could satisfy this. To get soft-fork backwards-compatibility, we'd introduce a new transaction data field to carry the proof, much like segwit added the witness data field. Then we require new clients to reject any EC signatures unless accompanied by this "proof-of-seed-derivation". Old clients still see valid EC spend TXs. Soft fork achieved.

As for the "Lifted FawkesCoin" commit/reveal protocol, it has some issues. I think it'd require a hard fork to implement as there are some properties of the protocol which we can't enforce without relaxing consensus rules. For example, letting miners claim UTXOs using the post-quantum proofs of ownership:

After the commitment has been posted, the spender has a limited time to post a reveal of the commitment to the blockchain. If they fail to do so, the miner can post the proof of ownershipto claim the entire UTXO, making spam attempts costly 

This is impossible without relaxing consensus rules on existing UTXOs' script pubkeys. Donating half of a TX's mining fees to an unrelated miner would also need a hard fork:

The fee paid for including tx is split equally between the miner who included tx and the miner who included (H(tx))

 

(though this might be fixable if you modify the protocol to instead require direct payment to the address of the miner who mined the H(tx) commitment.)

The table on p. 11 here (which is key to understanding the different trade-offs of the different methods) indicates which methods work as a soft-fork out of the box:

You’re right that Lifted Spending (Section 2.2 & 2.3) and Lifted Fawkes-Coin use a hard fork. I suspect that some of the other methods could potentially be implemented as a soft fork, using various tricks—along the lines of the ideas you’re suggesting. Our rationale was to avoid overcomplicating the paper in order to make it soft-fork-compatible.

 

The other problem is incentives. Why would miners ever mine a Lifted FawkesCoin reveal​ TX if they could simply wait and claim the pre-quantum UTXO themselves using the proof of ownership? The protocol seems to rely on miners ignoring this opportunity, or at least that the major mining pools won't collude to exploit it.

I’m not sure I fully understand your point. Are you asking what happens if the “reveal” part of a Lifted FawkesCoin is censored by all the miners?
Indeed, if all miners collude and decide to censor the "reveal" part of the transaction, they will be able to claim the pre-quantum OTXO themselves. But even today, if all (or a majority of) miners collude, double-spends are already possible.
Recall that there's a period of 100 blocks (see p. 20, especially step 7) for miners to include the "reveal". It is sufficient for just one honest miner to include the “reveal” transaction for the issue to be resolved.

 

The "Restrictive FawkesCoin" protocol would seem to fix this problem though.

 

Finally, the consensus implementation complexity for any Fawkescoin implementation would be enormous. There are so many context-specific validation steps. The modifications described in section 3.3 and section 4 only further exacerbate this. Sections 3 thru 5 describe all the various Fawkescoin protocols and modifications, and in total they are 16 pages long. I don't expect anyone could push that much protocol complexity into consensus in the next decade.

We're having a hard enough time coming to consensus on the "to freeze or not to freeze" debate, the OP_CTV debate, the OP_CAT debate, etc. I don't see a future where Bitcoin users can even comprehend all the rules and parameters included in the final FawkesCoin-driven protocol, let alone a world where we can all agree on them. We need something simpler, more closely aligned with existing consensus rules, that can be implemented and slotted into existing BIPs and UX neatly.

Personally I think the answer is to require a proof-of-seed-knowledge to spend any EC-signature-locked UTXO, and to implement it as a soft fork. It'd be expensive, and throughput would be low, but it'd also be far better than the bikeshed hell which we'd doubtless find ourselves in if we try to push the hulking mass of Fawkescoin into consensus. There'd be no complex timelock conditions, no commit/reveal protocols; just one new encumbrance added to old EC script pubkeys. Existing wallets can be upgraded without any time-sensitive migration procedures.

I agree that the protocols are complicated. We laid out the possible choices, with a special focus on tradeoffs, and I hope that at least one of them (and certainly not all) would get implemented. I think that unrestrictive Fawkes Coin is a fairly simple protocol, which doesn't require any cryptography either the type already used in Bitcoin (hashing for commit/reveal, and existing digital signatures, and the post-quantum digital signature which hopefully be decided upon in BIP-360). The only downside being that users need a post-quantum wallet to pay the fee from. The main advantage of Lifed Fawkes Coin is that the need to pay the fee from a post-quantum transaction is removed (at the cost of a more sophisticated protocol). 

 

So then we're left with this question: What primitive should we use to prove seed knowledge: Seed-lifted Picnic signatures or zk-STARKs? 

Cards on the table: I'm not very familiar with Picnic, but I am with zk-STARKs. I know zk-STARKs would be very useful to have on-hand as a primitive available to consensus, especially in a post-quantum world. They work for any general computation, with arbitrary private and public inputs. They are quick to verify but take a lot of work to produce. They are usually large, measured in tens of kilobytes, but that's similar to Picnic. 

Maybe it'd be worthwhile for someone to do some quantitative benchmarking and qualitative compare/contrast research between zk-STARKs and Picnic signatures (and maybe other alternatives too?), specifically for the case of BIP39 seed derivation proofs. I'm especially curious if an optimized zk-STARK circuit for BIP39/BIP32 derivation can be designed to reduce proving runtime and proof size. I'd also love to know if Picnic signatures could be reused for other things like rollups, IBD speedup, etc, as I know zk-STARKs could be used for.

In any case, while I don't think commit/reveal protocols like Lifted FawkesCoin or its variants are appropriate for a bitcoin consensus upgrade, I do really appreciate all the research that went into your paper Or. It is a perfect resource for anyone interested in PQ commit/reveal protocols and contains many nuggets of wisdom in that realm.

Thanks again for the kind words!
I don't share the same sentiment regarding the conclusion:
First, our FawkesCoin approach doesn't require new primitives (Picnic / zk-STARKs), so it can be implemented relatively easily. More importantly, it can accommodate many more transactions per block: AFAIK, a zk-STARK and similarly Picnic are roughly 2-3 orders of magnitude larger than an ECDSA signature (~100 Bytes vs.~10-100KB). A transaction fee costs an order of a dollar these days, so PICNIC/zk-STARK based approaches would cost hundreds of dollars, and would allow only a small number of people to recover their funds. The only downside of FawkesCoin is that spending is done in two separate steps (commit-wait 100 blocks-reveal), which is more cumbersome and takes longer. See my comment above regarding the advantages of Lifted FawkesCoin: FawkesCoin and Lifted FawkesCoin approaches can be used together.

Best,

Or

[conduition]

Hi Or,

Are you asking what happens if the “reveal” part of a Lifted FawkesCoin is censored by all the miners?

Indeed, if all miners collude and decide to censor the "reveal" part of the transaction, they will be able to claim the pre-quantum OTXO themselves. But even today, if all (or a majority of) miners collude, double-spends are already possible.

Yes, that's my question. There is a big difference between this and a double-spend attack.

A double-spend attack involves exercising enormous hashpower in a 51% attack to orphan an existing block and "undo" a transaction which the network previously saw as valid. Any gains from the double-spend attack would be offset by the cost of electricity wasted by mining the new block, and by the fees/block-reward lost in the orphaned block. And even then, the attacking miners have gained no new bitcoin - They probably only gained something off-chain, of equivalent value to the coins they double-spent. For instance, they may have deposited into an exchange and converted their double-spent coins into some other currency.

By contrast, censoring a lifted fawkescoin reveal TX requires no hashpower. It only requires collusion between miners to agree not to mine specific transactions. If they do this, they can swipe the vulnerable users' bitcoins with no real-world energy expenditure or on-chain losses. 

Unless i'm mistaken there, I'd say this property makes Lifted FawkesCoin a non-starter.

Restrictive FawkesCoin could be a viable option. It's about the same as any other commit/reveal protocol except that you've thought out how to rescue funds with exposed pubkeys, by providing a BIP32 parent xpriv in the reveal TX. This is great but does implicitly require that the coins must be restricted such that the QC attacker can't use a regular EC signature to steal them first. That requirement would be needed for any protocol that rescues UTXOs with exposed pubkeys of course. You're right that this would be simpler to implement than zk-STARKs, so maybe I spoke too soon.

regards,

conduition

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6326b5d0-df6b-4f40-9d15-9ed502278397n%40googlegroups.com.

[Boris Nagaev]

Hi Conduition,

Let's consider this scheme:

The commit_tx includes:

1. UTXO  
2. TXID  
3. MAC(TXID, key=pubkey)

The reveal transaction is just a normal Bitcoin transaction.

Validators would need to maintain a list of commitments per UTXO and only accept a reveal transaction that is the earliest one with a valid MAC. A validator of the reveal transaction sees the pubkey and can verify the MAC. A validator filters the list of commitments, keeping only the valid ones, and then selects the earliest among them. The reveal transaction must match the TXID from the winning commitment.

If someone tries to steal the coin, they would need to publish another commit transaction for the same UTXO. But without knowing the pubkey, how can they produce a valid MAC? They can't. All they can do is spam invalid commit transactions, which would have no effect. Even if malicious miners wait until a legitimate reveal transaction is published and then create a valid commit transaction, it would not be the earliest valid one. The earliest valid commit would still be the original one.

The downside is that this scheme requires storing all commitments (valid or not) until the coin is spent. Maybe the list can be compressed or pruned. Another limitation is that the reveal transaction must be fully constructed at the time of the commit, since its TXID is part of the commitment. This means the sender cannot adjust the reveal transaction later, not even to change the fee or use RBF. That said, maybe the requirement to know the TXID upfront could be relaxed with a different construction.

Best,
Boris

[conduition]

Hi Boris,

That sound workable, it's similar to other commit/reveal protocols. I have no problem with these, they're perfectly valid ways to encumber coins. The only issue I see with your suggested protocol is that it's only secure when pubkeys are still hidden. A quantum attacker could still commit, reveal, and steal coins from addresses whose pubkeys are already exposed.

As Or and Shai's paper has shown, we can fix that by modifying the scheme to include a BIP32 parent xpriv in the commit TX, rather than a bare pubkey. For the sake of simplicity, this should probably be the only commitment method available. If we also allowed bare pubkey commitments, validating nodes would have to keep track of whether or not an address's pubkey has been exposed in the past, and determine what types of commit/reveal spends to allow. Using just one method keeps things simpler.

So the protocol becomes:

The commit_tx includes:

1.  UTXO

2.  TXID

3.  MAC(TXID, key=bip32_xpriv_and_keypaths)

The reveal transaction must attach the bip32_xpriv_and_keypaths so validators can check the MAC.

Because this exposes the wallet's BIP32 parent key, we have to consider how to handle multi-input transactions, which would migrate the wallet's entire set of quantum-vulnerable UTXOs at once. Do i need to make a separate commit TX or OP_RETURN output for each UTXO i spend, each committing to the same TXID? Can i aggregate them together into one commitment somehow with a merkle tree?

These are all addressable problems, of course. I just haven't seen them all addressed in one place yet. The solutions are scattered through the mailing list and through papers like Or's. A comprehensive solution needs to have all these edgecases accounted for in a single concise protocol.

regards,

conduition

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c56b179f-2753-4f1c-80a4-14969e737d37n%40googlegroups.com.

[Nagaev Boris]

Hi Conduition,

Thanks for pushing it forward! Interestingly, we don't really need EC crypto to organize a payment scheme. We only need a symmetric equivalent of a digital signature (i.e. MAC) and a secure hash function. This is very exciting! The scheme can function as a backup plan in case we don't find a way to scale regular post-quantum signatures. Imagine the future in which we use expensive SPHINCS+ signatures for time-sensitive stuff and a cheap commit-reveal scheme for slow transactions. We can have a single type of address which supports both types of spending: (1) expensive and fast, (2) cheap and slow.

Switching back to coin recovery, there are a few challenges. I have thoughts on how to solve some of them.

1. We need to ensure that the scheme accepts only a single xpriv+path value. If there are multiple combinations possible (i.e. starting from different levels of derivation), then a validator wouldn't be able to determine if a commit is valid afterwards. Another commit may be valid, but made with a different xpriv+path input, so MAC won't verify. I think we can ensure that xpriv+path is unique by demanding that the path starts with a hardened step (i.e. hashing) and has no other hardened steps.

2. Coins whose private key is not a child of BIP32. One important instance is MuSig2 coins. In MuSig2 several private keys are generated by different parties, probably from different BIP32 parents, but I know of at least one case where completely different approach was chosen for derivation of a partial key. So there is no single BIP32 parent of MuSig2 addresses. Another obstacle is MAC generation if parties don't trust each other and don't want to share xprivs with each other. Maybe the scheme can be changed to pass xpriv through a tagged hash function prior to using it as a key in MAC to address this.

Maybe taproot addresses should have a special approach, because they have a key path spend which is unique among all address types.

3. Some xpubs may have too many coins to sweep in a single transaction. Since the BIP32 scheme exposes private xpriv in a reveal transaction, to sweep all the coins the owner has to first send all commit transactions that would cover all future sweep (reveal) transactions. If this is done one by one (commit1-reveal1-commit2-reveal2), then the remaining funds can be stolen by anyone, since the xpriv of the whole group is exposed.

4. Note that the BIP32 scheme requires attaching additional data (xprivs + derivation paths) to a reveal transaction. This is an additional burden compared with the pubkey scheme. We need to find a place to put the additional data along with the reveal transaction without modifying the TXID. That is why we can't put it into OP_RETURN. We can't put it into Witness, since it would break the signature - we can't do it, if we want it to be a softfork. We can make another Merkle tree similar to Segwit and put it there.

It seems that BIP32 and pubkey-based schemes have different trade-offs. Both of them can be provided but the pubkey-based scheme will be blocked for coins whose pubkeys were exposed in the past. All such coins can be found once, at the fork time, and future pubkey exposures can be ignored. It would involve reprocessing of all blocks, but this is a solvable technical issue, e.g. we can give nodes time to precalculate this data before validation rules change. The logic is that if someone exposed their pubkey in the post-quantum era it's their own fault and it is the same as if they exposed their private key now. So it is justifiable if a quantum attacker captures such coins - it is not the business of the network to secure funds in this case.

Best,

Boris

--

Best regards,
Boris Nagaev

[conduition]

Hey Boris,

I've been doing more research into ZK-STARK solutions, and the more i read, the more I am warming to the idea of BIP32 commit/reveal as a recovery mechanism. The smallest concrete zk-STARK proofs I could find were hundreds of kilobytes for even something as simple as a SHA512 hash preimage. BIP32 proofs would need that, plus secp256k1 arithmetic.

We only need a symmetric equivalent of a digital signature (i.e. MAC) and a secure hash function. This is very exciting! The scheme can function as a backup plan in case we don't find a way to scale regular post-quantum signatures. Imagine the future in which we use expensive SPHINCS+ signatures for time-sensitive stuff and a cheap commit-reveal scheme for slow transactions.

Don't get too excited - Commit/reveal protocols on bitcoin presuppose the availability of a post-quantum signature scheme. Otherwise, how do you publish the commitment TX securely? The commitment phase itself is a published BTC transaction, and if that TX is secured via EC signatures, then its inputs could be swiped by a fast CRQC.

We need to ensure that the scheme accepts only a single xpriv+path value. If there are multiple combinations possible (i.e. starting from different levels of derivation), then a validator wouldn't be able to determine if a commit is valid afterwards.

I'm not sure I understand the problem... Wouldn't this just mean that there can be more than one valid commitment for the same UTXO? That's always going to be possible because the owner could commit to more than one reveal transaction. We can't verify commitments for reveal TXs which are never published. Which is fine - validators just care whether the sender knew a valid parent xpriv before​ the reveal TX was published.

Now that I think about it, we safely can omit the bip32 key paths from the HMAC commitment. They serve no purpose there. 

Coins whose private key is not a child of BIP32. One important instance is MuSig2 coins.

Also FROST keys, ECDSA threshold MPC keys, paper wallets, and many others. I'm really not sure how we'd handle these. The lazy dev inside me wants to ignore them and focus on BIP32 wallets as that probably will make up the bulk volume of coins affected by an EC freeze.

MuSig is an interesting special case, because the aggregation of the group key is actually a quantum resistant one-way function. More concretely, given the musig group key X = H(L, A)*A + H(L, B)*B​ then a QC cannot practically compute a valid key set L = [A, B]. So you could make a commit/reveal scheme for MuSig keys by committing to (and then revealing) the key set L​. Nodes verify the group key X​ was computed correctly from L​. We'd have to assume that key set L​ is not available to a quantum attacker. No secret key sharing is needed for this.

FROST is not so fortunate. A FROST key is just the constant term of a polynomial. Any quantum attacker could invert a public key, and then forge an arbitrary polynomial with that key as its constant term.

I wouldn't worry too much about untrusting multisig groups though - such wallets are usually actively managed, so the parties involved would likely be active enough to migrate their coins to post-quantum addresses before any EC-restricting soft forks occur. Then again, this is just an opinion, no hard data to work with here.

Ancient paper wallet holders on the other hand are much more at risk, since these keys were often generated without BIP39 or BIP32. This might be one reason why allowing commit/reveal with bare pubkeys could be beneficial, but IDK if it outweighs the complexity costs.

Some xpubs may have too many coins to sweep in a single transaction.

This should be a pretty rare edgecase - but even in those cases, as you say, we can work around it by splitting up the reveal TX into multiple transactions and committing to each of them. Then wait a few blocks, and publish all reveal TXs at once.

Note that the BIP32 scheme requires attaching additional data (xprivs + derivation paths) to a reveal transaction. ... We can make another Merkle tree similar to Segwit and put it there.

Same would be true of any PICNIC or zk-STARK based solution. It's unavoidable if we want an EC recovery soft fork.

Both of them can be provided but the pubkey-based scheme will be blocked for coins whose pubkeys were exposed in the past. All such coins can be found once, at the fork time, and future pubkey exposures can be ignored.

This scan would miss a lot of exposed pubkeys - xpubs and other public keys shared off-chain for high-value wallets would become highly valuable commodities that could be sold to quantum attackers. But i guess it is doable. I'm not sure if its benefits outweigh its drawbacks. Basically it's a pick-your-poison choice between (1) allowing QCs to steal from pubkeys exposed off-chain, or (2) destroying the coins of paper/brain wallet hodlers (or anyone else who didn't use BIP32).

regards,

conduition

[Nagaev Boris]

Hey Conduition,

On Mon, Jul 28, 2025 at 6:38 PM conduition <condu...@proton.me> wrote:

Hey Boris,

I've been doing more research into ZK-STARK solutions, and the more i read, the more I am warming to the idea of BIP32 commit/reveal as a recovery mechanism. The smallest concrete zk-STARK proofs I could find were hundreds of kilobytes for even something as simple as a SHA512 hash preimage. BIP32 proofs would need that, plus secp256k1 arithmetic.

AFAIK, the size of a STARK is a polylog of the evaluation trace. So even if a single SHA512 evaluation costs several hundreds of kilobytes, maybe we can fit many signatures into a single STARK, since logarithm grows very slowly. Maybe even more than we have now. We may have a single STARK per block which validates all the stuff: recovery and PQ signatures. However I'm not an expert in STARKs, just starting to learn them. But I hope STARKs are a real thing!

 

We only need a symmetric equivalent of a digital signature (i.e. MAC) and a secure hash function. This is very exciting! The scheme can function as a backup plan in case we don't find a way to scale regular post-quantum signatures. Imagine the future in which we use expensive SPHINCS+ signatures for time-sensitive stuff and a cheap commit-reveal scheme for slow transactions.

Don't get too excited - Commit/reveal protocols on bitcoin presuppose the availability of a post-quantum signature scheme. Otherwise, how do you publish the commitment TX securely? The commitment phase itself is a published BTC transaction, and if that TX is secured via EC signatures, then its inputs could be swiped by a fast CRQC.

I understand :)

But I'm happy that at least we have secured one safe and affordable way to use Bitcoin in the post-quantum era: using the commit-reveal scheme and PQ to send commit transactions. Commits can be batched in a single transaction. Everyone having PQ funds could run a small business publishing commits for other people for a fee. Not an ideal world, but it is functional and scales without a block size increase. Having a way to compress PQ signatures (e.g. STARK) would be cooler, but the commit-reveal scheme is a strong plan B in case something goes wrong with that approach.

 

We need to ensure that the scheme accepts only a single xpriv+path value. If there are multiple combinations possible (i.e. starting from different levels of derivation), then a validator wouldn't be able to determine if a commit is valid afterwards.

I'm not sure I understand the problem... Wouldn't this just mean that there can be more than one valid commitment for the same UTXO? That's always going to be possible because the owner could commit to more than one reveal transaction. We can't verify commitments for reveal TXs which are never published. Which is fine - validators just care whether the sender knew a valid parent xpriv before the reveal TX was published.

We can't let multiple commits per UTXO be valid. Remember the original problem you posted a couple of messages ago: miners can collude and delay reveal transaction confirmation, so we need to make sure that the commitment of this reveal tx is the first valid commitment for this UTXO. How can a validator verify other commitments posted for the UTXO? They need to know the key used for MAC to check it. If the MAC key is not fixed per UTXO, this doesn't work: we can't check whether other commitments are valid, so we can't guarantee that the commitments of this reveal tx comes from the owner, not from a collusion of malicious miners who delayed the legitimate reveal transaction and made another commit tx using the private data from legitimate reveal tx.

 

Now that I think about it, we safely can omit the bip32 key paths from the HMAC commitment. They serve no purpose there. 

Yes, we can use the latest input of SHA512 during BIP32 key derivation as a MAC key. The reveal tx will have both the preimage and the BIP 32 path that should lead to the pubkey.

 

Coins whose private key is not a child of BIP32. One important instance is MuSig2 coins.

Also FROST keys, ECDSA threshold MPC keys, paper wallets, and many others. I'm really not sure how we'd handle these. The lazy dev inside me wants to ignore them and focus on BIP32 wallets as that probably will make up the bulk volume of coins affected by an EC freeze.

MuSig is an interesting special case, because the aggregation of the group key is actually a quantum resistant one-way function. More concretely, given the musig group key X = H(L, A)*A + H(L, B)*B then a QC cannot practically compute a valid key set L = [A, B]. So you could make a commit/reveal scheme for MuSig keys by committing to (and then revealing) the key set L. Nodes verify the group key X was computed correctly from L. We'd have to assume that key set L is not available to a quantum attacker. No secret key sharing is needed for this.

FROST is not so fortunate. A FROST key is just the constant term of a polynomial. Any quantum attacker could invert a public key, and then forge an arbitrary polynomial with that key as its constant term.

I wouldn't worry too much about untrusting multisig groups though - such wallets are usually actively managed, so the parties involved would likely be active enough to migrate their coins to post-quantum addresses before any EC-restricting soft forks occur. Then again, this is just an opinion, no hard data to work with here.

I guess inheritance schemes may use MuSig2 in a tap leaf with a timelock. MuSig2 is used, because it is more efficient; the timelock is just a protection. However if we keep the pubkey commit-reveal scheme for a while (see below), we won't need a separate scheme for MuSig2.

 

Ancient paper wallet holders on the other hand are much more at risk, since these keys were often generated without BIP39 or BIP32. This might be one reason why allowing commit/reveal with bare pubkeys could be beneficial, but IDK if it outweighs the complexity costs.

Some xpubs may have too many coins to sweep in a single transaction.

This should be a pretty rare edgecase - but even in those cases, as you say, we can work around it by splitting up the reveal TX into multiple transactions and committing to each of them. Then wait a few blocks, and publish all reveal TXs at once.

Note that the BIP32 scheme requires attaching additional data (xprivs + derivation paths) to a reveal transaction. ... We can make another Merkle tree similar to Segwit and put it there.

Same would be true of any PICNIC or zk-STARK based solution. It's unavoidable if we want an EC recovery soft fork.

It can be avoided in my original scheme using pubkey as MAC key. In this scheme, the reveal tx is just a regular transaction, no extra data needed. Everything needed to validate the commitment (the pubkey) is in the reveal transaction itself. It makes the scheme compatible with any modern transaction types and saves block space. The only downside is that it is not secure in case the pubkey leaks.

It doesn't have to be in EC recovery soft fork, we can enable it in phase B, since it is very simple and we have plenty of time to implement and test it. Also it doesn't block anyone and therefore it is much more likely to be adopted than the original approach (block first, recover later, maybe). At the same time the public key commit-reveal scheme saves a lot of coins in case of a quantum emergency, so it is definitely much better than doing nothing. If a person advocates to block vulnerable coins because of the price effect, they should support this scheme too, because it reduces dramatically the amount of vulnerable coins. Maybe this is the focal point?

BTW in both schemes we should think abouts UTXOs which have multiple public keys and signatures: traditional multisigs, some smart scripts. All EC signatures used in the script must have a commitment. But how to find which commitment is for which pubkey? Remember we should find all valid commitments and check that this one is the first... Just check all against all? It is O(N^2), where N is the number of EC signatures per witness. I propose to change the format of the commitment OP_RETURN to this:

 - UTXO

 - TXID

 - array of MACs in the order of EC operations in the witness script

 

This is also more space efficient, because UTXO and TXID will be the same, only the MAC part is different.

Both of them can be provided but the pubkey-based scheme will be blocked for coins whose pubkeys were exposed in the past. All such coins can be found once, at the fork time, and future pubkey exposures can be ignored.

This scan would miss a lot of exposed pubkeys - xpubs and other public keys shared off-chain for high-value wallets would become highly valuable commodities that could be sold to quantum attackers. But i guess it is doable. I'm not sure if its benefits outweigh its drawbacks. Basically it's a pick-your-poison choice between (1) allowing QCs to steal from pubkeys exposed off-chain, or (2) destroying the coins of paper/brain wallet hodlers (or anyone else who didn't use BIP32).

Yes, this is a hard choice. Maybe there is a compromise solution: the pubkey scheme can function for old coins for a limited amount of time. We'll hope that quantum attacks won't happen during that period. It will be sufficient for owners of paper wallets to move their funds. Then the pubkey scheme will stay disabled for old coins for 10 years. (Remember my another proposal to replace a permanent block with a long temporary block, this consideration is applicable here as well.) The BIP32 scheme can be used for such coins at any time. New coins should be good to use with the pubkey scheme, since it would be the responsibility of the coin owner not to expose public keys when the quantum threat is high.

Best,

Boris

[conduition]

Hi Boris,

We can't let multiple commits per UTXO be valid. Remember the original problem you posted a couple of messages ago: miners can collude and delay reveal transaction confirmation, so we need to make sure that the commitment of this reveal tx is the first valid commitment for this UTXO

Ah i see what you mean now. Your suggestion of requiring one and only one hardened derivation step is probably the easiest option to fix that. That way, for any set of EC keys, there exists at most one matching parent xpriv. Revealing that xpriv doesn't give observers any valid alternative HMAC keys.

It doesn't have to be in EC recovery soft fork, we can enable it in phase B, since it is very simple and we have plenty of time to implement and test it. Also it doesn't block anyone and therefore it is much more likely to be adopted than the original approach (block first, recover later, maybe)

That won't work - If you deploy phase B (restricting EC outputs) with bare pubkey commit/reveal without also supporting BIP32 commit/reveal for exposed pubkeys, then adding BIP32 commit/reveal later will be a hard fork. You'd be relaxing consensus rules to allow spending of outputs with exposed pubkeys.

- array of MACs in the order of EC operations in the witness script

Makes sense. At first i was going to suggest to merge the pubkeys together into one single MAC, but that'd create opportunity for miner collusion. You would indeed need one commitment hash per EC operation for watertight security.

For single-party BIP32 commit/reveal on the other hand, you'd probably never need more than 1 MAC per commitment, since the xpriv would probably cover every EC operation in the reveal TX (even across multiple UTXOs), and any given pubkey has at most one matching parent xpriv (if hardening is done only once).

To confirm, when validating a commitment that contains multiple MACs, the validator would need to assert that every​ MAC is the earliest valid MAC, right? If even one pubkey was exposed and committed earlier, it'd render the whole reveal TX invalid.

regards,

conduition

[Nagaev Boris]

Hi Conduition,

On Mon, Jul 28, 2025 at 9:24 PM conduition <condu...@proton.me> wrote:

Hi Boris,

We can't let multiple commits per UTXO be valid. Remember the original problem you posted a couple of messages ago: miners can collude and delay reveal transaction confirmation, so we need to make sure that the commitment of this reveal tx is the first valid commitment for this UTXO

Ah i see what you mean now. Your suggestion of requiring one and only one hardened derivation step is probably the easiest option to fix that. That way, for any set of EC keys, there exists at most one matching parent xpriv. Revealing that xpriv doesn't give observers any valid alternative HMAC keys.

It doesn't have to be in EC recovery soft fork, we can enable it in phase B, since it is very simple and we have plenty of time to implement and test it. Also it doesn't block anyone and therefore it is much more likely to be adopted than the original approach (block first, recover later, maybe)

That won't work - If you deploy phase B (restricting EC outputs) with bare pubkey commit/reveal without also supporting BIP32 commit/reveal for exposed pubkeys, then adding BIP32 commit/reveal later will be a hard fork. You'd be relaxing consensus rules to allow spending of outputs with exposed pubkeys.

Both commit-reveal schemes would be deployed simultaneously, but the BIP32 scheme will function forever for all the coins and the pubkey scheme will pause for old coins with exposed pubkeys after let's say 5 years for another 10 years. For new coins both schemes will work forever.

For example (exact years are just for illustration purposes):

2025-2030 current rules work

2030-2035 both commit-reveal schemes work for all coins, but it is impossible to spend from EC addresses without using a commit-reveal scheme anymore. Both schemes are deployed as a softfork, so transactions are still valid from the point of view of old nodes

2035-2045 the pubkey based commit-reveal scheme stops working for existing coins with exposed pubkeys. BIP32 scheme works and the pubkey scheme works for any new coins (created after 2035). This is the first real confiscatory event, since the pubkey scheme would be the only scheme available for some coins in 2035.

2045-inf the pubkey based scheme is revived

The whole timeline is applied (in block heights, not years) as a single fork in 2030. Another fork until 2045 can delay pubkey scheme revival. This is just needed to avoid permanent freeze after which it would be impossible to recover the coins without a hardfork.

 

- array of MACs in the order of EC operations in the witness script

Makes sense. At first i was going to suggest to merge the pubkeys together into one single MAC, but that'd create opportunity for miner collusion. You would indeed need one commitment hash per EC operation for watertight security.

One more caveat. We should include all the keys exposed in signature or witness of UTXO in the reveal transaction. We can't put the used EC keys only. Imagine a 1/2 traditional multisig. Witness has two public keys, but only one signature. We should demand both keys in the commitment, because otherwise a quantum attacker may see the reveal transaction and make a new reveal transaction, using another EC key of the multisig. The attacker would create a new commit transaction with that malicious reveal TXID and "sign" it with another public key (the one not used originally). A validator would accept such a new pair of commit and reveal transactions, since they will also check MAC using the used EC key only, not all the keys. A validator would consider a real commitment invalid and would think that the attacker's commitment is the first valid one. That is why it is important to put all EC pubkeys mentioned in witness (or traditional signature) of the reveal transaction, not just used onces, to prevent such "hijacking".

Actually, I didn't think about merging keys for MAC. Thanks for sharing the idea! Can you elaborate why this is not possible, please? Let's say the UTXO has 3 different keys in 1/3 traditional multisig. Can't we just combine them somehow, e.g. XOR or hash-and-XOR and use the result as a key for MAC? An attacker doesn't control these values and he doesn't control the script (unless multiple reveal transactions with different tapleaves were published, which is not allowed in such schemes). So until the reveal transaction is published the attacker can't forge commits. And once the reveal tx is published it doesn't make sense to forge, because it won't be the first valid commit. I don't see any vulnerability which is created by merging keys for MAC.

 

For single-party BIP32 commit/reveal on the other hand, you'd probably never need more than 1 MAC per commitment, since the xpriv would probably cover every EC operation in the reveal TX (even across multiple UTXOs), and any given pubkey has at most one matching parent xpriv (if hardening is done only once).

Yes. Note that in the BIP32 variant the reveal transaction has to include all derivation paths though, for every pubkey that is mentioned in the script.

 

To confirm, when validating a commitment that contains multiple MACs, the validator would need to assert that every MAC is the earliest valid MAC, right? If even one pubkey was exposed and committed earlier, it'd render the whole reveal TX invalid.

When validating a reveal transaction, a validator first collects all EC pubkeys from the script; not only used keys, but all - see above why. Then the validator loads all the commitments that were posted for that UTXO. Commitments may have this TXID or different TXID; the validator has to load all regardless of TXID. Then the validator goes through all the commitments and checks MACs. If the number of MACs doesn't match the number of EC pubkeys - exclude the commitment. Otherwise go through MACs and pubkeys one by one and check each MAC against the corresponding key. Cleartext for MAC is the TXID from that commitment. If any MAC doesn't verify - exclude the commitment. The remaining commitments passing these checks are valid. Check the first valid commitment. If it has TXID not matching TXID of the reveal transaction - fail the reveal tx validation.

An attacker can't copy MACs because they are bound to TXID of the original commitment and that TXID is legit. So we don't worry if we see one valid MAC in another commitment. To make the whole commitment valid an attacker has to copy-paste the whole commitment, which doesn't change anything - the list of commitments would have two identical valid commitments.

I propose to simplify this by using just one MAC with all the pubkeys as a single key. If you know why this is a bad idea, please share.

[conduition]

Hey Boris,

I propose to simplify this by using just one MAC with all the pubkeys as a single key. If you know why this is a bad idea, please share.

I think I forgot my train of thought here on why this allowed miner attack, probably should've written it down. Maybe i was thinking of merging individual per-key MACs together with a hash... Anyway, your suggestion of HMAC(key=[k1, k2, k3...], msg=txid) seems like a reasonable way of compressing the scheme. If I think of any way to break that I'll let you know. 

But perhaps there is an even better option. What if, rather than publishing a commitment to the EC keys (which is basically a commitment to the locking script), we publish a commitment to the witnesses​ that will be used to spend the UTXO? 

The witness stack always includes at least one EC signature, which is bound to both the transaction and the pubkey by OP_CHECKSIG. We are essentially pre-annoucning: "I will spend this UTXO using this set of signatures".

Then we could get away with a 68 byte commitment made of two hashes and a u32: (utxo, witness_hash)​. We no longer need to publish the TXID in the commitment, because witness_hash​ indirectly commits to it. You'd compute the witness hash by simply concatenating and hashing all the witness data for each input in consensus order.

This is all for unexposed addresses, btw. For UTXOs with exposed pubkeys, you could mix a BIP32 parent xpriv into the witness hash somehow, and would need to publish the xpriv in the reveal TX.

regards,

conduition

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAFC_Vt7a1O9vCdycRtUmTAQyL%3DifZAZt3Wzx-YBTQ1cKyJq55w%40mail.gmail.com.

[conduition]

I remember what i was talking about a few weeks back.

I was envisioning that all the pubkeys would be merged together across all inputs​, but this would break the total ordering on commitments. Given a reveal TX, the validator wouldn't know if the commitment being opened was the earliest​, because a miner could censor a reveal transaction for a block or two and insert a different one with a different set of inputs, resulting in a different HMAC key. 

This is also the reason why my "witness hashing" idea won't work. The witness stack can be changed by a Quantum adversary after the reveal TX is opened, by inverting one of the pubkeys and making a fresh new signature. This changes the HMAC key that would've been used in an authentic commitment, and validators won't be able to check the commitment ordering. So we do still need to HMAC sign the TXID, and we have to do it on a per-input basis.

We can​ merge pubkeys into a single HMAC key as you suggested Boris, as long as we merge only the pubkeys within a single locking script of a specific reveal TX input. This way the HMAC key that we reveal to open any commitment is always the same, regardless of who tries to spend the revealed input. Taproot would be an exception since a P2TR address can have many possible locking scripts with different sets of pubkeys, but a quantum attacker probably won't be able to find them without inverting SHA256.

This means the reveal TX validator can find a clean ordering of past commitments for that reveal, and this thwarts any attacks from miners that rely on censoring the reveal TX.

regards,

conduition

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/YX1Q8oL5phYHC8fM_m4aHakglTjz1RYlv8k7tGgbq9Rx_jx6BFmG6Y8uA7Vrma0fOX3kCTD30k0PCUGeBX_bnglN5GWCZdGABxKDOjvt_bA%3D%40proton.me.