Aligning privacy incentives in P2MR

A bitcoin-dev mailing list thread proposing to eliminate depth-zero script trees from BIP-360, so every P2MR output pays for at least two spending conditions. The author argues single-leaf trees create a perverse incentive (pointed out earlier by Matt Corallo and Antoine Poinsot): they make bare scripts cheaper in P2MR than in Taproot, encouraging protocol developers to skip cooperative spending paths and post-quantum fallback leaves, fingerprinting their transactions and eroding the privacy uniformity Taproot aimed for. The proposal was subsequently merged into BIP-360.

The thread then becomes the clearest single record of the strategy disagreement. Poinsot replies that the fix addresses the perverse incentive but not his core objection: P2MR costs ~15% more than a Taproot-style alternative for the single-key spending that dominates usage (he cites ~93.6% of recent transaction inputs), and any extra cost deters exactly the disengaged users a migration most needs. Pieter Wuille separates the design space along when elliptic-curve spending gets disabled inside the new output type — "Never" (P2MR as formulated), "Later" via a promised follow-up soft fork (the approach nicknamed P2TRv2), or "Now" (post-quantum-only from the start) — and argues "Never" is barely usable in practice, since staying quantum-safe in P2MR without a later disabling means never sharing xpubs, never reusing addresses, and forgoing multisig, Lightning, and silent payments. conduition counters that "Later" rests on a soft fork that may never come, making P2TRv2's security a matter of hope; Anthony Towns, waxwing/AdamISZ, and others weigh in on both sides.