Hey Pieter, nice to hear from you too on this.
Do you have any take on the OP idea about P2MR depth restrictions? > as far as compelling reasons go, I think the quantum resistance debate is > quite different from P2TR adoption. As Q-fear grows, I suspect there will be > increasingly loud and hard-to-ignore voices (and possibly regulation...) to > adopt post quantum cryptography technology stacks. I hope so too! It's totally possible that a significant majority of UTXOs migrate in time - say if you're right and there is a very public concerted push towards PQ, or if Q-day turns out to be 50+ years from now. But it's impossible to predict this. For now I hope for the best, but I also want to plan for the worst. If PQ fear is indeed such a strong motivating factor as you hypothesize, wouldn't this be an argument against P2TRv2? P2TRv2 isn't quantum-resistant by default but P2MR is. Personally, if I thought a CRQC is imminent, I would rather sell my coins or stow them in a P2WSH address than migrate to an address format which requires a follow-up fork to be secure. To borrow a phrase, P2TRv2 bears a systemic risk (solving the fork timing problem), whereas P2MR has only local risk (address reuse, which btw would also be solved if we could solve fork-timing). Antoine drew this comparison on his post too but we apparently disagree on which is preferable. Users and devs can control local risk with very simple software tweaks (to avoid address reuse) but they can't do anything about systemic risks. This is why I prefer P2MR. If the fork-timing problem can be solved conclusively then maybe P2TRv2 would be viable, but as you've alluded to, we have yet to hear any passable solution that doesn't require a cooperative CRQC. > No offense, but this sounds like a fairly depressing scenario to me. If an > ECDLP break happens before even a large majority of the "active" economy > adopts Q-safe outputs, I don't think there is much of an interesting future > for Bitcoin. Leaving many users' coins vulnerable to theft will undermine > short-term trust in the currency, possibly fatally so. The alternative, > burning significant amounts of users' coins will be seen as confiscation that > undermines the long-term stability value proposition bitcoin has, as it would > be indistinguishable from a PQC altcoin that imports some fairly arbitrary > subset of Bitcoin's UTXO set (see also > https://antoinep.com/posts/quantum_risk_mitigation/, where Antoine makes that > point in more detail). Agreed, it would suck, but would likely be viable. I lack data, but I suspect that by Q-day most coins will have some knowledge-asymmetry with a CRQC (hash preimages, BIP32 parent keys, hidden P2TR script paths, etc) and so can be rescued with simple commit/reveal protocols - no heavy ZK machinery or hard-forks needed. With that in mind, then it doesn't really matter how many recoverable coins migrate before Q-day, does it? If you can assume P2TRv2's PQ-security promise will be deployed on-time, then you can also assume any BIP32 wallet in-use today can be rescued. What we really must care about is migrating the unrecoverable fraction of coins (e.g. JBOK wallets with exposed pubkeys). These should already be rare and will only become rarer as more time passes. So in order to argue your point that P2TRv2 makes confiscation/theft less likely, you'd need to show that P2TRv2 will result in a meaningfully higher number of unrecoverable coins migrating. And I don't see why that would be the case. Holders of ancient JBOK coins with exposed keys are probably either dead, or have lost their keys. If a holder does still have the keys, then why would they move to P2TRv2 but not P2MR? On a more positive note, if we can someday say "Look, quantum computers appeared and screwed some people over, but most people can recover their coins as long as they fulfill any one of these common criteria," then that seems like Bitcoin's unique value and confiscation resistance is surprisingly intact to me. Certainly better than certain other altcoin migrations I've seen in the past, but I guess this is a subjective question, and everyone will have their own opinion. > It's possible to allow a Merkle tree whose leaves are either EC keys or > scripts, and then allow spending from the key-leaves by revealing the path > and a signature, but recover the expected public key from the signature. That > needs a variation of BIP340 that doesn't commit to the public keys (which may > break some of the proofs of higher-level schemes, but as long as there is no > ANYPREVOUT like functionality, the message implicitly commits to the output > so that may be fine). But even with that, efficiency is 32 bytes worse than > P2TR, because in a Q-safe setting with at least one additional PQC branch, > you have at least 32 bytes of Merkle path. Is this what you have in mind? Sorry to string you along but I'm gonna hold off here as I don't want to take credit for the idea by jumping the gun and explaining it myself. I'll leave it open for the actual author to chime in on this thread if/when he's ready :) > A reasonable intersection of both opinions could be further witness discount > of EC Schnorr of P2MR (Segwit v2). > Further 2x witness discount (total 8x witness discount) makes P2MR EC-spend > transaction cost almost at par with P2TRv2 key-spend path. I wouldn't rule out a discount in a future upgrade but for now i'm hesitant to bundle PQ addresses/signatures with anything that might disrupt the existing fee market, especially given the frustratingly controversial topic of inscriptions/spam. I can already picture the Knotsies decrying a witness-discounted PQ soft fork as "spam-support hidden behind quantum FUD". Never mind that we're already going to have to bump the stack element size limit... regards, conduition On Saturday, June 6th, 2026 at 12:30 AM, Pieter Wuille <[email protected]> wrote: > Hi Conduition, > > Some comments inline below. > > On Friday, June 5th, 2026 at 6:59 PM, 'conduition' via Bitcoin Development > Mailing List <[email protected]> wrote: > > > Hi Antoine, thanks for the feedback. Glad to hear you're receptive! > > > > > > > It's important to consider that in any scenario where Bitcoin as we know > > > it survives a CRQC, the vast majority of users would have had to migrate > > > to an output type that includes an escape hatch long before we could have > > > been reasonably certain that a CRQC would materialize. Therefore we > > > should not assume that the vast majority of users strongly desire to > > > migrate to an escape-hatch output type. (In fact, i think it would > > > actually be reasonable to assume none have a strong desire to do so. This > > > is because everyone has an incentive for everybody to migrate, but there > > > is little incentive for each individual to migrate if nobody else does.) > > > > > > > > > > > Therefore any additional barrier to encourage users to opt into an > > > escape-hatch output type is working against CRQC risk mitigation. > > > > > > All else being equal, whether we use P2MR or P2TRv2 I believe we will end > > up with roughly the same (small) fraction of the UTXO set migrated by > > Q-day. I believe this because address format adoption is always slow even > > with good incentives. Even after 7 years and plenty of incentives to > > migrate, P2TR still secures only a small fraction of the UTXO-set compared > > to P2(W)PKH, and a tiny fraction (0.75%) of the supply. See this 2025 > > report from mempool.space and this 2025 report from Galaxy Digital. > > Incentivizing adoption doesn't always lead to adoption, so why expect it to > > do so with P2TRv2? It doesn't offer any incentive over P2TR beyond a > > shallow promise of maybe-some-day-quantum-security. > > > I don't think that's necessarily the right conclusion. P2TR adoption is low, > partially because wallets and especially commercial service providers > generally don't ever upgrade their technology stacks unless there is a > compelling reason; the ecosystem primarily updates through companies going > out of business and being replaced by new ones, which are more likely to be > built using modern technology. We obviously cannot ask for faster movement > through business failure here, but as far as compelling reasons go, I think > the quantum resistance debate is quite different from P2TR adoption. As > Q-fear grows, I suspect there will be increasingly loud and hard-to-ignore > voices (and possibly regulation...) to adopt post quantum cryptography > technology stacks. At that point, wallets may start to offer users an > "Upgrade to quantum-resistant addresses?" migration button. In the case of > P2MR that will need to come with a "Warning: transactions will cost 15% more > going forward" notice. In the case of P2TRv2, depending on what what used > before it may have 0 impact on costs, or even be a discount going forward. If > on-chain fees remain as low as they are now, this may not matter, but > otherwise, I think the number may very well discourage a substantial amount > of users who aren't convinced about CRQC threats. And I think those users do > matter, unfortunately. > > > > Here's my timeline prediction, with the above precedent in mind. We deploy > > a PQ output type, some minority of UTXOs migrate to it. When the first > > confirmed ECDLP break is proven (e.g. if someone breaks a NUMS point) or > > suspected (someone stole Satoshi's coins), then we will deploy a rescue > > protocol which we hopefully prepared in advance to protect the majority > > procrastinator UTXOs. Maybe we disable EC spending at the same time (a > > valid option for either P2MR or P2TRv2). Then there will be a brief > > fork-war (hard or soft) revolving around the question of how to handle > > Satoshi's coins. After that IDK what happens, but I expect Bitcoin will > > survive if we prepare adequately today by deploying a quantum-safe address > > format and PQ signature scheme, and develop rescue protocols for later > > activation to move laggards over to PQ wallets. > > > No offense, but this sounds like a fairly depressing scenario to me. If an > ECDLP break happens before even a large majority of the "active" economy > adopts Q-safe outputs, I don't think there is much of an interesting future > for Bitcoin. Leaving many users' coins vulnerable to theft will undermine > short-term trust in the currency, possibly fatally so. The alternative, > burning significant amounts of users' coins will be seen as confiscation that > undermines the long-term stability value proposition bitcoin has, as it would > be indistinguishable from a PQC altcoin that imports some fairly arbitrary > subset of Bitcoin's UTXO set (see also > https://antoinep.com/posts/quantum_risk_mitigation/, where Antoine makes that > point in more detail). > > I cannot confidently state that your scenario is unlikely of course, but I > think there is little we can do today that affects the outcome in this case. > People can think about emergency recovery scenarios to scavenge what's left > to save (BIP32 ZKPs and all that), and the result may well survive, but I > don't think it'll be very interesting, and not something we as protocol > designers should optimize for at this stage. > > The interesting scenarios to me are ones where either a CRQC doesn't happen, > or where we get a large majority of users to adopt Q-safe outputs before that > happens. Maximizing the probability that that will happen should be our > priority. > > > > Whether we pick P2MR or P2TRv2 today, neither choice will affect the early > > stages of this plot-line very much, so we might as well optimize for the > > long-term future, and P2MR wins out there. > > > The ideal long-term future is one where we get feature-rich cryptographic > schemes that can replace most of the properties Bitcoin relies on today > (homomorphic derivation, efficient multisigs, ...) with low costs (through > discounts, smaller signatures/keys, efficient verification, ...). At that > point, they can be introduced in PQC-only outputs even (say, P2MR without any > EC opcodes ever), everyone can adopt them over time, and then when a CRQC > appears or not won't really matter. That technology does not exist today, I > think, so the best we can aim for today is something where most users can > migrate to with minimal downsides before Q-day, even if it comes with some > downsides afterwards, which will inevitably be chaotic but maybe not an > existential threat. I don't think it matters much that P2TR(v2) is slightly > less efficient than P2MR in this hopefully-avoidable chaos; we'll have much > bigger fish to fry. > > I believe P2MR is effectively optimizing for the time after/if a CRQC appears > (possibly only temporarily so if another migration to a more fully-features > PQC scheme is needed anyway then) while P2TRv2 is optimizing for the time > before a CRQC happens and minimizing barriers for adopting Q-safe coins. All > of this is under the assumption that P2MR comes with a reasonable expectation > of a narrow P2MR-only EC opcode disabling softfork when CRQCs happen (like > P2TRv2); without it, I believe it is much worse, as P2MR would be entirely > inadvisable to adopt by anyone whose workflow relies on sharing public keys > with others (hardware wallets with descriptor-based watchonly software, > wallets with indexing servers, multisig, Lightning, escrows, fee bumping, > ...). > > So, I prefer P2TRv2 here, though under the assumption that the narrow EC > opcode disabling softfork can be relied upon. I am not confident that that is > possible, though I have more thoughts on the matter. That's for another post, > though. > > > > > any additional barrier to encourage users to opt into an escape-hatch > > > output type is working against CRQC risk mitigation. And i think the > > > additional costs of using P2MR compared to P2TRv2 is one of them. > > > > > > I have good news for you: there is an optimization to BIP360 which would > > make single-signer Schnorr spending significantly (32 bytes) cheaper. It's > > not my idea so I don't want to jump the gun in explaining the details, but > > expect another mailing list post soon with more info. > > > It's possible to allow a Merkle tree whose leaves are either EC keys or > scripts, and then allow spending from the key-leaves by revealing the path > and a signature, but recover the expected public key from the signature. That > needs a variation of BIP340 that doesn't commit to the public keys (which may > break some of the proofs of higher-level schemes, but as long as there is no > ANYPREVOUT like functionality, the message implicitly commits to the output > so that may be fine). But even with that, efficiency is 32 bytes worse than > P2TR, because in a Q-safe setting with at least one additional PQC branch, > you have at least 32 bytes of Merkle path. Is this what you have in mind? > -- > Pieter > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/jVpYczjMUwILN76cjc9LSoXttkuOrkClgAX6gwtlQ4-lVEcGFKD8tEp72zhTCzCqmOdyrkyuoyGF2DA-p5WebDgmgXyAGpBnH6mYRGvl1-I%3D%40proton.me.
publickey - [email protected] - 0x474891AD.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
