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

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

[Greg Sanders]

[-- Attachment #1.1: Type: text/plain, Size: 3461 bytes --]

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

-- 
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/26b96fb1-d916-474a-bd23-920becc3412cn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3905 bytes --]

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

[Rijndael]

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

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

> On Jul 9, 2025, at 2:19 PM, Greg Sanders <gsanders87@gmail.com> wrote:
> 
> 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
> 
> -- 
> 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 <mailto:bitcoindev+unsubscribe@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/26b96fb1-d916-474a-bd23-920becc3412cn%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/26b96fb1-d916-474a-bd23-920becc3412cn%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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/682337FB-F451-459F-8B4C-56E61C49FA4F%40gmail.com.

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

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

[Rijndael]

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

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


> On Jul 9, 2025, at 3:59 PM, Rijndael <rot13maxi@gmail.com> wrote:
> 
> 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
> 
>> On Jul 9, 2025, at 2:19 PM, Greg Sanders <gsanders87@gmail.com> wrote:
>> 
>> 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
>> 
>> -- 
>> 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 <mailto:bitcoindev+unsubscribe@googlegroups.com>.
>> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/26b96fb1-d916-474a-bd23-920becc3412cn%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/26b96fb1-d916-474a-bd23-920becc3412cn%40googlegroups.com?utm_medium=email&utm_source=footer>.
> 

-- 
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/2273A82E-F515-4288-8C94-9768B10808C2%40gmail.com.

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

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

[Ademan]

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

Isn't it indirectly committed to by sha_sequences?

On Wed, Jul 9, 2025 at 3:09 PM Rijndael <rot13maxi@gmail.com> wrote:

> 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
>
> On Jul 9, 2025, at 2:19 PM, Greg Sanders <gsanders87@gmail.com> wrote:
>
> 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
>
> --
> 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/26b96fb1-d916-474a-bd23-920becc3412cn%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/26b96fb1-d916-474a-bd23-920becc3412cn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> 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/682337FB-F451-459F-8B4C-56E61C49FA4F%40gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/682337FB-F451-459F-8B4C-56E61C49FA4F%40gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAKwYL5GjrOp5QbwMF%2BvS6dDYPjc7tBNPAZsqVBzb1DcY_h4FpQ%40mail.gmail.com.

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

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

[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

On 2025-07-09 (Wed) at 11:19:22 -0700, Greg Sanders wrote:
> 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

-- 
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/aG9FEHF1lZlK6d0E%40console.

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

[James O'Beirne]

[-- 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 --]