Published on: 2020-02-03T08:20:52+00:00
The bitcoin-dev mailing list is currently discussing proposals to change the behavior of OP_CHECKTEMPLATEVERIFY (CTV) and how it should be specified. One proposal suggests that CTV should behave more like CHECKSIG, including a flags byte that specifies what is hashed. Another idea presented is the use of a flag called SIGHASH_NOSIG instead of an actual CheckSig SIGHASH Flag. However, this proposal has been criticized for being ill-advised due to the awkward API it would create and its incompatibility with soft-fork encoding rules.It was also suggested that committing to the input index using a flag instead of CTV may be less flexible. Enabling a flag right away may enable a big footgun right off the bat. NOINPUT as specified in a BIP isn't a great surrogate for CTV because CTV commits to the input index, which prevents half-spend. Committing to the input-index is not a sender policy choice, but a receiver policy choice. CSV is an example where redemption policies are committed to in the output by the sender via the sequence_no field, and then checked with an opcode OP_CSV to enable relative timelocks.The proposal imposes "MUST" conditions on the existence of the covenant itself, as well as the number of inputs and outputs, to prevent txid malleability so that such transactions can be used in offline protocols. Txid non-malleability can be achieved by enforcing that the output must be spent using SIGHASH_ALL instead of committing to the number of inputs separately with a new opcode. The MUST condition also helps with sighash caching for batch validation.The discussion revolves around the use of "MUST" conditions for validity caching, which is not actually helpful in precomputing information before fetching outputs from the database. Input indexes eliminate third-party malleability of input order and prevent half-spend, but there is confusion regarding their usage in transactions.CTV is equivalent to a flag in sequence_no that is logically MUST|ALL|NOSIG|INPUTINDEX and a redeemScript of <>. Lightning-like use cases might put sequence_no flags that are logically MAY|ALL|NOINPUT. OP_CAT already allows similar functionality with SIGHASHes, but it requires careful review due to its surprising functional consequences.The idea of expressing CTV as a sighash type today does not offer any benefits since a future soft fork can make CTV a valid hash in a new language. Instead of cramming logic into flags, it is suggested to construct the digest pattern in script or write an actual language for dealing with sighashes. However, this may lead to quadratic hashing if every output commits to a different complex thing. CTV is fully compatible with context-free validation optimizations, while other approaches may not be.The proposal suggests that OP_CHECKTEMPLATEVERIFY should behave more like CHECKSIG and have a flags byte that specifies what is hashed, unifying the ways a SigHash is computed. The CTV-type functionality using CHECKSIG is achievable with some form of NOINPUT flag. Committing to the number of inputs and outputs makes CTV hashes easier to compute with script, but it requires OP_CAT. However, committing to the input index is a sender-specified-policy choice and can be considered using a flag instead.A new flag SIGHASH_NOSIG might work as an alternative type of CHECKSIG operator or CTV might be renamed to CHECKSIGHASH, appending flag bytes to the hash to be checked. The flags discussed above, NOINPUT, NOSIG, INPUTINDEX are all really sender-policy choices, while SIGHASH flags are redeemer-choice. CSV (CHECKSEQUENCEVERIFY) shows that redemption policies are committed to in the output by the sender via the sequence_no field. As user policy choices, NOINPUT might be considered "MAY" conditions, while covenants are a MUST condition.Txid non-malleability can be achieved by enforcing that the output must be spent using SIGHASH_ALL instead of committing to the number of inputs separately with a new opcode. Assuming a CSV-type mechanism can be devised using sequence_no, CTV is equivalent to a flag in sequence_no that is logically MUST|ALL|NOSIG|INPUTINDEX and a redeemScript of <>. Lightning-like use cases might put sequence_no flags that are logically MAY|ALL|NOINPUT. The other mechanism for sender policy is scriptPubKey, which is heavily restricted by isStandard, but might be another place to specify flags like the above.
Updated on: 2023-08-02T01:50:00.155787+00:00