Yes, that is what I'm thinking of. Specifically as deployed by a wallet that reuses a single address
for ~all transactions, as those are the "marginal" wallets which we want to encourage to move (see
my goals post which I just sent).

Matt

On 4/15/26 12:01 PM, Ethan Heilman wrote:
> I believe we are talking about exactly the same thing. A P2MR output that can be spent with a EC
> leaf or a PQ leaf. Is that not what you mean?
>
> On Wed, Apr 15, 2026, 11:17 Matt Corallo <lf-lists@mattcorallo.com <mailto:lf-
> lists@mattcorallo.com>> wrote:
>
>
>
>>     On Apr 15, 2026, at 10:36, Ethan Heilman <eth3rs@gmail.com <mailto:eth3rs@gmail.com>> wrote:
>>
>>     
>>     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
>
>>     On Wed, Apr 15, 2026, 07:02 Matt Corallo <lf-lists@mattcorallo.com <mailto:lf-
>>     lists@mattcorallo.com>> wrote:
>>
>>         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.
>>         >
>>