* Re: [bitcoindev] Aligning privacy incentives in P2MR
2026-06-18 5:09 ` Anthony Towns
@ 2026-06-19 0:30 ` 'conduition' via Bitcoin Development Mailing List
2026-06-19 0:38 ` 'conduition' via Bitcoin Development Mailing List
2026-06-24 20:24 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2 siblings, 0 replies; 20+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-06-19 0:30 UTC (permalink / raw)
To: Anthony Towns, Pieter Wuille; +Cc: Antoine Poinsot, bitcoindev@googlegroups.com
[-- Attachment #1.1.1: Type: text/plain, Size: 34247 bytes --]
I really appreciate you all taking the time to have this important discussion together and still keeping things civil. The discussion on this thread has branched out from PQ migration destinations into also discussing confiscatory retroactive upgrades, like rescue protocols. I think, as per Antoine's recent thread, it's a mistake to conflate the two subjects, so this first email is just going to focus on designing secure PQ output types, and I'll include responses to the retroactive stuff in a separate message.
----------
I feel like we've all been pulled deep into the weeds of forecasting different quantum doom scenarios here. I'm gonna try to pick out the key disagreement we are dancing around, and examine it more closely.
Sipa's comment here:
> I can't imagine we don't get at least a year's worth of notice in the form of breakthroughs on simpler QC problems.
...is emblematic of an assumption baked into the security of P2TRv2: That we can predict Q-day. Unfortunately, no one - not even quantum computing experts, let alone the Bitcoin community - can reliably predict when Q-day will happen, if it even happens at all. I think this is the core problem we need to dissect.
On one hand, if we assume we'll be able to predict Q-day in advance, then we can get away with a lot: Use maximally efficient EC key-spending (P2TRv2) till the last moment, then disable EC. Deploy P2MR with only PQ sigs, and everyone can slowly migrate to use PQ sigs on P2MR. That'd be the ideal world.
But we may or may not live in that world. We have no certainty that such large technological leaps will happen slowly and behave predictably. Could the world in 1944 (outside Los Alamos) have confidently predicted the first use of an atomic bomb in 1945? Could the world in 2006 (outside Apple) have confidently predicted the iPhone would debut in 2007? How many of us in 2021 would have bet on LLMs or stable diffusion appearing? What the odds today on net-positive fusion energy for 2027? In many cases, even the innovators building these things couldn't have foreseen their success more than a few weeks in advance.
On the other hand, we also have no certainty a leap will happen quickly, or that it will happen at all. AJ highlighted some great quotes from the google paper which suggest it might happen quickly... but for all we know, maybe there's some "Great Filter" that stalls QC scaling around X Toffoli gates, or at n qubits.
Ultimately we just don't know one way or the other. AJ put it very well here:
> Picking when Q-day will occur, either individually for determining your own security posture, or collectively for organising a consensus change seems very difficulty: it involves evaluating both complex state of the art physics research, but also estimating the covert abilities of national governments and the incentives to attack bitcoin prior to revealing their capabilities. To me, that doesn't bode well for a smooth and fast deployment of a consensus change in advance of problems occuring.
With that in mind, i will now attempt an argument for P2MR based on the premise that Q-day is unpredictable (at least for now).
I follow sipa's more general belief that a follow-up EC disable soft-fork for the new output type is desirable, to reduce harm after Q-Day from EC pubkey exposure. We all seem to agree there.
However, I strongly doubt that we (the entire bitcoin community) will be able to time such a fork correctly. By "correctly", I mean: within a few days before, but no later than Q-day (the first day a CRQC would be able to start stealing coins).
Why am I so strict about the timing? Consider if we accepted AJ's definition of perfect timing,
> FWIW, I would define "timed perfectly" precisely as "EC disabling fork happens before Q-day". Maybe allowing some additional months of EC-efficiency would be a win while not taking out too much migration time, but for me "perfection" here means "no one who upgraded lost money via quantum-related vulnerabilities".
...with which sipa seems to agree:
> FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed perfectly. The expectation should be just that it happens before Q-day, and when it looks inevitable or the fear about that is large enough
I disagree. If we disable EC months in advance of Q-day, and if we do so only for the new output type, then it will likely backfire. During those months, a subset of coins will regress back to using classical wallets - P2TR, P2WPKH, etc - for many reasons. Maybe they think CRQCs are not a real threat yet. Maybe they think they can predict Q-day better than we did, and don't want to pay the extra sats for larger PQ signatures until then. Maybe they need EC for a specific protocol and haven't finished migrating their code to PQ yet. Who knows. But the longer the duration between EC disabling and the first verifiable proof of CRQCs (likely to arrive on or after Q-day), the more opportunity and incentive there will be for users to regress back to a place of vulnerability.
Thus if we entirely rely on EC disabling for the security of the new output type, as in P2TRv2, we should time such a deployment perfectly: Any later and all users are vulnerable. Too much earlier, and users are incentivized to regress.
Also recall that "we disable" really means "the entire community agrees to disable". If dictatorial power were vested in the hands of a well-informed autist with a Dark-Forest-style Big Red Button, then maybe they'd have a chance to react to Q-day. But an entire decentralized network, fraught with misinformation and polarized politics? Not likely, unless we can build and deploy a trustless, unattended canary in advance of Q-day, which somehow doesn't require a cooperative CRQC. That seems implausible today but I would welcome any evidence to the contrary.
And so, since timing is hard, I assert that we should prefer P2MR over P2TRv2 because we are confident P2MR is sound even if the EC disable fork is deployed late (after Q-day).
With P2MR, we at least have some wiggle-room in our timing of the EC disabling soft-fork. Maybe not a lot - depends on how much users expose their EC leaves - but perhaps enough to give us time to react while the CRQC gets busy cracking exposed keys.
As to the question of P2MR's "friction" that sipa claims discourages migration, I think this is a low-impact point in the debate and I have no rebuttal, except that a temporary tax of 32 weight units per input seems a small price for insurance against theft/devaluation of one's entire stack. I suspect P2MR's current popularity - even before Boris' EC recovery idea - is driven by that sentiment. If anything I'd argue that P2TRv2's timing-sensitivity would have an even sharper chilling effect and would curb migration progress much more than P2MR's 32 extra weight units would.
Maybe I am wrong, and 32 WU/input is a significant factor impacting user behavior before Q-day. If so, this amplifies my earlier point that deploying EC disabling too early will incentivize regression to classical addresses, and we would need to be even more careful in our timing: The pre-Q-day efficiency gap between EC and PQ sigs is much wider than the gap between P2MR and P2TRv2.
With my main argument made, I'd like to respond to individual points and questions:
> I have reservations too about the "Later" EC-disabling soft fork expectations about P2TRv2, but they're not about whether the future Bitcoin ecosystem can coordinate a softfork; that seems almost trivial if not doing so poses an existential threat, and could be done within a few months if it's expected and designed already. I'm more worried about it not being adopted due to indifference/friction, or being abused/misused.
Interesting, what gives you confidence that we'll be able to coordinate and time it correctly? Assuming everyone agrees and wants to, how would we go about it?
> Bitcoin can only meaningfully survive a systemic risk of this nature through collective action
Agreed! I think we just disagree about which collective actions are most important, and we have differing confidence in the feasibility of those actions and their timing.
> This focus on allowing individual users the ability to safeguard their coins just feels like a red herring: I'm not worried about my own coins being stolen. I'm worried about (fear of) a CRQC undermining trust in the currency as a whole, or through a fear-driven consensus change the ecosystem destroying its own values beforehand.
I second AJ:
> While I appreciate your point, I also feel that "allowing individual users the ability to safeguard their coins" is pretty close to the entire point of Bitcoin. :)
Sovereign control of value is the core promise of Bitcoin.
However, sipa's argument is also very valid. We need to do everything we can to preserve overall integrity of the entire UTXO set, as much as is humanly possible. This preserves trust in the currency as a whole.
We can have both, by deploying P2MR with PQ sigs to secure those who can migrate in time, and then an EC disabling follow-up, maybe with rescue protocols to secure procrastinators. This protects as many UTXOs as I think are possible with current knowledge, and is not as sensitive to timing as if we used P2TRv2.
> I understand the feeling of urgency, but this seems like a "we must do something, this is something, thus we must do it!" approach that just gives people the impression something is being done, without fundamentally tackling the hard problem of actually migrating Bitcoin, and leaving that harder problem to a (to me) very undesirable, but still unspecified future. And solving that harder problem will inevitably need another consensus change later, so it doesn't help with the "running out of years" problem if you believe those take too long.
I also dislike that class of argument. People use it all the time here to justify half-baked "solutions" to quantum problems. But that's not what I was saying in my point.
The act of migration itself is indeed a very complex task, vastly different from designing the migration paths. We can't start working on the latter until we have the former. So no, working on a migration path is really important and does help with "running out of years", because if we did nothing we'd have nowhere to migrate coins to, or we'd have to rush something out in a hurry when it is urgently needed.
> Of course, if you believe it's the only possible future, I understand you'd come to a different conclusion. But is it really? Do you think this isn't a plausible future:
> ...
> There are many other possible futures. Some are minor variations of these two scenarios. Some are fairly bad independently of the choice between P2MR or P2TRv2 (e.g. Q-day comes before any substantial migration). Some are mostly fine regardless (e.g. everyone has time to migrate to later P2QR isogeny stuff, or just no CRQC ever). But these two in particular, I think have a much better chance of happening with P2TRv2 than P2MR, because far more people can just adopt it with low friction.
The future you describe is absolutely plausible, and I would much prefer it, but the steps where the new output type "gets adopted by practically all active users" and where "the community quickly soft forks to disable EC paths/opcodes" are both doing doing a lot of work there. Both are possible, but uncertain, and so we ought to prepare for the alternatives too, right?
> - Isogenies (or something else) get a ton more attention, implementations get more efficient, gain well-studied features like tweaking and homomorphic derivation, get far better confidence in their security.
I hope you'll be as excited I as I am to learn that isogenies already have tweaking/derivation! See my own post here and this paper released just 10 days ago which proves the idea secure.
> - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
It is a common misconception that we can use toy curves as canaries. Unfortunately we can't trust succinct proofs on small curves because they could be classically forgeable. Pollard-Rho can break ECDLP for points of order `n` with only `sqrt(n)` work today. For example, in 2016 these researchers broke a 117-bit binary-field curve using FPGAs, and this paper's authors broke a 112-bit prime-field curve using a cluster of 200 playstations!
So how big does a canary curve need to be, to be out of reach of Pollard-Rho but within reach of a fledgling CRQC?
Bitcoin miners are today cumulatively doing about 2^95 work per year measured in SHA256 hashes (source). Pollard-rho work is measured in point additions, which is slower than SHA256, but only by a constant factor.
Thus for a canary to be reasonably safe against large-scale classical attacks triggering a false-positive, we'd need a much larger curve, probably 192 bits or more, for a canary. That's uncomfortably close to the danger zone, especially given the warnings AJ cited, and worse, it would be a moving goalpost as classical parallelized-computing scales up.
> Personally, that leaves me at a minimum very skeptical of the utility of introducing either P2MR or P2TRv2 (etc) approaches that don't also introduce a quantum-safe spending path on day one.
Likewise. We don't want people migrating to PQ output types without a PQ spending path. So we wouldn't want to deploy P2MR without a PQ signature scheme to back it up. I hope we'll deploy both upgrades simultaneously in a single soft-fork package. Maybe some time after deployment, we can change mempool relay policy to consider payments to legacy addresses as non-standard, and so further encourage migration without heavy-handed consensus changes like those proposed by BIP361.
> Preserving bitcoin as a personally-possessible inflation resistant store of value seems both possible and worth caring about, even if other constraints means that many people can't afford to personally hold it (and have to go through ETFs/exchanges/banks) and that it can't be used for day-to-day transactions. Would be very disappointing if true, and even given Q-day in a few years I expect we could do better than just that, but it doesn't feel like a throw-in-the-towel event to me.
A big +1 from me on this.
Also remember that even if Bitcoin becomes awkward to use for a few years, we can one day install better cryptography to bring lost features back, improve scaling with discounts or more-efficient signatures, etc. But once UTXOs are lost or stolen, we can never recover them without a contentious ETH-classic-esque hard-fork.
regards,
conduition
On Wednesday, June 17th, 2026 at 11:20 PM, Anthony Towns aj@erisian.com.au wrote:
> On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote:
>
> > I want to first correct a potential misunderstanding here, because
> > I realize the terms "Later" and "Never" aren't very descriptive. They
> > are specifically about an expected and relied-upon expectation that an
> > EC-disabling fork will happen that at least applies to the output type
> > itself, in time. "Later" is the expectation that such a disabling will
> > happen after the output type is introduced, but still in time (so, before
> > Q-day). Outputs without a strong expectation that their EC paths/opcodes
> > will be disabled, or not in time, I classify under "Never".
>
> > I believe here you're instead arguing for P2MR ("Merkle-Never")
> > over all "Later" options. That was my previous point: I think (solely)
> > having "Never" output types like P2MR is just utterly insufficient for
> > any worthwhile migration. It's so incompatible with today's workflows
> > that it either won't be adopted, or (possibly inadvertently) adopted
> > in an insecure fashion. Yes, it gives people the option to safeguard
> > their own coins, but to me that's disaster recovery territory - I think
> > we ought to prioritize maximizing the chances for saving the currency
> > as a whole in case Q-day comes, not a small subset of individual users'
> > coins. P2MR (alone) doesn't really achieve much in that regard in my view,
> > thus we at least need something of the "Later" class in addition.
>
> I'm not sure I follow/agree with the logic here. I think the general idea
> is:
>
> 1) we create some new address types that allow post-quantum spending, but
> also allow efficient quantum-vulnerable spending that can be used prior
> to Q-day
>
> 2) many people migrate to these new address types
>
> 3) Q-day arrives
>
> 4) all spending goes via the post-quantum paths, and everyone's funds are
> safe
>
> There are three main variations to this, I think:
>
> Later-dominant: towards the end of (2) but prior to (3), the
> quantum-vulnerable spend paths are disabled in a predictable, planned
> manner, preventing coin theft, but not disrupting active usage
> significantly (or not disrupting it any more than the proximity of
> Q-day already is).
>
> Self-reliance: Q-day goes from maybe to definitely faster than consensus
> changes can be coordinated, and the only reason people's funds remain
> safe is that they can (and do) keep the quantum-vulnerable spend
> paths secret.
>
> Disaster-recovery: neither the "predictable/planned consensus change" of
> Later nor the "everyone takes responsiblity for their own funds"
> works, and the only way to avoid a large percentage of bitcoin
> becoming a reward for quantum research is to replace EC spend paths
> with a ZK proof of knowledge of a BIP32 seed or similar, requiring
> a hard fork. Such a hard fork would be certain to be controversial
> ("why at this height: I received a payment five blocks after //
> my funds were stolen by a quantum attacker five blocks earlier //
> why are only BIP32 funds recoverable not scheme X"), but if no other
> approach works, might still be the ultimately outcome.
>
> > So the point here was just: if you already accept the need for a "Later"
> > output type (= one with builtin-in EC disabling expected from the start),
> > P2TRv2 is preferable over P2MR+ED, because:
>
> As far as I can see, only having P2TRv2 addresses would rule out the
> "self-reliance" path here.
>
> Picking when Q-day will occur, either individually for determining
> your own security posture, or collectively for organising a consensus
> change seems very difficulty: it involves evaluating both complex state
> of the art physics research, but also estimating the covert abilities
> of national governments and the incentives to attack bitcoin prior to
> revealing their capabilities. To me, that doesn't bode well for a smooth
> and fast deployment of a consensus change in advance of problems occuring.
>
> It's possible that general carelessness on behalf of users would also
> rule out the effectiveness of a self-reliance approach: if only the most
> conscientious 1% of users make use of P2MR securely, that might secure 10%
> of funds, but having 90% of the bitcoin supply crash probably wouldn't be
> very valuable either. But even then, that may make the "disaster-recovery"
> approach less problematic, by ensuring the 1%/10% who were conscientious
> can avoid being part of the "my funds were stolen by a quantum attacker"
> contingent, eg.
>
> > > Theorycrafting for a second here. It's reasonable to conjecture fee
> > > rates will be much higher post-Q-day, and thus P2MR's 32 byte advantage
> > > over P2TRv2 will yield significant savings for end-users in absolute
> > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes becomes
> > > significant (100 sats per spend or more).
>
> I don't think that is the right way to look at. 8vb/input is about
> an additional 14% today (vs a taproot key-path spend), but with the
> post-quantum signatures we have available now that's likely to reduce
> to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,
> you're only getting an expected savings in fees / increase in block
> capacity on that order of magnitude, ie: 1%-7%. That's nice to have,
> for sure, but doesn't compare to introducing a new address type that
> puts the PQ sigs in an extension block, or one that uses ZK proofs to
> do cross-input or cross-transaction signature aggregation, eg. So a 32B
> witness overhead for an unused/unusable key-path post-Q-day doesn't seem
> very relevant to me.
>
> > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
> > perfectly. The expectation should be just that it happens before Q-day,
> > and when it looks inevitable or the fear about that is large enough.
>
> FWIW, I would define "timed perfectly" precisely as "EC disabling
> fork happens before Q-day". Maybe allowing some additional months of
> EC-efficiency would be a win while not taking out too much migration time,
> but for me "perfection" here means "no one who upgraded lost money via
> quantum-related vulnerabilities".
>
> One reason I'm doubtful is that I think for some the "it looks inevitable"
> threshold has already been crossed, eg:
>
> > > So let me attempt to partially fill the silence, similarly to what
> > > Scott Aaronson did in his April 29 post. Given everything I know,
> > > including scary non-public information, I now put the odds of qday by
> > > 2032 at 50%. 10% by 2030.
>
> > > IMO a good target date for migration is 2029, roughly 3.5 years
> > > out. 2029 happens to be the date selected by Google, Cloudflare, and
> > > the Ethereum Foundation.
>
> https://x.com/drakefjustin/status/2061793725299224676
>
> > > So, here it is: if quantum computers start breaking cryptography a
> > > few years from now, don’t you dare come to this blog and tell me that
> > > I failed to warn you. This post is your warning. Please start switching
> > > to quantum-resistant encryption, and urge your company or organization
> > > or blockchain or standards body to do the same.
>
> https://scottaaronson.blog/?p=9718
>
> Personally, that leaves me at a minimum very skeptical of the utility
> of introducing either P2MR or P2TRv2 (etc) approaches that don't also
> introduce a quantum-safe spending path on day one.
>
> > First a meta-point here: the reason I like separating the discussion into different dimensions than just "P2TRv2 vs P2MR" is because there are more options than those two, and not every argument applies to the same separation into two classes. Let me list them explicitly here, roughly in decreasing order of how strongly I feel about them:
> > - We need at least a "Later" option for meaningful migration, i.e. P2TRv2 or P2MR+ED.
> > - Within the "Later" option, P2TRv2 is preferable.
> > - A "Later" option benefits from being the only PQC migration strategy, making it a Schelling point.
>
> Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
> "Later-dominant" scenario, and only to the degree that it's slightly
> cheaper prior to Q-day. If it were the only available option, that would
> increase the risk of loss involved with both the other approaches. (I
> don't think P2TRv2 is meaningfully more private than P2MR in the way
> taproot v1 is, as presumably you'd only adopt that address format if
> you wanted to have a post-quantum script path)
>
> > > You'd have to convince everyone to deploy and then adopt P2TRv2 today under the public knowledge that it is insecure and their coins are more likely to be stolen. That's a hard sell.
> >
> > > How does one pitch P2TRv2 to users? "It will be quantum secure one day we promise because everyone is incentivized to fix it later as Bitcoin will die if we don't."
> > >
> > > How do you pitch P2MR? "It's quantum secure if you use it correctly."
> > > To me, the pitch is "Bitcoin can only remain valuable if we mostly/all migrate." for both. P2TRv2 is just much easier to adopt, because P2MR (or any "Never" output type) fundamentally requires many users to change their workflows entirely.
>
> Let's call NoEC-day the earlier of activation of a soft-fork disabling
> EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably
> equal to "the day the bitcoin ecosystem has finally agreed that CRQCs
> are inevitable".
>
> My (cynical?) view is the only people who will adopt either P2TRv2 or
> P2MR prior to NoEC-day being schedule will be people who are willign
> to use those features in a quantum-safe way -- that is, keeping their
> EC pubkeys secret, and only revealing those EC pubkeys to spend them
> immediately, prior to NoEC-day. In that view, the EC-spend-paths of such
> coins prior to NoEC-day are only an opportunistic "make spends cheaper"
> shortcut, they don't allow the funds to be used in lightning channels
> or to let your wallet be audited via sharing an xpub or anything similar.
>
> Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible
> that lightning software could get an upgrade to generate post-quantum
> signatures for channel commitments or HTLC claims, I just think it's
> pretty unlikely that that will happen at a meaningful scale when everyone
> has much more immediate and less theoretical things to work on prior to
> NoEC-day, especially when the efficiency/performance of such changes is
> likely to be very low.
>
> > This focus on allowing individual users the ability to safeguard their
> > coins just feels like a red herring: [...]
>
> While I appreciate your point, I also feel that "allowing individual
> users the ability to safeguard their coins" is pretty close to the entire
> point of Bitcoin. :)
>
> > In either case, I consider anything that requires hardcoding
> > specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus
> > rules (and only allowing those coins to survive) to be squarely in
> > disaster-recovery land. It feels like embracing arbitrariness, and
> > giving up on the permissionlessness that makes Bitcoin interesting -
> > if the community shows it can get consensus on effectively burning
> > coins except those that match a whitelist, it feels hard to maintain
> > censorship-freeness as a value, even if the whitelist includes most of
> > the (active) coins. That is of course not to say such techniques aren't
> > interesting to work on, but to me, their place is in disaster recovery
> > scenarios to save what's left, after Q-day, if migration attempts were
> > unsuccessful. In such a setting, I think we're already in effectively an
> > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly
> > growing) set of ways to recover burned coins can be hardforked in.
>
> Just for the record, I think the above is an accurate description of the
> "disaster-recovery" scenario above: the "quantum-safe" hard-fork variant
> of bitcoin would be fairly described as a utxo-bootstrapped altcoin,
> would compete in the market with the "quantum-unsafe" bitcoin that
> existing nodes would continue to follow, and possibly there would be
> many slightly varying such altcoins competing with each other, eg on
> exactly what height the utxo snapshot was taken or what coins become
> spendable. It would not be a fun time for holders of affected utxos.
>
> > My impression is that your approach is to have an answer for many
> > possible futures, including ones where Q-day arrives within just a few
> > years.
>
> "The key of strategy... is not to choose a path to victory, but to choose
> so that all paths lead to a victory."
>
> -- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit
>
> > But optimizing for disaster-recovery also means reducing the
> > chances of preserving Bitcoin as we know it in the scenarios where a
> > successful migration is still possible. And if Q-day does arrive that
> > soon, I don't see what we can do today that would preserve Bitcoin in
> > a form we care about anyway. By accepting that, we can focus on the
> > futures where our choices today can still materially improve the outcome.
>
> Preserving bitcoin as a personally-possessible inflation resistant
> store of value seems both possible and worth caring about, even if other
> constraints means that many people can't afford to personally hold it
> (and have to go through ETFs/exchanges/banks) and that it can't be used
> for day-to-day transactions. Would be very disappointing if true, and
> even given Q-day in a few years I expect we could do better than just
> that, but it doesn't feel like a throw-in-the-towel event to me.
>
> > > Essentially yes though, I expect the majority of holders will probably
> > > migrate to PQ addresses via rescue protocols, either on Bitcoin or a fork
> > > thereof. Even if we can't come to consensus and deploy a new output type,
> > > we'll still be able to rescue most coins. It's just that we'd have nowhere
> > > to rescue them to, so we ought to make PQ wallets available soon, so we're
> > > not in a rush to build them later when we need them. If a PQ wallet can
> > > use cheap EC signatures while they're still trustworthy, all the better
>
> FWIW, that's my guess on how things would play out if the near-term Q-day
> timelines I've seen (ie, 2029 to 2035) match reality. I hope that's
> pessimistic (either because the Q-day timelines are bad estimates, or
> because migration happens in a more orderly fashion), but I guess we'll
> see. I don't rate my ability to evaluate Q-day predictions very highly.
>
> > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
>
> I'm not in a position to judge, but the google paper claims:
>
> "Indeed, if a leading quantum architecture encounters and overcomes
> all its scaling challenges before producing a device able to
> solve (for example) 32-bit ECDLP, then there may be little time
> between the breaking of 32-bit ECDLP and the breaking of 256-bit
> ECDLP. Furthermore, the community should not expect to see published
> demonstrations of the most advanced quantum error-correction
> architectures and quantum algorithms deployed to cryptanalytic
> problems. Thus, a successful public demonstration of Shor’s
> algorithm on a 32-bit elliptic curve should not be seen as a wake-up
> call to adopt PQC as much as a potential signal that PQC adoption
> has already failed."
>
> and places the required tiffoli gates and logical qubits for a 32-bit
> break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100)
> for 256-bit.
>
> > Of course, if you believe it's the only possible future, I understand
> > you'd come to a different conclusion. But is it really? Do you think
> > this isn't a plausible future:
>
> > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too) gets introduced in the next few years, with hash-based PQC opcodes.
> > - Over the course of the next decade or so, it gets adopted by practically all active users.
>
> I think it might be better to look at that scenario in a more fine-grained
> way? I think your "Late-ish" scenario is:
>
> 1) P2TRv2 (or whatever) is introduced
> 2) Some PQ opcodes get enabled, allowing expensive but PQ-safe spend-paths
> via those outputs
> 3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of P2TRv2,
> but EC spend paths continue to be what's used in practice.
> 4) Some better PQ solutions become available, allowing cheap PQ-safe spend-paths
> 5) Everyone switches from EC paths to the new PQ paths.
> 6) NoEC-day happens, but no one is impacted.
>
> I think your "Soon-ish" scenario differs as of step (4):
>
> 4) NoEC-day happens. Massive disruption because the "what's used in practice"
> path breaks, but everything is recoverable.
> 5) Post-quantum approaches get even higher priority
>
> I'm skeptical of step 3 here; and would expect to see something more like:
>
> 3') Only a small proportion of users (ie, the most conscientious/fearful)
> switch to P2TRv2 with most preferring to stick with what works
>
> That has no real impact on the Late-ish scenario, but changes the Soon-ish
> scenario to either:
>
> 4'a) NoEC-day happens substantially before Q-day; people hurry to migrate
> to P2TRv2, but it mostly works.
>
> or
>
> 4'b) NoEC-day happens essentially at the same time as Q-day; coins get
> stolen and we hit the disaster-recovery scenario.
>
> Perhaps the difference between (3') and (3) playing out in reality
> is just having nearly everyone agree that the upgrade is essential,
> and rather than leaving it to self-interest/market-dynamics, having a
> consistent push that every single wallet/service that doesn't deprecate
> every current address type is a danger to the entire ecosystem, even
> absent widespread agreement on when/if Q-day will happen. Arguably that
> would be easier to agree on if the incremental cost of EC spend paths
> in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to
> zero, rather than up to ~14% per input.
>
> Cheers,
> aj
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/p8AVEmAtWdA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ajN9be00Br-O3-9R%40erisian.com.au.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/jG9NFDBJtTNnd3Fl9DxXjINqOHifXM3xqxnpLHcrcKrxCHY999yf8uHB3-zBdRjhyu65nuWSUnMl0BvmdAmxvDvx2qOyyoZ5desBEdVWGpY%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 42701 bytes --]
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [bitcoindev] Aligning privacy incentives in P2MR
2026-06-18 5:09 ` Anthony Towns
2026-06-19 0:30 ` 'conduition' via Bitcoin Development Mailing List
@ 2026-06-19 0:38 ` 'conduition' via Bitcoin Development Mailing List
2026-06-22 11:33 ` waxwing/ AdamISZ
2026-06-24 20:24 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2 siblings, 1 reply; 20+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-06-19 0:38 UTC (permalink / raw)
To: Anthony Towns, Pieter Wuille; +Cc: Antoine Poinsot, bitcoindev@googlegroups.com
[-- Attachment #1.1.1: Type: text/plain, Size: 26517 bytes --]
Now I have some points I'd like to respond to about rescue protocols. This is largely tangential to the P2MR/P2TRv2 question.
> In either case, I consider anything that requires hardcoding specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus rules (and only allowing those coins to survive) to be squarely in disaster-recovery land. It feels like embracing arbitrariness, and giving up on the permissionlessness that makes Bitcoin interesting
It's fair to say such a solution is arbitrary, insofar as the knowledge asymmetries like BIP32 CKD are arbitrary. But can you propose any alternatives which are not arbitrary?
I would not count hoping for majority migration to be a valid solution. We ought to consider and plan for the contingency that migration to the PQ output type is underwhelming, even if that is not the best outcome, because such an outcome is still likely even if the new output type were magically 10x cheaper and more private than P2TR.
> My impression is that your approach is to have an answer for many possible futures, including ones where Q-day arrives within just a few years. But optimizing for disaster-recovery also means reducing the chances of preserving Bitcoin as we know it in the scenarios where a successful migration is still possible. And if Q-day does arrive that soon, I don't see what we can do today that would preserve Bitcoin in a form we care about anyway. By accepting that, we can focus on the futures where our choices today can still materially improve the outcome.
Mostly yes. I gotta agree with AJ's quote here. In chess, one wins by forcing the worst possible outcome to be victory. In probabilistic games, one wins by maximizing the chance of success and minimizing the cost of failure. We should be doing the same thing here.
A quantum "disaster recovery" scenario, as you put it, is absolutely worth optimizing for IMO, because with our current trajectory it seems very plausible, and yet its severe consequences can be mostly mitigated at little cost. I don't think we should abandon such survivable scenarios just because they're less palatable than others.
I dispute that rescue protocols would discourage PQ migration. Quite the opposite: They force PQ migration even for inactive users, by turning vulnerable UTXOs into PQ-safe ones retroactively.
Even if rescue protocols do massively discourage migration to PQ outputs, this would be of little consequence exactly because rescue protocols would exist (which is their beauty). Even in the most extreme case where we deploy a PQ output type and exactly nobody migrates to it, we can still use rescue protocols to achieve the same rate of ownership-preservation as if all quantum-recoverable coins (BIP32, hashed addr, etc) had migrated to PQ outputs immediately. It'll be less efficient and more awkward, but far from hopeless.
Again, the real target demographic that we need to focus on migrating is the quantum unrecoverable subset, i.e. coins which have no quantum-hard knowledge asymmetry, like satoshi's coins, P2PK wallets, and JBOK wallets with exposed pubkeys. If we expect to have rescue protocols, then we don't really care what address format these coins move to, as long as it's to something quantum-recoverable. But convincing them to move at all seems hard, because their owners are probably dead or the keys are lost. How to handle such coins after Q-day is an open question, and it seems to boil down to the good old "freeze-or-steal" debate.
> If Q-day comes before migration can reach meaningful levels (what those are is probably a matter of perspective), then I think there isn't much of an interesting future for Bitcoin anyway.
The future is only as interesting as we make it. Even if Q-Day comes before most coins migrate, we have an opportunity to make that future interesting, using rescue protocols. Maybe some folks don't want to work on them or would rather sell their coins first, and that's totally valid, but I implore you to at least keep your mind open to the possible futures that rescue protocols open up, because it is unclear exactly which future we are bound for and I'd rather that neutral internet money still exists in each of them.
We have to play the cards we are dealt, and right now we've been dealt a very fortunate hand because of BIP32 (thanks to you sipa!): Most users have at least some secret knowledge that a CRQC cannot forge, and that's a pretty awesome privilege, one which even extends to other blockchains whose wallets use BIP32, or its derivatives. You should be very proud of that IMO 🙂
> Disaster-recovery: neither the "predictable/planned consensus change" of Later nor the "everyone takes responsiblity for their own funds" works, and the only way to avoid a large percentage of bitcoin becoming a reward for quantum research is to replace EC spend paths with a ZK proof of knowledge of a BIP32 seed or similar, requiring a hard fork.
@AJ rescue protocols can be deployed via soft fork, because we'd be constricting rules and not relaxing them. We'd require any EC spends to also satisfy the rescue protocol in addition to the existing consensus rules (signatures etc). Of course, there might be external reasons to deploy it as a hard fork, e.g. to roll back mass theft if we don't time things right, or to disentangle from quantum-theft advocates, but I think we should aim for soft fork compatibility if possible.
> the "quantum-safe" hard-fork variant of bitcoin would be fairly described as a utxo-bootstrapped altcoin, would compete in the market with the "quantum-unsafe" bitcoin thatexisting nodes would continue to follow, and possibly there would be many slightly varying such altcoins competing with each other, eg on exactly what height the utxo snapshot was taken or what coins become spendable. It would not be a fun time for holders of affected utxos.
I really hope we do not end up in a situation with competing rescue protocol deployments. I don't think snapshots are necessary so that's not really a factor.
As for the exact conditions which permit rescue... that could indeed get dicey if we need to collate a bunch of different rescue protocols into one Frankensteinian mess. The most popular proposal will probably be one which covers all the most common hard-relations, but this still needs more research.
If we think of rescue protocols more abstractly, the spender just needs to prove their script pubkey commited to a quantum-hard relation, and that the spender knows the witness to that relation. It doesn't actually matter which exact relation - BIP32, hashed address, musig, whatever - just that it's quantum-hard. Maybe there is a way to formulate a two-step proof system general enough to rescue UTXOs with any such relation, by first proving the relation is quantum-hard, then proving you know the witness to the relation. That would be awesome but still an open problem.
regards,
conduition
On Wednesday, June 17th, 2026 at 11:20 PM, Anthony Towns aj@erisian.com.au wrote:
> On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote:
>
> > I want to first correct a potential misunderstanding here, because
> > I realize the terms "Later" and "Never" aren't very descriptive. They
> > are specifically about an expected and relied-upon expectation that an
> > EC-disabling fork will happen that at least applies to the output type
> > itself, in time. "Later" is the expectation that such a disabling will
> > happen after the output type is introduced, but still in time (so, before
> > Q-day). Outputs without a strong expectation that their EC paths/opcodes
> > will be disabled, or not in time, I classify under "Never".
>
> > I believe here you're instead arguing for P2MR ("Merkle-Never")
> > over all "Later" options. That was my previous point: I think (solely)
> > having "Never" output types like P2MR is just utterly insufficient for
> > any worthwhile migration. It's so incompatible with today's workflows
> > that it either won't be adopted, or (possibly inadvertently) adopted
> > in an insecure fashion. Yes, it gives people the option to safeguard
> > their own coins, but to me that's disaster recovery territory - I think
> > we ought to prioritize maximizing the chances for saving the currency
> > as a whole in case Q-day comes, not a small subset of individual users'
> > coins. P2MR (alone) doesn't really achieve much in that regard in my view,
> > thus we at least need something of the "Later" class in addition.
>
> I'm not sure I follow/agree with the logic here. I think the general idea
> is:
>
> 1) we create some new address types that allow post-quantum spending, but
> also allow efficient quantum-vulnerable spending that can be used prior
> to Q-day
>
> 2) many people migrate to these new address types
>
> 3) Q-day arrives
>
> 4) all spending goes via the post-quantum paths, and everyone's funds are
> safe
>
> There are three main variations to this, I think:
>
> Later-dominant: towards the end of (2) but prior to (3), the
> quantum-vulnerable spend paths are disabled in a predictable, planned
> manner, preventing coin theft, but not disrupting active usage
> significantly (or not disrupting it any more than the proximity of
> Q-day already is).
>
> Self-reliance: Q-day goes from maybe to definitely faster than consensus
> changes can be coordinated, and the only reason people's funds remain
> safe is that they can (and do) keep the quantum-vulnerable spend
> paths secret.
>
> Disaster-recovery: neither the "predictable/planned consensus change" of
> Later nor the "everyone takes responsiblity for their own funds"
> works, and the only way to avoid a large percentage of bitcoin
> becoming a reward for quantum research is to replace EC spend paths
> with a ZK proof of knowledge of a BIP32 seed or similar, requiring
> a hard fork. Such a hard fork would be certain to be controversial
> ("why at this height: I received a payment five blocks after //
> my funds were stolen by a quantum attacker five blocks earlier //
> why are only BIP32 funds recoverable not scheme X"), but if no other
> approach works, might still be the ultimately outcome.
>
> > So the point here was just: if you already accept the need for a "Later"
> > output type (= one with builtin-in EC disabling expected from the start),
> > P2TRv2 is preferable over P2MR+ED, because:
>
> As far as I can see, only having P2TRv2 addresses would rule out the
> "self-reliance" path here.
>
> Picking when Q-day will occur, either individually for determining
> your own security posture, or collectively for organising a consensus
> change seems very difficulty: it involves evaluating both complex state
> of the art physics research, but also estimating the covert abilities
> of national governments and the incentives to attack bitcoin prior to
> revealing their capabilities. To me, that doesn't bode well for a smooth
> and fast deployment of a consensus change in advance of problems occuring.
>
> It's possible that general carelessness on behalf of users would also
> rule out the effectiveness of a self-reliance approach: if only the most
> conscientious 1% of users make use of P2MR securely, that might secure 10%
> of funds, but having 90% of the bitcoin supply crash probably wouldn't be
> very valuable either. But even then, that may make the "disaster-recovery"
> approach less problematic, by ensuring the 1%/10% who were conscientious
> can avoid being part of the "my funds were stolen by a quantum attacker"
> contingent, eg.
>
> > > Theorycrafting for a second here. It's reasonable to conjecture fee
> > > rates will be much higher post-Q-day, and thus P2MR's 32 byte advantage
> > > over P2TRv2 will yield significant savings for end-users in absolute
> > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes becomes
> > > significant (100 sats per spend or more).
>
> I don't think that is the right way to look at. 8vb/input is about
> an additional 14% today (vs a taproot key-path spend), but with the
> post-quantum signatures we have available now that's likely to reduce
> to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,
> you're only getting an expected savings in fees / increase in block
> capacity on that order of magnitude, ie: 1%-7%. That's nice to have,
> for sure, but doesn't compare to introducing a new address type that
> puts the PQ sigs in an extension block, or one that uses ZK proofs to
> do cross-input or cross-transaction signature aggregation, eg. So a 32B
> witness overhead for an unused/unusable key-path post-Q-day doesn't seem
> very relevant to me.
>
> > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
> > perfectly. The expectation should be just that it happens before Q-day,
> > and when it looks inevitable or the fear about that is large enough.
>
> FWIW, I would define "timed perfectly" precisely as "EC disabling
> fork happens before Q-day". Maybe allowing some additional months of
> EC-efficiency would be a win while not taking out too much migration time,
> but for me "perfection" here means "no one who upgraded lost money via
> quantum-related vulnerabilities".
>
> One reason I'm doubtful is that I think for some the "it looks inevitable"
> threshold has already been crossed, eg:
>
> > > So let me attempt to partially fill the silence, similarly to what
> > > Scott Aaronson did in his April 29 post. Given everything I know,
> > > including scary non-public information, I now put the odds of qday by
> > > 2032 at 50%. 10% by 2030.
>
> > > IMO a good target date for migration is 2029, roughly 3.5 years
> > > out. 2029 happens to be the date selected by Google, Cloudflare, and
> > > the Ethereum Foundation.
>
> https://x.com/drakefjustin/status/2061793725299224676
>
> > > So, here it is: if quantum computers start breaking cryptography a
> > > few years from now, don’t you dare come to this blog and tell me that
> > > I failed to warn you. This post is your warning. Please start switching
> > > to quantum-resistant encryption, and urge your company or organization
> > > or blockchain or standards body to do the same.
>
> https://scottaaronson.blog/?p=9718
>
> Personally, that leaves me at a minimum very skeptical of the utility
> of introducing either P2MR or P2TRv2 (etc) approaches that don't also
> introduce a quantum-safe spending path on day one.
>
> > First a meta-point here: the reason I like separating the discussion into different dimensions than just "P2TRv2 vs P2MR" is because there are more options than those two, and not every argument applies to the same separation into two classes. Let me list them explicitly here, roughly in decreasing order of how strongly I feel about them:
> > - We need at least a "Later" option for meaningful migration, i.e. P2TRv2 or P2MR+ED.
> > - Within the "Later" option, P2TRv2 is preferable.
> > - A "Later" option benefits from being the only PQC migration strategy, making it a Schelling point.
>
> Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
> "Later-dominant" scenario, and only to the degree that it's slightly
> cheaper prior to Q-day. If it were the only available option, that would
> increase the risk of loss involved with both the other approaches. (I
> don't think P2TRv2 is meaningfully more private than P2MR in the way
> taproot v1 is, as presumably you'd only adopt that address format if
> you wanted to have a post-quantum script path)
>
> > > You'd have to convince everyone to deploy and then adopt P2TRv2 today under the public knowledge that it is insecure and their coins are more likely to be stolen. That's a hard sell.
> >
> > > How does one pitch P2TRv2 to users? "It will be quantum secure one day we promise because everyone is incentivized to fix it later as Bitcoin will die if we don't."
> > >
> > > How do you pitch P2MR? "It's quantum secure if you use it correctly."
> > > To me, the pitch is "Bitcoin can only remain valuable if we mostly/all migrate." for both. P2TRv2 is just much easier to adopt, because P2MR (or any "Never" output type) fundamentally requires many users to change their workflows entirely.
>
> Let's call NoEC-day the earlier of activation of a soft-fork disabling
> EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably
> equal to "the day the bitcoin ecosystem has finally agreed that CRQCs
> are inevitable".
>
> My (cynical?) view is the only people who will adopt either P2TRv2 or
> P2MR prior to NoEC-day being schedule will be people who are willign
> to use those features in a quantum-safe way -- that is, keeping their
> EC pubkeys secret, and only revealing those EC pubkeys to spend them
> immediately, prior to NoEC-day. In that view, the EC-spend-paths of such
> coins prior to NoEC-day are only an opportunistic "make spends cheaper"
> shortcut, they don't allow the funds to be used in lightning channels
> or to let your wallet be audited via sharing an xpub or anything similar.
>
> Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible
> that lightning software could get an upgrade to generate post-quantum
> signatures for channel commitments or HTLC claims, I just think it's
> pretty unlikely that that will happen at a meaningful scale when everyone
> has much more immediate and less theoretical things to work on prior to
> NoEC-day, especially when the efficiency/performance of such changes is
> likely to be very low.
>
> > This focus on allowing individual users the ability to safeguard their
> > coins just feels like a red herring: [...]
>
> While I appreciate your point, I also feel that "allowing individual
> users the ability to safeguard their coins" is pretty close to the entire
> point of Bitcoin. :)
>
> > In either case, I consider anything that requires hardcoding
> > specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus
> > rules (and only allowing those coins to survive) to be squarely in
> > disaster-recovery land. It feels like embracing arbitrariness, and
> > giving up on the permissionlessness that makes Bitcoin interesting -
> > if the community shows it can get consensus on effectively burning
> > coins except those that match a whitelist, it feels hard to maintain
> > censorship-freeness as a value, even if the whitelist includes most of
> > the (active) coins. That is of course not to say such techniques aren't
> > interesting to work on, but to me, their place is in disaster recovery
> > scenarios to save what's left, after Q-day, if migration attempts were
> > unsuccessful. In such a setting, I think we're already in effectively an
> > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly
> > growing) set of ways to recover burned coins can be hardforked in.
>
> Just for the record, I think the above is an accurate description of the
> "disaster-recovery" scenario above: the "quantum-safe" hard-fork variant
> of bitcoin would be fairly described as a utxo-bootstrapped altcoin,
> would compete in the market with the "quantum-unsafe" bitcoin that
> existing nodes would continue to follow, and possibly there would be
> many slightly varying such altcoins competing with each other, eg on
> exactly what height the utxo snapshot was taken or what coins become
> spendable. It would not be a fun time for holders of affected utxos.
>
> > My impression is that your approach is to have an answer for many
> > possible futures, including ones where Q-day arrives within just a few
> > years.
>
> "The key of strategy... is not to choose a path to victory, but to choose
> so that all paths lead to a victory."
>
> -- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit
>
> > But optimizing for disaster-recovery also means reducing the
> > chances of preserving Bitcoin as we know it in the scenarios where a
> > successful migration is still possible. And if Q-day does arrive that
> > soon, I don't see what we can do today that would preserve Bitcoin in
> > a form we care about anyway. By accepting that, we can focus on the
> > futures where our choices today can still materially improve the outcome.
>
> Preserving bitcoin as a personally-possessible inflation resistant
> store of value seems both possible and worth caring about, even if other
> constraints means that many people can't afford to personally hold it
> (and have to go through ETFs/exchanges/banks) and that it can't be used
> for day-to-day transactions. Would be very disappointing if true, and
> even given Q-day in a few years I expect we could do better than just
> that, but it doesn't feel like a throw-in-the-towel event to me.
>
> > > Essentially yes though, I expect the majority of holders will probably
> > > migrate to PQ addresses via rescue protocols, either on Bitcoin or a fork
> > > thereof. Even if we can't come to consensus and deploy a new output type,
> > > we'll still be able to rescue most coins. It's just that we'd have nowhere
> > > to rescue them to, so we ought to make PQ wallets available soon, so we're
> > > not in a rush to build them later when we need them. If a PQ wallet can
> > > use cheap EC signatures while they're still trustworthy, all the better
>
> FWIW, that's my guess on how things would play out if the near-term Q-day
> timelines I've seen (ie, 2029 to 2035) match reality. I hope that's
> pessimistic (either because the Q-day timelines are bad estimates, or
> because migration happens in a more orderly fashion), but I guess we'll
> see. I don't rate my ability to evaluate Q-day predictions very highly.
>
> > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
>
> I'm not in a position to judge, but the google paper claims:
>
> "Indeed, if a leading quantum architecture encounters and overcomes
> all its scaling challenges before producing a device able to
> solve (for example) 32-bit ECDLP, then there may be little time
> between the breaking of 32-bit ECDLP and the breaking of 256-bit
> ECDLP. Furthermore, the community should not expect to see published
> demonstrations of the most advanced quantum error-correction
> architectures and quantum algorithms deployed to cryptanalytic
> problems. Thus, a successful public demonstration of Shor’s
> algorithm on a 32-bit elliptic curve should not be seen as a wake-up
> call to adopt PQC as much as a potential signal that PQC adoption
> has already failed."
>
> and places the required tiffoli gates and logical qubits for a 32-bit
> break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100)
> for 256-bit.
>
> > Of course, if you believe it's the only possible future, I understand
> > you'd come to a different conclusion. But is it really? Do you think
> > this isn't a plausible future:
>
> > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too) gets introduced in the next few years, with hash-based PQC opcodes.
> > - Over the course of the next decade or so, it gets adopted by practically all active users.
>
> I think it might be better to look at that scenario in a more fine-grained
> way? I think your "Late-ish" scenario is:
>
> 1) P2TRv2 (or whatever) is introduced
> 2) Some PQ opcodes get enabled, allowing expensive but PQ-safe spend-paths
> via those outputs
> 3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of P2TRv2,
> but EC spend paths continue to be what's used in practice.
> 4) Some better PQ solutions become available, allowing cheap PQ-safe spend-paths
> 5) Everyone switches from EC paths to the new PQ paths.
> 6) NoEC-day happens, but no one is impacted.
>
> I think your "Soon-ish" scenario differs as of step (4):
>
> 4) NoEC-day happens. Massive disruption because the "what's used in practice"
> path breaks, but everything is recoverable.
> 5) Post-quantum approaches get even higher priority
>
> I'm skeptical of step 3 here; and would expect to see something more like:
>
> 3') Only a small proportion of users (ie, the most conscientious/fearful)
> switch to P2TRv2 with most preferring to stick with what works
>
> That has no real impact on the Late-ish scenario, but changes the Soon-ish
> scenario to either:
>
> 4'a) NoEC-day happens substantially before Q-day; people hurry to migrate
> to P2TRv2, but it mostly works.
>
> or
>
> 4'b) NoEC-day happens essentially at the same time as Q-day; coins get
> stolen and we hit the disaster-recovery scenario.
>
> Perhaps the difference between (3') and (3) playing out in reality
> is just having nearly everyone agree that the upgrade is essential,
> and rather than leaving it to self-interest/market-dynamics, having a
> consistent push that every single wallet/service that doesn't deprecate
> every current address type is a danger to the entire ecosystem, even
> absent widespread agreement on when/if Q-day will happen. Arguably that
> would be easier to agree on if the incremental cost of EC spend paths
> in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to
> zero, rather than up to ~14% per input.
>
> Cheers,
> aj
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/p8AVEmAtWdA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ajN9be00Br-O3-9R%40erisian.com.au.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/xXllZpuSNUfmizNVhO9lt8q7Wi-l5-7RsHBHnO2FmenEj52K8FF2hhoW1fg_UMRMkhYzzrXS9sGDsKaYfKxviiaQ3mIuesm-bfEII79EI8g%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 37571 bytes --]
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [bitcoindev] Aligning privacy incentives in P2MR
2026-06-19 0:38 ` 'conduition' via Bitcoin Development Mailing List
@ 2026-06-22 11:33 ` waxwing/ AdamISZ
0 siblings, 0 replies; 20+ messages in thread
From: waxwing/ AdamISZ @ 2026-06-22 11:33 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 28616 bytes --]
> It is a common misconception that we can use toy curves as canaries.
Unfortunately we can't trust succinct proofs on small curves because they
could be classically forgeable. Pollard-Rho can break ECDLP for points of
order n with only sqrt(n) work today. For example, in 2016 these
researchers broke a 117-bit binary-field curve using FPGAs
<https://cryptojedi.org/papers/sect113r2-20161212.pdf>, and this paper's
authors broke a 112-bit prime-field curve using a cluster of 200
playstations <https://www.joppebos.com/files/rho_ps3.pdf>!
This hinges on what you consider 'toy'. Since there are good O(sqrt(n))
algos, a 128 bit curve is not really secure (you're in the range where
non-trivial endomorphisms and other technical tricks could make a
difference, but anyway it's pretty clearly within 'state actor' range). But
that maybe is not a valid basis for dismissing even 160 bit curves (80 bits
seems out of range?), let alone the 192 bit curves that have been
standardized in the past.
The more interesting question for me is whether just looking for
lower-entropy secrets in secp256k1 (i.e. the canary explicitly tells the
attackers that the discrete log < t << n), or alternatively looking for
properly chosen secrets from a smaller curve, is equivalent, from the point
of view of Shor. As per my "is it “the same” to solve a 192 bit secret on
secp, as to solve a same-size secret on secp192r1" question from [1]. (I
actually wrote "secp" not "secp256k1" or "r1", I forgot that we are talking
about 2 different curve equations; that's another knot to untangle; is it
only the size of the group that matters? seems like the curve eqn shouldn't
matter here). These questions are easy to ask but maybe quite hard to
answer!
I think canaries are unlikely to be useful, but only 'moderately unlikely',
such that creating them may not be a total waste of time.
Regards,
AdamISZ/waxwing
[1] https://delvingbitcoin.org/t/qcap-a-bitcoin-native-quantum-canary-alert/2498/6
On Thursday, June 18, 2026 at 9:41:01 PM UTC-3 conduition wrote:
> Now I have some points I'd like to respond to about rescue protocols. This
> is largely tangential to the P2MR/P2TRv2 question.
>
> In either case, I consider anything that requires hardcoding specific
> wallet designs (BIP32 or otherwise) into Bitcoin's consensus rules (and
> only allowing those coins to survive) to be squarely in disaster-recovery
> land. It feels like embracing arbitrariness, and giving up on the
> permissionlessness that makes Bitcoin interesting
>
> It's fair to say such a solution is arbitrary, insofar as the knowledge
> asymmetries like BIP32 CKD are arbitrary. But can you propose any
> alternatives which are not arbitrary?
>
> I would not count *hoping for majority migration* to be a valid solution.
> We ought to consider and plan for the contingency that migration to the PQ
> output type is underwhelming, even if that is not the *best* outcome,
> because such an outcome is still likely even if the new output type were
> magically 10x cheaper and more private than P2TR.
>
> My impression is that your approach is to have an answer for many possible
> futures, including ones where Q-day arrives within just a few years. But
> optimizing for disaster-recovery also means reducing the chances of
> preserving Bitcoin as we know it in the scenarios where a successful
> migration is still possible. And if Q-day does arrive that soon, I don't
> see what we can do today that would preserve Bitcoin in a form we care
> about anyway. By accepting that, we can focus on the futures where our
> choices today can still materially improve the outcome.
>
> Mostly yes. I gotta agree with AJ's quote here. In chess, one wins by
> forcing the worst possible outcome to be victory. In probabilistic games,
> one wins by maximizing the chance of success and minimizing the cost of
> failure. We should be doing the same thing here.
>
> A quantum "disaster recovery" scenario, as you put it, is absolutely worth
> optimizing for IMO, because with our current trajectory it seems very
> plausible, and yet its severe consequences can be mostly mitigated at
> little cost. I don't think we should abandon such survivable scenarios just
> because they're less palatable than others.
>
> I dispute that rescue protocols would discourage PQ migration. Quite the
> opposite: They *force* PQ migration even for inactive users, by turning
> vulnerable UTXOs into PQ-safe ones retroactively.
>
> Even if rescue protocols do massively discourage migration to PQ outputs,
> this would be of little consequence *exactly because rescue protocols
> would** exist* (which is their beauty). Even in the most extreme case
> where we deploy a PQ output type and exactly *nobody* migrates to it, we
> can still use rescue protocols to achieve the same rate of
> ownership-preservation as if all quantum-recoverable coins (BIP32, hashed
> addr, etc) had migrated to PQ outputs *immediately*. It'll be less
> efficient and more awkward, but far from hopeless.
>
> Again, the real target demographic that we need to focus on migrating is
> the *quantum unrecoverable subset*, i.e. coins which have no quantum-hard
> knowledge asymmetry, like satoshi's coins, P2PK wallets, and JBOK wallets
> with exposed pubkeys. If we expect to have rescue protocols, then we don't
> really care what address format these coins move to, as long as it's to
> *something* quantum-recoverable. But convincing them to move at all seems
> hard, because their owners are probably dead or the keys are lost. How to
> handle such coins after Q-day is an open question, and it seems to boil
> down to the good old "freeze-or-steal" debate.
>
> If Q-day comes before migration can reach meaningful levels (what those
> are is probably a matter of perspective), then I think there isn't much of
> an interesting future for Bitcoin anyway.
>
> The future is only as interesting as we make it. Even if Q-Day comes
> before most coins migrate, we have an opportunity to make that future
> interesting, using rescue protocols. Maybe some folks don't want to work on
> them or would rather sell their coins first, and that's totally valid, but
> I implore you to at least keep your mind open to the possible futures that
> rescue protocols open up, because it is unclear exactly which future we are
> bound for and I'd rather that neutral internet money still exists in each
> of them.
>
> We have to play the cards we are dealt, and right now we've been dealt a
> very fortunate hand because of BIP32 (thanks to you sipa!): Most users
> have at least *some* secret knowledge that a CRQC cannot forge, and
> that's a pretty awesome privilege, one which even extends to other
> blockchains whose wallets use BIP32, or its derivatives. You should be very
> proud of that IMO 🙂
>
>
> Disaster-recovery: neither the "predictable/planned consensus change" of Later
> nor the "everyone takes responsiblity for their own funds" works, and the
> only way to avoid a large percentage of bitcoin becoming a reward for
> quantum research is to replace EC spend paths with a ZK proof of knowledge
> of a BIP32 seed or similar, requiring a hard fork.
>
> @AJ rescue protocols can be deployed via soft fork, because we'd be
> constricting rules and not relaxing them. We'd require any EC spends to
> *also* satisfy the rescue protocol in addition to the existing consensus
> rules (signatures etc). Of course, there might be external reasons to
> deploy it as a hard fork, e.g. to roll back mass theft if we don't time
> things right, or to disentangle from quantum-theft advocates, but I think
> we should aim for soft fork compatibility if possible.
>
>
> the "quantum-safe" hard-fork variant of bitcoin would be fairly described
> as a utxo-bootstrapped altcoin, would compete in the market with the
> "quantum-unsafe" bitcoin thatexisting nodes would continue to follow, and
> possibly there would be many slightly varying such altcoins competing with
> each other, eg on exactly what height the utxo snapshot was taken or what
> coins become spendable. It would not be a fun time for holders of affected
> utxos.
>
> I really hope we do not end up in a situation with competing rescue
> protocol deployments. I don't think snapshots are necessary so that's not
> really a factor.
> As for the exact conditions which permit rescue... that could indeed get
> dicey if we need to collate a bunch of different rescue protocols into one
> Frankensteinian mess. The most popular proposal will probably be one which
> covers all the most common hard-relations, but this still needs more
> research.
> If we think of rescue protocols more abstractly, the spender just needs to
> prove their script pubkey commited to a quantum-hard relation, and that the
> spender knows the witness to that relation. It doesn't actually matter
> which exact relation - BIP32, hashed address, musig, whatever - just that
> it's quantum-hard. Maybe there is a way to formulate a two-step proof
> system general enough to rescue UTXOs with any such relation, by first
> proving the relation is quantum-hard, then proving you know the witness to
> the relation. That would be awesome but still an open problem.
>
> regards,
> conduition
>
>
> On Wednesday, June 17th, 2026 at 11:20 PM, Anthony Towns
> a...@erisian.com.au wrote:
>
> On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote:
>
> I want to first correct a potential misunderstanding here, because
> I realize the terms "Later" and "Never" aren't very descriptive. They
> are specifically about an expected and relied-upon expectation that an
> EC-disabling fork will happen that at least applies to the output type
> itself, in time. "Later" is the expectation that such a disabling will
> happen after the output type is introduced, but still in time (so, before
> Q-day). Outputs without a strong expectation that their EC paths/opcodes
> will be disabled, or not in time, I classify under "Never".
>
> I believe here you're instead arguing for P2MR ("Merkle-Never")
> over all "Later" options. That was my previous point: I think (solely)
> having "Never" output types like P2MR is just utterly insufficient for
> any worthwhile migration. It's so incompatible with today's workflows
> that it either won't be adopted, or (possibly inadvertently) adopted
> in an insecure fashion. Yes, it gives people the option to safeguard
> their own coins, but to me that's disaster recovery territory - I think
> we ought to prioritize maximizing the chances for saving the currency
> as a whole in case Q-day comes, not a small subset of individual users'
> coins. P2MR (alone) doesn't really achieve much in that regard in my view,
> thus we at least need something of the "Later" class in addition.
>
> I'm not sure I follow/agree with the logic here. I think the general idea
> is:
>
> 1) we create some new address types that allow post-quantum spending, but
> also allow efficient quantum-vulnerable spending that can be used prior
> to Q-day
>
> 2) many people migrate to these new address types
>
> 3) Q-day arrives
>
> 4) all spending goes via the post-quantum paths, and everyone's funds are
> safe
>
> There are three main variations to this, I think:
>
> Later-dominant: towards the end of (2) but prior to (3), the
> quantum-vulnerable spend paths are disabled in a predictable, planned
> manner, preventing coin theft, but not disrupting active usage
> significantly (or not disrupting it any more than the proximity of
> Q-day already is).
>
> Self-reliance: Q-day goes from maybe to definitely faster than consensus
> changes can be coordinated, and the only reason people's funds remain
> safe is that they can (and do) keep the quantum-vulnerable spend
> paths secret.
>
> Disaster-recovery: neither the "predictable/planned consensus change" of
> Later nor the "everyone takes responsiblity for their own funds"
> works, and the only way to avoid a large percentage of bitcoin
> becoming a reward for quantum research is to replace EC spend paths
> with a ZK proof of knowledge of a BIP32 seed or similar, requiring
> a hard fork. Such a hard fork would be certain to be controversial
> ("why at this height: I received a payment five blocks after //
> my funds were stolen by a quantum attacker five blocks earlier //
> why are only BIP32 funds recoverable not scheme X"), but if no other
> approach works, might still be the ultimately outcome.
>
> So the point here was just: if you already accept the need for a "Later"
> output type (= one with builtin-in EC disabling expected from the start),
> P2TRv2 is preferable over P2MR+ED, because:
>
> As far as I can see, only having P2TRv2 addresses would rule out the
> "self-reliance" path here.
>
> Picking when Q-day will occur, either individually for determining
> your own security posture, or collectively for organising a consensus
> change seems very difficulty: it involves evaluating both complex state
> of the art physics research, but also estimating the covert abilities
> of national governments and the incentives to attack bitcoin prior to
> revealing their capabilities. To me, that doesn't bode well for a smooth
> and fast deployment of a consensus change in advance of problems occuring.
>
> It's possible that general carelessness on behalf of users would also
> rule out the effectiveness of a self-reliance approach: if only the most
> conscientious 1% of users make use of P2MR securely, that might secure 10%
> of funds, but having 90% of the bitcoin supply crash probably wouldn't be
> very valuable either. But even then, that may make the "disaster-recovery"
> approach less problematic, by ensuring the 1%/10% who were conscientious
> can avoid being part of the "my funds were stolen by a quantum attacker"
> contingent, eg.
>
> Theorycrafting for a second here. It's reasonable to conjecture fee
> rates will be much higher post-Q-day, and thus P2MR's 32 byte advantage
> over P2TRv2 will yield significant savings for end-users in absolute
> terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes becomes
> significant (100 sats per spend or more).
>
> I don't think that is the right way to look at. 8vb/input is about
> an additional 14% today (vs a taproot key-path spend), but with the
> post-quantum signatures we have available now that's likely to reduce
> to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,
> you're only getting an expected savings in fees / increase in block
> capacity on that order of magnitude, ie: 1%-7%. That's nice to have,
> for sure, but doesn't compare to introducing a new address type that
> puts the PQ sigs in an extension block, or one that uses ZK proofs to
> do cross-input or cross-transaction signature aggregation, eg. So a 32B
> witness overhead for an unused/unusable key-path post-Q-day doesn't seem
> very relevant to me.
>
> FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
> perfectly. The expectation should be just that it happens before Q-day,
> and when it looks inevitable or the fear about that is large enough.
>
> FWIW, I would define "timed perfectly" precisely as "EC disabling
> fork happens before Q-day". Maybe allowing some additional months of
> EC-efficiency would be a win while not taking out too much migration time,
> but for me "perfection" here means "no one who upgraded lost money via
> quantum-related vulnerabilities".
>
> One reason I'm doubtful is that I think for some the "it looks inevitable"
> threshold has already been crossed, eg:
>
> So let me attempt to partially fill the silence, similarly to what
> Scott Aaronson did in his April 29 post. Given everything I know,
> including scary non-public information, I now put the odds of qday by
> 2032 at 50%. 10% by 2030.
>
> IMO a good target date for migration is 2029, roughly 3.5 years
> out. 2029 happens to be the date selected by Google, Cloudflare, and
> the Ethereum Foundation.
>
> https://x.com/drakefjustin/status/2061793725299224676
>
> So, here it is: if quantum computers start breaking cryptography a
> few years from now, don’t you dare come to this blog and tell me that
> I failed to warn you. This post is your warning. Please start switching
> to quantum-resistant encryption, and urge your company or organization
> or blockchain or standards body to do the same.
>
> https://scottaaronson.blog/?p=9718
>
> Personally, that leaves me at a minimum very skeptical of the utility
> of introducing either P2MR or P2TRv2 (etc) approaches that don't also
> introduce a quantum-safe spending path on day one.
>
> First a meta-point here: the reason I like separating the discussion into
> different dimensions than just "P2TRv2 vs P2MR" is because there are more
> options than those two, and not every argument applies to the same
> separation into two classes. Let me list them explicitly here, roughly in
> decreasing order of how strongly I feel about them:
> - We need at least a "Later" option for meaningful migration, i.e. P2TRv2
> or P2MR+ED.
> - Within the "Later" option, P2TRv2 is preferable.
> - A "Later" option benefits from being the only PQC migration strategy,
> making it a Schelling point.
>
> Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
> "Later-dominant" scenario, and only to the degree that it's slightly
> cheaper prior to Q-day. If it were the only available option, that would
> increase the risk of loss involved with both the other approaches. (I
> don't think P2TRv2 is meaningfully more private than P2MR in the way
> taproot v1 is, as presumably you'd only adopt that address format if
> you wanted to have a post-quantum script path)
>
> You'd have to convince everyone to deploy and then adopt P2TRv2 today
> under the public knowledge that it is insecure and their coins are more
> likely to be stolen. That's a hard sell.
>
> How does one pitch P2TRv2 to users? "It will be quantum secure one day we
> promise because everyone is incentivized to fix it later as Bitcoin will
> die if we don't."
>
> How do you pitch P2MR? "It's quantum secure if you use it correctly."
> To me, the pitch is "Bitcoin can only remain valuable if we mostly/all
> migrate." for both. P2TRv2 is just much easier to adopt, because P2MR (or
> any "Never" output type) fundamentally requires many users to change their
> workflows entirely.
>
> Let's call NoEC-day the earlier of activation of a soft-fork disabling
> EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably
> equal to "the day the bitcoin ecosystem has finally agreed that CRQCs
> are inevitable".
>
> My (cynical?) view is the only people who will adopt either P2TRv2 or
> P2MR prior to NoEC-day being schedule will be people who are willign
> to use those features in a quantum-safe way -- that is, keeping their
> EC pubkeys secret, and only revealing those EC pubkeys to spend them
> immediately, prior to NoEC-day. In that view, the EC-spend-paths of such
> coins prior to NoEC-day are only an opportunistic "make spends cheaper"
> shortcut, they don't allow the funds to be used in lightning channels
> or to let your wallet be audited via sharing an xpub or anything similar.
>
> Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible
> that lightning software could get an upgrade to generate post-quantum
> signatures for channel commitments or HTLC claims, I just think it's
> pretty unlikely that that will happen at a meaningful scale when everyone
> has much more immediate and less theoretical things to work on prior to
> NoEC-day, especially when the efficiency/performance of such changes is
> likely to be very low.
>
> This focus on allowing individual users the ability to safeguard their
> coins just feels like a red herring: [...]
>
> While I appreciate your point, I also feel that "allowing individual
> users the ability to safeguard their coins" is pretty close to the entire
> point of Bitcoin. :)
>
> In either case, I consider anything that requires hardcoding
> specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus
> rules (and only allowing those coins to survive) to be squarely in
> disaster-recovery land. It feels like embracing arbitrariness, and
> giving up on the permissionlessness that makes Bitcoin interesting -
> if the community shows it can get consensus on effectively burning
> coins except those that match a whitelist, it feels hard to maintain
> censorship-freeness as a value, even if the whitelist includes most of
> the (active) coins. That is of course not to say such techniques aren't
> interesting to work on, but to me, their place is in disaster recovery
> scenarios to save what's left, after Q-day, if migration attempts were
> unsuccessful. In such a setting, I think we're already in effectively an
> altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly
> growing) set of ways to recover burned coins can be hardforked in.
>
> Just for the record, I think the above is an accurate description of the
> "disaster-recovery" scenario above: the "quantum-safe" hard-fork variant
> of bitcoin would be fairly described as a utxo-bootstrapped altcoin,
> would compete in the market with the "quantum-unsafe" bitcoin that
> existing nodes would continue to follow, and possibly there would be
> many slightly varying such altcoins competing with each other, eg on
> exactly what height the utxo snapshot was taken or what coins become
> spendable. It would not be a fun time for holders of affected utxos.
>
> My impression is that your approach is to have an answer for many
> possible futures, including ones where Q-day arrives within just a few
> years.
>
> "The key of strategy... is not to choose a path to victory, but to choose
> so that all paths lead to a victory."
>
> -- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit
>
> But optimizing for disaster-recovery also means reducing the
> chances of preserving Bitcoin as we know it in the scenarios where a
> successful migration is still possible. And if Q-day does arrive that
> soon, I don't see what we can do today that would preserve Bitcoin in
> a form we care about anyway. By accepting that, we can focus on the
> futures where our choices today can still materially improve the outcome.
>
> Preserving bitcoin as a personally-possessible inflation resistant
> store of value seems both possible and worth caring about, even if other
> constraints means that many people can't afford to personally hold it
> (and have to go through ETFs/exchanges/banks) and that it can't be used
> for day-to-day transactions. Would be very disappointing if true, and
> even given Q-day in a few years I expect we could do better than just
> that, but it doesn't feel like a throw-in-the-towel event to me.
>
> Essentially yes though, I expect the majority of holders will probably
> migrate to PQ addresses via rescue protocols, either on Bitcoin or a fork
> thereof. Even if we can't come to consensus and deploy a new output type,
> we'll still be able to rescue most coins. It's just that we'd have nowhere
> to rescue them to, so we ought to make PQ wallets available soon, so we're
> not in a rush to build them later when we need them. If a PQ wallet can
> use cheap EC signatures while they're still trustworthy, all the better
>
> FWIW, that's my guess on how things would play out if the near-term Q-day
> timelines I've seen (ie, 2029 to 2035) match reality. I hope that's
> pessimistic (either because the Q-day timelines are bad estimates, or
> because migration happens in a more orderly fashion), but I guess we'll
> see. I don't rate my ability to evaluate Q-day predictions very highly.
>
> - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
>
> I'm not in a position to judge, but the google paper claims:
>
> "Indeed, if a leading quantum architecture encounters and overcomes
> all its scaling challenges before producing a device able to
> solve (for example) 32-bit ECDLP, then there may be little time
> between the breaking of 32-bit ECDLP and the breaking of 256-bit
> ECDLP. Furthermore, the community should not expect to see published
> demonstrations of the most advanced quantum error-correction
> architectures and quantum algorithms deployed to cryptanalytic
> problems. Thus, a successful public demonstration of Shor’s
> algorithm on a 32-bit elliptic curve should not be seen as a wake-up
> call to adopt PQC as much as a potential signal that PQC adoption
> has already failed."
>
> and places the required tiffoli gates and logical qubits for a 32-bit
> break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100)
> for 256-bit.
>
> Of course, if you believe it's the only possible future, I understand
> you'd come to a different conclusion. But is it really? Do you think
> this isn't a plausible future:
>
> - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too)
> gets introduced in the next few years, with hash-based PQC opcodes.
> - Over the course of the next decade or so, it gets adopted by practically
> all active users.
>
> I think it might be better to look at that scenario in a more fine-grained
> way? I think your "Late-ish" scenario is:
>
> 1) P2TRv2 (or whatever) is introduced
> 2) Some PQ opcodes get enabled, allowing expensive but PQ-safe spend-paths
> via those outputs
> 3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of
> P2TRv2,
> but EC spend paths continue to be what's used in practice.
> 4) Some better PQ solutions become available, allowing cheap PQ-safe
> spend-paths
> 5) Everyone switches from EC paths to the new PQ paths.
> 6) NoEC-day happens, but no one is impacted.
>
> I think your "Soon-ish" scenario differs as of step (4):
>
> 4) NoEC-day happens. Massive disruption because the "what's used in
> practice"
> path breaks, but everything is recoverable.
> 5) Post-quantum approaches get even higher priority
>
> I'm skeptical of step 3 here; and would expect to see something more like:
>
> 3') Only a small proportion of users (ie, the most conscientious/fearful)
> switch to P2TRv2 with most preferring to stick with what works
>
> That has no real impact on the Late-ish scenario, but changes the Soon-ish
> scenario to either:
>
> 4'a) NoEC-day happens substantially before Q-day; people hurry to migrate
> to P2TRv2, but it mostly works.
>
> or
>
> 4'b) NoEC-day happens essentially at the same time as Q-day; coins get
> stolen and we hit the disaster-recovery scenario.
>
> Perhaps the difference between (3') and (3) playing out in reality
> is just having nearly everyone agree that the upgrade is essential,
> and rather than leaving it to self-interest/market-dynamics, having a
> consistent push that every single wallet/service that doesn't deprecate
> every current address type is a danger to the entire ecosystem, even
> absent widespread agreement on when/if Q-day will happen. Arguably that
> would be easier to agree on if the incremental cost of EC spend paths
> in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to
> zero, rather than up to ~14% per input.
>
> Cheers,
> aj
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/bitcoindev/p8AVEmAtWdA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> bitcoindev+...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/ajN9be00Br-O3-9R%40erisian.com.au
> .
>
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2acb0488-6016-4ae3-b459-0bec5bee9d78n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 37776 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Aligning privacy incentives in P2MR
2026-06-18 5:09 ` Anthony Towns
2026-06-19 0:30 ` 'conduition' via Bitcoin Development Mailing List
2026-06-19 0:38 ` 'conduition' via Bitcoin Development Mailing List
@ 2026-06-24 20:24 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-06-24 22:00 ` Anthony Derbidge
2 siblings, 1 reply; 20+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2026-06-24 20:24 UTC (permalink / raw)
To: Anthony Towns; +Cc: Pieter Wuille, conduition, bitcoindev@googlegroups.com
Hi AJ,
> There are three main variations to this, I think:
>
> [...]
>
> Self-reliance: Q-day goes from maybe to definitely faster than consensus
> changes can be coordinated, and the only reason people's funds remain
> safe is that they can (and do) keep the quantum-vulnerable spend
> paths secret.
I think that scenario may only result in a successful migration if the vast
majority of users have updated their workflows to keep said quantum vulnerable
paths secret.
This may only happen if the vast majority of users either:
1. have preemptively updated their workflows during the "maybe" period;
2. react promptly enough (within weeks? a couple months?) to migrate all their wealth.
Option (1) is utterly implausible. As Pieter explained in his email, we can't
expect users to adopt workflows radically at odds with how they use Bitcoin
today in response to a (still --at the time they need to migrate) speculative
threat.
I believe Bitcoin is successful precisely because users are not required to be
active bitcoiners and pay close attention to avoid losing their funds. A
substantial share of users value and rely on this property, and therefore Option
(2) is likewise implausible.
Therefore i don't think the "Self-reliance" variation can result in a successful
migration.
> As far as I can see, only having P2TRv2 addresses would rule out the "self-reliance" path here.
>
> Picking when Q-day will occur, either individually for determining
> your own security posture, or collectively for organising a consensus
> change seems very difficulty: it involves evaluating both complex state
> of the art physics research, but also estimating the covert abilities
> of national governments and the incentives to attack bitcoin prior to
> revealing their capabilities. To me, that doesn't bode well for a smooth
> and fast deployment of a consensus change in advance of problems occuring.
Yes. P2TRv2 optimizes for the "Later dominant" path at the expense of the
"self-reliance" path. I think this is good, because our best (only?) shot at
fully migrating large amounts of users is to provide them with a virtually free
way to opt into a future consensus-triggered migration.
The follow-up step does not require predicting with precision the day on which
an attack would be set up, but to be done before a CRQC could realistically
threaten Bitcoin. Definitely not a piece of cake, but not infeasible. In fact if
P2TRv2 does become the Schelling point for PQ migration, i would be more
concerned about the follow-up step happening too soon rather than too late.
Of course, if a full CRQC is built in secret, with no reliable information about
the progress getting out whatsoever, and subsequently starts attacking Bitcoin
overnight, then this migration strategy would fail. But so would any other
migration strategy!
> It's possible that general carelessness on behalf of users would also
> rule out the effectiveness of a self-reliance approach: if only the most
> conscientious 1% of users make use of P2MR securely, that might secure 10%
> of funds, but having 90% of the bitcoin supply crash probably wouldn't be
> very valuable either.
For what it’s worth, while the supply at risk matters, i think the primary
metric we should optimize for is the share of users at risk. Widespread,
indiscriminate theft would fatally undermine trust in Bitcoin, whereas more
concentrated sweeps (such as that of early, presumed-lost coins) *could* cause
severe price shocks without necessarily destroying confidence in the system
itself.
> > > Theorycrafting for a second here. It's reasonable to conjecture fee
> > > rates will be much higher post-Q-day, and thus P2MR's 32 byte advantage
> > > over P2TRv2 will yield significant savings for end-users in absolute
> > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes becomes
> > > significant (100 sats per spend or more).
>
> I don't think that is the right way to look at. 8vb/input is about
> an additional 14% today (vs a taproot key-path spend), but with the
> post-quantum signatures we have available now that's likely to reduce
> to ~7% (SHRINCS) or ~1% (winternitz).
Yes. Also, our goal here is to mitigate the risk that a CRQC materializes by
providing a path for Bitcoin to survive it. We shouldn't take the risk for a
certainty and shift the goal to designing the best possible PQ-Bitcoin. This can
be done if/when it becomes clearer that CRQCs will become a reality.
> > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
> > perfectly. The expectation should be just that it happens before Q-day,
> > and when it looks inevitable or the fear about that is large enough.
>
> FWIW, I would define "timed perfectly" precisely as "EC disabling
> fork happens before Q-day". Maybe allowing some additional months of
> EC-efficiency would be a win while not taking out too much migration time,
> but for me "perfection" here means "no one who upgraded lost money via
> quantum-related vulnerabilities".
I don't think that's a good definition of "timed perfectly". By your definition,
EC could be disabled from the get-go, Bitcoin's migration would spectacularly
fail because very few users switched to the new output type, and it would still
be "timed perfectly". :)
I would define "timed perfectly" as maximizing the number of migrated users
without any of them losing money to a CRQC. But it's not quite the right
definition, because there is also probably an aspect of not doing it
prematurely, i.e. in the scenario where the CRQC threat never materializes, no
P2TRv2 user is forced to use heavily restrictive PQ worklows.
> Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
> "Later-dominant" scenario, and only to the degree that it's slightly
> cheaper prior to Q-day.
From the perspective that a successful migration hinges on virtually all users
opting into a (full) migration to CRQC-safe workflows, this difference in costs
is material. Especially since users would presumably need to opt in long before
we know whether CRQCs will become a reality anytime soon.
> My (cynical?) view is the only people who will adopt either P2TRv2 or
> P2MR prior to NoEC-day being schedule will be people who are willign
> to use those features in a quantum-safe way -- that is, keeping their
> EC pubkeys secret, and only revealing those EC pubkeys to spend them
> immediately, prior to NoEC-day.
How can this apply to P2TRv2, where EC pubkeys are always public?
I think i disagree that most users of P2MR, were it made available, would treat
their EC public keys as secrets. But more importantly, the whole point of
P2TRv2, or more generally of what Pieter labels "Later" type strategies, is
precisely to avoid imposing on individual users the costs of treating their
public keys as secrets. P2TRv2 (compared to other "Later" options) also ensures
that using it is no more costly than using any other available output type.
Together, these properties may make users who are not yet particularly
concerned, or are simply unaware, indifferent to opting in: they bear the
additional costs only if the CRQC threat materializes and are no worse off if it
does not.
> > This focus on allowing individual users the ability to safeguard their
> > coins just feels like a red herring: [...]
>
> While I appreciate your point, I also feel that "allowing individual
> users the ability to safeguard their coins" is pretty close to the entire
> point of Bitcoin. :)
Cherry-picking this part of Pieter's sentence does not do it justice. Of course
we all agree about this. But as he says in the part you left out, not addressing
this issue as a systemic one is exactly how we lose that property: "I'm not
worried about my own coins being stolen. I'm worried about (fear of) a CRQC
undermining trust in the currency as a whole, or through a fear-driven consensus
change the ecosystem destroying its own values beforehand."
> having a consistent push that every single wallet/service that doesn't deprecate every current
> address type is a danger to the entire ecosystem, even absent widespread agreement on when/if
> Q-day will happen. Arguably that would be easier to agree on if the incremental cost of EC spend
> paths in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to zero, rather than up
> to ~14% per input.
Yes, that's essentially the case for P2TRv2.
Best,
Antoine
On Thursday, June 18th, 2026 at 1:09 AM, Anthony Towns <aj@erisian.com.au> wrote:
> On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote:
> > I want to first correct a potential misunderstanding here, because
> > I realize the terms "Later" and "Never" aren't very descriptive. They
> > are specifically about an expected and relied-upon expectation that an
> > EC-disabling fork will happen that at least applies to the output type
> > itself, in time. "Later" is the expectation that such a disabling will
> > happen after the output type is introduced, but still in time (so, before
> > Q-day). Outputs without a strong expectation that their EC paths/opcodes
> > will be disabled, or not in time, I classify under "Never".
>
> > I believe here you're instead arguing for P2MR ("Merkle-Never")
> > over all "Later" options. That was my previous point: I think (solely)
> > having "Never" output types like P2MR is just utterly insufficient for
> > any worthwhile migration. It's so incompatible with today's workflows
> > that it either won't be adopted, or (possibly inadvertently) adopted
> > in an insecure fashion. Yes, it gives people the option to safeguard
> > their own coins, but to me that's disaster recovery territory - I think
> > we ought to prioritize maximizing the chances for saving the currency
> > as a whole in case Q-day comes, not a small subset of individual users'
> > coins. P2MR (alone) doesn't really achieve much in that regard in my view,
> > thus we at least need something of the "Later" class in addition.
>
> I'm not sure I follow/agree with the logic here. I think the general idea
> is:
>
> 1) we create some new address types that allow post-quantum spending, but
> also allow efficient quantum-vulnerable spending that can be used prior
> to Q-day
>
> 2) many people migrate to these new address types
>
> 3) Q-day arrives
>
> 4) all spending goes via the post-quantum paths, and everyone's funds are
> safe
>
> There are three main variations to this, I think:
>
> Later-dominant: towards the end of (2) but prior to (3), the
> quantum-vulnerable spend paths are disabled in a predictable, planned
> manner, preventing coin theft, but not disrupting active usage
> significantly (or not disrupting it any more than the proximity of
> Q-day already is).
>
> Self-reliance: Q-day goes from maybe to definitely faster than consensus
> changes can be coordinated, and the only reason people's funds remain
> safe is that they can (and do) keep the quantum-vulnerable spend
> paths secret.
>
> Disaster-recovery: neither the "predictable/planned consensus change" of
> Later nor the "everyone takes responsiblity for their own funds"
> works, and the only way to avoid a large percentage of bitcoin
> becoming a reward for quantum research is to replace EC spend paths
> with a ZK proof of knowledge of a BIP32 seed or similar, requiring
> a hard fork. Such a hard fork would be certain to be controversial
> ("why at this height: I received a payment five blocks after //
> my funds were stolen by a quantum attacker five blocks earlier //
> why are only BIP32 funds recoverable not scheme X"), but if no other
> approach works, might still be the ultimately outcome.
>
> > So the point here was just: if you already accept the need for a "Later"
> > output type (= one with builtin-in EC disabling expected from the start),
> > P2TRv2 is preferable over P2MR+ED, because:
>
> As far as I can see, only having P2TRv2 addresses would rule out the
> "self-reliance" path here.
>
> Picking when Q-day will occur, either individually for determining
> your own security posture, or collectively for organising a consensus
> change seems very difficulty: it involves evaluating both complex state
> of the art physics research, but also estimating the covert abilities
> of national governments and the incentives to attack bitcoin prior to
> revealing their capabilities. To me, that doesn't bode well for a smooth
> and fast deployment of a consensus change in advance of problems occuring.
>
> It's possible that general carelessness on behalf of users would also
> rule out the effectiveness of a self-reliance approach: if only the most
> conscientious 1% of users make use of P2MR securely, that might secure 10%
> of funds, but having 90% of the bitcoin supply crash probably wouldn't be
> very valuable either. But even then, that may make the "disaster-recovery"
> approach less problematic, by ensuring the 1%/10% who were conscientious
> can avoid being part of the "my funds were stolen by a quantum attacker"
> contingent, eg.
>
> > > Theorycrafting for a second here. It's reasonable to conjecture fee
> > > rates will be much higher post-Q-day, and thus P2MR's 32 byte advantage
> > > over P2TRv2 will yield significant savings for end-users in absolute
> > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes becomes
> > > significant (100 sats per spend or more).
>
> I don't think that is the right way to look at. 8vb/input is about
> an additional 14% today (vs a taproot key-path spend), but with the
> post-quantum signatures we have available now that's likely to reduce
> to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,
> you're only getting an expected savings in fees / increase in block
> capacity on that order of magnitude, ie: 1%-7%. That's nice to have,
> for sure, but doesn't compare to introducing a new address type that
> puts the PQ sigs in an extension block, or one that uses ZK proofs to
> do cross-input or cross-transaction signature aggregation, eg. So a 32B
> witness overhead for an unused/unusable key-path post-Q-day doesn't seem
> very relevant to me.
>
> > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
> > perfectly. The expectation should be just that it happens before Q-day,
> > and when it looks inevitable or the fear about that is large enough.
>
> FWIW, I would define "timed perfectly" precisely as "EC disabling
> fork happens before Q-day". Maybe allowing some additional months of
> EC-efficiency would be a win while not taking out too much migration time,
> but for me "perfection" here means "no one who upgraded lost money via
> quantum-related vulnerabilities".
>
> One reason I'm doubtful is that I think for some the "it looks inevitable"
> threshold has already been crossed, eg:
>
> >> So let me attempt to partially fill the silence, similarly to what
> >> Scott Aaronson did in his April 29 post. Given everything I know,
> >> including scary non-public information, I now put the odds of qday by
> >> 2032 at 50%. 10% by 2030.
>
> >> IMO a good target date for migration is 2029, roughly 3.5 years
> >> out. 2029 happens to be the date selected by Google, Cloudflare, and
> >> the Ethereum Foundation.
>
> https://x.com/drakefjustin/status/2061793725299224676
>
> >> So, here it is: if quantum computers start breaking cryptography a
> >> few years from now, don’t you dare come to this blog and tell me that
> >> I failed to warn you. This post is your warning. Please start switching
> >> to quantum-resistant encryption, and urge your company or organization
> >> or blockchain or standards body to do the same.
>
> https://scottaaronson.blog/?p=9718
>
> Personally, that leaves me at a minimum very skeptical of the utility
> of introducing either P2MR or P2TRv2 (etc) approaches that don't also
> introduce a quantum-safe spending path on day one.
>
> > First a meta-point here: the reason I like separating the discussion into different dimensions than just "P2TRv2 vs P2MR" is because there are more options than those two, and not every argument applies to the same separation into two classes. Let me list them explicitly here, roughly in decreasing order of how strongly I feel about them:
> > - We need at least a "Later" option for meaningful migration, i.e. P2TRv2 or P2MR+ED.
> > - Within the "Later" option, P2TRv2 is preferable.
> > - A "Later" option benefits from being the only PQC migration strategy, making it a Schelling point.
>
> Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
> "Later-dominant" scenario, and only to the degree that it's slightly
> cheaper prior to Q-day. If it were the only available option, that would
> increase the risk of loss involved with both the other approaches. (I
> don't think P2TRv2 is meaningfully more private than P2MR in the way
> taproot v1 is, as presumably you'd only adopt that address format if
> you wanted to have a post-quantum script path)
>
> > > You'd have to convince everyone to deploy and then adopt P2TRv2 today under the public knowledge that it is insecure and their coins are more likely to be stolen. That's a hard sell.
> >
> > > How does one pitch P2TRv2 to users? "It will be quantum secure one day we promise because everyone is incentivized to fix it later as Bitcoin will die if we don't."
> > >
> > > How do you pitch P2MR? "It's quantum secure if you use it correctly."
> > To me, the pitch is "Bitcoin can only remain valuable if we mostly/all migrate." for both. P2TRv2 is just much easier to adopt, because P2MR (or any "Never" output type) fundamentally requires many users to change their workflows entirely.
>
> Let's call NoEC-day the earlier of activation of a soft-fork disabling
> EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably
> equal to "the day the bitcoin ecosystem has finally agreed that CRQCs
> are inevitable".
>
> My (cynical?) view is the only people who will adopt either P2TRv2 or
> P2MR prior to NoEC-day being schedule will be people who are willign
> to use those features in a quantum-safe way -- that is, keeping their
> EC pubkeys secret, and only revealing those EC pubkeys to spend them
> immediately, prior to NoEC-day. In that view, the EC-spend-paths of such
> coins prior to NoEC-day are only an opportunistic "make spends cheaper"
> shortcut, they don't allow the funds to be used in lightning channels
> or to let your wallet be audited via sharing an xpub or anything similar.
>
> Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible
> that lightning software could get an upgrade to generate post-quantum
> signatures for channel commitments or HTLC claims, I just think it's
> pretty unlikely that that will happen at a meaningful scale when everyone
> has much more immediate and less theoretical things to work on prior to
> NoEC-day, especially when the efficiency/performance of such changes is
> likely to be very low.
>
> > This focus on allowing individual users the ability to safeguard their
> > coins just feels like a red herring: [...]
>
> While I appreciate your point, I also feel that "allowing individual
> users the ability to safeguard their coins" is pretty close to the entire
> point of Bitcoin. :)
>
> > In either case, I consider anything that requires hardcoding
> > specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus
> > rules (and only allowing those coins to survive) to be squarely in
> > disaster-recovery land. It feels like embracing arbitrariness, and
> > giving up on the permissionlessness that makes Bitcoin interesting -
> > if the community shows it can get consensus on effectively burning
> > coins except those that match a whitelist, it feels hard to maintain
> > censorship-freeness as a value, even if the whitelist includes most of
> > the (active) coins. That is of course not to say such techniques aren't
> > interesting to work on, but to me, their place is in disaster recovery
> > scenarios to save what's left, after Q-day, if migration attempts were
> > unsuccessful. In such a setting, I think we're already in effectively an
> > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly
> > growing) set of ways to recover burned coins can be hardforked in.
>
> Just for the record, I think the above is an accurate description of the
> "disaster-recovery" scenario above: the "quantum-safe" hard-fork variant
> of bitcoin would be fairly described as a utxo-bootstrapped altcoin,
> would compete in the market with the "quantum-unsafe" bitcoin that
> existing nodes would continue to follow, and possibly there would be
> many slightly varying such altcoins competing with each other, eg on
> exactly what height the utxo snapshot was taken or what coins become
> spendable. It would not be a fun time for holders of affected utxos.
>
> > My impression is that your approach is to have an answer for many
> > possible futures, including ones where Q-day arrives within just a few
> > years.
>
> "The key of strategy... is not to choose a path to victory, but to choose
> so that all paths lead to a victory."
>
> -- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit
>
> > But optimizing for disaster-recovery also means reducing the
> > chances of preserving Bitcoin as we know it in the scenarios where a
> > successful migration is still possible. And if Q-day does arrive that
> > soon, I don't see what we can do today that would preserve Bitcoin in
> > a form we care about anyway. By accepting that, we can focus on the
> > futures where our choices today can still materially improve the outcome.
>
> Preserving bitcoin as a personally-possessible inflation resistant
> store of value seems both possible and worth caring about, even if other
> constraints means that many people can't afford to personally hold it
> (and have to go through ETFs/exchanges/banks) and that it can't be used
> for day-to-day transactions. Would be very disappointing if true, and
> even given Q-day in a few years I expect we could do better than just
> that, but it doesn't feel like a throw-in-the-towel event to me.
>
> > > Essentially yes though, I expect the majority of holders will probably
> > > migrate to PQ addresses via rescue protocols, either on Bitcoin or a fork
> > > thereof. Even if we can't come to consensus and deploy a new output type,
> > > we'll still be able to rescue most coins. It's just that we'd have nowhere
> > > to rescue them to, so we ought to make PQ wallets available soon, so we're
> > > not in a rush to build them later when we need them. If a PQ wallet can
> > > use cheap EC signatures while they're still trustworthy, all the better
>
> FWIW, that's my guess on how things would play out if the near-term Q-day
> timelines I've seen (ie, 2029 to 2035) match reality. I hope that's
> pessimistic (either because the Q-day timelines are bad estimates, or
> because migration happens in a more orderly fashion), but I guess we'll
> see. I don't rate my ability to evaluate Q-day predictions very highly.
>
> > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
>
> I'm not in a position to judge, but the google paper claims:
>
> "Indeed, if a leading quantum architecture encounters and overcomes
> all its scaling challenges before producing a device able to
> solve (for example) 32-bit ECDLP, then there may be little time
> between the breaking of 32-bit ECDLP and the breaking of 256-bit
> ECDLP. Furthermore, the community should not expect to see published
> demonstrations of the most advanced quantum error-correction
> architectures and quantum algorithms deployed to cryptanalytic
> problems. Thus, a successful public demonstration of Shor’s
> algorithm on a 32-bit elliptic curve should not be seen as a wake-up
> call to adopt PQC as much as a potential signal that PQC adoption
> has already failed."
>
> and places the required tiffoli gates and logical qubits for a 32-bit
> break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100)
> for 256-bit.
>
> > Of course, if you believe it's the only possible future, I understand
> > you'd come to a different conclusion. But is it really? Do you think
> > this isn't a plausible future:
>
> > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too) gets introduced in the next few years, with hash-based PQC opcodes.
> > - Over the course of the next decade or so, it gets adopted by practically all active users.
>
> I think it might be better to look at that scenario in a more fine-grained
> way? I think your "Late-ish" scenario is:
>
> 1) P2TRv2 (or whatever) is introduced
> 2) Some PQ opcodes get enabled, allowing expensive but PQ-safe spend-paths
> via those outputs
> 3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of P2TRv2,
> but EC spend paths continue to be what's used in practice.
> 4) Some better PQ solutions become available, allowing cheap PQ-safe spend-paths
> 5) Everyone switches from EC paths to the new PQ paths.
> 6) NoEC-day happens, but no one is impacted.
>
> I think your "Soon-ish" scenario differs as of step (4):
>
> 4) NoEC-day happens. Massive disruption because the "what's used in practice"
> path breaks, but everything is recoverable.
> 5) Post-quantum approaches get even higher priority
>
> I'm skeptical of step 3 here; and would expect to see something more like:
>
> 3') Only a small proportion of users (ie, the most conscientious/fearful)
> switch to P2TRv2 with most preferring to stick with what works
>
> That has no real impact on the Late-ish scenario, but changes the Soon-ish
> scenario to either:
>
> 4'a) NoEC-day happens substantially before Q-day; people hurry to migrate
> to P2TRv2, but it mostly works.
>
> or
>
> 4'b) NoEC-day happens essentially at the same time as Q-day; coins get
> stolen and we hit the disaster-recovery scenario.
>
> Perhaps the difference between (3') and (3) playing out in reality
> is just having nearly everyone agree that the upgrade is essential,
> and rather than leaving it to self-interest/market-dynamics, having a
> consistent push that every single wallet/service that doesn't deprecate
> every current address type is a danger to the entire ecosystem, even
> absent widespread agreement on when/if Q-day will happen. Arguably that
> would be easier to agree on if the incremental cost of EC spend paths
> in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to
> zero, rather than up to ~14% per input.
>
> Cheers,
> aj
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/SHKHzyvg1Rr2E-CBLdgNEinhsndgXog0v4YxlDBJAYVcwjCEnBdByD-3_PSCZzkf9nHeisOKHSqjsBrTgumAVwsZPHHnwrx7FcpZeVZiups%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [bitcoindev] Aligning privacy incentives in P2MR
2026-06-24 20:24 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
@ 2026-06-24 22:00 ` Anthony Derbidge
2026-06-25 15:24 ` Alex
2026-06-26 9:27 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
0 siblings, 2 replies; 20+ messages in thread
From: Anthony Derbidge @ 2026-06-24 22:00 UTC (permalink / raw)
To: Antoine Poinsot
Cc: Anthony Towns, Pieter Wuille, conduition,
bitcoindev@googlegroups.com
[-- Attachment #1: Type: text/plain, Size: 30487 bytes --]
I agree with the core point that Bitcoin’s post-quantum transition cannot
rely primarily on self-reliance. If the migration requires most users to
understand Q-Day timing, keep EC spend paths secret, or react quickly under
pressure, then it is unlikely to protect Bitcoin as a system. The safer
path needs to be low-friction and close to the default experience long
before the threat becomes urgent.
That is why a "Later" style strategy seems compelling: ordinary users can
opt into a future migration path without immediately adopting restrictive
post-quantum workflows, while consensus can still act when the risk becomes
concrete. Bitcoin mainnet should remain simple and conservative, while more
complex identity, recovery, coordination, and enhanced post-quantum
workflows can exist in optional Bitcoin-aligned layers rather than the base
layer.
Systems such as Lightning and ProofnetBTC can experiment with those
optional workflows and recovery models while continuing to settle to Bitcoin,
allowing innovation without requiring the Bitcoin mainnet itself to absorb
that additional complexity.
Best,
Anthony D.
On Wed, Jun 24, 2026 at 3:50 PM 'Antoine Poinsot' via Bitcoin Development
Mailing List <bitcoindev@googlegroups.com> wrote:
> Hi AJ,
>
> > There are three main variations to this, I think:
> >
> > [...]
> >
> > Self-reliance: Q-day goes from maybe to definitely faster than consensus
> > changes can be coordinated, and the only reason people's funds remain
> > safe is that they can (and do) keep the quantum-vulnerable spend
> > paths secret.
>
> I think that scenario may only result in a successful migration if the vast
> majority of users have updated their workflows to keep said quantum
> vulnerable
> paths secret.
>
> This may only happen if the vast majority of users either:
> 1. have preemptively updated their workflows during the "maybe" period;
> 2. react promptly enough (within weeks? a couple months?) to migrate all
> their wealth.
>
> Option (1) is utterly implausible. As Pieter explained in his email, we
> can't
> expect users to adopt workflows radically at odds with how they use Bitcoin
> today in response to a (still --at the time they need to migrate)
> speculative
> threat.
>
> I believe Bitcoin is successful precisely because users are not required
> to be
> active bitcoiners and pay close attention to avoid losing their funds. A
> substantial share of users value and rely on this property, and therefore
> Option
> (2) is likewise implausible.
>
> Therefore i don't think the "Self-reliance" variation can result in a
> successful
> migration.
>
> > As far as I can see, only having P2TRv2 addresses would rule out the
> "self-reliance" path here.
> >
> > Picking when Q-day will occur, either individually for determining
> > your own security posture, or collectively for organising a consensus
> > change seems very difficulty: it involves evaluating both complex state
> > of the art physics research, but also estimating the covert abilities
> > of national governments and the incentives to attack bitcoin prior to
> > revealing their capabilities. To me, that doesn't bode well for a smooth
> > and fast deployment of a consensus change in advance of problems
> occuring.
>
> Yes. P2TRv2 optimizes for the "Later dominant" path at the expense of the
> "self-reliance" path. I think this is good, because our best (only?) shot
> at
> fully migrating large amounts of users is to provide them with a virtually
> free
> way to opt into a future consensus-triggered migration.
>
> The follow-up step does not require predicting with precision the day on
> which
> an attack would be set up, but to be done before a CRQC could realistically
> threaten Bitcoin. Definitely not a piece of cake, but not infeasible. In
> fact if
> P2TRv2 does become the Schelling point for PQ migration, i would be more
> concerned about the follow-up step happening too soon rather than too late.
>
> Of course, if a full CRQC is built in secret, with no reliable information
> about
> the progress getting out whatsoever, and subsequently starts attacking
> Bitcoin
> overnight, then this migration strategy would fail. But so would any other
> migration strategy!
>
> > It's possible that general carelessness on behalf of users would also
> > rule out the effectiveness of a self-reliance approach: if only the most
> > conscientious 1% of users make use of P2MR securely, that might secure
> 10%
> > of funds, but having 90% of the bitcoin supply crash probably wouldn't be
> > very valuable either.
>
> For what it’s worth, while the supply at risk matters, i think the primary
> metric we should optimize for is the share of users at risk. Widespread,
> indiscriminate theft would fatally undermine trust in Bitcoin, whereas more
> concentrated sweeps (such as that of early, presumed-lost coins) *could*
> cause
> severe price shocks without necessarily destroying confidence in the system
> itself.
>
> > > > Theorycrafting for a second here. It's reasonable to conjecture fee
> > > > rates will be much higher post-Q-day, and thus P2MR's 32 byte
> advantage
> > > > over P2TRv2 will yield significant savings for end-users in absolute
> > > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes
> becomes
> > > > significant (100 sats per spend or more).
> >
> > I don't think that is the right way to look at. 8vb/input is about
> > an additional 14% today (vs a taproot key-path spend), but with the
> > post-quantum signatures we have available now that's likely to reduce
> > to ~7% (SHRINCS) or ~1% (winternitz).
>
> Yes. Also, our goal here is to mitigate the risk that a CRQC materializes
> by
> providing a path for Bitcoin to survive it. We shouldn't take the risk for
> a
> certainty and shift the goal to designing the best possible PQ-Bitcoin.
> This can
> be done if/when it becomes clearer that CRQCs will become a reality.
>
> > > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
> > > perfectly. The expectation should be just that it happens before Q-day,
> > > and when it looks inevitable or the fear about that is large enough.
> >
> > FWIW, I would define "timed perfectly" precisely as "EC disabling
> > fork happens before Q-day". Maybe allowing some additional months of
> > EC-efficiency would be a win while not taking out too much migration
> time,
> > but for me "perfection" here means "no one who upgraded lost money via
> > quantum-related vulnerabilities".
>
> I don't think that's a good definition of "timed perfectly". By your
> definition,
> EC could be disabled from the get-go, Bitcoin's migration would
> spectacularly
> fail because very few users switched to the new output type, and it would
> still
> be "timed perfectly". :)
>
> I would define "timed perfectly" as maximizing the number of migrated users
> without any of them losing money to a CRQC. But it's not quite the right
> definition, because there is also probably an aspect of not doing it
> prematurely, i.e. in the scenario where the CRQC threat never
> materializes, no
> P2TRv2 user is forced to use heavily restrictive PQ worklows.
>
> > Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
> > "Later-dominant" scenario, and only to the degree that it's slightly
> > cheaper prior to Q-day.
>
> From the perspective that a successful migration hinges on virtually all
> users
> opting into a (full) migration to CRQC-safe workflows, this difference in
> costs
> is material. Especially since users would presumably need to opt in long
> before
> we know whether CRQCs will become a reality anytime soon.
>
> > My (cynical?) view is the only people who will adopt either P2TRv2 or
> > P2MR prior to NoEC-day being schedule will be people who are willign
> > to use those features in a quantum-safe way -- that is, keeping their
> > EC pubkeys secret, and only revealing those EC pubkeys to spend them
> > immediately, prior to NoEC-day.
>
> How can this apply to P2TRv2, where EC pubkeys are always public?
>
> I think i disagree that most users of P2MR, were it made available, would
> treat
> their EC public keys as secrets. But more importantly, the whole point of
> P2TRv2, or more generally of what Pieter labels "Later" type strategies, is
> precisely to avoid imposing on individual users the costs of treating their
> public keys as secrets. P2TRv2 (compared to other "Later" options) also
> ensures
> that using it is no more costly than using any other available output type.
> Together, these properties may make users who are not yet particularly
> concerned, or are simply unaware, indifferent to opting in: they bear the
> additional costs only if the CRQC threat materializes and are no worse off
> if it
> does not.
>
> > > This focus on allowing individual users the ability to safeguard their
> > > coins just feels like a red herring: [...]
> >
> > While I appreciate your point, I also feel that "allowing individual
> > users the ability to safeguard their coins" is pretty close to the entire
> > point of Bitcoin. :)
>
> Cherry-picking this part of Pieter's sentence does not do it justice. Of
> course
> we all agree about this. But as he says in the part you left out, not
> addressing
> this issue as a systemic one is exactly how we lose that property: "I'm not
> worried about my own coins being stolen. I'm worried about (fear of) a CRQC
> undermining trust in the currency as a whole, or through a fear-driven
> consensus
> change the ecosystem destroying its own values beforehand."
>
> > having a consistent push that every single wallet/service that doesn't
> deprecate every current
> > address type is a danger to the entire ecosystem, even absent widespread
> agreement on when/if
> > Q-day will happen. Arguably that would be easier to agree on if the
> incremental cost of EC spend
> > paths in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is
> near to zero, rather than up
> > to ~14% per input.
>
> Yes, that's essentially the case for P2TRv2.
>
> Best,
> Antoine
>
>
>
> On Thursday, June 18th, 2026 at 1:09 AM, Anthony Towns <aj@erisian.com.au>
> wrote:
>
> > On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote:
> > > I want to first correct a potential misunderstanding here, because
> > > I realize the terms "Later" and "Never" aren't very descriptive. They
> > > are specifically about an expected and relied-upon expectation that an
> > > EC-disabling fork will happen that at least applies to the output type
> > > itself, in time. "Later" is the expectation that such a disabling will
> > > happen after the output type is introduced, but still in time (so,
> before
> > > Q-day). Outputs without a strong expectation that their EC
> paths/opcodes
> > > will be disabled, or not in time, I classify under "Never".
> >
> > > I believe here you're instead arguing for P2MR ("Merkle-Never")
> > > over all "Later" options. That was my previous point: I think (solely)
> > > having "Never" output types like P2MR is just utterly insufficient for
> > > any worthwhile migration. It's so incompatible with today's workflows
> > > that it either won't be adopted, or (possibly inadvertently) adopted
> > > in an insecure fashion. Yes, it gives people the option to safeguard
> > > their own coins, but to me that's disaster recovery territory - I think
> > > we ought to prioritize maximizing the chances for saving the currency
> > > as a whole in case Q-day comes, not a small subset of individual users'
> > > coins. P2MR (alone) doesn't really achieve much in that regard in my
> view,
> > > thus we at least need something of the "Later" class in addition.
> >
> > I'm not sure I follow/agree with the logic here. I think the general idea
> > is:
> >
> > 1) we create some new address types that allow post-quantum spending,
> but
> > also allow efficient quantum-vulnerable spending that can be used
> prior
> > to Q-day
> >
> > 2) many people migrate to these new address types
> >
> > 3) Q-day arrives
> >
> > 4) all spending goes via the post-quantum paths, and everyone's funds
> are
> > safe
> >
> > There are three main variations to this, I think:
> >
> > Later-dominant: towards the end of (2) but prior to (3), the
> > quantum-vulnerable spend paths are disabled in a predictable, planned
> > manner, preventing coin theft, but not disrupting active usage
> > significantly (or not disrupting it any more than the proximity of
> > Q-day already is).
> >
> > Self-reliance: Q-day goes from maybe to definitely faster than consensus
> > changes can be coordinated, and the only reason people's funds remain
> > safe is that they can (and do) keep the quantum-vulnerable spend
> > paths secret.
> >
> > Disaster-recovery: neither the "predictable/planned consensus change" of
> > Later nor the "everyone takes responsiblity for their own funds"
> > works, and the only way to avoid a large percentage of bitcoin
> > becoming a reward for quantum research is to replace EC spend paths
> > with a ZK proof of knowledge of a BIP32 seed or similar, requiring
> > a hard fork. Such a hard fork would be certain to be controversial
> > ("why at this height: I received a payment five blocks after //
> > my funds were stolen by a quantum attacker five blocks earlier //
> > why are only BIP32 funds recoverable not scheme X"), but if no other
> > approach works, might still be the ultimately outcome.
> >
> > > So the point here was just: if you already accept the need for a
> "Later"
> > > output type (= one with builtin-in EC disabling expected from the
> start),
> > > P2TRv2 is preferable over P2MR+ED, because:
> >
> > As far as I can see, only having P2TRv2 addresses would rule out the
> > "self-reliance" path here.
> >
> > Picking when Q-day will occur, either individually for determining
> > your own security posture, or collectively for organising a consensus
> > change seems very difficulty: it involves evaluating both complex state
> > of the art physics research, but also estimating the covert abilities
> > of national governments and the incentives to attack bitcoin prior to
> > revealing their capabilities. To me, that doesn't bode well for a smooth
> > and fast deployment of a consensus change in advance of problems
> occuring.
> >
> > It's possible that general carelessness on behalf of users would also
> > rule out the effectiveness of a self-reliance approach: if only the most
> > conscientious 1% of users make use of P2MR securely, that might secure
> 10%
> > of funds, but having 90% of the bitcoin supply crash probably wouldn't be
> > very valuable either. But even then, that may make the
> "disaster-recovery"
> > approach less problematic, by ensuring the 1%/10% who were conscientious
> > can avoid being part of the "my funds were stolen by a quantum attacker"
> > contingent, eg.
> >
> > > > Theorycrafting for a second here. It's reasonable to conjecture fee
> > > > rates will be much higher post-Q-day, and thus P2MR's 32 byte
> advantage
> > > > over P2TRv2 will yield significant savings for end-users in absolute
> > > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes
> becomes
> > > > significant (100 sats per spend or more).
> >
> > I don't think that is the right way to look at. 8vb/input is about
> > an additional 14% today (vs a taproot key-path spend), but with the
> > post-quantum signatures we have available now that's likely to reduce
> > to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,
> > you're only getting an expected savings in fees / increase in block
> > capacity on that order of magnitude, ie: 1%-7%. That's nice to have,
> > for sure, but doesn't compare to introducing a new address type that
> > puts the PQ sigs in an extension block, or one that uses ZK proofs to
> > do cross-input or cross-transaction signature aggregation, eg. So a 32B
> > witness overhead for an unused/unusable key-path post-Q-day doesn't seem
> > very relevant to me.
> >
> > > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
> > > perfectly. The expectation should be just that it happens before Q-day,
> > > and when it looks inevitable or the fear about that is large enough.
> >
> > FWIW, I would define "timed perfectly" precisely as "EC disabling
> > fork happens before Q-day". Maybe allowing some additional months of
> > EC-efficiency would be a win while not taking out too much migration
> time,
> > but for me "perfection" here means "no one who upgraded lost money via
> > quantum-related vulnerabilities".
> >
> > One reason I'm doubtful is that I think for some the "it looks
> inevitable"
> > threshold has already been crossed, eg:
> >
> > >> So let me attempt to partially fill the silence, similarly to what
> > >> Scott Aaronson did in his April 29 post. Given everything I know,
> > >> including scary non-public information, I now put the odds of qday by
> > >> 2032 at 50%. 10% by 2030.
> >
> > >> IMO a good target date for migration is 2029, roughly 3.5 years
> > >> out. 2029 happens to be the date selected by Google, Cloudflare, and
> > >> the Ethereum Foundation.
> >
> > https://x.com/drakefjustin/status/2061793725299224676
> >
> > >> So, here it is: if quantum computers start breaking cryptography a
> > >> few years from now, don’t you dare come to this blog and tell me that
> > >> I failed to warn you. This post is your warning. Please start
> switching
> > >> to quantum-resistant encryption, and urge your company or organization
> > >> or blockchain or standards body to do the same.
> >
> > https://scottaaronson.blog/?p=9718
> >
> > Personally, that leaves me at a minimum very skeptical of the utility
> > of introducing either P2MR or P2TRv2 (etc) approaches that don't also
> > introduce a quantum-safe spending path on day one.
> >
> > > First a meta-point here: the reason I like separating the discussion
> into different dimensions than just "P2TRv2 vs P2MR" is because there are
> more options than those two, and not every argument applies to the same
> separation into two classes. Let me list them explicitly here, roughly in
> decreasing order of how strongly I feel about them:
> > > - We need at least a "Later" option for meaningful migration, i.e.
> P2TRv2 or P2MR+ED.
> > > - Within the "Later" option, P2TRv2 is preferable.
> > > - A "Later" option benefits from being the only PQC migration
> strategy, making it a Schelling point.
> >
> > Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
> > "Later-dominant" scenario, and only to the degree that it's slightly
> > cheaper prior to Q-day. If it were the only available option, that would
> > increase the risk of loss involved with both the other approaches. (I
> > don't think P2TRv2 is meaningfully more private than P2MR in the way
> > taproot v1 is, as presumably you'd only adopt that address format if
> > you wanted to have a post-quantum script path)
> >
> > > > You'd have to convince everyone to deploy and then adopt P2TRv2
> today under the public knowledge that it is insecure and their coins are
> more likely to be stolen. That's a hard sell.
> > >
> > > > How does one pitch P2TRv2 to users? "It will be quantum secure one
> day we promise because everyone is incentivized to fix it later as Bitcoin
> will die if we don't."
> > > >
> > > > How do you pitch P2MR? "It's quantum secure if you use it correctly."
> > > To me, the pitch is "Bitcoin can only remain valuable if we mostly/all
> migrate." for both. P2TRv2 is just much easier to adopt, because P2MR (or
> any "Never" output type) fundamentally requires many users to change their
> workflows entirely.
> >
> > Let's call NoEC-day the earlier of activation of a soft-fork disabling
> > EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably
> > equal to "the day the bitcoin ecosystem has finally agreed that CRQCs
> > are inevitable".
> >
> > My (cynical?) view is the only people who will adopt either P2TRv2 or
> > P2MR prior to NoEC-day being schedule will be people who are willign
> > to use those features in a quantum-safe way -- that is, keeping their
> > EC pubkeys secret, and only revealing those EC pubkeys to spend them
> > immediately, prior to NoEC-day. In that view, the EC-spend-paths of such
> > coins prior to NoEC-day are only an opportunistic "make spends cheaper"
> > shortcut, they don't allow the funds to be used in lightning channels
> > or to let your wallet be audited via sharing an xpub or anything similar.
> >
> > Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible
> > that lightning software could get an upgrade to generate post-quantum
> > signatures for channel commitments or HTLC claims, I just think it's
> > pretty unlikely that that will happen at a meaningful scale when everyone
> > has much more immediate and less theoretical things to work on prior to
> > NoEC-day, especially when the efficiency/performance of such changes is
> > likely to be very low.
> >
> > > This focus on allowing individual users the ability to safeguard their
> > > coins just feels like a red herring: [...]
> >
> > While I appreciate your point, I also feel that "allowing individual
> > users the ability to safeguard their coins" is pretty close to the entire
> > point of Bitcoin. :)
> >
> > > In either case, I consider anything that requires hardcoding
> > > specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus
> > > rules (and only allowing those coins to survive) to be squarely in
> > > disaster-recovery land. It feels like embracing arbitrariness, and
> > > giving up on the permissionlessness that makes Bitcoin interesting -
> > > if the community shows it can get consensus on effectively burning
> > > coins except those that match a whitelist, it feels hard to maintain
> > > censorship-freeness as a value, even if the whitelist includes most of
> > > the (active) coins. That is of course not to say such techniques aren't
> > > interesting to work on, but to me, their place is in disaster recovery
> > > scenarios to save what's left, after Q-day, if migration attempts were
> > > unsuccessful. In such a setting, I think we're already in effectively
> an
> > > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly
> > > growing) set of ways to recover burned coins can be hardforked in.
> >
> > Just for the record, I think the above is an accurate description of the
> > "disaster-recovery" scenario above: the "quantum-safe" hard-fork variant
> > of bitcoin would be fairly described as a utxo-bootstrapped altcoin,
> > would compete in the market with the "quantum-unsafe" bitcoin that
> > existing nodes would continue to follow, and possibly there would be
> > many slightly varying such altcoins competing with each other, eg on
> > exactly what height the utxo snapshot was taken or what coins become
> > spendable. It would not be a fun time for holders of affected utxos.
> >
> > > My impression is that your approach is to have an answer for many
> > > possible futures, including ones where Q-day arrives within just a few
> > > years.
> >
> > "The key of strategy... is not to choose a path to victory, but to choose
> > so that all paths lead to a victory."
> >
> > -- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit
> >
> > > But optimizing for disaster-recovery also means reducing the
> > > chances of preserving Bitcoin as we know it in the scenarios where a
> > > successful migration is still possible. And if Q-day does arrive that
> > > soon, I don't see what we can do today that would preserve Bitcoin in
> > > a form we care about anyway. By accepting that, we can focus on the
> > > futures where our choices today can still materially improve the
> outcome.
> >
> > Preserving bitcoin as a personally-possessible inflation resistant
> > store of value seems both possible and worth caring about, even if other
> > constraints means that many people can't afford to personally hold it
> > (and have to go through ETFs/exchanges/banks) and that it can't be used
> > for day-to-day transactions. Would be very disappointing if true, and
> > even given Q-day in a few years I expect we could do better than just
> > that, but it doesn't feel like a throw-in-the-towel event to me.
> >
> > > > Essentially yes though, I expect the majority of holders will
> probably
> > > > migrate to PQ addresses via rescue protocols, either on Bitcoin or a
> fork
> > > > thereof. Even if we can't come to consensus and deploy a new output
> type,
> > > > we'll still be able to rescue most coins. It's just that we'd have
> nowhere
> > > > to rescue them to, so we ought to make PQ wallets available soon, so
> we're
> > > > not in a rush to build them later when we need them. If a PQ wallet
> can
> > > > use cheap EC signatures while they're still trustworthy, all the
> better
> >
> > FWIW, that's my guess on how things would play out if the near-term Q-day
> > timelines I've seen (ie, 2029 to 2035) match reality. I hope that's
> > pessimistic (either because the Q-day timelines are bad estimates, or
> > because migration happens in a more orderly fashion), but I guess we'll
> > see. I don't rate my ability to evaluate Q-day predictions very highly.
> >
> > > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
> >
> > I'm not in a position to judge, but the google paper claims:
> >
> > "Indeed, if a leading quantum architecture encounters and overcomes
> > all its scaling challenges before producing a device able to
> > solve (for example) 32-bit ECDLP, then there may be little time
> > between the breaking of 32-bit ECDLP and the breaking of 256-bit
> > ECDLP. Furthermore, the community should not expect to see published
> > demonstrations of the most advanced quantum error-correction
> > architectures and quantum algorithms deployed to cryptanalytic
> > problems. Thus, a successful public demonstration of Shor’s
> > algorithm on a 32-bit elliptic curve should not be seen as a wake-up
> > call to adopt PQC as much as a potential signal that PQC adoption
> > has already failed."
> >
> > and places the required tiffoli gates and logical qubits for a 32-bit
> > break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100)
> > for 256-bit.
> >
> > > Of course, if you believe it's the only possible future, I understand
> > > you'd come to a different conclusion. But is it really? Do you think
> > > this isn't a plausible future:
> >
> > > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added
> too) gets introduced in the next few years, with hash-based PQC opcodes.
> > > - Over the course of the next decade or so, it gets adopted by
> practically all active users.
> >
> > I think it might be better to look at that scenario in a more
> fine-grained
> > way? I think your "Late-ish" scenario is:
> >
> > 1) P2TRv2 (or whatever) is introduced
> > 2) Some PQ opcodes get enabled, allowing expensive but PQ-safe
> spend-paths
> > via those outputs
> > 3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of
> P2TRv2,
> > but EC spend paths continue to be what's used in practice.
> > 4) Some better PQ solutions become available, allowing cheap PQ-safe
> spend-paths
> > 5) Everyone switches from EC paths to the new PQ paths.
> > 6) NoEC-day happens, but no one is impacted.
> >
> > I think your "Soon-ish" scenario differs as of step (4):
> >
> > 4) NoEC-day happens. Massive disruption because the "what's used in
> practice"
> > path breaks, but everything is recoverable.
> > 5) Post-quantum approaches get even higher priority
> >
> > I'm skeptical of step 3 here; and would expect to see something more
> like:
> >
> > 3') Only a small proportion of users (ie, the most
> conscientious/fearful)
> > switch to P2TRv2 with most preferring to stick with what works
> >
> > That has no real impact on the Late-ish scenario, but changes the
> Soon-ish
> > scenario to either:
> >
> > 4'a) NoEC-day happens substantially before Q-day; people hurry to
> migrate
> > to P2TRv2, but it mostly works.
> >
> > or
> >
> > 4'b) NoEC-day happens essentially at the same time as Q-day; coins get
> > stolen and we hit the disaster-recovery scenario.
> >
> > Perhaps the difference between (3') and (3) playing out in reality
> > is just having nearly everyone agree that the upgrade is essential,
> > and rather than leaving it to self-interest/market-dynamics, having a
> > consistent push that every single wallet/service that doesn't deprecate
> > every current address type is a danger to the entire ecosystem, even
> > absent widespread agreement on when/if Q-day will happen. Arguably that
> > would be easier to agree on if the incremental cost of EC spend paths
> > in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to
> > zero, rather than up to ~14% per input.
> >
> > Cheers,
> > aj
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/SHKHzyvg1Rr2E-CBLdgNEinhsndgXog0v4YxlDBJAYVcwjCEnBdByD-3_PSCZzkf9nHeisOKHSqjsBrTgumAVwsZPHHnwrx7FcpZeVZiups%3D%40protonmail.com
> .
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACja%3DNz%3DA2wV68MMBYcgOMDjwcXpKNQsptdP2NVqXske%3DONG6w%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 35250 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [bitcoindev] Aligning privacy incentives in P2MR
2026-06-24 22:00 ` Anthony Derbidge
@ 2026-06-25 15:24 ` Alex
2026-06-26 9:27 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
1 sibling, 0 replies; 20+ messages in thread
From: Alex @ 2026-06-25 15:24 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 32801 bytes --]
> Systems such as Lightning and ProofnetBTC
Plugging your own L2 is not going to change the fact Bitcoin will need PQC
to even allow those L2s to settle securely. Everything else is make belief.
> allowing innovation without requiring the Bitcoin mainnet itself to
absorb that additional complexity
You're essentially sweeping the problem under the rug without actually
solving it, it's just a word salad that doesn't add up logically. Bitcoin
(the L1) will absolutely need PQC otherwise whatever you build on top has
no better security than what we began with, even if those L2s have <hyper
secure PQC>, if they settle in Bitcoin they are no more secure than Bitcoin
itself.
The complexity introduced into Bitcoin will grow as we drag our feet:
1. If Bitcoin gets hash based PQC before Q-day, very little complexity and
security assumptions are added. These are 1970s kind of algos that build on
existing hashes in Bitcoin.
2. If Bitcoin does not get any PQC before Q-day, then we need to introduce
severely more complex and prone to bugs (see Zcash recent break) ZK-STARK
Circuits which are orders of magnitude more complex than a simple hash
based signature algo.
The more we reject the QC problem, the bigger in complexity the solutions
will have to be.
torsdag 25 juni 2026 kl. 00:35:38 UTC+2 skrev Anthony Derbidge:
> I agree with the core point that Bitcoin’s post-quantum transition cannot
> rely primarily on self-reliance. If the migration requires most users to
> understand Q-Day timing, keep EC spend paths secret, or react quickly under
> pressure, then it is unlikely to protect Bitcoin as a system. The safer
> path needs to be low-friction and close to the default experience long
> before the threat becomes urgent.
>
> That is why a "Later" style strategy seems compelling: ordinary users can
> opt into a future migration path without immediately adopting restrictive
> post-quantum workflows, while consensus can still act when the risk becomes
> concrete. Bitcoin mainnet should remain simple and conservative, while more
> complex identity, recovery, coordination, and enhanced post-quantum
> workflows can exist in optional Bitcoin-aligned layers rather than the base
> layer.
>
> Systems such as Lightning and ProofnetBTC can experiment with those
> optional workflows and recovery models while continuing to settle to
> Bitcoin, allowing innovation without requiring the Bitcoin mainnet itself
> to absorb that additional complexity.
>
> Best,
> Anthony D.
>
> On Wed, Jun 24, 2026 at 3:50 PM 'Antoine Poinsot' via Bitcoin Development
> Mailing List <bitco...@googlegroups.com> wrote:
>
>> Hi AJ,
>>
>> > There are three main variations to this, I think:
>> >
>> > [...]
>> >
>> > Self-reliance: Q-day goes from maybe to definitely faster than consensus
>> > changes can be coordinated, and the only reason people's funds remain
>> > safe is that they can (and do) keep the quantum-vulnerable spend
>> > paths secret.
>>
>> I think that scenario may only result in a successful migration if the
>> vast
>> majority of users have updated their workflows to keep said quantum
>> vulnerable
>> paths secret.
>>
>> This may only happen if the vast majority of users either:
>> 1. have preemptively updated their workflows during the "maybe" period;
>> 2. react promptly enough (within weeks? a couple months?) to migrate all
>> their wealth.
>>
>> Option (1) is utterly implausible. As Pieter explained in his email, we
>> can't
>> expect users to adopt workflows radically at odds with how they use
>> Bitcoin
>> today in response to a (still --at the time they need to migrate)
>> speculative
>> threat.
>>
>> I believe Bitcoin is successful precisely because users are not required
>> to be
>> active bitcoiners and pay close attention to avoid losing their funds. A
>> substantial share of users value and rely on this property, and therefore
>> Option
>> (2) is likewise implausible.
>>
>> Therefore i don't think the "Self-reliance" variation can result in a
>> successful
>> migration.
>>
>> > As far as I can see, only having P2TRv2 addresses would rule out the
>> "self-reliance" path here.
>> >
>> > Picking when Q-day will occur, either individually for determining
>> > your own security posture, or collectively for organising a consensus
>> > change seems very difficulty: it involves evaluating both complex state
>> > of the art physics research, but also estimating the covert abilities
>> > of national governments and the incentives to attack bitcoin prior to
>> > revealing their capabilities. To me, that doesn't bode well for a smooth
>> > and fast deployment of a consensus change in advance of problems
>> occuring.
>>
>> Yes. P2TRv2 optimizes for the "Later dominant" path at the expense of the
>> "self-reliance" path. I think this is good, because our best (only?) shot
>> at
>> fully migrating large amounts of users is to provide them with a
>> virtually free
>> way to opt into a future consensus-triggered migration.
>>
>> The follow-up step does not require predicting with precision the day on
>> which
>> an attack would be set up, but to be done before a CRQC could
>> realistically
>> threaten Bitcoin. Definitely not a piece of cake, but not infeasible. In
>> fact if
>> P2TRv2 does become the Schelling point for PQ migration, i would be more
>> concerned about the follow-up step happening too soon rather than too
>> late.
>>
>> Of course, if a full CRQC is built in secret, with no reliable
>> information about
>> the progress getting out whatsoever, and subsequently starts attacking
>> Bitcoin
>> overnight, then this migration strategy would fail. But so would any other
>> migration strategy!
>>
>> > It's possible that general carelessness on behalf of users would also
>> > rule out the effectiveness of a self-reliance approach: if only the most
>> > conscientious 1% of users make use of P2MR securely, that might secure
>> 10%
>> > of funds, but having 90% of the bitcoin supply crash probably wouldn't
>> be
>> > very valuable either.
>>
>> For what it’s worth, while the supply at risk matters, i think the primary
>> metric we should optimize for is the share of users at risk. Widespread,
>> indiscriminate theft would fatally undermine trust in Bitcoin, whereas
>> more
>> concentrated sweeps (such as that of early, presumed-lost coins) *could*
>> cause
>> severe price shocks without necessarily destroying confidence in the
>> system
>> itself.
>>
>> > > > Theorycrafting for a second here. It's reasonable to conjecture fee
>> > > > rates will be much higher post-Q-day, and thus P2MR's 32 byte
>> advantage
>> > > > over P2TRv2 will yield significant savings for end-users in absolute
>> > > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes
>> becomes
>> > > > significant (100 sats per spend or more).
>> >
>> > I don't think that is the right way to look at. 8vb/input is about
>> > an additional 14% today (vs a taproot key-path spend), but with the
>> > post-quantum signatures we have available now that's likely to reduce
>> > to ~7% (SHRINCS) or ~1% (winternitz).
>>
>> Yes. Also, our goal here is to mitigate the risk that a CRQC materializes
>> by
>> providing a path for Bitcoin to survive it. We shouldn't take the risk
>> for a
>> certainty and shift the goal to designing the best possible PQ-Bitcoin.
>> This can
>> be done if/when it becomes clearer that CRQCs will become a reality.
>>
>> > > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
>> > > perfectly. The expectation should be just that it happens before
>> Q-day,
>> > > and when it looks inevitable or the fear about that is large enough.
>> >
>> > FWIW, I would define "timed perfectly" precisely as "EC disabling
>> > fork happens before Q-day". Maybe allowing some additional months of
>> > EC-efficiency would be a win while not taking out too much migration
>> time,
>> > but for me "perfection" here means "no one who upgraded lost money via
>> > quantum-related vulnerabilities".
>>
>> I don't think that's a good definition of "timed perfectly". By your
>> definition,
>> EC could be disabled from the get-go, Bitcoin's migration would
>> spectacularly
>> fail because very few users switched to the new output type, and it would
>> still
>> be "timed perfectly". :)
>>
>> I would define "timed perfectly" as maximizing the number of migrated
>> users
>> without any of them losing money to a CRQC. But it's not quite the right
>> definition, because there is also probably an aspect of not doing it
>> prematurely, i.e. in the scenario where the CRQC threat never
>> materializes, no
>> P2TRv2 user is forced to use heavily restrictive PQ worklows.
>>
>> > Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
>> > "Later-dominant" scenario, and only to the degree that it's slightly
>> > cheaper prior to Q-day.
>>
>> From the perspective that a successful migration hinges on virtually all
>> users
>> opting into a (full) migration to CRQC-safe workflows, this difference in
>> costs
>> is material. Especially since users would presumably need to opt in long
>> before
>> we know whether CRQCs will become a reality anytime soon.
>>
>> > My (cynical?) view is the only people who will adopt either P2TRv2 or
>> > P2MR prior to NoEC-day being schedule will be people who are willign
>> > to use those features in a quantum-safe way -- that is, keeping their
>> > EC pubkeys secret, and only revealing those EC pubkeys to spend them
>> > immediately, prior to NoEC-day.
>>
>> How can this apply to P2TRv2, where EC pubkeys are always public?
>>
>> I think i disagree that most users of P2MR, were it made available, would
>> treat
>> their EC public keys as secrets. But more importantly, the whole point of
>> P2TRv2, or more generally of what Pieter labels "Later" type strategies,
>> is
>> precisely to avoid imposing on individual users the costs of treating
>> their
>> public keys as secrets. P2TRv2 (compared to other "Later" options) also
>> ensures
>> that using it is no more costly than using any other available output
>> type.
>> Together, these properties may make users who are not yet particularly
>> concerned, or are simply unaware, indifferent to opting in: they bear the
>> additional costs only if the CRQC threat materializes and are no worse
>> off if it
>> does not.
>>
>> > > This focus on allowing individual users the ability to safeguard their
>> > > coins just feels like a red herring: [...]
>> >
>> > While I appreciate your point, I also feel that "allowing individual
>> > users the ability to safeguard their coins" is pretty close to the
>> entire
>> > point of Bitcoin. :)
>>
>> Cherry-picking this part of Pieter's sentence does not do it justice. Of
>> course
>> we all agree about this. But as he says in the part you left out, not
>> addressing
>> this issue as a systemic one is exactly how we lose that property: "I'm
>> not
>> worried about my own coins being stolen. I'm worried about (fear of) a
>> CRQC
>> undermining trust in the currency as a whole, or through a fear-driven
>> consensus
>> change the ecosystem destroying its own values beforehand."
>>
>> > having a consistent push that every single wallet/service that doesn't
>> deprecate every current
>> > address type is a danger to the entire ecosystem, even absent
>> widespread agreement on when/if
>> > Q-day will happen. Arguably that would be easier to agree on if the
>> incremental cost of EC spend
>> > paths in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is
>> near to zero, rather than up
>> > to ~14% per input.
>>
>> Yes, that's essentially the case for P2TRv2.
>>
>> Best,
>> Antoine
>>
>>
>>
>> On Thursday, June 18th, 2026 at 1:09 AM, Anthony Towns <
>> a...@erisian.com.au> wrote:
>>
>> > On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote:
>> > > I want to first correct a potential misunderstanding here, because
>> > > I realize the terms "Later" and "Never" aren't very descriptive. They
>> > > are specifically about an expected and relied-upon expectation that an
>> > > EC-disabling fork will happen that at least applies to the output type
>> > > itself, in time. "Later" is the expectation that such a disabling will
>> > > happen after the output type is introduced, but still in time (so,
>> before
>> > > Q-day). Outputs without a strong expectation that their EC
>> paths/opcodes
>> > > will be disabled, or not in time, I classify under "Never".
>> >
>> > > I believe here you're instead arguing for P2MR ("Merkle-Never")
>> > > over all "Later" options. That was my previous point: I think (solely)
>> > > having "Never" output types like P2MR is just utterly insufficient for
>> > > any worthwhile migration. It's so incompatible with today's workflows
>> > > that it either won't be adopted, or (possibly inadvertently) adopted
>> > > in an insecure fashion. Yes, it gives people the option to safeguard
>> > > their own coins, but to me that's disaster recovery territory - I
>> think
>> > > we ought to prioritize maximizing the chances for saving the currency
>> > > as a whole in case Q-day comes, not a small subset of individual
>> users'
>> > > coins. P2MR (alone) doesn't really achieve much in that regard in my
>> view,
>> > > thus we at least need something of the "Later" class in addition.
>> >
>> > I'm not sure I follow/agree with the logic here. I think the general
>> idea
>> > is:
>> >
>> > 1) we create some new address types that allow post-quantum spending,
>> but
>> > also allow efficient quantum-vulnerable spending that can be used
>> prior
>> > to Q-day
>> >
>> > 2) many people migrate to these new address types
>> >
>> > 3) Q-day arrives
>> >
>> > 4) all spending goes via the post-quantum paths, and everyone's funds
>> are
>> > safe
>> >
>> > There are three main variations to this, I think:
>> >
>> > Later-dominant: towards the end of (2) but prior to (3), the
>> > quantum-vulnerable spend paths are disabled in a predictable,
>> planned
>> > manner, preventing coin theft, but not disrupting active usage
>> > significantly (or not disrupting it any more than the proximity of
>> > Q-day already is).
>> >
>> > Self-reliance: Q-day goes from maybe to definitely faster than
>> consensus
>> > changes can be coordinated, and the only reason people's funds remain
>> > safe is that they can (and do) keep the quantum-vulnerable spend
>> > paths secret.
>> >
>> > Disaster-recovery: neither the "predictable/planned consensus change"
>> of
>> > Later nor the "everyone takes responsiblity for their own funds"
>> > works, and the only way to avoid a large percentage of bitcoin
>> > becoming a reward for quantum research is to replace EC spend paths
>> > with a ZK proof of knowledge of a BIP32 seed or similar, requiring
>> > a hard fork. Such a hard fork would be certain to be controversial
>> > ("why at this height: I received a payment five blocks after //
>> > my funds were stolen by a quantum attacker five blocks earlier //
>> > why are only BIP32 funds recoverable not scheme X"), but if no other
>> > approach works, might still be the ultimately outcome.
>> >
>> > > So the point here was just: if you already accept the need for a
>> "Later"
>> > > output type (= one with builtin-in EC disabling expected from the
>> start),
>> > > P2TRv2 is preferable over P2MR+ED, because:
>> >
>> > As far as I can see, only having P2TRv2 addresses would rule out the
>> > "self-reliance" path here.
>> >
>> > Picking when Q-day will occur, either individually for determining
>> > your own security posture, or collectively for organising a consensus
>> > change seems very difficulty: it involves evaluating both complex state
>> > of the art physics research, but also estimating the covert abilities
>> > of national governments and the incentives to attack bitcoin prior to
>> > revealing their capabilities. To me, that doesn't bode well for a smooth
>> > and fast deployment of a consensus change in advance of problems
>> occuring.
>> >
>> > It's possible that general carelessness on behalf of users would also
>> > rule out the effectiveness of a self-reliance approach: if only the most
>> > conscientious 1% of users make use of P2MR securely, that might secure
>> 10%
>> > of funds, but having 90% of the bitcoin supply crash probably wouldn't
>> be
>> > very valuable either. But even then, that may make the
>> "disaster-recovery"
>> > approach less problematic, by ensuring the 1%/10% who were conscientious
>> > can avoid being part of the "my funds were stolen by a quantum attacker"
>> > contingent, eg.
>> >
>> > > > Theorycrafting for a second here. It's reasonable to conjecture fee
>> > > > rates will be much higher post-Q-day, and thus P2MR's 32 byte
>> advantage
>> > > > over P2TRv2 will yield significant savings for end-users in absolute
>> > > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes
>> becomes
>> > > > significant (100 sats per spend or more).
>> >
>> > I don't think that is the right way to look at. 8vb/input is about
>> > an additional 14% today (vs a taproot key-path spend), but with the
>> > post-quantum signatures we have available now that's likely to reduce
>> > to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,
>> > you're only getting an expected savings in fees / increase in block
>> > capacity on that order of magnitude, ie: 1%-7%. That's nice to have,
>> > for sure, but doesn't compare to introducing a new address type that
>> > puts the PQ sigs in an extension block, or one that uses ZK proofs to
>> > do cross-input or cross-transaction signature aggregation, eg. So a 32B
>> > witness overhead for an unused/unusable key-path post-Q-day doesn't seem
>> > very relevant to me.
>> >
>> > > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
>> > > perfectly. The expectation should be just that it happens before
>> Q-day,
>> > > and when it looks inevitable or the fear about that is large enough.
>> >
>> > FWIW, I would define "timed perfectly" precisely as "EC disabling
>> > fork happens before Q-day". Maybe allowing some additional months of
>> > EC-efficiency would be a win while not taking out too much migration
>> time,
>> > but for me "perfection" here means "no one who upgraded lost money via
>> > quantum-related vulnerabilities".
>> >
>> > One reason I'm doubtful is that I think for some the "it looks
>> inevitable"
>> > threshold has already been crossed, eg:
>> >
>> > >> So let me attempt to partially fill the silence, similarly to what
>> > >> Scott Aaronson did in his April 29 post. Given everything I know,
>> > >> including scary non-public information, I now put the odds of qday by
>> > >> 2032 at 50%. 10% by 2030.
>> >
>> > >> IMO a good target date for migration is 2029, roughly 3.5 years
>> > >> out. 2029 happens to be the date selected by Google, Cloudflare, and
>> > >> the Ethereum Foundation.
>> >
>> > https://x.com/drakefjustin/status/2061793725299224676
>> >
>> > >> So, here it is: if quantum computers start breaking cryptography a
>> > >> few years from now, don’t you dare come to this blog and tell me that
>> > >> I failed to warn you. This post is your warning. Please start
>> switching
>> > >> to quantum-resistant encryption, and urge your company or
>> organization
>> > >> or blockchain or standards body to do the same.
>> >
>> > https://scottaaronson.blog/?p=9718
>> >
>> > Personally, that leaves me at a minimum very skeptical of the utility
>> > of introducing either P2MR or P2TRv2 (etc) approaches that don't also
>> > introduce a quantum-safe spending path on day one.
>> >
>> > > First a meta-point here: the reason I like separating the discussion
>> into different dimensions than just "P2TRv2 vs P2MR" is because there are
>> more options than those two, and not every argument applies to the same
>> separation into two classes. Let me list them explicitly here, roughly in
>> decreasing order of how strongly I feel about them:
>> > > - We need at least a "Later" option for meaningful migration, i.e.
>> P2TRv2 or P2MR+ED.
>> > > - Within the "Later" option, P2TRv2 is preferable.
>> > > - A "Later" option benefits from being the only PQC migration
>> strategy, making it a Schelling point.
>> >
>> > Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
>> > "Later-dominant" scenario, and only to the degree that it's slightly
>> > cheaper prior to Q-day. If it were the only available option, that would
>> > increase the risk of loss involved with both the other approaches. (I
>> > don't think P2TRv2 is meaningfully more private than P2MR in the way
>> > taproot v1 is, as presumably you'd only adopt that address format if
>> > you wanted to have a post-quantum script path)
>> >
>> > > > You'd have to convince everyone to deploy and then adopt P2TRv2
>> today under the public knowledge that it is insecure and their coins are
>> more likely to be stolen. That's a hard sell.
>> > >
>> > > > How does one pitch P2TRv2 to users? "It will be quantum secure one
>> day we promise because everyone is incentivized to fix it later as Bitcoin
>> will die if we don't."
>> > > >
>> > > > How do you pitch P2MR? "It's quantum secure if you use it
>> correctly."
>> > > To me, the pitch is "Bitcoin can only remain valuable if we
>> mostly/all migrate." for both. P2TRv2 is just much easier to adopt, because
>> P2MR (or any "Never" output type) fundamentally requires many users to
>> change their workflows entirely.
>> >
>> > Let's call NoEC-day the earlier of activation of a soft-fork disabling
>> > EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably
>> > equal to "the day the bitcoin ecosystem has finally agreed that CRQCs
>> > are inevitable".
>> >
>> > My (cynical?) view is the only people who will adopt either P2TRv2 or
>> > P2MR prior to NoEC-day being schedule will be people who are willign
>> > to use those features in a quantum-safe way -- that is, keeping their
>> > EC pubkeys secret, and only revealing those EC pubkeys to spend them
>> > immediately, prior to NoEC-day. In that view, the EC-spend-paths of such
>> > coins prior to NoEC-day are only an opportunistic "make spends cheaper"
>> > shortcut, they don't allow the funds to be used in lightning channels
>> > or to let your wallet be audited via sharing an xpub or anything
>> similar.
>> >
>> > Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible
>> > that lightning software could get an upgrade to generate post-quantum
>> > signatures for channel commitments or HTLC claims, I just think it's
>> > pretty unlikely that that will happen at a meaningful scale when
>> everyone
>> > has much more immediate and less theoretical things to work on prior to
>> > NoEC-day, especially when the efficiency/performance of such changes is
>> > likely to be very low.
>> >
>> > > This focus on allowing individual users the ability to safeguard their
>> > > coins just feels like a red herring: [...]
>> >
>> > While I appreciate your point, I also feel that "allowing individual
>> > users the ability to safeguard their coins" is pretty close to the
>> entire
>> > point of Bitcoin. :)
>> >
>> > > In either case, I consider anything that requires hardcoding
>> > > specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus
>> > > rules (and only allowing those coins to survive) to be squarely in
>> > > disaster-recovery land. It feels like embracing arbitrariness, and
>> > > giving up on the permissionlessness that makes Bitcoin interesting -
>> > > if the community shows it can get consensus on effectively burning
>> > > coins except those that match a whitelist, it feels hard to maintain
>> > > censorship-freeness as a value, even if the whitelist includes most of
>> > > the (active) coins. That is of course not to say such techniques
>> aren't
>> > > interesting to work on, but to me, their place is in disaster recovery
>> > > scenarios to save what's left, after Q-day, if migration attempts were
>> > > unsuccessful. In such a setting, I think we're already in effectively
>> an
>> > > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly
>> > > growing) set of ways to recover burned coins can be hardforked in.
>> >
>> > Just for the record, I think the above is an accurate description of the
>> > "disaster-recovery" scenario above: the "quantum-safe" hard-fork variant
>> > of bitcoin would be fairly described as a utxo-bootstrapped altcoin,
>> > would compete in the market with the "quantum-unsafe" bitcoin that
>> > existing nodes would continue to follow, and possibly there would be
>> > many slightly varying such altcoins competing with each other, eg on
>> > exactly what height the utxo snapshot was taken or what coins become
>> > spendable. It would not be a fun time for holders of affected utxos.
>> >
>> > > My impression is that your approach is to have an answer for many
>> > > possible futures, including ones where Q-day arrives within just a few
>> > > years.
>> >
>> > "The key of strategy... is not to choose a path to victory, but to
>> choose
>> > so that all paths lead to a victory."
>> >
>> > -- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit
>> >
>> > > But optimizing for disaster-recovery also means reducing the
>> > > chances of preserving Bitcoin as we know it in the scenarios where a
>> > > successful migration is still possible. And if Q-day does arrive that
>> > > soon, I don't see what we can do today that would preserve Bitcoin in
>> > > a form we care about anyway. By accepting that, we can focus on the
>> > > futures where our choices today can still materially improve the
>> outcome.
>> >
>> > Preserving bitcoin as a personally-possessible inflation resistant
>> > store of value seems both possible and worth caring about, even if other
>> > constraints means that many people can't afford to personally hold it
>> > (and have to go through ETFs/exchanges/banks) and that it can't be used
>> > for day-to-day transactions. Would be very disappointing if true, and
>> > even given Q-day in a few years I expect we could do better than just
>> > that, but it doesn't feel like a throw-in-the-towel event to me.
>> >
>> > > > Essentially yes though, I expect the majority of holders will
>> probably
>> > > > migrate to PQ addresses via rescue protocols, either on Bitcoin or
>> a fork
>> > > > thereof. Even if we can't come to consensus and deploy a new output
>> type,
>> > > > we'll still be able to rescue most coins. It's just that we'd have
>> nowhere
>> > > > to rescue them to, so we ought to make PQ wallets available soon,
>> so we're
>> > > > not in a rush to build them later when we need them. If a PQ wallet
>> can
>> > > > use cheap EC signatures while they're still trustworthy, all the
>> better
>> >
>> > FWIW, that's my guess on how things would play out if the near-term
>> Q-day
>> > timelines I've seen (ie, 2029 to 2035) match reality. I hope that's
>> > pessimistic (either because the Q-day timelines are bad estimates, or
>> > because migration happens in a more orderly fashion), but I guess we'll
>> > see. I don't rate my ability to evaluate Q-day predictions very highly.
>> >
>> > > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
>> >
>> > I'm not in a position to judge, but the google paper claims:
>> >
>> > "Indeed, if a leading quantum architecture encounters and overcomes
>> > all its scaling challenges before producing a device able to
>> > solve (for example) 32-bit ECDLP, then there may be little time
>> > between the breaking of 32-bit ECDLP and the breaking of 256-bit
>> > ECDLP. Furthermore, the community should not expect to see published
>> > demonstrations of the most advanced quantum error-correction
>> > architectures and quantum algorithms deployed to cryptanalytic
>> > problems. Thus, a successful public demonstration of Shor’s
>> > algorithm on a 32-bit elliptic curve should not be seen as a wake-up
>> > call to adopt PQC as much as a potential signal that PQC adoption
>> > has already failed."
>> >
>> > and places the required tiffoli gates and logical qubits for a 32-bit
>> > break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100)
>> > for 256-bit.
>> >
>> > > Of course, if you believe it's the only possible future, I understand
>> > > you'd come to a different conclusion. But is it really? Do you think
>> > > this isn't a plausible future:
>> >
>> > > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added
>> too) gets introduced in the next few years, with hash-based PQC opcodes.
>> > > - Over the course of the next decade or so, it gets adopted by
>> practically all active users.
>> >
>> > I think it might be better to look at that scenario in a more
>> fine-grained
>> > way? I think your "Late-ish" scenario is:
>> >
>> > 1) P2TRv2 (or whatever) is introduced
>> > 2) Some PQ opcodes get enabled, allowing expensive but PQ-safe
>> spend-paths
>> > via those outputs
>> > 3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of
>> P2TRv2,
>> > but EC spend paths continue to be what's used in practice.
>> > 4) Some better PQ solutions become available, allowing cheap PQ-safe
>> spend-paths
>> > 5) Everyone switches from EC paths to the new PQ paths.
>> > 6) NoEC-day happens, but no one is impacted.
>> >
>> > I think your "Soon-ish" scenario differs as of step (4):
>> >
>> > 4) NoEC-day happens. Massive disruption because the "what's used in
>> practice"
>> > path breaks, but everything is recoverable.
>> > 5) Post-quantum approaches get even higher priority
>> >
>> > I'm skeptical of step 3 here; and would expect to see something more
>> like:
>> >
>> > 3') Only a small proportion of users (ie, the most
>> conscientious/fearful)
>> > switch to P2TRv2 with most preferring to stick with what works
>> >
>> > That has no real impact on the Late-ish scenario, but changes the
>> Soon-ish
>> > scenario to either:
>> >
>> > 4'a) NoEC-day happens substantially before Q-day; people hurry to
>> migrate
>> > to P2TRv2, but it mostly works.
>> >
>> > or
>> >
>> > 4'b) NoEC-day happens essentially at the same time as Q-day; coins get
>> > stolen and we hit the disaster-recovery scenario.
>> >
>> > Perhaps the difference between (3') and (3) playing out in reality
>> > is just having nearly everyone agree that the upgrade is essential,
>> > and rather than leaving it to self-interest/market-dynamics, having a
>> > consistent push that every single wallet/service that doesn't deprecate
>> > every current address type is a danger to the entire ecosystem, even
>> > absent widespread agreement on when/if Q-day will happen. Arguably that
>> > would be easier to agree on if the incremental cost of EC spend paths
>> > in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to
>> > zero, rather than up to ~14% per input.
>> >
>> > Cheers,
>> > aj
>> >
>>
>> --
>> 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/SHKHzyvg1Rr2E-CBLdgNEinhsndgXog0v4YxlDBJAYVcwjCEnBdByD-3_PSCZzkf9nHeisOKHSqjsBrTgumAVwsZPHHnwrx7FcpZeVZiups%3D%40protonmail.com
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a57e3fa9-b137-4b5e-8656-d09d9e77b126n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 38128 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [bitcoindev] Aligning privacy incentives in P2MR
2026-06-24 22:00 ` Anthony Derbidge
2026-06-25 15:24 ` Alex
@ 2026-06-26 9:27 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
2026-06-26 16:11 ` 'conduition' via Bitcoin Development Mailing List
1 sibling, 1 reply; 20+ messages in thread
From: 'ArmchairCryptologist' via Bitcoin Development Mailing List @ 2026-06-26 9:27 UTC (permalink / raw)
To: bitcoindev@googlegroups.com
[-- Attachment #1: Type: text/plain, Size: 32969 bytes --]
In my humble opinion, I think the preference for P2MR vs P2TRv2 for users would largely boil down to whether or not someone is a long-term holder, or someone who actively makes frequent transactions on the network.
On one hand, if I were a self-reliant long-term holder of significant assets (which I may or may not be), I would be reluctant to use P2TRv2 for this, since the funds would always be fully exposed to CRQCs until such a time EC spending is disabled by a third party, which may or may not happen in time.
On the other, if I were making frequent transactions on the network (which I may or may not do), I would be reluctant to use P2MR for this due to the additional transaction cost, which would be wasteful before CRQCs exist - and especially considering that they might never exist.
As such, unless someone were to come up with a different scheme that has the best of both worlds, I feel like the discussion should be more along the lines of "one, or possibly both if it is beneficial" rather than "we have to pick just one no matter what".
Personally, using the ideas Pieter Wuille presented in the other thread, my preference would be to add both:
- P2TRv2 using one or both of the Tripwire and Miner Lockdown triggers (P2TRv2-T / P2TRv2-ML / P2TRv2-T-ML) to emergency-disable EC spending, while still leaving the ability to disable it with a soft fork, for frequent transactors and people who trust miners to act responsibly.
- P2MR (plain), with EC spending only disabled with a soft fork, for the self-reliant holders who know (how) to not expose their EC public key and want full control over their funds.
This would leave EC spending available for P2MR while it is still in the "danger zone" and after it has been initially disabled for P2TRv2, but when/if EC spending is considered by the developers to be completely broken, a follow-up soft fork would disable it for both address types.
I feel like this should be worth the trade-offs of easier wallet fingerprinting as well as the increase in implementation complexity and long-term maintenance cost - but then again, I'm not the one paying that cost, and the people who will might disagree.
--
Best,ArmchairCryptologist
On Thursday, June 25th, 2026 at 12:35 AM, Anthony Derbidge <aderb001@gmail.com> wrote:
> I agree with the core point that Bitcoin’s post-quantum transition cannot rely primarily on self-reliance. If the migration requires most users to understand Q-Day timing, keep EC spend paths secret, or react quickly under pressure, then it is unlikely to protect Bitcoin as a system. The safer path needs to be low-friction and close to the default experience long before the threat becomes urgent.
>
> That is why a "Later" style strategy seems compelling: ordinary users can opt into a future migration path without immediately adopting restrictive post-quantum workflows, while consensus can still act when the risk becomes concrete. Bitcoin mainnet should remain simple and conservative, while more complex identity, recovery, coordination, and enhanced post-quantum workflows can exist in optional Bitcoin-aligned layers rather than the base layer.
>
> Systems such as Lightning and ProofnetBTC can experiment with those optional workflows and recovery models while continuing to settle to Bitcoin, allowing innovation without requiring the Bitcoin mainnet itself to absorb that additional complexity.
>
> Best,
> Anthony D.
>
> On Wed, Jun 24, 2026 at 3:50 PM 'Antoine Poinsot' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
>
>> Hi AJ,
>>
>>> There are three main variations to this, I think:
>>>
>>> [...]
>>>
>>> Self-reliance: Q-day goes from maybe to definitely faster than consensus
>>> changes can be coordinated, and the only reason people's funds remain
>>> safe is that they can (and do) keep the quantum-vulnerable spend
>>> paths secret.
>>
>> I think that scenario may only result in a successful migration if the vast
>> majority of users have updated their workflows to keep said quantum vulnerable
>> paths secret.
>>
>> This may only happen if the vast majority of users either:
>> 1. have preemptively updated their workflows during the "maybe" period;
>> 2. react promptly enough (within weeks? a couple months?) to migrate all their wealth.
>>
>> Option (1) is utterly implausible. As Pieter explained in his email, we can't
>> expect users to adopt workflows radically at odds with how they use Bitcoin
>> today in response to a (still --at the time they need to migrate) speculative
>> threat.
>>
>> I believe Bitcoin is successful precisely because users are not required to be
>> active bitcoiners and pay close attention to avoid losing their funds. A
>> substantial share of users value and rely on this property, and therefore Option
>> (2) is likewise implausible.
>>
>> Therefore i don't think the "Self-reliance" variation can result in a successful
>> migration.
>>
>>> As far as I can see, only having P2TRv2 addresses would rule out the "self-reliance" path here.
>>>
>>> Picking when Q-day will occur, either individually for determining
>>> your own security posture, or collectively for organising a consensus
>>> change seems very difficulty: it involves evaluating both complex state
>>> of the art physics research, but also estimating the covert abilities
>>> of national governments and the incentives to attack bitcoin prior to
>>> revealing their capabilities. To me, that doesn't bode well for a smooth
>>> and fast deployment of a consensus change in advance of problems occuring.
>>
>> Yes. P2TRv2 optimizes for the "Later dominant" path at the expense of the
>> "self-reliance" path. I think this is good, because our best (only?) shot at
>> fully migrating large amounts of users is to provide them with a virtually free
>> way to opt into a future consensus-triggered migration.
>>
>> The follow-up step does not require predicting with precision the day on which
>> an attack would be set up, but to be done before a CRQC could realistically
>> threaten Bitcoin. Definitely not a piece of cake, but not infeasible. In fact if
>> P2TRv2 does become the Schelling point for PQ migration, i would be more
>> concerned about the follow-up step happening too soon rather than too late.
>>
>> Of course, if a full CRQC is built in secret, with no reliable information about
>> the progress getting out whatsoever, and subsequently starts attacking Bitcoin
>> overnight, then this migration strategy would fail. But so would any other
>> migration strategy!
>>
>>> It's possible that general carelessness on behalf of users would also
>>> rule out the effectiveness of a self-reliance approach: if only the most
>>> conscientious 1% of users make use of P2MR securely, that might secure 10%
>>> of funds, but having 90% of the bitcoin supply crash probably wouldn't be
>>> very valuable either.
>>
>> For what it’s worth, while the supply at risk matters, i think the primary
>> metric we should optimize for is the share of users at risk. Widespread,
>> indiscriminate theft would fatally undermine trust in Bitcoin, whereas more
>> concentrated sweeps (such as that of early, presumed-lost coins) *could* cause
>> severe price shocks without necessarily destroying confidence in the system
>> itself.
>>
>>> > > Theorycrafting for a second here. It's reasonable to conjecture fee
>>> > > rates will be much higher post-Q-day, and thus P2MR's 32 byte advantage
>>> > > over P2TRv2 will yield significant savings for end-users in absolute
>>> > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes becomes
>>> > > significant (100 sats per spend or more).
>>>
>>> I don't think that is the right way to look at. 8vb/input is about
>>> an additional 14% today (vs a taproot key-path spend), but with the
>>> post-quantum signatures we have available now that's likely to reduce
>>> to ~7% (SHRINCS) or ~1% (winternitz).
>>
>> Yes. Also, our goal here is to mitigate the risk that a CRQC materializes by
>> providing a path for Bitcoin to survive it. We shouldn't take the risk for a
>> certainty and shift the goal to designing the best possible PQ-Bitcoin. This can
>> be done if/when it becomes clearer that CRQCs will become a reality.
>>
>>> > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
>>> > perfectly. The expectation should be just that it happens before Q-day,
>>> > and when it looks inevitable or the fear about that is large enough.
>>>
>>> FWIW, I would define "timed perfectly" precisely as "EC disabling
>>> fork happens before Q-day". Maybe allowing some additional months of
>>> EC-efficiency would be a win while not taking out too much migration time,
>>> but for me "perfection" here means "no one who upgraded lost money via
>>> quantum-related vulnerabilities".
>>
>> I don't think that's a good definition of "timed perfectly". By your definition,
>> EC could be disabled from the get-go, Bitcoin's migration would spectacularly
>> fail because very few users switched to the new output type, and it would still
>> be "timed perfectly". :)
>>
>> I would define "timed perfectly" as maximizing the number of migrated users
>> without any of them losing money to a CRQC. But it's not quite the right
>> definition, because there is also probably an aspect of not doing it
>> prematurely, i.e. in the scenario where the CRQC threat never materializes, no
>> P2TRv2 user is forced to use heavily restrictive PQ worklows.
>>
>>> Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
>>> "Later-dominant" scenario, and only to the degree that it's slightly
>>> cheaper prior to Q-day.
>>
>> From the perspective that a successful migration hinges on virtually all users
>> opting into a (full) migration to CRQC-safe workflows, this difference in costs
>> is material. Especially since users would presumably need to opt in long before
>> we know whether CRQCs will become a reality anytime soon.
>>
>>> My (cynical?) view is the only people who will adopt either P2TRv2 or
>>> P2MR prior to NoEC-day being schedule will be people who are willign
>>> to use those features in a quantum-safe way -- that is, keeping their
>>> EC pubkeys secret, and only revealing those EC pubkeys to spend them
>>> immediately, prior to NoEC-day.
>>
>> How can this apply to P2TRv2, where EC pubkeys are always public?
>>
>> I think i disagree that most users of P2MR, were it made available, would treat
>> their EC public keys as secrets. But more importantly, the whole point of
>> P2TRv2, or more generally of what Pieter labels "Later" type strategies, is
>> precisely to avoid imposing on individual users the costs of treating their
>> public keys as secrets. P2TRv2 (compared to other "Later" options) also ensures
>> that using it is no more costly than using any other available output type.
>> Together, these properties may make users who are not yet particularly
>> concerned, or are simply unaware, indifferent to opting in: they bear the
>> additional costs only if the CRQC threat materializes and are no worse off if it
>> does not.
>>
>>> > This focus on allowing individual users the ability to safeguard their
>>> > coins just feels like a red herring: [...]
>>>
>>> While I appreciate your point, I also feel that "allowing individual
>>> users the ability to safeguard their coins" is pretty close to the entire
>>> point of Bitcoin. :)
>>
>> Cherry-picking this part of Pieter's sentence does not do it justice. Of course
>> we all agree about this. But as he says in the part you left out, not addressing
>> this issue as a systemic one is exactly how we lose that property: "I'm not
>> worried about my own coins being stolen. I'm worried about (fear of) a CRQC
>> undermining trust in the currency as a whole, or through a fear-driven consensus
>> change the ecosystem destroying its own values beforehand."
>>
>>> having a consistent push that every single wallet/service that doesn't deprecate every current
>>> address type is a danger to the entire ecosystem, even absent widespread agreement on when/if
>>> Q-day will happen. Arguably that would be easier to agree on if the incremental cost of EC spend
>>> paths in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to zero, rather than up
>>> to ~14% per input.
>>
>> Yes, that's essentially the case for P2TRv2.
>>
>> Best,
>> Antoine
>>
>> On Thursday, June 18th, 2026 at 1:09 AM, Anthony Towns <aj@erisian.com.au> wrote:
>>
>>> On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote:
>>> > I want to first correct a potential misunderstanding here, because
>>> > I realize the terms "Later" and "Never" aren't very descriptive. They
>>> > are specifically about an expected and relied-upon expectation that an
>>> > EC-disabling fork will happen that at least applies to the output type
>>> > itself, in time. "Later" is the expectation that such a disabling will
>>> > happen after the output type is introduced, but still in time (so, before
>>> > Q-day). Outputs without a strong expectation that their EC paths/opcodes
>>> > will be disabled, or not in time, I classify under "Never".
>>>
>>> > I believe here you're instead arguing for P2MR ("Merkle-Never")
>>> > over all "Later" options. That was my previous point: I think (solely)
>>> > having "Never" output types like P2MR is just utterly insufficient for
>>> > any worthwhile migration. It's so incompatible with today's workflows
>>> > that it either won't be adopted, or (possibly inadvertently) adopted
>>> > in an insecure fashion. Yes, it gives people the option to safeguard
>>> > their own coins, but to me that's disaster recovery territory - I think
>>> > we ought to prioritize maximizing the chances for saving the currency
>>> > as a whole in case Q-day comes, not a small subset of individual users'
>>> > coins. P2MR (alone) doesn't really achieve much in that regard in my view,
>>> > thus we at least need something of the "Later" class in addition.
>>>
>>> I'm not sure I follow/agree with the logic here. I think the general idea
>>> is:
>>>
>>> 1) we create some new address types that allow post-quantum spending, but
>>> also allow efficient quantum-vulnerable spending that can be used prior
>>> to Q-day
>>>
>>> 2) many people migrate to these new address types
>>>
>>> 3) Q-day arrives
>>>
>>> 4) all spending goes via the post-quantum paths, and everyone's funds are
>>> safe
>>>
>>> There are three main variations to this, I think:
>>>
>>> Later-dominant: towards the end of (2) but prior to (3), the
>>> quantum-vulnerable spend paths are disabled in a predictable, planned
>>> manner, preventing coin theft, but not disrupting active usage
>>> significantly (or not disrupting it any more than the proximity of
>>> Q-day already is).
>>>
>>> Self-reliance: Q-day goes from maybe to definitely faster than consensus
>>> changes can be coordinated, and the only reason people's funds remain
>>> safe is that they can (and do) keep the quantum-vulnerable spend
>>> paths secret.
>>>
>>> Disaster-recovery: neither the "predictable/planned consensus change" of
>>> Later nor the "everyone takes responsiblity for their own funds"
>>> works, and the only way to avoid a large percentage of bitcoin
>>> becoming a reward for quantum research is to replace EC spend paths
>>> with a ZK proof of knowledge of a BIP32 seed or similar, requiring
>>> a hard fork. Such a hard fork would be certain to be controversial
>>> ("why at this height: I received a payment five blocks after //
>>> my funds were stolen by a quantum attacker five blocks earlier //
>>> why are only BIP32 funds recoverable not scheme X"), but if no other
>>> approach works, might still be the ultimately outcome.
>>>
>>> > So the point here was just: if you already accept the need for a "Later"
>>> > output type (= one with builtin-in EC disabling expected from the start),
>>> > P2TRv2 is preferable over P2MR+ED, because:
>>>
>>> As far as I can see, only having P2TRv2 addresses would rule out the
>>> "self-reliance" path here.
>>>
>>> Picking when Q-day will occur, either individually for determining
>>> your own security posture, or collectively for organising a consensus
>>> change seems very difficulty: it involves evaluating both complex state
>>> of the art physics research, but also estimating the covert abilities
>>> of national governments and the incentives to attack bitcoin prior to
>>> revealing their capabilities. To me, that doesn't bode well for a smooth
>>> and fast deployment of a consensus change in advance of problems occuring.
>>>
>>> It's possible that general carelessness on behalf of users would also
>>> rule out the effectiveness of a self-reliance approach: if only the most
>>> conscientious 1% of users make use of P2MR securely, that might secure 10%
>>> of funds, but having 90% of the bitcoin supply crash probably wouldn't be
>>> very valuable either. But even then, that may make the "disaster-recovery"
>>> approach less problematic, by ensuring the 1%/10% who were conscientious
>>> can avoid being part of the "my funds were stolen by a quantum attacker"
>>> contingent, eg.
>>>
>>> > > Theorycrafting for a second here. It's reasonable to conjecture fee
>>> > > rates will be much higher post-Q-day, and thus P2MR's 32 byte advantage
>>> > > over P2TRv2 will yield significant savings for end-users in absolute
>>> > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes becomes
>>> > > significant (100 sats per spend or more).
>>>
>>> I don't think that is the right way to look at. 8vb/input is about
>>> an additional 14% today (vs a taproot key-path spend), but with the
>>> post-quantum signatures we have available now that's likely to reduce
>>> to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,
>>> you're only getting an expected savings in fees / increase in block
>>> capacity on that order of magnitude, ie: 1%-7%. That's nice to have,
>>> for sure, but doesn't compare to introducing a new address type that
>>> puts the PQ sigs in an extension block, or one that uses ZK proofs to
>>> do cross-input or cross-transaction signature aggregation, eg. So a 32B
>>> witness overhead for an unused/unusable key-path post-Q-day doesn't seem
>>> very relevant to me.
>>>
>>> > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
>>> > perfectly. The expectation should be just that it happens before Q-day,
>>> > and when it looks inevitable or the fear about that is large enough.
>>>
>>> FWIW, I would define "timed perfectly" precisely as "EC disabling
>>> fork happens before Q-day". Maybe allowing some additional months of
>>> EC-efficiency would be a win while not taking out too much migration time,
>>> but for me "perfection" here means "no one who upgraded lost money via
>>> quantum-related vulnerabilities".
>>>
>>> One reason I'm doubtful is that I think for some the "it looks inevitable"
>>> threshold has already been crossed, eg:
>>>
>>> >> So let me attempt to partially fill the silence, similarly to what
>>> >> Scott Aaronson did in his April 29 post. Given everything I know,
>>> >> including scary non-public information, I now put the odds of qday by
>>> >> 2032 at 50%. 10% by 2030.
>>>
>>> >> IMO a good target date for migration is 2029, roughly 3.5 years
>>> >> out. 2029 happens to be the date selected by Google, Cloudflare, and
>>> >> the Ethereum Foundation.
>>>
>>> https://x.com/drakefjustin/status/2061793725299224676
>>>
>>> >> So, here it is: if quantum computers start breaking cryptography a
>>> >> few years from now, don’t you dare come to this blog and tell me that
>>> >> I failed to warn you. This post is your warning. Please start switching
>>> >> to quantum-resistant encryption, and urge your company or organization
>>> >> or blockchain or standards body to do the same.
>>>
>>> https://scottaaronson.blog/?p=9718
>>>
>>> Personally, that leaves me at a minimum very skeptical of the utility
>>> of introducing either P2MR or P2TRv2 (etc) approaches that don't also
>>> introduce a quantum-safe spending path on day one.
>>>
>>> > First a meta-point here: the reason I like separating the discussion into different dimensions than just "P2TRv2 vs P2MR" is because there are more options than those two, and not every argument applies to the same separation into two classes. Let me list them explicitly here, roughly in decreasing order of how strongly I feel about them:
>>> > - We need at least a "Later" option for meaningful migration, i.e. P2TRv2 or P2MR+ED.
>>> > - Within the "Later" option, P2TRv2 is preferable.
>>> > - A "Later" option benefits from being the only PQC migration strategy, making it a Schelling point.
>>>
>>> Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
>>> "Later-dominant" scenario, and only to the degree that it's slightly
>>> cheaper prior to Q-day. If it were the only available option, that would
>>> increase the risk of loss involved with both the other approaches. (I
>>> don't think P2TRv2 is meaningfully more private than P2MR in the way
>>> taproot v1 is, as presumably you'd only adopt that address format if
>>> you wanted to have a post-quantum script path)
>>>
>>> > > You'd have to convince everyone to deploy and then adopt P2TRv2 today under the public knowledge that it is insecure and their coins are more likely to be stolen. That's a hard sell.
>>> >
>>> > > How does one pitch P2TRv2 to users? "It will be quantum secure one day we promise because everyone is incentivized to fix it later as Bitcoin will die if we don't."
>>> > >
>>> > > How do you pitch P2MR? "It's quantum secure if you use it correctly."
>>> > To me, the pitch is "Bitcoin can only remain valuable if we mostly/all migrate." for both. P2TRv2 is just much easier to adopt, because P2MR (or any "Never" output type) fundamentally requires many users to change their workflows entirely.
>>>
>>> Let's call NoEC-day the earlier of activation of a soft-fork disabling
>>> EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably
>>> equal to "the day the bitcoin ecosystem has finally agreed that CRQCs
>>> are inevitable".
>>>
>>> My (cynical?) view is the only people who will adopt either P2TRv2 or
>>> P2MR prior to NoEC-day being schedule will be people who are willign
>>> to use those features in a quantum-safe way -- that is, keeping their
>>> EC pubkeys secret, and only revealing those EC pubkeys to spend them
>>> immediately, prior to NoEC-day. In that view, the EC-spend-paths of such
>>> coins prior to NoEC-day are only an opportunistic "make spends cheaper"
>>> shortcut, they don't allow the funds to be used in lightning channels
>>> or to let your wallet be audited via sharing an xpub or anything similar.
>>>
>>> Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible
>>> that lightning software could get an upgrade to generate post-quantum
>>> signatures for channel commitments or HTLC claims, I just think it's
>>> pretty unlikely that that will happen at a meaningful scale when everyone
>>> has much more immediate and less theoretical things to work on prior to
>>> NoEC-day, especially when the efficiency/performance of such changes is
>>> likely to be very low.
>>>
>>> > This focus on allowing individual users the ability to safeguard their
>>> > coins just feels like a red herring: [...]
>>>
>>> While I appreciate your point, I also feel that "allowing individual
>>> users the ability to safeguard their coins" is pretty close to the entire
>>> point of Bitcoin. :)
>>>
>>> > In either case, I consider anything that requires hardcoding
>>> > specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus
>>> > rules (and only allowing those coins to survive) to be squarely in
>>> > disaster-recovery land. It feels like embracing arbitrariness, and
>>> > giving up on the permissionlessness that makes Bitcoin interesting -
>>> > if the community shows it can get consensus on effectively burning
>>> > coins except those that match a whitelist, it feels hard to maintain
>>> > censorship-freeness as a value, even if the whitelist includes most of
>>> > the (active) coins. That is of course not to say such techniques aren't
>>> > interesting to work on, but to me, their place is in disaster recovery
>>> > scenarios to save what's left, after Q-day, if migration attempts were
>>> > unsuccessful. In such a setting, I think we're already in effectively an
>>> > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly
>>> > growing) set of ways to recover burned coins can be hardforked in.
>>>
>>> Just for the record, I think the above is an accurate description of the
>>> "disaster-recovery" scenario above: the "quantum-safe" hard-fork variant
>>> of bitcoin would be fairly described as a utxo-bootstrapped altcoin,
>>> would compete in the market with the "quantum-unsafe" bitcoin that
>>> existing nodes would continue to follow, and possibly there would be
>>> many slightly varying such altcoins competing with each other, eg on
>>> exactly what height the utxo snapshot was taken or what coins become
>>> spendable. It would not be a fun time for holders of affected utxos.
>>>
>>> > My impression is that your approach is to have an answer for many
>>> > possible futures, including ones where Q-day arrives within just a few
>>> > years.
>>>
>>> "The key of strategy... is not to choose a path to victory, but to choose
>>> so that all paths lead to a victory."
>>>
>>> -- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit
>>>
>>> > But optimizing for disaster-recovery also means reducing the
>>> > chances of preserving Bitcoin as we know it in the scenarios where a
>>> > successful migration is still possible. And if Q-day does arrive that
>>> > soon, I don't see what we can do today that would preserve Bitcoin in
>>> > a form we care about anyway. By accepting that, we can focus on the
>>> > futures where our choices today can still materially improve the outcome.
>>>
>>> Preserving bitcoin as a personally-possessible inflation resistant
>>> store of value seems both possible and worth caring about, even if other
>>> constraints means that many people can't afford to personally hold it
>>> (and have to go through ETFs/exchanges/banks) and that it can't be used
>>> for day-to-day transactions. Would be very disappointing if true, and
>>> even given Q-day in a few years I expect we could do better than just
>>> that, but it doesn't feel like a throw-in-the-towel event to me.
>>>
>>> > > Essentially yes though, I expect the majority of holders will probably
>>> > > migrate to PQ addresses via rescue protocols, either on Bitcoin or a fork
>>> > > thereof. Even if we can't come to consensus and deploy a new output type,
>>> > > we'll still be able to rescue most coins. It's just that we'd have nowhere
>>> > > to rescue them to, so we ought to make PQ wallets available soon, so we're
>>> > > not in a rush to build them later when we need them. If a PQ wallet can
>>> > > use cheap EC signatures while they're still trustworthy, all the better
>>>
>>> FWIW, that's my guess on how things would play out if the near-term Q-day
>>> timelines I've seen (ie, 2029 to 2035) match reality. I hope that's
>>> pessimistic (either because the Q-day timelines are bad estimates, or
>>> because migration happens in a more orderly fashion), but I guess we'll
>>> see. I don't rate my ability to evaluate Q-day predictions very highly.
>>>
>>> > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
>>>
>>> I'm not in a position to judge, but the google paper claims:
>>>
>>> "Indeed, if a leading quantum architecture encounters and overcomes
>>> all its scaling challenges before producing a device able to
>>> solve (for example) 32-bit ECDLP, then there may be little time
>>> between the breaking of 32-bit ECDLP and the breaking of 256-bit
>>> ECDLP. Furthermore, the community should not expect to see published
>>> demonstrations of the most advanced quantum error-correction
>>> architectures and quantum algorithms deployed to cryptanalytic
>>> problems. Thus, a successful public demonstration of Shor’s
>>> algorithm on a 32-bit elliptic curve should not be seen as a wake-up
>>> call to adopt PQC as much as a potential signal that PQC adoption
>>> has already failed."
>>>
>>> and places the required tiffoli gates and logical qubits for a 32-bit
>>> break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100)
>>> for 256-bit.
>>>
>>> > Of course, if you believe it's the only possible future, I understand
>>> > you'd come to a different conclusion. But is it really? Do you think
>>> > this isn't a plausible future:
>>>
>>> > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too) gets introduced in the next few years, with hash-based PQC opcodes.
>>> > - Over the course of the next decade or so, it gets adopted by practically all active users.
>>>
>>> I think it might be better to look at that scenario in a more fine-grained
>>> way? I think your "Late-ish" scenario is:
>>>
>>> 1) P2TRv2 (or whatever) is introduced
>>> 2) Some PQ opcodes get enabled, allowing expensive but PQ-safe spend-paths
>>> via those outputs
>>> 3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of P2TRv2,
>>> but EC spend paths continue to be what's used in practice.
>>> 4) Some better PQ solutions become available, allowing cheap PQ-safe spend-paths
>>> 5) Everyone switches from EC paths to the new PQ paths.
>>> 6) NoEC-day happens, but no one is impacted.
>>>
>>> I think your "Soon-ish" scenario differs as of step (4):
>>>
>>> 4) NoEC-day happens. Massive disruption because the "what's used in practice"
>>> path breaks, but everything is recoverable.
>>> 5) Post-quantum approaches get even higher priority
>>>
>>> I'm skeptical of step 3 here; and would expect to see something more like:
>>>
>>> 3') Only a small proportion of users (ie, the most conscientious/fearful)
>>> switch to P2TRv2 with most preferring to stick with what works
>>>
>>> That has no real impact on the Late-ish scenario, but changes the Soon-ish
>>> scenario to either:
>>>
>>> 4'a) NoEC-day happens substantially before Q-day; people hurry to migrate
>>> to P2TRv2, but it mostly works.
>>>
>>> or
>>>
>>> 4'b) NoEC-day happens essentially at the same time as Q-day; coins get
>>> stolen and we hit the disaster-recovery scenario.
>>>
>>> Perhaps the difference between (3') and (3) playing out in reality
>>> is just having nearly everyone agree that the upgrade is essential,
>>> and rather than leaving it to self-interest/market-dynamics, having a
>>> consistent push that every single wallet/service that doesn't deprecate
>>> every current address type is a danger to the entire ecosystem, even
>>> absent widespread agreement on when/if Q-day will happen. Arguably that
>>> would be easier to agree on if the incremental cost of EC spend paths
>>> in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to
>>> zero, rather than up to ~14% per input.
>>>
>>> Cheers,
>>> aj
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to [bitcoindev+unsubscribe@googlegroups.com](mailto:bitcoindev%2Bunsubscribe@googlegroups.com).
>> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/SHKHzyvg1Rr2E-CBLdgNEinhsndgXog0v4YxlDBJAYVcwjCEnBdByD-3_PSCZzkf9nHeisOKHSqjsBrTgumAVwsZPHHnwrx7FcpZeVZiups%3D%40protonmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACja%3DNz%3DA2wV68MMBYcgOMDjwcXpKNQsptdP2NVqXske%3DONG6w%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2UBm2dVIs3jNHvlZtgXA_7Pfa09T6bK0BBkpvEZUMV8CNgeOwpG87vmUZ9vEnn0TQIfag2uIbiViizuDaND9UljX9LdDqHYXgJhTlW7OGqs%3D%40protonmail.com.
[-- Attachment #2: Type: text/html, Size: 38787 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [bitcoindev] Aligning privacy incentives in P2MR
2026-06-26 9:27 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
@ 2026-06-26 16:11 ` 'conduition' via Bitcoin Development Mailing List
0 siblings, 0 replies; 20+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-06-26 16:11 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 36510 bytes --]
Hey list,
Following up on my original post, a PR has been filed and merged into
BIP360 which amends the spec to change depth-zero trees to be
anyone-can-spend. Kudos to Ethan Heilman for this excellent suggestion in
response to my OP. P2MR is now much more closely aligned with P2TR in terms
of privacy (though still not perfectly).
https://github.com/bitcoin/bips/pull/2198
I would also like to point out that a much more secure candidate than
P2TRv2 exists. In this delving thread
<https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603>,
Ruben, AJ, and I discussed the option of using Boris Nagaev's EC recovery
idea to implement "P2TRH" (essentially P2TR but with the output key hidden
behind a hash). Thanks to EC recovery, key-spend witnesses would still be
only 64 bytes as in P2TR. We would lose Schnorr batch verification, but
gain protection against long-exposure attacks, because bare EC pubkeys are
no longer posted in the script pubkey. A PQ leaf can be hidden in a script
tree commitment just like in P2TRv2.
I think this is a much more compelling candidate than P2TRv2. It still
requires a follow-up soft-fork to at least disable EC key-spending, but
until then users with funds in such hashed addresses would be safe provided
they do not attempt to spend their coins before the disabling fork is
activated.
Ultimately I still suspect the community will favor P2MR, because P2MR will
still be desirable to deploy one way or the other after Q-day, with or
without EC disabling, and regardless of how that disabling is triggered. It
requires no follow-up and incentivizes migration due to its security
properties, now with negligible (32b) cost thanks to recoverable EC leaves.
I would be fine with ArmchairCryptologist's idea of deploying two output
types, although it seems redundant to me personally: Anyone doing
high-volume transacting who cares so much about fees is probably reactive
enough to move coins to P2MR when a CRQC threat is apparent, and could do
so much faster than we can deploy any EC-disabling soft-fork. Also, if fees
are indeed so important, then why has only a tiny fraction of the UTXO set
migrated to P2TR? (I've made these points in earlier emails)
regards,
conduition
On Friday, June 26, 2026 at 3:42:05 AM UTC-6 ArmchairCryptologist wrote:
> In my humble opinion, I think the preference for P2MR vs P2TRv2 for users
> would largely boil down to whether or not someone is a long-term holder, or
> someone who actively makes frequent transactions on the network.
>
> On one hand, if I were a self-reliant long-term holder of significant
> assets (which I may or may not be), I would be reluctant to use P2TRv2 for
> this, since the funds would always be fully exposed to CRQCs until such a
> time EC spending is disabled by a third party, which may or may not happen
> in time.
>
> On the other, if I were making frequent transactions on the network (which
> I may or may not do), I would be reluctant to use P2MR for this due to the
> additional transaction cost, which would be wasteful before CRQCs exist -
> and especially considering that they might never exist.
>
> As such, unless someone were to come up with a different scheme that has
> the best of both worlds, I feel like the discussion should be more along
> the lines of "one, or possibly both if it is beneficial" rather than "we
> have to pick just one no matter what".
>
> Personally, using the ideas Pieter Wuille presented in the other thread,
> my preference would be to add both:
>
> - P2TRv2 using one or both of the Tripwire and Miner Lockdown triggers
> (P2TRv2-T / P2TRv2-ML / P2TRv2-T-ML) to emergency-disable EC spending,
> while still leaving the ability to disable it with a soft fork, for
> frequent transactors and people who trust miners to act responsibly.
>
> - P2MR (plain), with EC spending only disabled with a soft fork, for the
> self-reliant holders who know (how) to not expose their EC public key and
> want full control over their funds.
>
> This would leave EC spending available for P2MR while it is still in the
> "danger zone" and after it has been initially disabled for P2TRv2, but
> when/if EC spending is considered by the developers to be completely
> broken, a follow-up soft fork would disable it for both address types.
>
> I feel like this should be worth the trade-offs of easier wallet
> fingerprinting as well as the increase in implementation complexity and
> long-term maintenance cost - but then again, I'm not the one paying that
> cost, and the people who will might disagree.
>
> --
> Best,
> ArmchairCryptologist
>
> On Thursday, June 25th, 2026 at 12:35 AM, Anthony Derbidge <
> ader...@gmail.com> wrote:
>
> I agree with the core point that Bitcoin’s post-quantum transition cannot
> rely primarily on self-reliance. If the migration requires most users to
> understand Q-Day timing, keep EC spend paths secret, or react quickly under
> pressure, then it is unlikely to protect Bitcoin as a system. The safer
> path needs to be low-friction and close to the default experience long
> before the threat becomes urgent.
>
> That is why a "Later" style strategy seems compelling: ordinary users can
> opt into a future migration path without immediately adopting restrictive
> post-quantum workflows, while consensus can still act when the risk becomes
> concrete. Bitcoin mainnet should remain simple and conservative, while more
> complex identity, recovery, coordination, and enhanced post-quantum
> workflows can exist in optional Bitcoin-aligned layers rather than the base
> layer.
>
> Systems such as Lightning and ProofnetBTC can experiment with those
> optional workflows and recovery models while continuing to settle to
> Bitcoin, allowing innovation without requiring the Bitcoin mainnet itself
> to absorb that additional complexity.
>
> Best,
> Anthony D.
>
> On Wed, Jun 24, 2026 at 3:50 PM 'Antoine Poinsot' via Bitcoin Development
> Mailing List <bitco...@googlegroups.com> wrote:
>
>> Hi AJ,
>>
>> > There are three main variations to this, I think:
>> >
>> > [...]
>> >
>> > Self-reliance: Q-day goes from maybe to definitely faster than consensus
>> > changes can be coordinated, and the only reason people's funds remain
>> > safe is that they can (and do) keep the quantum-vulnerable spend
>> > paths secret.
>>
>> I think that scenario may only result in a successful migration if the
>> vast
>> majority of users have updated their workflows to keep said quantum
>> vulnerable
>> paths secret.
>>
>> This may only happen if the vast majority of users either:
>> 1. have preemptively updated their workflows during the "maybe" period;
>> 2. react promptly enough (within weeks? a couple months?) to migrate all
>> their wealth.
>>
>> Option (1) is utterly implausible. As Pieter explained in his email, we
>> can't
>> expect users to adopt workflows radically at odds with how they use
>> Bitcoin
>> today in response to a (still --at the time they need to migrate)
>> speculative
>> threat.
>>
>> I believe Bitcoin is successful precisely because users are not required
>> to be
>> active bitcoiners and pay close attention to avoid losing their funds. A
>> substantial share of users value and rely on this property, and therefore
>> Option
>> (2) is likewise implausible.
>>
>> Therefore i don't think the "Self-reliance" variation can result in a
>> successful
>> migration.
>>
>> > As far as I can see, only having P2TRv2 addresses would rule out the
>> "self-reliance" path here.
>> >
>> > Picking when Q-day will occur, either individually for determining
>> > your own security posture, or collectively for organising a consensus
>> > change seems very difficulty: it involves evaluating both complex state
>> > of the art physics research, but also estimating the covert abilities
>> > of national governments and the incentives to attack bitcoin prior to
>> > revealing their capabilities. To me, that doesn't bode well for a smooth
>> > and fast deployment of a consensus change in advance of problems
>> occuring.
>>
>> Yes. P2TRv2 optimizes for the "Later dominant" path at the expense of the
>> "self-reliance" path. I think this is good, because our best (only?) shot
>> at
>> fully migrating large amounts of users is to provide them with a
>> virtually free
>> way to opt into a future consensus-triggered migration.
>>
>> The follow-up step does not require predicting with precision the day on
>> which
>> an attack would be set up, but to be done before a CRQC could
>> realistically
>> threaten Bitcoin. Definitely not a piece of cake, but not infeasible. In
>> fact if
>> P2TRv2 does become the Schelling point for PQ migration, i would be more
>> concerned about the follow-up step happening too soon rather than too
>> late.
>>
>> Of course, if a full CRQC is built in secret, with no reliable
>> information about
>> the progress getting out whatsoever, and subsequently starts attacking
>> Bitcoin
>> overnight, then this migration strategy would fail. But so would any other
>> migration strategy!
>>
>> > It's possible that general carelessness on behalf of users would also
>> > rule out the effectiveness of a self-reliance approach: if only the most
>> > conscientious 1% of users make use of P2MR securely, that might secure
>> 10%
>> > of funds, but having 90% of the bitcoin supply crash probably wouldn't
>> be
>> > very valuable either.
>>
>> For what it’s worth, while the supply at risk matters, i think the primary
>> metric we should optimize for is the share of users at risk. Widespread,
>> indiscriminate theft would fatally undermine trust in Bitcoin, whereas
>> more
>> concentrated sweeps (such as that of early, presumed-lost coins) *could*
>> cause
>> severe price shocks without necessarily destroying confidence in the
>> system
>> itself.
>>
>> > > > Theorycrafting for a second here. It's reasonable to conjecture fee
>> > > > rates will be much higher post-Q-day, and thus P2MR's 32 byte
>> advantage
>> > > > over P2TRv2 will yield significant savings for end-users in absolute
>> > > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes
>> becomes
>> > > > significant (100 sats per spend or more).
>> >
>> > I don't think that is the right way to look at. 8vb/input is about
>> > an additional 14% today (vs a taproot key-path spend), but with the
>> > post-quantum signatures we have available now that's likely to reduce
>> > to ~7% (SHRINCS) or ~1% (winternitz).
>>
>> Yes. Also, our goal here is to mitigate the risk that a CRQC materializes
>> by
>> providing a path for Bitcoin to survive it. We shouldn't take the risk
>> for a
>> certainty and shift the goal to designing the best possible PQ-Bitcoin.
>> This can
>> be done if/when it becomes clearer that CRQCs will become a reality.
>>
>> > > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
>> > > perfectly. The expectation should be just that it happens before
>> Q-day,
>> > > and when it looks inevitable or the fear about that is large enough.
>> >
>> > FWIW, I would define "timed perfectly" precisely as "EC disabling
>> > fork happens before Q-day". Maybe allowing some additional months of
>> > EC-efficiency would be a win while not taking out too much migration
>> time,
>> > but for me "perfection" here means "no one who upgraded lost money via
>> > quantum-related vulnerabilities".
>>
>> I don't think that's a good definition of "timed perfectly". By your
>> definition,
>> EC could be disabled from the get-go, Bitcoin's migration would
>> spectacularly
>> fail because very few users switched to the new output type, and it would
>> still
>> be "timed perfectly". :)
>>
>> I would define "timed perfectly" as maximizing the number of migrated
>> users
>> without any of them losing money to a CRQC. But it's not quite the right
>> definition, because there is also probably an aspect of not doing it
>> prematurely, i.e. in the scenario where the CRQC threat never
>> materializes, no
>> P2TRv2 user is forced to use heavily restrictive PQ worklows.
>>
>> > Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
>> > "Later-dominant" scenario, and only to the degree that it's slightly
>> > cheaper prior to Q-day.
>>
>> From the perspective that a successful migration hinges on virtually all
>> users
>> opting into a (full) migration to CRQC-safe workflows, this difference in
>> costs
>> is material. Especially since users would presumably need to opt in long
>> before
>> we know whether CRQCs will become a reality anytime soon.
>>
>> > My (cynical?) view is the only people who will adopt either P2TRv2 or
>> > P2MR prior to NoEC-day being schedule will be people who are willign
>> > to use those features in a quantum-safe way -- that is, keeping their
>> > EC pubkeys secret, and only revealing those EC pubkeys to spend them
>> > immediately, prior to NoEC-day.
>>
>> How can this apply to P2TRv2, where EC pubkeys are always public?
>>
>> I think i disagree that most users of P2MR, were it made available, would
>> treat
>> their EC public keys as secrets. But more importantly, the whole point of
>> P2TRv2, or more generally of what Pieter labels "Later" type strategies,
>> is
>> precisely to avoid imposing on individual users the costs of treating
>> their
>> public keys as secrets. P2TRv2 (compared to other "Later" options) also
>> ensures
>> that using it is no more costly than using any other available output
>> type.
>> Together, these properties may make users who are not yet particularly
>> concerned, or are simply unaware, indifferent to opting in: they bear the
>> additional costs only if the CRQC threat materializes and are no worse
>> off if it
>> does not.
>>
>> > > This focus on allowing individual users the ability to safeguard their
>> > > coins just feels like a red herring: [...]
>> >
>> > While I appreciate your point, I also feel that "allowing individual
>> > users the ability to safeguard their coins" is pretty close to the
>> entire
>> > point of Bitcoin. :)
>>
>> Cherry-picking this part of Pieter's sentence does not do it justice. Of
>> course
>> we all agree about this. But as he says in the part you left out, not
>> addressing
>> this issue as a systemic one is exactly how we lose that property: "I'm
>> not
>> worried about my own coins being stolen. I'm worried about (fear of) a
>> CRQC
>> undermining trust in the currency as a whole, or through a fear-driven
>> consensus
>> change the ecosystem destroying its own values beforehand."
>>
>> > having a consistent push that every single wallet/service that doesn't
>> deprecate every current
>> > address type is a danger to the entire ecosystem, even absent
>> widespread agreement on when/if
>> > Q-day will happen. Arguably that would be easier to agree on if the
>> incremental cost of EC spend
>> > paths in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is
>> near to zero, rather than up
>> > to ~14% per input.
>>
>> Yes, that's essentially the case for P2TRv2.
>>
>> Best,
>> Antoine
>>
>>
>>
>> On Thursday, June 18th, 2026 at 1:09 AM, Anthony Towns <
>> a...@erisian.com.au> wrote:
>>
>> > On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote:
>> > > I want to first correct a potential misunderstanding here, because
>> > > I realize the terms "Later" and "Never" aren't very descriptive. They
>> > > are specifically about an expected and relied-upon expectation that an
>> > > EC-disabling fork will happen that at least applies to the output type
>> > > itself, in time. "Later" is the expectation that such a disabling will
>> > > happen after the output type is introduced, but still in time (so,
>> before
>> > > Q-day). Outputs without a strong expectation that their EC
>> paths/opcodes
>> > > will be disabled, or not in time, I classify under "Never".
>> >
>> > > I believe here you're instead arguing for P2MR ("Merkle-Never")
>> > > over all "Later" options. That was my previous point: I think (solely)
>> > > having "Never" output types like P2MR is just utterly insufficient for
>> > > any worthwhile migration. It's so incompatible with today's workflows
>> > > that it either won't be adopted, or (possibly inadvertently) adopted
>> > > in an insecure fashion. Yes, it gives people the option to safeguard
>> > > their own coins, but to me that's disaster recovery territory - I
>> think
>> > > we ought to prioritize maximizing the chances for saving the currency
>> > > as a whole in case Q-day comes, not a small subset of individual
>> users'
>> > > coins. P2MR (alone) doesn't really achieve much in that regard in my
>> view,
>> > > thus we at least need something of the "Later" class in addition.
>> >
>> > I'm not sure I follow/agree with the logic here. I think the general
>> idea
>> > is:
>> >
>> > 1) we create some new address types that allow post-quantum spending,
>> but
>> > also allow efficient quantum-vulnerable spending that can be used prior
>> > to Q-day
>> >
>> > 2) many people migrate to these new address types
>> >
>> > 3) Q-day arrives
>> >
>> > 4) all spending goes via the post-quantum paths, and everyone's funds
>> are
>> > safe
>> >
>> > There are three main variations to this, I think:
>> >
>> > Later-dominant: towards the end of (2) but prior to (3), the
>> > quantum-vulnerable spend paths are disabled in a predictable, planned
>> > manner, preventing coin theft, but not disrupting active usage
>> > significantly (or not disrupting it any more than the proximity of
>> > Q-day already is).
>> >
>> > Self-reliance: Q-day goes from maybe to definitely faster than consensus
>> > changes can be coordinated, and the only reason people's funds remain
>> > safe is that they can (and do) keep the quantum-vulnerable spend
>> > paths secret.
>> >
>> > Disaster-recovery: neither the "predictable/planned consensus change" of
>> > Later nor the "everyone takes responsiblity for their own funds"
>> > works, and the only way to avoid a large percentage of bitcoin
>> > becoming a reward for quantum research is to replace EC spend paths
>> > with a ZK proof of knowledge of a BIP32 seed or similar, requiring
>> > a hard fork. Such a hard fork would be certain to be controversial
>> > ("why at this height: I received a payment five blocks after //
>> > my funds were stolen by a quantum attacker five blocks earlier //
>> > why are only BIP32 funds recoverable not scheme X"), but if no other
>> > approach works, might still be the ultimately outcome.
>> >
>> > > So the point here was just: if you already accept the need for a
>> "Later"
>> > > output type (= one with builtin-in EC disabling expected from the
>> start),
>> > > P2TRv2 is preferable over P2MR+ED, because:
>> >
>> > As far as I can see, only having P2TRv2 addresses would rule out the
>> > "self-reliance" path here.
>> >
>> > Picking when Q-day will occur, either individually for determining
>> > your own security posture, or collectively for organising a consensus
>> > change seems very difficulty: it involves evaluating both complex state
>> > of the art physics research, but also estimating the covert abilities
>> > of national governments and the incentives to attack bitcoin prior to
>> > revealing their capabilities. To me, that doesn't bode well for a smooth
>> > and fast deployment of a consensus change in advance of problems
>> occuring.
>> >
>> > It's possible that general carelessness on behalf of users would also
>> > rule out the effectiveness of a self-reliance approach: if only the most
>> > conscientious 1% of users make use of P2MR securely, that might secure
>> 10%
>> > of funds, but having 90% of the bitcoin supply crash probably wouldn't
>> be
>> > very valuable either. But even then, that may make the
>> "disaster-recovery"
>> > approach less problematic, by ensuring the 1%/10% who were conscientious
>> > can avoid being part of the "my funds were stolen by a quantum attacker"
>> > contingent, eg.
>> >
>> > > > Theorycrafting for a second here. It's reasonable to conjecture fee
>> > > > rates will be much higher post-Q-day, and thus P2MR's 32 byte
>> advantage
>> > > > over P2TRv2 will yield significant savings for end-users in absolute
>> > > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes
>> becomes
>> > > > significant (100 sats per spend or more).
>> >
>> > I don't think that is the right way to look at. 8vb/input is about
>> > an additional 14% today (vs a taproot key-path spend), but with the
>> > post-quantum signatures we have available now that's likely to reduce
>> > to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,
>> > you're only getting an expected savings in fees / increase in block
>> > capacity on that order of magnitude, ie: 1%-7%. That's nice to have,
>> > for sure, but doesn't compare to introducing a new address type that
>> > puts the PQ sigs in an extension block, or one that uses ZK proofs to
>> > do cross-input or cross-transaction signature aggregation, eg. So a 32B
>> > witness overhead for an unused/unusable key-path post-Q-day doesn't seem
>> > very relevant to me.
>> >
>> > > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
>> > > perfectly. The expectation should be just that it happens before
>> Q-day,
>> > > and when it looks inevitable or the fear about that is large enough.
>> >
>> > FWIW, I would define "timed perfectly" precisely as "EC disabling
>> > fork happens before Q-day". Maybe allowing some additional months of
>> > EC-efficiency would be a win while not taking out too much migration
>> time,
>> > but for me "perfection" here means "no one who upgraded lost money via
>> > quantum-related vulnerabilities".
>> >
>> > One reason I'm doubtful is that I think for some the "it looks
>> inevitable"
>> > threshold has already been crossed, eg:
>> >
>> > >> So let me attempt to partially fill the silence, similarly to what
>> > >> Scott Aaronson did in his April 29 post. Given everything I know,
>> > >> including scary non-public information, I now put the odds of qday by
>> > >> 2032 at 50%. 10% by 2030.
>> >
>> > >> IMO a good target date for migration is 2029, roughly 3.5 years
>> > >> out. 2029 happens to be the date selected by Google, Cloudflare, and
>> > >> the Ethereum Foundation.
>> >
>> > https://x.com/drakefjustin/status/2061793725299224676
>> >
>> > >> So, here it is: if quantum computers start breaking cryptography a
>> > >> few years from now, don’t you dare come to this blog and tell me that
>> > >> I failed to warn you. This post is your warning. Please start
>> switching
>> > >> to quantum-resistant encryption, and urge your company or
>> organization
>> > >> or blockchain or standards body to do the same.
>> >
>> > https://scottaaronson.blog/?p=9718
>> >
>> > Personally, that leaves me at a minimum very skeptical of the utility
>> > of introducing either P2MR or P2TRv2 (etc) approaches that don't also
>> > introduce a quantum-safe spending path on day one.
>> >
>> > > First a meta-point here: the reason I like separating the discussion
>> into different dimensions than just "P2TRv2 vs P2MR" is because there are
>> more options than those two, and not every argument applies to the same
>> separation into two classes. Let me list them explicitly here, roughly in
>> decreasing order of how strongly I feel about them:
>> > > - We need at least a "Later" option for meaningful migration, i.e.
>> P2TRv2 or P2MR+ED.
>> > > - Within the "Later" option, P2TRv2 is preferable.
>> > > - A "Later" option benefits from being the only PQC migration
>> strategy, making it a Schelling point.
>> >
>> > Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
>> > "Later-dominant" scenario, and only to the degree that it's slightly
>> > cheaper prior to Q-day. If it were the only available option, that would
>> > increase the risk of loss involved with both the other approaches. (I
>> > don't think P2TRv2 is meaningfully more private than P2MR in the way
>> > taproot v1 is, as presumably you'd only adopt that address format if
>> > you wanted to have a post-quantum script path)
>> >
>> > > > You'd have to convince everyone to deploy and then adopt P2TRv2
>> today under the public knowledge that it is insecure and their coins are
>> more likely to be stolen. That's a hard sell.
>> > >
>> > > > How does one pitch P2TRv2 to users? "It will be quantum secure one
>> day we promise because everyone is incentivized to fix it later as Bitcoin
>> will die if we don't."
>> > > >
>> > > > How do you pitch P2MR? "It's quantum secure if you use it
>> correctly."
>> > > To me, the pitch is "Bitcoin can only remain valuable if we
>> mostly/all migrate." for both. P2TRv2 is just much easier to adopt, because
>> P2MR (or any "Never" output type) fundamentally requires many users to
>> change their workflows entirely.
>> >
>> > Let's call NoEC-day the earlier of activation of a soft-fork disabling
>> > EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably
>> > equal to "the day the bitcoin ecosystem has finally agreed that CRQCs
>> > are inevitable".
>> >
>> > My (cynical?) view is the only people who will adopt either P2TRv2 or
>> > P2MR prior to NoEC-day being schedule will be people who are willign
>> > to use those features in a quantum-safe way -- that is, keeping their
>> > EC pubkeys secret, and only revealing those EC pubkeys to spend them
>> > immediately, prior to NoEC-day. In that view, the EC-spend-paths of such
>> > coins prior to NoEC-day are only an opportunistic "make spends cheaper"
>> > shortcut, they don't allow the funds to be used in lightning channels
>> > or to let your wallet be audited via sharing an xpub or anything
>> similar.
>> >
>> > Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible
>> > that lightning software could get an upgrade to generate post-quantum
>> > signatures for channel commitments or HTLC claims, I just think it's
>> > pretty unlikely that that will happen at a meaningful scale when
>> everyone
>> > has much more immediate and less theoretical things to work on prior to
>> > NoEC-day, especially when the efficiency/performance of such changes is
>> > likely to be very low.
>> >
>> > > This focus on allowing individual users the ability to safeguard their
>> > > coins just feels like a red herring: [...]
>> >
>> > While I appreciate your point, I also feel that "allowing individual
>> > users the ability to safeguard their coins" is pretty close to the
>> entire
>> > point of Bitcoin. :)
>> >
>> > > In either case, I consider anything that requires hardcoding
>> > > specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus
>> > > rules (and only allowing those coins to survive) to be squarely in
>> > > disaster-recovery land. It feels like embracing arbitrariness, and
>> > > giving up on the permissionlessness that makes Bitcoin interesting -
>> > > if the community shows it can get consensus on effectively burning
>> > > coins except those that match a whitelist, it feels hard to maintain
>> > > censorship-freeness as a value, even if the whitelist includes most of
>> > > the (active) coins. That is of course not to say such techniques
>> aren't
>> > > interesting to work on, but to me, their place is in disaster recovery
>> > > scenarios to save what's left, after Q-day, if migration attempts were
>> > > unsuccessful. In such a setting, I think we're already in effectively
>> an
>> > > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly
>> > > growing) set of ways to recover burned coins can be hardforked in.
>> >
>> > Just for the record, I think the above is an accurate description of the
>> > "disaster-recovery" scenario above: the "quantum-safe" hard-fork variant
>> > of bitcoin would be fairly described as a utxo-bootstrapped altcoin,
>> > would compete in the market with the "quantum-unsafe" bitcoin that
>> > existing nodes would continue to follow, and possibly there would be
>> > many slightly varying such altcoins competing with each other, eg on
>> > exactly what height the utxo snapshot was taken or what coins become
>> > spendable. It would not be a fun time for holders of affected utxos.
>> >
>> > > My impression is that your approach is to have an answer for many
>> > > possible futures, including ones where Q-day arrives within just a few
>> > > years.
>> >
>> > "The key of strategy... is not to choose a path to victory, but to
>> choose
>> > so that all paths lead to a victory."
>> >
>> > -- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit
>> >
>> > > But optimizing for disaster-recovery also means reducing the
>> > > chances of preserving Bitcoin as we know it in the scenarios where a
>> > > successful migration is still possible. And if Q-day does arrive that
>> > > soon, I don't see what we can do today that would preserve Bitcoin in
>> > > a form we care about anyway. By accepting that, we can focus on the
>> > > futures where our choices today can still materially improve the
>> outcome.
>> >
>> > Preserving bitcoin as a personally-possessible inflation resistant
>> > store of value seems both possible and worth caring about, even if other
>> > constraints means that many people can't afford to personally hold it
>> > (and have to go through ETFs/exchanges/banks) and that it can't be used
>> > for day-to-day transactions. Would be very disappointing if true, and
>> > even given Q-day in a few years I expect we could do better than just
>> > that, but it doesn't feel like a throw-in-the-towel event to me.
>> >
>> > > > Essentially yes though, I expect the majority of holders will
>> probably
>> > > > migrate to PQ addresses via rescue protocols, either on Bitcoin or
>> a fork
>> > > > thereof. Even if we can't come to consensus and deploy a new output
>> type,
>> > > > we'll still be able to rescue most coins. It's just that we'd have
>> nowhere
>> > > > to rescue them to, so we ought to make PQ wallets available soon,
>> so we're
>> > > > not in a rush to build them later when we need them. If a PQ wallet
>> can
>> > > > use cheap EC signatures while they're still trustworthy, all the
>> better
>> >
>> > FWIW, that's my guess on how things would play out if the near-term
>> Q-day
>> > timelines I've seen (ie, 2029 to 2035) match reality. I hope that's
>> > pessimistic (either because the Q-day timelines are bad estimates, or
>> > because migration happens in a more orderly fashion), but I guess we'll
>> > see. I don't rate my ability to evaluate Q-day predictions very highly.
>> >
>> > > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
>> >
>> > I'm not in a position to judge, but the google paper claims:
>> >
>> > "Indeed, if a leading quantum architecture encounters and overcomes
>> > all its scaling challenges before producing a device able to
>> > solve (for example) 32-bit ECDLP, then there may be little time
>> > between the breaking of 32-bit ECDLP and the breaking of 256-bit
>> > ECDLP. Furthermore, the community should not expect to see published
>> > demonstrations of the most advanced quantum error-correction
>> > architectures and quantum algorithms deployed to cryptanalytic
>> > problems. Thus, a successful public demonstration of Shor’s
>> > algorithm on a 32-bit elliptic curve should not be seen as a wake-up
>> > call to adopt PQC as much as a potential signal that PQC adoption
>> > has already failed."
>> >
>> > and places the required tiffoli gates and logical qubits for a 32-bit
>> > break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100)
>> > for 256-bit.
>> >
>> > > Of course, if you believe it's the only possible future, I understand
>> > > you'd come to a different conclusion. But is it really? Do you think
>> > > this isn't a plausible future:
>> >
>> > > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added
>> too) gets introduced in the next few years, with hash-based PQC opcodes.
>> > > - Over the course of the next decade or so, it gets adopted by
>> practically all active users.
>> >
>> > I think it might be better to look at that scenario in a more
>> fine-grained
>> > way? I think your "Late-ish" scenario is:
>> >
>> > 1) P2TRv2 (or whatever) is introduced
>> > 2) Some PQ opcodes get enabled, allowing expensive but PQ-safe
>> spend-paths
>> > via those outputs
>> > 3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of
>> P2TRv2,
>> > but EC spend paths continue to be what's used in practice.
>> > 4) Some better PQ solutions become available, allowing cheap PQ-safe
>> spend-paths
>> > 5) Everyone switches from EC paths to the new PQ paths.
>> > 6) NoEC-day happens, but no one is impacted.
>> >
>> > I think your "Soon-ish" scenario differs as of step (4):
>> >
>> > 4) NoEC-day happens. Massive disruption because the "what's used in
>> practice"
>> > path breaks, but everything is recoverable.
>> > 5) Post-quantum approaches get even higher priority
>> >
>> > I'm skeptical of step 3 here; and would expect to see something more
>> like:
>> >
>> > 3') Only a small proportion of users (ie, the most
>> conscientious/fearful)
>> > switch to P2TRv2 with most preferring to stick with what works
>> >
>> > That has no real impact on the Late-ish scenario, but changes the
>> Soon-ish
>> > scenario to either:
>> >
>> > 4'a) NoEC-day happens substantially before Q-day; people hurry to
>> migrate
>> > to P2TRv2, but it mostly works.
>> >
>> > or
>> >
>> > 4'b) NoEC-day happens essentially at the same time as Q-day; coins get
>> > stolen and we hit the disaster-recovery scenario.
>> >
>> > Perhaps the difference between (3') and (3) playing out in reality
>> > is just having nearly everyone agree that the upgrade is essential,
>> > and rather than leaving it to self-interest/market-dynamics, having a
>> > consistent push that every single wallet/service that doesn't deprecate
>> > every current address type is a danger to the entire ecosystem, even
>> > absent widespread agreement on when/if Q-day will happen. Arguably that
>> > would be easier to agree on if the incremental cost of EC spend paths
>> > in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to
>> > zero, rather than up to ~14% per input.
>> >
>> > Cheers,
>> > aj
>> >
>>
>> --
>> 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/SHKHzyvg1Rr2E-CBLdgNEinhsndgXog0v4YxlDBJAYVcwjCEnBdByD-3_PSCZzkf9nHeisOKHSqjsBrTgumAVwsZPHHnwrx7FcpZeVZiups%3D%40protonmail.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+...@googlegroups.com.
>
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CACja%3DNz%3DA2wV68MMBYcgOMDjwcXpKNQsptdP2NVqXske%3DONG6w%40mail.gmail.com
> .
>
>
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/88207cb2-e266-4f84-be3f-f245a3e2724en%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 43386 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread