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

[Greg Sanders <gsanders87@gmail.com>]

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