A Taproot-native (re-)bindable transaction bundle proposal

[Greg Sanders]

Hello all,

This is a bit of a follow-up from "What's a good stopping point? ... CTV/CSFS..." from [^1]

> There has been several objections to this proposal, which we can group into three categories:
exploration of alternatives, demonstration of usage, and design of the operations to achieve these capabilities

For this e-mail I would like to address the third point proactively: design of the operations to achieve these capabilities.

Antoine Poinsot, Steven Roose, and I have been working on a familiar, yet concrete technical proposal that focuses on three well-understood capabilities:

1. "Next transaction" capability, ala BIP119
2. "Verify signature of message on stack", ala BIP348
3. "Push taproot internal key onto stack", ala BIP349

These first two capabilities can offer radical simplifications
to well-understood systems when combined. The third is a simple
update that dovetails with the first two.

The BIP text is here(https://github.com/instagibbs/bips/blob/bip_op_templatehash/bip-templatehash-csfs-ik.md) and PR here(https://github.com/instagibbs/bips/pull/1), with full motivation for this particular bundle and rationale discussing alternatives. Our main contribution is a fully specified `OP_TEMPLATEHASH` as a drop-in replacement for BIP119 `OP_CHECKTEMPLATEVERIFY`. `OP_TEMPLATEHASH` is a simpler and more modern implementation of the "next transaction" capability. It differs in committing to the Taproot annex and being otherwise Taproot native, which allows us to:

- Use the `OP_SUCCESS` upgrade hooks in place of legacy `OP_NOP`s and be able to push the template hash on the stack making the flagship use case of rebindable signatures more efficient.
- Re-use the existing pre-computed Taproot sighash fields only instead of introducing new ones (substantially simplifying the implementation and review of the specifications).
- Not commit to the spending transaction's scriptSigs (which are both unecessary and may incentivize ad-hoc uses of legacy input scripts as programs).
- Not unnecessarily modify the less well-understood legacy Script.

Another notable difference is the lack of "bare CTV" analogue, which is implemented here(https://github.com/instagibbs/bitcoin/tree/p2th) but left out of the bundle due to lack of demonstrated utility.

The BIP for `OP_TEMPLATEHASH` is here(https://github.com/instagibbs/bips/blob/bip_op_templatehash/bip-templatehash.md) and a complete implementation is provided here(https://github.com/instagibbs/bitcoin/pull/3). The bundle itself is heavily inspired by "LNHANCE"(https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376).

We are hopeful that an opcode/implementation-focused discussion can be held
concurrently with other efforts such as discussions as to whether
or not this capability set is a good stopping point, including whether
this bundle is worth implementing on its own at all, as well as what
level of assurances we should have as far as tooling and proof of concepts
is concerned.

Best,
Greg

(1) https://groups.google.com/g/bitcoindev/c/-qJc1EWQzY0

[Rijndael]

Hey Greg,

The CTV commitment includes the number of inputs. I notice that the TEMPLATEHASH commitment does not. What’s the rationale there?

Thanks, 

Rijndael

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/26b96fb1-d916-474a-bd23-920becc3412cn%40googlegroups.com.

[Rijndael]

Hey Greg (again),

I think I answered my own question: the TEMPLATEHASH commitment is a subset of the bip341 common signature message, which does not commit to number of inputs so this doesnt either. The sequences commitment _should_ implicitly fix the number of inputs. 

Rijndael

[Ademan]

Isn't it indirectly committed to by sha_sequences?

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/682337FB-F451-459F-8B4C-56E61C49FA4F%40gmail.com.

[Brandon Black]

Hi Greg,

First, thank you for working on these important consensus changes.

## Comparison of hashes.

Compared to CTV, TEMPLATEHASH drops nInputs, nOutputs, and scriptSigs;
and adds the taproot annex presence flag and taproot annex.

Compared to SIGHASH_ANYSCRIPTANYPREVOUT|ALL, TEMPLATEHASH drops
hash_type, _this_ sequence, key_version, and codesep_pos; and adds _all_
sequences.

This puts TEMPLATEHASH in a pretty comfortable middle ground between
CTV's hash and ANYSCRIPTANYPREVOUT's. It indirectly commits to the
number of inputs via sequences, is capable of creating stable txids with
1 input, and makes no concession to constructing the hash on the stack
nor to legacy script.

## Capabilities

As has been previously discussed, all protocols that are possible with
LNHANCE are possible with CTV+CSFS alone. That remains true with
TEMPLATEHASH+CSFS. The other two LNHANCE opcodes are optimizations. This
proposal includes INTERNALKEY for its ability to save 32WU in common
protocols where the taproot internal key can be reused in scripts (e.g.
Lightning Symmetry). The final LNHANCE opcode, PAIRCOMMIT, is omitted
from this proposal and its optimization capacity is enabled for certain
specific cases by TEMPLATEHASH committing to the taproot annex. For
protocols which need to bind and make available one additional data push
with a spend (either pre-committed or spend-time committed), this is
sufficient.

One comment on the commitment to the annex: In my X spaces today, we
discussed whether this restricts future uses of the annex in practice.
We concluded that while it does eliminate certain perverse ways of
implementing certain annex extensions, it does not seem to eliminate any
possible protocol application. E.g. once we have an opcode that is
expected to be used in pre-committed transaction scripts in the wild, we
cannot make a consensus rule that requires all taproot spends to have a
non-empty annex.

## Efficiency

Comparing this proposal to LNHANCE and other earlier proposals in terms
of its efficiency for implementing common proposed protocols: unless a
protocol requires multiple data commitments (e.g. a complex delegation
to key_a after locktime_a or key_b after locktime_b), this proposal will
be within the range of +1WU to -33WU.

For protocols that could have used bare CTV, this proposal is 69WU less
efficient, but as of this writing the only protocol that is known to
take advantage of bare CTV is congestion control trees. I am not aware
of any concrete proposal to implement these.

For protocols that do require multiple data commitments, each additional
data commitment requires an additional pubkey and 3 signatures to
implement Key Laddering. Adding PAIRCOMMIT or CAT to consensus would
eliminate this.

Concretely, I believe this proposal will be 32WU more efficient in the
Lightning Symmetry uncontested close case.

## Closing thoughts

I'm happy to see this tightly scoped tapscript only opcode package
proposed. As of this writing, I do not have any technical misgivings
about this selection of opcodes and functionality.

I hope to see this proposal garner review from the broader technical
community!

Thanks again for your work,

--Brandon

[James O'Beirne]

Hi Greg,

Congratulations on the BIPs and happy to see a concrete counterproposal
from you and the coauthors.

While the simplicity of the BIPs and draft implementation are
refreshing, I see a few issues relative to BIP-119:

# Annex commitment

TEMPLATEHASH commits to the annex, whereas CTV does not. I think this
poses some potential issues.

We don't know what the annex will be used for yet. BIP-341, where the
annex is defined, writes

> Until the meaning of this field is defined by another softfork, users
> SHOULD NOT include annex in transactions, or it may lead to PERMANENT
> FUND LOSS. [0]

To date, no other widely adopted BIP has spelled out exactly what the
annex will ultimately be used for.

The germane thing in this case is that the annex contents are specified
at *spend time*, whereas the CTV or TEMPLATEHASH hash must be
precomputed before the creation of the UTXO.

If the hash must know the contents of the annex prior to spend time, it
fundamentally constrains how the annex can be used in conjunction with
TEMPLATEHASH (since you have to anticipate the contents of the annex).

Some conceivable uses of the annex that have been floated are:

- for cross-input signature aggregation,
- for amount checks in aggregate vault operations[1],
- for implementing some SIGHASH_GROUP-like function[2].

To me it isn't inconceivable, and is perhaps even likely, that the use
of the CTV-like functionality and some of the above future examples
might overlap.

Rather than bundling a commitment to the annex with TEMPLATEHASH, it
would seem more prudent to defer treatment of the annex until we've
decided what it is. It might ultimately make sense to have some
orthogonal opcode ("OP_CHECKANNEX" or something) that allows script
authors to explicitly specify annex expectations.


[0]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
[1]: https://github.com/bitcoin/bitcoin/commit/2c63a983ddb7f2b7eaaedc8313fbeaf8f7c1b128
[2]: https://gnusha.org/pi/bitcoindev/2022030505...@erisian.com.au/


# No witness v0 (segwit) support

I think the lack of TEMPLATEHASH's availability in a witness v0 script
context will significantly limit its deployability for at least the next
few years and possibly permanently for some users.

Right now two separate estimates put Taproot usage (by value) at
0.1% or 0.75% as of May 2025[3][4]. This is nearly four years after its
activation. We can't say exactly why users aren't upgrading, but the
reality is that the overwhelming majority of value transfer in bitcoin
is still happening in a pre-Taproot script context.

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.

While the TEMPLATEHASH authors don't acknowledge vaults in their
proposal, there is popular demand for CTV on the basis of being both a
simple vaulting mechanism[5] and a necessary ingredient for more ergonomic
vaults[6]. Much of my own professional grounding for supporting CTV stems
from this use.

TEMPLATEHASH's lack of witness v0 support hampers this use, and prevents
many industrial users who are (for varying reasons) stuck in a wit-v0
world from making use of the simple vaulting primitives that much CTV
interest comes from.

[3]: https://www.unchained.com/blog/bitcoin-address-types-compared
[4]: https://research.mempool.space/utxo-set-report/
[5]: https://github.com/jamesob/simple-ctv-vault

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

The reality is that we're still living in a witness v0 world; there will
be significant amounts of wit v0 traffic for the foreseeable future. To
throw that context aside is to ignore many potential users.

# Non-blocking gripes

I'm disappointed by the lack of consideration for the succinct "deferred
payout" or "congestion control" use that is provided by either bare CTV
or your P2TH ("witness v2") patch, but that isn't surprising given the
unwillingness on the part of the authors to acknowledge the potential
value of that use.

Even though it's disappointing to me, its absence here wouldn't hold up
my support for the proposal.

---

I'm glad to see progress on the prospect of making bitcoin's script more
useful, thanks for your work.

James

[Antoine Poinsot]

Hi James,

Thanks for your interest in our proposal.

You point that the annex commitment may prevent someone who pre-committed to a spending transaction
through OP_TEMPLATEHASH from using a different annex at spending time. Annex commitment is important
for rebindable signatures, but also for committing to the spending transaction: it allows to be
forward-compatible with future uses of the annex (from proof of publication not requiring an
additional signature to being able to pre-commit to any consensus meaning the annex may be given
in a future soft fork). In this regard it is no different from other fields of the transaction
that are today defined at spend time and OP_TEMPLATEHASH would allow to pre-commit to.

You list 3 examples where you claim a user who has committed to the transaction to spend his utxo,
turns out to be willing to use a different annex than the one committed. The first example lacks
citation: could you explain the exact scenario with CISA here? The next two examples i don't think
make sense. First you point to my amounts check idea, but these only ever make sense if you haven't
already completely committed to the spending transaction! If you have pre-committed to the spending
transaction through OP_TEMPLATEHASH (or even OP_CTV for that matter), you have already committed to
how the value from this output will flow into the spending transaction's outputs. Same for your
third example, the SIGHASH_GROUP idea: what's the point in having a signature that commits to part
of the spending transaction's outputs when all of those outputs are already set in stone through an
OP_TEMPLATEHASH commitment?

I think a better argument for your position is that pre-committing to the annex weakens the upgrade
hook it provides: it could arguably increase the risk of invalidating someone's coins if/when the
annex is given meaning in the future. I would object that first of all pre-committing to the
offending annex only marginally makes it worse compared to pre-signing it, and more importantly if
we think people would design software that create such transactions in spite of the very clear
warning "users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS" then
all bets are off. By this token, users may commit to other upgrade hooks: a higher nVersion, future
Segwit versions in transaction outputs, etc.

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.

Regarding your non-blocking gripes, let me state that P2TH is still very much on the table (like any
other change really). If an optimisation for congestion control is really important, using a new
Segwit version would be worth it, and the implementation is trivial (and is even more so if you end
up being correct regarding annex commitment). We are just all three of us very unconvinced that it
is in fact worth it, as are many others it appears.

Best,
Antoine Poinsot

[^0]: See https://mainnet.observer/charts/inputs-types-by-count and
https://mainnet.observer/charts/output-type-distribution-count
[^1]: Hovering the percentages for dates 2025-07-07 (closest i could get to today) and 2024-01-02
(closest i could get to 1st Jan 2024) at https://mainnet.observer/charts/output-type-distribution-amount.

> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPfvXf%2BE0YDzqY_jsGVoc4KKh_Kgsp-p20wNAD05tv_rMNG2sA%40mail.gmail.com.

[James O'Beirne]

Hi Antoine,

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

I think you might have misparsed my email; I wasn't using one
observation to justify the other.

I ran a script[0] to tally the value of newly created outputs by address
type, and the node tells me that 93.5% of all output-value created over
the last three months is non-P2TR.

I'll leave it to you as to whether 93.5% constitutes an "overwhelming
majority of value transfer," but I wouldn't really consider that
characterization as dishonest.

> In 2024 and 2025 between 20% and 40% of all onchain transfers used

> Taproot[^0].

If we're going to talk about cherry-picking, here's where to do it.
From the previously linked mempool.space research post[1], they "find
that the vast majority (86%) of p2tr UTXOs are sub-1000 sats in value."
So the case for *ahem* "legitimate" Taproot activity is probably worse.

[0]: https://gist.github.com/jamesob/1e3b07af5fbc1ef9bd9471d83f8d1fa6
[1]: https://research.mempool.space/utxo-set-report/

> We should not provide new features for an outdated scripting context
> unless we have a strong reason to.

Based on the numbers above, many users would likely disagree that
witness v0 is outdated. Sure, there are benefits to Taproot and I like
Schnorr signatures as much as the next guy, but the fact is that there's
nothing wrong with wit v0 and most users of bitcoin still make use of
it. Professionally, I'm in this position.

I'll respond to the other stuff later.

Sincerely,
James

[Murch]

Hello list,

On 2025-07-10 05:24, James O'Beirne wrote:
> Right now two separate estimates put Taproot usage (by value) at
> 0.1% or 0.75% as of May 2025[3][4]. This is nearly four years after its
> activation. We can't say exactly why users aren't upgrading, but the
> reality is that the overwhelming majority of value transfer in bitcoin
> is still happening in a pre-Taproot script context.

I thought there might be interest in a few more metrics regarding P2TR
usage.

Stats on the current UTXO set, from today:
• Bitcoins held in P2TR outputs¹: ~156,309 (0.79% of supply)
• P2TR UTXO count¹: 57,956,440 (34.7% of UTXO count)

30-day averages as of 2025-07-10:
• P2TR outputs by value²: 8.3%
• P2TR output count³: 20.0%
• P2TR input count⁴: KP 16.0%, SP: 7.0%

"P2TR outputs by value" has been trending up steadily since February,
being 1.4% on February 1st, possibly due to more people taking on UTXO
management tasks and wallet updates since the mempool cleared end of
January.

Cheers,
Murch

———

¹ via https://dune.com/murchandamus/bitcoins-utxo-set
² via https://mainnet.observer/charts/output-type-distribution-amount/
³ https://mainnet.observer/charts/output-type-distribution-count/
⁴ https://mainnet.observer/charts/inputs-types-by-count/

[/dev /fd0]

>  P2TR UTXO count¹: 57,956,440 (34.7% of UTXO count)

The fact that 86% of these UTXOs are under 1000 sats suggests that the use cases envisioned by protocol developers before taproot activation are still struggling to gain adoption.

/dev/fd0
floppy disk guy

[Antoine Poinsot]

What are these "struggling use cases envisioned by protocol developers"? I am not aware of any claims made by the Taproot authors regarding the usage it would get a few years after its activation. You wouldn't put words in anyone's mouth, would you?

--

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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2c16b2d0-ac82-4c10-8404-02001bda2658n%40googlegroups.com.

[Antoine Poinsot]

Hi James,

I'll let readers decide for themselves whether your citation of that data was intended to justify the content of the sentence that immediately followed.

Thanks for the script. It is consistent with the numbers that Murch and I cited. This is equivalent to picking 90-day as the moving average on 0xb10c's website[^0]. Again, a quick glance at this graph gives a pretty good indication of the direction of Taproot adoption. The share of created outputs (by value) went from 1.6% a year ago to 6.7% today.

We all wish Bitcoin users adopted the latest technology faster than they do, but this is probably only going to get slower as Bitcoin matures. And the trend from the past year gives some reason to be optimistic.

In any case, none of this is a reason to incentivize users to stay on older versions of the scripting context by going out of our way to also enable new features there. If anything the slight nudge to upgrade to Taproot should be seen as a good thing.

Best,
Antoine

[^0]: https://mainnet.observer/charts/output-type-distribution-amount/

--

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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPfvXfL59wF-sfrnwkK0NUeGCphsJ1VJzGmbTUDHgNFncx2VSw%40mail.gmail.com.

[Peter Todd]

On Fri, Jul 11, 2025 at 08:44:09PM -0700, /dev /fd0 wrote:
> > P2TR UTXO count¹: 57,956,440 (34.7% of UTXO count)
>
> The fact that 86% of these UTXOs are under 1000 sats suggests that the use
> cases envisioned by protocol developers before taproot activation are still
> struggling to gain adoption.

We created a new address standard and asked everyone to eventually transition
to it.

Some brand new use-cases creating lots of UTXOs popped up, and decided to
implement it on day zero. Just like we asked.

The fact that existing code, deployed in production, takes much longer to
upgrade should not surprise anyone. That's not a failure of taproot. It's just
inevitable. Even P2PKH addresses are still fairly commonly used, even though
they're inherently quite a lot more expensive in terms of fees.

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[Peter Todd]

On Fri, Jul 11, 2025 at 06:59:18PM -0400, James O'Beirne wrote:
> Hi Antoine,
>
> > 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".
>
> I think you might have misparsed my email; I wasn't using one
> observation to justify the other.
>
> I ran a script[0] to tally the value of newly created outputs by address
> type, and the node tells me that 93.5% of all output-value created over
> the last three months is non-P2TR.

The total output value created that is non-P2TR is irrelevant here: all those
outputs are being created by existing production systems. Obviously, they have
no reason to rush to implementing taproot. Heck, as I just mentioned elsewhere,
even P2PKH addresses are *still* fairly commonly used even though there are
significant fee savings to upgrading. People just don't like upgrading existing
- working - code unless there is a really good reason.

What we're discussing here is a new scripting feature, that inevitably are only
useful for brand new code. There are no sigificant obstacles to new code making
use of taproot.

ACK new opcodes being taproot only.

[Sjors Provoost]

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 <bitco...@googlegroups.com> het volgende geschreven:

[...]

[Antoine Poinsot]

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 <sj...@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 bitco...@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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4E54B8EA-9BE8-4660-AA29-72E14C3AADF5%40sprovoost.nl.

[Greg Maxwell]

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?

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ZVpECz43S3fTL1NKxxHANGsvtOJmQJmstZ6Xa9laLg7WkdmiLL10yqKgVjsOb0GZFkEpz4vaBfN-uy3mu7kFT41QFTuXD3a_tSoLpSIbIGs%3D%40protonmail.com.

[Garlo Nicon]

> There are no sigificant obstacles to new code making use of taproot.

Using OP_SIZE on top of Schnorr signature doesn't reveal Proof of Work behind it. But if it is done behind P2WSH, then it works much better (the smaller DER signature is, the more Proof of Work it requires). Which means, that if you want to have Proof of Work, and any conditions, then you are forced to use P2WSH or something older (but older things are non-standard). In theory, that kind of problems could be solved by new opcodes like OP_CAT, but then, they would open more use cases, which may have unknown side effects (like implementing BIP-300 or BIP-301 without any additional soft-fork).

Also, if you use OP_CHECKMULTISIG, then it is guaranteed, that all signatures can sign the same z-value, if they want (which is useful, when ECDSA is used as a 256-bit calculator; if secp256k1 will ever be broken, and OP_CHECKMULTISIG won't be disabled, then I guess using it as a big number calculator will be the main use case). However, in Taproot, there is OP_CHECKSIGADD instead, and then, each OP_CHECKSIG call is executed on a different z-value, and it is much harder to force it to be the same for different signatures.

Another combination, which can be used only in legacy scripts, is moving coins from random P2PK outputs with out-of-bounds SIGHASH_SINGLE, from known public keys, with unknown private keys. Then, even P2WSH cannot do that, because z-value cannot be controlled by the spender in any reasonable way (and different sighashes cannot be chained, because when txid inside input can change, then next signature in the chain can be invalid; it is hard to make a chain of one-input-one-output signatures, when all of them would use sighashes SINGLE with ANYONECANPAY, because adding any input or output to anything in that chain, will instantly invalidate all following signatures).

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aHi80KYQB7ZnUiVl%40petertodd.org.