On 2/12/26 1:08 PM, Ethan Heilman wrote:
> Yep, we absolutely agree! I just don't see a reason to do P2MR over just utilizing P2TR (or
maybe P2TRv2).
Here is my P2TRv2/ P2TRD vs P2MR analysis.
Terms:
- P2TRv2-disable-soft-fork - refers to the soft-fork that disables key spend paths for P2TRv2
outputs, but does not disable key spend paths for other P2TR outputs.
- Q-day-long - The day at which long exposure attacks start happening.
Set of outcomes for P2TRv2:
Future-A: Q-day-long happens and P2TRv2-disable-soft-fork is NOT activated. Funds are stolen from
P2TRv2 outputs, trust in Bitcoin declines.
Future-B: Q-day-long happens and P2TRv2-disable-soft-fork is activated. P2TRv2 outputs are protected
from quantum attacks.
Set of outcomes for P2MR:
Future-C: Funds in P2MR are safe even if Q-day-long happens unexpectedly.
The risk of Future-A will be priced into the value of Bitcoin. We can reduce Future-A risk by
activating P2TRv2-disable-soft-fork as early as possible. Activating P2TRv2-disable-soft-fork as
early as possible is equivalent to activating P2MR. Thus, might as well activate P2MR instead.
Do we want to tell holders:
- Move to P2TRv2 and then trust us to activate the P2TRv2-disable-soft-fork in
time
- Or move to P2MR, you'll be safe.
No, P2TRv2 and P2MR are totally equivalent here. Because address reuse is rampant, P2MR will *also*
require an equivalent P2MR-disable-soft-fork. The only material difference is the cost, and some
small minority that doesn't do heavy address reuse.
> Still, I think my point stands - in the face of many bitcoiners writing off the quantum
threat, wallets aren't going to have a lot of incentive to adopt technologies that make things
marginally more expensive.
Maybe in 2027, but what about 2028, 2029? If we see steady progress toward a CRQC the drumbeat will
become louder and louder and wallets will want to tell their users they are quantum-safe and secure
against classical attacks on ECC.
The first parties to move over will likely be big holders willing to pay a trivial increase in fees
for security against existential tail risks.
Right, so the first parties to move will be the ones we don't really care about (because they can
just move quickly later anyway) :).
> I'm confused by this comment - a soft fork that disables insecure spend paths to avoid them
being stolen is likely going to have a very easy time, not "fight an uphill battle"?
soft-fork-1: Disables insecure key spend paths in P2TR. I don't have an opinion on the ethics of
this, but the incentives are aligned to make this happen (reduces supply).
soft-fork-2: ZKP proof of seed phase to allow people to safely spend from a disabled key spend path.
The incentives are aligned to oppose this soft-fork (increases supply).
The incentives support soft-fork-1 happening, but soft-fork-2 not happening. I don't claim to
predict a future here, but the incentive issue here worries me.
Fair. Given the ethics questions and the amount of pushback I have to imagine every effort *has* to
be made to allow maximum wallets to retain coin ownership as otherwise the resulting Bitcoin has
less value just because of seizure concerns. This all depends a ton on specifics, though - has it
been 5 years since P2TRv2 was added? 10? 25? When did wallets start migrating in earnest? Did they
even until it was too late?
Other questions:
Soft-fork-1 must be designed so that soft-fork-2 is not a hard fork, that seems doable, has anyone
written up a plan for it?
I believe this is largely only possible either with an ethereum-style "difficulty bomb" or simply
doint it all in one go.
How big is this proposed PQ ZKP proof of seed phase? I've been assuming ~100kb per spend since we
have to use PQ ZKPs.
Yes, I imagine quite large. Hence good to push migration along first. If migration is limited, I
imagine there will be some desire to provide strong fee-discounts for these ZKPs, maybe also
aggregating them in blocks.
Matt
--
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/ade8d7f0-8793-4971-a5bd-fc60e76f513a%40mattcorallo.com.
