Dear Conduition, Antonie, and list, 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.
Anyway, we will have to discuss discount policy when we try to add PQ signature to Bitcoin. I think we could discount witness for those who use EC Schnorr leaf if larger transaction cost heavily discourages the migration. Best Regards, Hayashi On Saturday, 6 June 2026 at 6:59:18 am UTC+8 conduition 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 > <https://research.mempool.space/utxo-set-report/> and this 2025 report > from Galaxy Digital > <https://www.galaxy.com/insights/research/bitcoin-onchain-fees-utxo>. > 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*. > > 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. > > 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. > > 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. > > regards, > conduition > On Friday, June 5th, 2026 at 3:56 PM, Antoine Poinsot < > [email protected]> wrote: > > Hi conduition, > > I think this would address the perverse incentive concern, but still fail > in not disincentivizing mass migration. > > 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. And i > think the additional costs of using P2MR compared to P2TRv2 is one of them. > Most likely all "long-tail" users, who would be the least likely to seek > migration, use single-key spending policies. In fact, most Bitcoin users > do: in the past 90 days of blocks, 93.6% of all transaction inputs are > for single-key spending policies > <https://mainnet.observer/charts/inputs-types-by-count/>. For a typical > 2-input 2-output transaction for a "single-key wallet", P2MR is about 15% > more expensive to use than P2TRv2 [^0]. > > I understand that P2MR does not introduce this additional cost just for > kicks, but i think "long-range" protection is a red-herring and not worth > hindering individual migration to the escape-hatch output type, which is > critical to the systemic migration of Bitcoin away from relying on EC > cryptography. > > So your proposal does address one of my concerns with a P2MR + PQ opcode > strategy. However, i still believe P2TRv2 to be a superior strategy for the > reason outlined above. > > Best, > Antoine > > [^0]: Using 57.5*2 + 43*2 > <https://bitcoin.stackexchange.com/a/75124/101498> = 201 vbytes as the > base size. P2MR adds an additional 32 witness bytes in the control block > for the PQ spend path, and an additional 35 witness bytes for the EC leaf > script reveal. That's 33.5 more vbytes per input, which is 116.66% the size > of the same transaction with P2TRv2. > On Wednesday, June 3rd, 2026 at 7:26 PM, 'conduition' via Bitcoin > Development Mailing List <[email protected]> wrote: > > Hi list. I'm following up on an idea I sketched in this thread debating > P2MR vs P2TRv2 <https://groups.google.com/g/bitcoindev/c/Qy4gwAGTK2w>. > > The premise is this: What if we modified this line of BIP360: > > The last stack element is called the control block c, and must have length > 1 + 32 * m, for a value of m that is an integer between 0 and 128, > inclusive. Fail if it does not have such a length. > > > To this: > > The last stack element is called the control block c, and must have length > 1 + 32 * m, for a value of m that is an integer between *1* and 128, > inclusive. Fail if it does not have such a length. > > > The key change is that the control block must now include at least one > merkle authentication path. This effectively bans depth-zero script trees > in P2MR, and requires every P2MR address to always pay the cost of having > at least two spending conditions. > > This seems like a reduction in P2MR's features and efficiency. Why would > we want to ban depth-zero script trees? Well these seem to be the source > of a perverse incentive, as pointed out by Matt Corallo and Antoine Poinsot > in prior threads <https://groups.google.com/g/bitcoindev/c/JA3kDl8AmQg>. > Bitcoin script users are economically and practically incentivized by P2MR > to use depth-zero script trees because their witnesses are *smaller* than > if the same script were used in a taproot script spend. > > Furthermore, depending on the exact scripts and the developers' resources, > devs using P2MR for a multi-party scripting protocol may not be > sufficiently incentivized to add a cooperative spending path, even if their > protocol might allow it. Doing so would require a depth-1 tree, which > increases the witness size of the non-cooperative script spend path by 32 > bytes. For some short scripts, e.g <height> CLTV <pubkey> CHECKSIG, the > devs may actually have incentive *not* to add a cooperative spending > path, because the cooperative path would actually be *less-efficient* > than just using the non-cooperative path as the single leaf of a depth-zero > tree. This leads to easy fingerprinting of scripting protocols, less > privacy for everyone else, and undoes a key design goal of P2TR. > > In Matt's words > <https://groups.google.com/g/bitcoindev/c/JA3kDl8AmQg/m/EWS5ZxqZAAAJ>: > > The value of taproot is that its design natively adds [a cooperative > spending path] *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... > > > 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 > > > By eliminating depth-zero script trees, we'd force all P2MR users to pay > for the cost of having *at least* two spending conditions. We'd eliminate > the incentive for script devs to use P2MR over P2TR because both are > equally efficient, and incentivize P2MR users to add a cooperative spending > path using BIP340, since those users are already paying for the cost of > having a depth-1 tree anyway. > > This change to BIP360 wouldn't affect the recommended standard use-cases > for single-signer and multisig P2MR: hybrid addresses with one Schnorr leaf > and one PQ leaf. If anything, this change would encourage the proper use of > PQ fallback scripts, because the incentive logic can be applied to someone > who tries to use P2MR with only a single EC Schnorr leaf: This user must > pay for the cost of a second leaf script anyway, so why not follow > best-practices and add a PQ leaf? > > AFAICT this change only affects use cases which would otherwise degrade > the fungibility of the UTXO set according to BIP360 critics, and encourages > those use-cases to adopt a cooperative spending path which (assuming all > other factors equal) will be indistinguishable from a regular single-signer > P2MR wallet with a PQ fallback leaf. > > I've already chatted about this off-list with some BIP360 proponents and > they seem receptive, but I'm really curious about the opinions of those who > are leaning towards P2TRv2. Would this change to BIP360 address your > concerns surrounding P2MR's privacy incentives? If not, why? > > regards, > conduition > > > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/Q8YTY1ArMzia7tRvcZ5v769WPxCMxAl_0rUy-byOBjBcTd4HXj7IB7Yt4gxLbKqk7EXFWy-PuGB6QtI28qRjE5Vob-l44UmBH6L8aXInoSk%3D%40proton.me > . > > > > -- 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/76e281e7-c4b4-4267-9bda-edfd2ee19dc0n%40googlegroups.com.
