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 <[email protected]> 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/[email protected]/ > > > # 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 [email protected]. > 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/_POzkO7sHDURx6skGAWsrxN_UUtN_6Ak6donzVhmzYzAV6Ej22jBnE2baxM_WtqxW2RNvDjze72kOVgowNhqGSJ1dg5m_HTO3FuG6QM5daw%3D%40protonmail.com.
