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

["James O'Beirne" <james.obeirne@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4838 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 6059 bytes --]