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

From: Greg Maxwell <[email-masked]>
Date: Wed, 30 Jul 2025 19:44:20 +0000

The burden should be on the proposers to show that their proposal is safe,
cost minimized, etc.

Significant design went into tapscript to make it safer and easier to add
opcodes,  I spent a while searching and none of the authors of these
proposals were standing up saying those improvements were irrelevant.
Supporting it in multiple places is larger and more complex itself, but it
is especially so when the result is missing out on improvements that make
it easier and more accurate to analyze the safety of the addition.

That's not to say that it should absolutely not be done, but there ought to
be a really clear and non-speculative case made for it.

I'd like to know more about this claim wrt HSMs and schnorr signatures, --
who is claiming this, over which products, and how does that interact e.g.
with CTV where there isn't even a signature?

On Wed, Jul 30, 2025 at 6:29 PM 'Antoine Poinsot' via Bitcoin Development
Mailing List <[email-masked]> wrote:

> Hi Sjors,
>
> I am not discounting that argument, i addressed it. To reiterate, i
> believe (as do others apparently) that unless
> there is a good reason not to we should only add new features in the
> latest, sanest, version of the scripting system.
>
> Furthermore, Bitcoin's last soft fork aimed to provide a way to have the
> output type not leak any information about
> the receiver's spending conditions (as well as possibly reducing
> information leak at spend time, too). In the last
> upgrade, Bitcoin users opted in to a design such as using Tapscript would
> be indistinguishable at reception time,
> at the price of making Tapscript spends slightly more expensive.
> Incentivizing to use older, distinguishable, output
> types by adding new features there (thereby even making it cheaper to use
> than proper Tapscript) would be completely
> inconsistent with this. For what it's worth, this was also recently
> discussed by one of the Taproot authors in the
> context of BIP360:
> https://delvingbitcoin.org/t/changes-to-bip-360-pay-to-quantum-resistant-hash-p2qrh/1811/11
> .
>
> Therefore, our starting position when considering upgrades to the
> scripting system should be to keep to Tapscript.
> I am happy to change my mind about making OP_TEMPLATEHASH and/or OP_CSFS
> available in P2WSH, but i have yet to see
> a compelling reason to do so.
>
> Best,
> Antoine Poinsot
>
> On Wednesday, July 30th, 2025 at 12:06 PM, Sjors Provoost <
> [email-masked]> wrote:
>
> >
> >
> > 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
> .
>
> --
> 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/ZVpECz43S3fTL1NKxxHANGsvtOJmQJmstZ6Xa9laLg7WkdmiLL10yqKgVjsOb0GZFkEpz4vaBfN-uy3mu7kFT41QFTuXD3a_tSoLpSIbIGs%3D%40protonmail.com
> .
>

-- 
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/CAAS2fgSh%2BW_zKigMJ147wJiS4eUxyLrqJi6qrnweTgH7G9jgoA%40mail.gmail.com.