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.