> 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...supply
and demand is king, especially with the "confiscatory" nature is basically nil as ~all wallets today
use seedphrases, which could still be spent with a ZK proof-of-seedphrase :).
This line of reasoning is wrong imo.
If supply and demand is king, why not just delete supply as much as possible? No more mining? Arbitrary freezing of various actors' coins (but with warning! so it's only confiscation in quotes, right?).
Hypothetical: someone proposes a fork which freezes all coins residing at utxos with addresses containing "234" (insert technical description as appropriate - you get the idea). It'll be a bit like the rules about driving into town with various letters in your license plate, though, a bit more permanent :) The vast majority will benefit economically from the lazy few who don't notice, since if they pay attention, they can hop out of the frozen addresses with time to spare, so why doesn't it happen?
Obviously, ridiculous examples, but .. point stands in general:
It's a curious kind of self-referential. The "market" here is really the set of holders, their *short term* interest is to grab any they can, but their long term interest is to have their stash keep its value. There is *nothing* that will destroy bitcoin's value more effectively (certainly not technical issues like bugs, certainly not an unexpected unlock of a big amount of coins to be moved in the market) than an event that questions the "private property promise":
1/ coin inflation schedule is set in stone;
2/ if you can cryptographically validate a transfer, bitcoin will let you do it, i.e. you can always spend your own money;
3/ if you "locked" a utxo with a certain ruleset in the past, that ruleset will still be active and let you spend in future, i.e. you can't be locked out of your own money.
Bitcoin is the only digital asset in the world for which those assertions are credible; it has never yet violated them, and imo it's the thing that keeps it unique and important (PoW ties in; it's another aspect of the same rigid adherence to no controlling entities).
That's why both this idea and Peter Todd's tail emission idea, both high quality engineering-safety thinking, will not happen, in my opinion.
> ZK proof-of-seedphrase :).
Oh cool, that's a good point. Ethan's counterpoint is good too, that we would need a consensus rule and that's v. hard, but: my spidey sense is tingling a bit about whether people might find tricks to avoid it: if you consider the very clever tricks recently discovered around Glock, ArgoMAC and so on, they enable gating txs behind ZKP schemes w/o new consensus but what we're talking about here is way more narrowly defined than the larger problem they're trying to solve, which might support being optimistic ...).
Cheers,
AdamISZ/waxwing
On Wednesday, February 11, 2026 at 12:55:19 PM UTC-6 Matt Corallo wrote:
On 2/10/26 11:44 AM, Ethan Heilman wrote:
> > If Bitcoin disables Taproot key path spends before Q-day, then doing this via Taproot instead of
> BIP 360 would be preferable.
>
> I worry about making the transition to quantum-safe outputs depend on a contentious debate over a
> confiscatory soft fork. Uncertainty over whether the soft fork would be released and if released
> would be activated means that wallets and custodians are unlikely to have invested the resources
> into upgrading to support script only P2TR.
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...supply
and demand is king, especially with the "confiscatory" nature is basically nil as ~all wallets today
use seedphrases, which could still be spent with a ZK proof-of-seedphrase :).
> The benefit of BIP 360's P2MR (Pay-to-Merkle-Root) + SLH_DSA is that it avoids this controversy by
> being opt-in and non-confiscatory. This also means that BIP 360 + SLH_DSA is likely to activated
> early, allowing wallets and custodians ample time to build support after activation.
The drawback being that it will see zero relevant adoption until its way too late.
The only entities that would reasonably adopt something like this are large custodians, who aren't
worth worrying about as they'll easily migrate all their coins over the course of a few days or
weeks in an emergency scenario, and highly specialty wallets. The point of any PQ soft fork today is
if it can actually drive wallets to start making progress on PQ deployment. A new address type that
is 10x more expensive to transact with is going to see ~zero adoption in "consumer wallets" until
its urgent, at which point its obviously way, way too late.
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.
> > We could define a new SegWit version that is a copy of Taproot. The new version number simply
> signals that the owner consents to a future deactivation of key path spends. Unlike BIP 360, this
> approach would still require actually disabling the key path before Q-day, but it is not
> confiscatory and allows using Taproot's benefits until then (with a privacy hit from having two
> versions of Taproot in parallel).
>
> Let's call this P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 evolved from this P2TRD idea, to
> minimize the following hazards in P2TRD.
>
> 1. P2TRD requires a soft fork that depends on accurately predicting Q-day or when EC Schnorr is
> classically broken. We must not only predict Q-day but also convince the community that the
> prediction is correct. If we mess up the timing, Bitcoin is significantly harmed. This means that
> people will constantly be yelling that we are messing up the timing. It will make quantum FUD worse
> not better.
No it doesn't - it requires a soft fork when the risk is imminent, but it happening somewhat before
that time is okay too.
> 2. P2TRD (Pay-to-Tap-Root-Disablable) to be non-confiscatory users must create a script spend that
> replicates their key spend, But users and wallets are likely to screw this up and not create script
> spends. The is no way to see if a wallet is actually creating the script spend on the blockchain.
I mean people can create invalid addresses today in plenty of ways. How is this unique?
> 3. To be safe from long-exposure attacks P2TRD can't use the same public key for the script spend as
> the key spend. Since wallets will prefer the key spend to the script spend, a user might not realize
> if they lost the keying material for their script spend until after activation.
It would almost certainly just be a key derived from the seedphrase via another hash function, so
there's no real risk of this.
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/efa3dd60-84c2-48ea-9fc7-ae5057590cb9n%40googlegroups.com.