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

["'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>]

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 <sjors@sprovoost.nl> 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 bitcoindev@googlegroups.com 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 bitcoindev+unsubscribe@googlegroups.com.
> 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ZVpECz43S3fTL1NKxxHANGsvtOJmQJmstZ6Xa9laLg7WkdmiLL10yqKgVjsOb0GZFkEpz4vaBfN-uy3mu7kFT41QFTuXD3a_tSoLpSIbIGs%3D%40protonmail.com.