ZmnSCPxj already observed in [1] that these ops would enable introspection of any field of the transactions and make both `OP_CHECKLOCKTIMEVERIFY` and `OP_CHECKSEQUENCEVERIFY` superfluous.
There is much more to this as enumerated in generic terms by Russel O’Connor below and I would like to add a concrete example.

We could implement oracle less difficulty contracts without the need the of a CISC type OP_WORKVERIFY but instead through resurrection/extension of OP_CAT, OP_GREATERTHANOREQUAL and introduction of a new RISC opcode OP_CHECKBLOCKATHEIGHT[3] suggested by Luke Dashjr. Thanks for the pointer to Nathan Cook [4]

Technically we could resurrect and add them without burning more than one OP_NOP by redefining it as a prefix (OP_EXTENSION), such as:

OP_EXTENSION OP_CAT would become a two byte opcode pointing to a resurrected implementation of OP_CAT.

This could be soft forked in.

A concrete oracle less difficulty contract could look like:
It is an european digital call option on target difficulty after maturity and 10 blocks notice period. I gave you reasons while having these would increase bitcoin's security in [2]

IF
	<maturity as block height + 10> CHECKLOCKTIMEVERIFY DROP
      <speculator’s key> CHECKSIGVERIFY
ELSE
	OP_DUP  <maturity as block height - 1> OP_CHECKBLOCKATHEIGHT OP_LESSTHANEQUAL OP_VERIFY
	OP_SWAP OP_CAT  OP_CAT  OP_HASH256 <contracted target> OP_LESSTHANEQUAL OP_VERIFY
	<miner’s key> CHECKSIGVERIFY
ENDIF

insurance premium could be collected by the seller of the insurance after maturity + 10 blocks if target difficulty was not reached

<speculator’s signature>

miner would get back its insurance premium plus collateral of the seller if target difficulty was not reached at maturity. Miner has 10 blocks time after maturity to claim with:

<maturity block header after prevhash> <maturity block version> <prevhash>

The stack would be in second case processed as:

1: after pushes
<maturity block prevhash>
<maturity block version>
<maturity block block header after prevhash>

2: after OP_DUP:
<maturity block prevhash>
<maturity block prevhash>
<maturity block version>
<maturity block block header after prevhash>

3: after push
<maturity as block height - 1>
<maturity block prevhash>
<maturity block prevhash>
<maturity block version>
<maturity block block header after prevhash>

4: after OP_CHECKBLOCKATHEIGHT OP_VERIFY is successful proving that prevhash is the block at maturity block height - 1
<maturity block prevhash>
<maturity block version>
<maturity block block header after prevhash>

5: after OP_SWAP
<block version>
<maturity block prevhash>
<block header after prevhash>

6: after OP_CAT
<maturity block version concatenated with maturity prevhash>
<maturity block block header after maturity prevhash>

7: after OP_CAT
<complete block header>

8: after OP_HASH256
<block hash computed for header>

9: after push
<contracted target>
<block hash computed for header>

10: after OP_GREATERTHANOREQUAL OP_VERIFY proves that contracted target was reached

Tamas Blummer


[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016966.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016966.html>
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017019.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017019.html>
[3] https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki <https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki>
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016954.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016954.html>
[5] https://github.com/bitcoin/bitcoin/blob/master/src/script/script.h <https://github.com/bitcoin/bitcoin/blob/master/src/script/script.h>
> On May 22, 2019, at 23:01, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for Bitcoin via new Script operations.  However, I think that these proposals miss the mark when it comes to how they approach Bitcoin Script and language features.
> 
> Bitcoin Script appears designed to be a flexible programmable system that provides generic features to be composed to achieve various purposes.  Thus, when we design new language features for Script, we should be striving, as much as possible, to similarly build general purpose tools which can in turn be used for a variety of purposes.
> 
> I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail to achieve these design goals.  They are both are designed with very narrow applications in mind, while also going out of their way to extend the semantic domain of the interpretation of Bitcoin operations in new ways that complicate their specification.  In the case of SIGHASH_ANYPREVOUT, the semantic domain is extended by adding new counters to track the use of various v0 and v2 signature types.  In the case of OP_CHECKOUTPUTHASHVERIFY, it employs a new context-sensitive operation that peeks at the value of surrounding opcodes.
> 
> Instead, I propose that, for the time being, we simply implement OP_CAT and OP_CHECKSIGFROMSTACKVERIFY.  OP_CAT pops two byte arrays off the stack and pushes their concatenation back onto the stack.  OP_CHECKSIGFROMSTACKVERIFY pops a signature, message, and pubkey off the stack and performs a bip-schnorr verification on the SHA256 hash of the message.
> 
> In concert, these two operations enable:
> 
> * Oracle signature verification, including discrete log contracts.
> * Amortized secure multiparty computations (see "Amortizing Secure Computation with Penalties" by Kumaresan and Bentov).
> * Transaction introspection including:
> + <> Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply by the nature of the construction.
> + <> Decide if a transaction has exactly one input or not. (etc.)
> + Weak covenants, which can verify output scripts to see if they are among a set of predefined values or verify the output hash.
> 
> and presumably more applications as well.
> 
> For better or for worse, without an OP_PUBKEYTWEEK operation available, the more interesting recursive-covenants remain largely out of reach, with the exception of a recursive covenant that is only able to send back to its own address, possibly abusing its own TXO value as a state variable.
> 
> All this is accomplished by two straightforward opcodes whose semantics are pure computational operations on stack values.  The only semantic side-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the existing 'sigops_passed' count.  Moreover, I feel that adding these operations does not preclude adding more specialized opcodes in the future as an optimization for whatever popular constructions come up, once we know what those are.
> 
> I feel that this style of generic building blocks truly embodies what is meant by "programmable money".
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev