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 <[email protected]> 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 <[email protected]> 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 [email protected] >> <mailto:[email protected]>. >> 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2273A82E-F515-4288-8C94-9768B10808C2%40gmail.com.
