# CTV++ OP\_TEMPLATEHASH and OP\_INPUTAMOUNTS

**URL:** <https://delvingbitcoin.org/t/ctv-op-templatehash-and-op-inputamounts/1344>\
**Category:** Protocol Design\
**Created:** [December 30, 2024, 12:21pm UTC](https://delvingbitcoin.org/t/ctv-op-templatehash-and-op-inputamounts/1344 "2024-12-30T12:21:16Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![moonsettler](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/moonsettler/32/38_2.png) [@moonsettler](https://delvingbitcoin.org/u/moonsettler)\
**Post date:** [December 30, 2024, 10:11pm UTC](https://delvingbitcoin.org/t/ctv-op-templatehash-and-op-inputamounts/1344/3 "2024-12-30T22:11:19Z")

</div>

It all depends on if said generality is even wanted. There is a gigantic threshold between being able to introspect the inputs or parent transactions in a meaningful way or not. It’s like two different universes.

The point of this exercise if you like, is to show what you can do by staying within the exact set of fields `CTV` commits to, just with more flexibility or programmability than you get with something like a singular use of `TXHASH`.

And you get a lot of utility out of it without really violating said threshold boundaries.

**edit:** See [Optimistic ZK verification using MATT](https://delvingbitcoin.org/t/optimistic-zk-verification-using-matt/1050/1)!

---

_[View the full topic](https://delvingbitcoin.org/t/ctv-op-templatehash-and-op-inputamounts/1344)._