On 2/11/26 5:57 PM, Ethan Heilman wrote:
>  > For what its worth I do not see a scenario where a decision ultimately made by the market will
> pick the fork side with materially, say 5-10x higher, supply, over the side with lower supply...
>
> Completely agree, the incentives favor lower supply. I wouldn't want to count on it happening and
> even if it does happen the freeze fork might not freeze P2TR. According to the 2025 chaincode report
> [0] P2TR represents only 0.75% of total supply.

I believe we're talking past each other, then. This was a side note - as Jonas mentioned it seems
reasonable that a P2TR-based QC signature validation opcode could come with an on-chain signaling
bit (i.e. a "Taproot V2" that is functionally identical but indicates the presence of a QC signature
script path available).

>  > ~all wallets today use seedphrases, which could still be spent with a ZK proof-of-seedphrase :).
>
> I'm all for putting ZKPs in consensus, but it seems unlikely to me that it will happen.

We just agreed that its highly likely that insecure spend paths are disabled. I do not remotely see
how such an action could occur if the result is that a large number of coins are seized. The only
viable approach way for that is to allow seedphrase-based wallets to retain access.

> It is better
> to make Bitcoin safe than promise safety that requires a future hardfork.

There is no hardfork required here.

> This is especially true
> since as you point out lower supply is incentivized, so a soft fork that freezes coins would be
> fighting an uphill battle.

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"?

>  > Hell, *any* PQ soft fork is going to see limited adoption in "consumer wallets" until its
> urgent, hence why I think the community will be basically forced to disable insecure spend paths and
> only
> allow spends via ZK proof-of-seedphrase. But at least something that doesn't also 10x
> transaction costs might reasonably be adopted by default by wallets that don't use seedphrases like
> Bitcoin Core.
>
> I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use quantum-safe outputs (Schnorr OR
> PQ) with Schnorr as the default spend. The wallets can market themselves as quantum safe.

This flies in the face of the last 15 years of experience with Bitcoin wallets. Yea, it sounds
great, but we've got 15 years of experience showing that wallets only adapt when they go out of
business/stop being maintained and get replaced with new wallets (which often ship with the latest
technology). Worse, many bitcoiners (maybe rightfully, maybe not) entirely write off the quantum
threat - all the more reason they will simply not adopt any changes.

> The cost
> in transaction fees to a user is small, a 1 input P2MR transaction would only be 37 bytes larger
> when compared with a 1 input P2TR transaction. Those 37 bytes are in the witness, so the real cost
> is ~10 vbytes.

Apologies, I had understood the P2MR proposal to only feature PQC-based schemes, rather than also
offering schnorr as an option, leading me to incorrectly conclude it would be drastically more
expensive, rather than marginally so.

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.

Worse, there's no real advantage here over just doing in the taproot key path - because of address
reuse a wallet relying on P2MR + schnorr anyway will ~always have its public key revealed so we
might as well continue relying on P2TR to save the 37 witness bytes and get the same result (that
wallets can do something cheap with "just" a key derivation change and explicitly opt in to a future
soft fork which disables the then-insecure spend paths).

> Yes, if Q-day happens, time passes and then quantum computers become powerful enough to perform
> short-exposure attacks, anyone needing to move their coins to an output have to pay fees for an
> additional 8,000 bytes (SLH_DSA) or 324 bytes (SHRINCs). This is still better than a PQ ZKP proof of
> the seed which would be between 20,000 to 120,000 bytes and more likely to have a security flaw than
> SLH_DSA.

Yep, I'm not proposing at all that we do nothing because a ZKP of seedphrase is an option, rather we
should add support for SHRINCS and encourage wallet adoption. But at the same time we should
understand that we're incredibly unlikely to see the kind of adoption in time to avoid the need to
do something like a ZKP of seedphrase when the time comes.

This is also probably the least interesting point of contention, FWIW - this is a decision for a
future bitcoin community, not a decision for us to make today.

> If efficient quantum signatures or compression techniques are developed, we can and should adopt
> them. If they are efficient enough, they can become the default. This proposal is designed to keep
> funds safe in the intermediate period while better techniques are developed to cover the tail risk
> where Q-day happens before the technology we need to completely ready.

Yep, we absolutely agree! I just don't see a reason to do P2MR over just utilizing P2TR (or maybe
P2TRv2).

>  > No it doesn't - it requires a soft fork when the risk is imminent, but it happening somewhat
> before that time is okay too.
>
> We might wait too long and misjudge the risk and Q-day happens before the soft fork activates? What
> happens if freeze fork is activated but then 3 years pass and it looks like a CRQC isn't going to
> happen after all? Now people who had their coins frozen are pushing to undo the soft fork.

> This approach carries too much risk from uncertainty and it was "the plan" it signles that Bitcoin 
> leaving things up to chance that don't have to be left to chance.
>
> Enabling people to opt in as early as possible enables the prudent to protect themselves for very
> little effort and cost. Those people know their coins are safe and can still use their coin as they
> did before.

We agree. I believe your response is based on a misunderstanding of my argument, hopefully clarified
above.

>  > I mean people can create invalid addresses today in plenty of ways. How is this unique?
>
> P2TRD would be an address, which looks exactly like a 100% valid address and which can be spend from
> like a valid address and hwoever at some future time, it may or may not, become frozen.

Sure, but this is still no different than any other P2TR script-path structure - you have to test
things you use, even if you use them rarely, which is the entire point of the P2TR design :).

Matt