The proposal is P2MR with PQ sigs and no Schnorr address reuse. Address reuse in this setting should be treated as security vulnerability.
The context was a discussion of using P2MR with a EX fallback “until it’s time”. This avoids the substantial fee and functionality-loss overhead of hash-based signatures “until it’s time”.
Yes, of course people could opt to not do that, but then we’re back to where we started - not solving a useful problem for those who the problem actually impacts.
> As such, P2MR with a EC-based key for short-term efficiency reasons has the same quantum security as P2TR or P2TRv2.
This is incorrect.
1. As long as the Schnorr pubkey has not been leaked by the wallet. The wallet is PQ safe.
Right, the context is a “normal” wallet which transacts occasionally. A pure receive-only wallet is fine but that’s such a narrow use-case I’m not even sure it’s worth discussing?
2. Even if the Schnorr pubkey has been leaked by the wallet, if the PQ leaf hash is not publicly known it is safe against long exposure attacks.
Huh? If the address is reused as-is (as is the case the most popular Bitcoin wallets today) a CRQC can trivially steal the funds with the EC key. What am I missing?
P2TR is **always** vulnerable to short and long exposure attacks. There is no better wallet hygiene that can fix this.
You are comparing:
P2MR + PQ signatures: A wallet messing up their implementation of PQ safe transactions and introducing a vulnerability and weakening a subset of outputs. If implemented correctly 100% of the outputs are safe.
vs.
P2TR: A design where 100% of outputs are vulnerable even if the implementation is perfect.
These aren't the same thing at all, nor do they provide the same security.
No, I’m comparing a realistic deployment of P2MR for the wallets which are relevant to the “we should give them maximum time to migrate” discussion in a world where they use P2MR to a world without. Yes, there are wallets that would use P2MR “right”, but those wallets literally do not matter for a discussion around what we need to get in place as soon as possible - large custodians who won’t make any mistakes with their cold storage are just as capable of making no mistakes later as they are today.
For the actual wallets that we want to get migrating as soon as possible we’re talking about things that aren’t going to pay a 10x cost increase and are going to continue using a single static address.
Matt
Oh, apologies, I was in a bit of a rush yesterday and forgot the most important reason why P2MR
doesn't help at all - address reuse.
In practice the "long tail" of Bitcoin wallets (which, as noted below are most of what we care
about) do strict address reuse. Mostly a consequence of address-based blockchain systems its become
an expected feature that the address displayed in a wallet is static and does not change. As such,
P2MR with a EC-based key for short-term efficiency reasons has the same quantum security as P2TR or
P2TRv2.
Matt
On 4/14/26 4:04 PM, Matt Corallo wrote:
> I'm gonna top-post because I think we're too far in the weeds and the high-level argument is getting
> lost. No, of course I do not thing that our job is to "convince" any quantum skeptics. What is our
> job is making sure the *bitcoin system* is ready in case a CRQC does become a reality. That means
> looking at the system as a whole, not individuals. Notably, this means that if the decisions we make
> result in a bitcoin where some people who are super worried about a CRQC have migrated but everyone
> else hasn't, and a CRQC becomes an imminent reality, *we've failed*. In such a world, bitcoin
> becomes largely value-less and the paranoid folks who migrated long ago and paid for it have
> accomplished absolutely nothing. I hope we can at least agree on this point.
>
> On 4/14/26 2:56 PM, conduition wrote:
>> Hi Matt,
>>
>>> Right but you didn't contend with my point at all, only ignored it. Its great that you can move
>>> your coins into something so that your coins aren't stolen but...who cares? If a huge % of
>>> outstanding bitcoin supply is being stolen that impacts you just as much as if your own coins
>>> were being stolen!
>>
>> I don't think I ignored anything, but maybe I just didn't understand your point.
>>
>> To me, your point seems to be (I'm summarizing here) that "Nobody will migrate to P2MR before Q-
>> day because it is slightly worse than P2TR until Q-day". And your conclusion is, in your own words:
>>
>>> Thus, ISTM the focus *has* to be on something that has minimal drawbacks - not losing the script
>>> policy privacy of P2TR, low or no fee overhead, etc.
>>
>> This seems to imply you're arguing that at least some of those same people (who wouldn't use P2MR)
>> WOULD migrate to P2TRv2, because it is exactly as good as P2TR until Q-Day.
>
> Yes, exactly.
>
>> I respectfully disagree with this argument, and I gave my reasoning as to why in my last reply. To
>> review:
>>
>> - P2MR is quantum-secure by default.
>> - P2MR is more efficient long-term.
>
> This assumes a CRQC.
>
>> - P2MR does not commit us to carrying legacy crypto cruft past its shelf-life.
>
> Nor does P2TRv2? No one is suggesting P2TRv2 becomes some standard that all wallets use forever. No
> matter what we do we carry the "cruft" of P2TR in Bitcoin forever (+/-), P2TRv2 has literally zero
> additional cruft.
>
>> - P2MR and P2TRv2 are both equivalent to quantum-skeptics, who have no incentive to migrate either
>> way.
>
> See below
>
>> - The short-term efficiency difference in P2MR and P2TRv2 is a negligible trade-off to anyone who
>> ISN'T a total quantum-skeptic.
>> - Fee-sensitive users are online and adaptive, and can use P2TR until Q-day; They do not need
>> P2TRv2 any more than fee-insensitive users.
>
> I disagree very strongly with this. This would be true if everyone had their own custom-built wallet
> that they designed to meet their goals exactly. In the real world people pick wallets based on many
> other factors, and developers build wallets for many different users, some of which may be fee
> sensitive and some of which may not be, all of whom will use the same default configuration.
>
>> - P2MR has utility even if Q-day never comes.
>
> I disagree. The overall utility to the Bitcoin system of something like P2TR is also the global
> default that is strongly baked in which results in
>
>> - Also, I failed to make this point in my last reply: P2MR and P2TRv2 have the same privacy
>> profile AFAICT, assuming both commit to a hash-based fallback leaf script.
>
> I don't see how this is true in practice. Maybe in a world where everyone uses P2MR with a single
> left-hand leaf at depth one with a single EC schnorr key which is musig2, but....come on. The value
> of taproot is that its design natively adds this *for free* to every contracting protocol, and not
> only adds it for free but *forces* every contracting protocol to carry at least some of the cost if
> they decline to do this. This results in a massive net privacy win across the entire Bitcoin
> ecosystem, and I don't see how you can argue that these things are equivalent in practice, just
> because they could in theory be used in a way where they are in theory.
>
>> Therefore, P2MR is the better long-term choice.
>>
>> If we assume Bitcoin will survive long into the future after CRQCs appear, then we should favor
>> the best long-term design choices over short-term compromises. Thus, we should deploy P2MR and NOT
>> deploy P2TRv2.
>
> Not only do I disagree with most of your points here, but I disagree that we should be optimizing
> for a "long-term design" which we intend to be *the* design we use in the face of an imminent CRQC.
> We already know we're not doing that - we're not using lattices or isogenies or whatever we'll
> actually end up using because those things aren't ready. They likely will be by the time a CQRC is
> imminent. If they aren't, we'll almost certainly be back to the drawing board on witness discounts
> and whatever else which will mandate a new address format anyway. There is basically zero chance
> that whatever we do today will be what we end up using "normally" in a world with a CRQC.
>
>>> But what about someone who sees quantum computers as 90% FUD that might happen eventually but
>>> won't for 50 years but still gets users nagging them about it and support for importing some new
>>> seedphrase format that derives a SHRINCS key in addition to the EC ones? That's much less of a
>>> straw man and way more realistic - and also a place where someone might do the work (or, well,
>>> merge a PR if its done for them) but probably won't if they're building a consumer wallet that is
>>> used by some to transact regularly (but, let's face it, used primarily by some people who put
>>> some money in and then forgot about it for five years).
>>
>> Very specific. You're talking about wallet developers here, right? Exchanges? Bitcoin businesses
>> in general etc? And you're saying that the people running these businesses and building the
>> wallets - those who are being "nagged" to implement something that the rest of the cryptographic
>> world has already starting rolling out in production [1] - You're saying that a subclass of these
>> people - those who are "mostly" skeptical of quantum hype - WOULD implement P2TRv2, but WOULDN'T
>> implement P2MR?
>>
>> It's debatable how big that subclass would be, especially given the current landscape.
>
> I don't think this is "very specific" at all? In fact I think this is the *dominant* case. By coin
> volume, yes, the biggest wallet is Coinbase's custody product. By wallet count, the biggest wallet
> is probably something like Trust Wallet. Its trash, doesn't care about Bitcoin, makes many terrible
> design decisions which are actively hostile to its users, and yet they are the ones who actually
> decide in what way most bitcoin are stored! I don't know what their particular view on quantum is,
> but my sense of most developers is that the view is generally "well, it'll happen at some point, but
> its not totally urgent". Meanwhile, people are almost without question going to nag some wallets for
> "quantum security" once its a thing.
>
> You might reasonably disagree with whether they would implement P2TRv2 vs P2MR, I think its
> definitely a subtle argument, but I don't think you can reasonably disagree that these are exactly
> the most important constituent here.
>
> > But even if one confidently sees CRQCs as 50 years away, then I'd refer back to my earlier
> response, and argue that any such skeptical developer has no reason to implement either P2MR or
> P2TRv2 today, apart from compatibility with other software which DOES implement them. If "nagging"
> is the only motivation a dev or business owner has to implement a PQ output type, then one need not
> distinguish between the two. They'd just implement whatever is standardized to please their users,
> and carry on with their day.>
>> If I'm being a little more realistic, most wallet devs will follow whatever is standardized just
>> to get more market share. I somehow doubt devs will turn up their noses and say "it's not
>> efficient enough, I won't implement that even if a large chunk of my customers are clamoring for it."
>>
>> I think this reveals the source of our disagreement. In your arguments, you are placing a lot of
>> weight on the importance of pre-quantum fee-efficiency in the new output type, so much so that you
>> seem to think devs would willingly ignore a potential existential threat to save users a few sats
>> per transaction.
>
> It is far from only "pre-quantum fee-effeciency", its also the value for the entire Bitcoin system
> of the privacy taproot offers. But I think the more important argument specifically here is the
> question of what they will make the *default*. In a world with P2MR I could absolutely see them
> implementing a P2MR option which you can opt into in the settings. That fails to accomplish our
> goals entirely. Maybe they also would do the same for P2TR/P2TRv2, but I at least think that's
> somewhat less likely, but in any case better for the bitcoin system overall if that's where we land.
>
>> But maybe look at it this way:
>>
>> - Whether quantum computers are 5, 10, 50 years or more away, anyone who truly cares about a few
>> extra sats per TX can continue to use P2TR when actively transacting pre-Q-Day, and use P2MR for
>> high-security cold storage. The result is mostly the same as if we deployed P2TRv2. Yes, there is
>> some risk of being caught with your pants down on Q-day, but the same is true of P2TRv2 because we
>> might not time the key-spend disabling follow-up fork correctly.
>> - Mining fees are a part of everyday life for Bitcoiners, and the pre-quantum fee difference
>> between P2TR and P2MR is NOTHING compared to the fee spike we'll all have to endure after Q-day,
>> no matter what fancy cryptography we may end up using by then. There are far more important things
>> we can optimize.
>>
>>> Again, you ignore that the impact is global, not local. Yes, quantum-skeptics have to be brought
>>> along over time if you want to have any hope of bitcoin actually being relevant.
>>
>> Our job is not to proselytize and convince people that the quantum threat is real, nor is it even
>> to encourage migration by design. Our job is to prepare an optimal migration path in case the
>> threat is real. If CRQCs do appear, everyone will want to migrate to PQC sooner or later. If they
>> do not, everyone moves on with their lives and the new output type becomes a relic (in P2MR's
>> case, an occasionally useful one).
>>
>> Even if you feel your job IS to convince and migrate as many users as possible, I would argue
>> it'll be hard to convince anyone to migrate to an address format that isn't PQ-safe by default.
>> Bitcoiners trust code, not promises, and P2TRv2 is only PQ-safe if you trust its promise of a
>> future soft fork, while its code would be PQ-vulnerable by default. And the only benefit to
>> accepting this risk seems to be a trivial discount in fees pre-Q-day. I don't speak for everyone
>> of course, but personally I'd rather keep my cold-storage coins on a P2WSH address than on P2TRv2,
>> because at least then I know for sure a CRQC will have a hard time stealing my coins regardless of
>> what upgrades the community does or doesn't deploy in the future.
>
> See intro. I don't really see how you can reasonably conclude that our goal is only to enable a
> small subset of people to migrate. That way leas only to a total failure of the bitcoin system.
>
>>> Sure, but any short term hash-based signature migration path is really not intended as the final
>>> state anyway - if Bitcoin is stuck with only hash based signatures and a CRQC exists in 20 years
>>> that's a pretty terrible outcome. Hopefully by the time a CRQC becomes a real threat we have much
>>> more confidence in lattice-based systems (or whatever PQC is popular then) and we can add
>>> whatever output type makes sense at that point.
>>
>> I agree about hash-based sigs not being the endgame. Though, this doesn't mean P2MR isn't. We're
>> talking about output types here, not opcodes. I would argue P2MR remains useful regardless of the
>> cryptography we use: lattice, isogeny, hash-based, multivariate, whatever. Merkle trees have been
>> around for almost 50 years and seem hard to beat.
>>
>> For instance, we could reconstruct P2TR using isogenies [2], but would we really want to? Using
>> today's witness discount levels, it would actually be MORE efficient overall to spend with SQIsign
>> inside a P2MR tree, than it would be to use SQIsign to key-spend with some hypothetical "Pay-to-
>> supersingular-curve" output type [^3]. I realize I'm kinda trashing my own research by saying
>> this, but it shows how hard it is to beat P2MR, even if you can accept new cryptographic
>> assumptions and the accompanying performance penalties.
>
> Yes, we probably would. Not because of efficiency but because a goal of taproot is *privacy* while
> offering efficiency for the common (all-sign) case. That is generally true across contracting
> protocols and makes things net-cheaper with a taproot-style system where you hit the common case
> often. This is another reason why P2MR is quite a loss -
>
>> Even if we do someday find some novel cryptosystem which permits rerandomization, and we design a
>> new output type as efficient and performant as P2TR but in a post-quantum context, is the systemic
>> risk really worth saving a few vbytes - a small fraction of the entire witness? If so, how many
>> decades or centuries need to pass for everyone else to share that confidence?
>>
>> Personally I think we should learn our lesson from this P2TR debacle, and encourage users to hide
>> public keys behind hash functions from now on, and to bolster riskier algorithms with hash-based
>> fallback keys, so that we always have at least one layer of protection between keys and any novel
>> cryptanalytic breakthroughs. Posting our plain pubkeys on-chain does sometimes have fun benefits,
>> but the drawbacks are deadly serious.
>>
>> Until SHA256 collision resistance is broken, I'd expect P2MR is probably the pinnacle of secure PQ
>> address formats, and even then we'd probably end up reimplementing P2MR with some newer hash
>> function. Hopefully someday someone proves me wrong, but we can only engineer with what we know
>> today, and today P2MR seems the most optimal conservative option for long-term security and
>> cryptographic agility.
>
> As mentioned above if we end up in this situation we're almost certainly going to be discussing a
> P2MRv2 with an additional witness discount, so...
>
>>> And with them they will take bitcoin's value...
>>
>> If you're really worried about a supply glut caused by CRQCs stealing and dumping them, then
>> debating about P2TRv2 and P2MR is a distraction. IMO, most coins will probably not migrate before
>> Q-Day regardless of what output types we deploy, because many coins are held by dead hands, or by
>> living hands who just don't read the news.
>>
>> If this concerns you (and it concerns me too), then saving a few vbytes per spend pre-Q-day is
>> trivial by comparison, and optimizing it will make little impact on the integrity of the UTXO set
>> after Q-day. I would instead suggest you pursue the retroactive area of research (rescue
>> protocols, quantum canaries, hourglass, exposure statistics, etc). This is a domain where real
>> impact can be made to mitigate the risk of a supply glut when/if CRQCs appear. Opportunities
>> abound. We would be glad of the help :)
>
> This is fair, and we should do this too, but I don't see how it implies we should not also be
> concerned with ensuring maximum possible migration.
>
>
>> Anyways, I appreciate the good-spirited debate, but to save myself time I don't think I'll
>> continue replying. I've laid out my argument for P2MR pretty clearly and I feel it is as
>> convincing as I can make it. I'd be happy to acknowledge any misunderstanding I may have had about
>> your earlier points in favor of P2TRv2.
>
> Fair enough. I continue to think we're talking past each other somewhat but ultimately I think my
> concern is for ensuring bitcoin survives, while you're more concerned with giving those who are
> concerned an option to feel warm and fuzzy :).
>
>> As to the original subject of the email thread, and Antoine's original points, seems like we are
>> all in agreement.
> Indeed.
>