Posted by Brandon Black
Jul 10, 2025/04:44 UTC
The discussion revolves around the intricacies of TEMPLATEHASH in comparison to other hashing mechanisms like CTV and SIGHASH_ANYSCRIPTANYPREVOUT|ALL, highlighting its unique position and the modifications it brings to the table. TEMPLATEHASH distinguishes itself by omitting certain elements present in the others, such as nInputs, nOutputs, and scriptSigs, while incorporating features like the taproot annex presence flag and taproot annex. This adjustment allows TEMPLATEHASH to indirectly commit to the number of inputs through sequences, facilitating the creation of stable transaction IDs with minimal inputs without compromising on legacy script compatibility or necessitating hash construction on the stack.
The capabilities section delves into the potential of TEMPLATEHASH when integrated with CSFS, maintaining that all protocols achievable with LNHANCE could also be realized using a combination of CTV and CSFS alone. The proposal introduces INTERNALKEY for its efficiency in common protocols, citing a saving of 32WU by reusing the taproot internal key in scripts, exemplified by the Lightning Symmetry protocol. Although PAIRCOMMIT is excluded from this proposal, TEMPLATEHASH's commitment to the taproot annex enables certain optimizations, particularly for protocols requiring an additional data push during spend, either pre-committed or committed at spend-time. The conversation also touches upon the implications of committing to the annex for future protocol extensions, concluding that while it may restrict some implementations, it does not foreclose on any viable protocol applications.
Efficiency comparisons are made between this proposal and previous ones, illustrating how TEMPLATEHASH positions itself in terms of workload units (WU) for implementing common protocols. It is noted to be slightly less efficient than bare CTV for protocols not requiring multiple data commitments, but significantly more so for those that do, thanks to its streamlined approach. Particularly in scenarios like the uncontested close case in the Lightning Symmetry protocol, TEMPLATEHASH proves to be more advantageous. The proposal is seen as a targeted enhancement to tapscript, optimizing opcode package without inducing technical reservations. The author expresses a desire for the proposal to undergo thorough review within the broader technical community, reflecting a commitment to collaborative development and innovation in the space.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback