Here’s what I think OP_TEMPLATEHASH might look like, which could then be combined with OP_CHECKSIGFROMSTACK(VERIFY) to provide APO (but not APO|SINGLE) behavior.
All OP_TEMPLATEHASH hashes commit to <hash_mode> OP_TEMPLATEHASH (i.e.
0x0050, 0x5150, &c), the transaction’s version, number of
outputs, and outputs.
We define the following groups of input data:
- may be included for any input
prevout:prevscript: output amount and scriptsequence:
- only from the input being validated
script: control block, leaf script, and code separator positionannex: taproot spend type and annex
- other data
locktime:scriptsigs: hash of all scriptSigs if any scriptSig is non-empty
We define the following paired hashing modes using a numeric hash_mode that
can be represented by an opcode. Even modes do not hash annex, odd do.
| mode | included data |
|---|---|
| 0,1 | - |
| 2,3 | locktime and this sequence (3 similar to bip118 0xc1) |
| 4,5 | “2” with this prevscript and script (5 similar to bip118 0x41) |
| 6,7 | nInputs |
| 8,9 | “6” with locktime and all sequences |
| 10,11 | “8” with scriptsigs (similar to bip119) |
| 12,13 | “10” with all prevscripts and script |
| 14,15 | “12” with all but input 0’s prevout[1] |
Modes 14,15 only work on input 0 which is a bit of an odd behavior, but enables a hash mode that constrains all other inputs’ prevouts without incurring quadratic hashing. Because such a mode could only ever be used on one input to a transaction, constraining it to input 0 seems a reasonable solution. ↩︎