Subject: Re: [bitcoindev] A Taproot-native (re-)bindable transaction bundle proposal

From: Sjors Provoost <[email-masked]>
Date: Wed, 30 Jul 2025 17:40:25 +0200

Regarding the (lack of) support of v0 SegWit, James O'Beirne wrote:

> To date I haven't heard any concrete downside of including witness v0
> support for an opcode like this other than "it's marginally more to
> think about during review."

I wouldn't discount that argument though. It's very nice to not have to think about any of the problems that v1 (taproot) already fixed. We know that review has been a major bottleneck for these proposals.

That said, it may be useful to have a "patch" for both the BIP text and the implementation that does support v0. I'm sure it's a lot less scary than pre-SegWit support.

> One concrete impediment to Taproot adoption among custodians is the lack
> of native HSM support for the Schnorr signature scheme. It's reasonable
> to believe that some already-deployed HSM contexts may never get to
> Taprootability.

I find it worrying that companies claiming to build military grade ultra secure hardware, that are used protect hundred of billions of dollars, have refused to implement Schnorr signatures for 5+ years now.

It also means they can't support MuSig2 and instead have to use ECDSA signature aggregation. They also can't support script path spending, which isn't great for privacy.

I guess we'll have to wait until enough other crypto chains migrate to Schnorr so there's enough trade volume to justify paying an engineer to spend two weeks fixing this firmware.

That said, I don't use such services (for more than a few minutes) and I don't think we should "force" people to upgrade by stubbornly not supporting v0.

- Sjors

> Op 11 jul 2025, om 20:37 heeft 'Antoine Poinsot' via Bitcoin Development Mailing List <[email-masked]> het volgende geschreven:

[...]

> Your second main criticism concerns the lack of Segwit v0 support. You start by cherry-picking some
> data about Taproot's usage, so i'll ask you to please keep the discussion honest here. You state
> that between 0.1% and 0.75% of all bitcoins in existence are held in P2TR outputs, and use this
> figure to conclude the "overwhelming majority of **value transfer** in bitcoin is still happening in
> a pre-Taproot script context". This non-sequitur reads as though you'd already settled on the
> conclusion and were reaching for data that might appear to support it. In 2024 and 2025 between 20%
> and 40% of all onchain transfers used Taproot[^0] (vs between 1% and 3% for P2WSH). Even
> considering the value of these transfers gives a pretty clear trajectory: since the beginning of
> 2024 the percentage of BTC getting locked into P2TR outputs quadrupled from 2.2% to 8.5%[^1] (the
> percentage for P2WSH was steady from 16.4% to 16.8%).
> 
> I strongly believe our default position should be to only enable new features in the latest
> iteration of the scripting system. While Segwit v0 fixed the most important quirks of legacy Script,
> Taproot/Tapscript finishes this work by removing the remaining instances of quadratic hashing,
> enforcing by consensus more malleability-related standardness rules, being compatible with batched
> validation today and a possible future CISA, and finally presenting the slight but still good to
> have privacy improvement that all outputs look the same before being spent (and sometimes even after
> being spent although it's harder to achieve). We should not provide new features for an outdated
> scripting context unless we have a strong reason to.
> 
> I don't think you provide a strong reason not to stick to Tapscript. You claim that many industrial
> players would not be able to use OP_TEMPLATEHASH but you don't back it up with anything
> demonstrating those companies 1) desire to use OP_TEMPLATEHASH and jointly 2) are somehow unable to
> upgrade from P2WSH to Taproot.

-- 
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-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4E54B8EA-9BE8-4660-AA29-72E14C3AADF5%40sprovoost.nl.