From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: James O'Beirne <james.obeirne@gmail•com>
Cc: Greg Sanders <gsanders87@gmail•com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A Taproot-native (re-)bindable transaction bundle proposal
Date: Fri, 11 Jul 2025 18:37:31 +0000 [thread overview]
Message-ID: <_POzkO7sHDURx6skGAWsrxN_UUtN_6Ak6donzVhmzYzAV6Ej22jBnE2baxM_WtqxW2RNvDjze72kOVgowNhqGSJ1dg5m_HTO3FuG6QM5daw=@protonmail.com> (raw)
In-Reply-To: <CAPfvXf+E0YDzqY_jsGVoc4KKh_Kgsp-p20wNAD05tv_rMNG2sA@mail.gmail.com>
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.
On Thursday, July 10th, 2025 at 9:04 AM, James O'Beirne <james.obeirne@gmail•com> wrote:
> 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/20220305055924.GB5308@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
>
> --
> 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/CAPfvXf%2BE0YDzqY_jsGVoc4KKh_Kgsp-p20wNAD05tv_rMNG2sA%40mail.gmail.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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/_POzkO7sHDURx6skGAWsrxN_UUtN_6Ak6donzVhmzYzAV6Ej22jBnE2baxM_WtqxW2RNvDjze72kOVgowNhqGSJ1dg5m_HTO3FuG6QM5daw%3D%40protonmail.com.
next prev parent reply other threads:[~2025-07-11 18:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-09 18:19 Greg Sanders
2025-07-09 19:59 ` Rijndael
2025-07-09 20:05 ` Rijndael
2025-07-09 20:14 ` Ademan
2025-07-10 4:44 ` Brandon Black
2025-07-10 12:24 ` James O'Beirne
2025-07-11 18:37 ` 'Antoine Poinsot' via Bitcoin Development Mailing List [this message]
2025-07-11 22:59 ` James O'Beirne
2025-07-12 0:27 ` Murch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='_POzkO7sHDURx6skGAWsrxN_UUtN_6Ak6donzVhmzYzAV6Ej22jBnE2baxM_WtqxW2RNvDjze72kOVgowNhqGSJ1dg5m_HTO3FuG6QM5daw=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(echo .)com \
--cc=gsanders87@gmail$(echo .)com \
--cc=james.obeirne@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox