BIP-119 OP_CHECKTEMPLATEVERIFY is a simple proposal to power the next wave of Bitcoin adoption and applications.
The underlying technology is carefully engineered to be simple to understand, easy to use, and safe to deploy. BIP-119 accomplishes this by enabling transaction introspection. A transaction introspection allows a user to restrict where they can spend some of their own bitcoin, beyond private key ownership or timing rules such as in the case of a timelock. This addition greatly expands the expressibility of Bitcoin’s primitives for use in application and layer 2 development on top of the core protocol. See resources for more info and use cases.
BIP-119 does the following:
There is at least one element on the stack, fail otherwise
The element on the stack is 32 bytes long, NOP otherwise
The DefaultCheckTemplateVerifyHash of the transaction at the current input index is equal to the element on the stack, fail otherwise
The DefaultCheckTemplateVerifyHash commits to the serialized version, lock time, scriptSigs hash (if any non-null scriptSigs), number of inputs, sequences hash, number of outputs, outputs hash, and currently executing input index.
The recommended standardness rules additionally:
Reject non-32 byte as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS.
Transaction introspections are restrictions on how a coin may be spent beyond key ownership. Transaction introspections can be useful to construct smart contracts. As transaction introspections are complex to implement and risk introducing fungibility discriminants they have not been seriously considered for inclusion in Bitcoin.
This BIP introduces a simple transaction introspection called a *template* which enables a limited set of highly valuable use cases without significant risk.
Author Jeremy Rubin maintains utxos.org to explore details and use cases related to BIP-119 in depth. See also the BIP itself:
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
There is a fundamental issue with CTV in either the spec or the reference implementation that makes it unsafe for inclusion to Bitcoin. Examples of such an issue:
Coin Theft: It's possible to construct a witness to a CTV-using Output such that the funds can move in an unintended manner.
DoS: Transactions or blocks that take longer than 1 minute to validate as a consequence of CTV
TXID-instability: in the narrow carve out where predicting TXIDs should work (single input CTV from a known output), one is able to malleate the TXID in a way that would break non-interactive lightning channels Invalid CTV transactions stuck in mempool with standard flags after activation, leading to an invalid mineable block template. Severity would be assessed higher if this issue were unique to CTV and not something previous soft forks also had, but this would be treated as severe.
Something that ought to be fixed before release of CTV. Does not require changes to the BIP. Examples of such an issue:
Invalid CTV transactions stuck in mempool with standard flags after activation, but not mineable.
Malicious series of reorg blocks following activation able to disrupt normal function of the mempool (e.g., clearing validation caches)
Something that could be fixed for a benefit, but does not cause an issue if it is not:
Something that requires a clarification to the BIP, but is correct in the reference implementation:
the BIP specifies how to compute the hash in O(N) and the code does it in O(1), following the BIP would lead to a DoS bug.
Improving Performance, but not fixing a DoS Issue
Noting missing test coverage issues, mutation testing opportunities, etc.
A comment does not explain the existing code.
"General core issues". These are rewardable at the discretion of the bounty operators (Lincoln Network), but are not a consequence of the code changes brought by BIP-119:
Changes to activation logic, discovery of a bug that would lead to inconsistent activation.
Reviews that add a unique and detailed perspective to the conversation but do not expose an underlying flaw:
Detailed notes on what was reviewed, why it seems to be safe/ok
Contributing new tests, test vectors, mutation testing
Simulations, case study analysis on the impact of CTV
Proof of safety to the core Bitcoin protocol by adding the BIP
PoC demo applications and detailed viability writeups (using Sapio or other tools). Negative feedback is encouraged here too, e.g., we built a vault V that did x y z with P properties, but if we could use the F alternative then it would be better in W way (the vault V in this example would have to not be a trivially improvable strawman example). If an application is somehow "production grade", rewards could be quite high.
Implementations of Vaults
Payment Pools
Non-Interactive Lightning Channel Batching
High-Quality Library support
Hardware Wallet support
Out of scope issues: "general core issues". These are rewardable at the discretion of the bounty operators (Lincoln Network), but are not a consequence of the code changes brought by BIP-119:
Changes to activation logic, and discovery of a bug that would lead to inconsistent activation.