make CHECKOUTPUTSVERIFY take stack arg, but check prev. executed opcode

[dgpv]

This is to illustrate my point (made here: https://twitter.com/dmpsim/status/1130889625298509824) that checking previously executed opcode is simple enough, and allows to retain the consistency of stack-based execution model.

to argue my point further:

Making opcode behavior depend on the previous executed opcode adds complexity to the script execution model, but the amount of complexity added by this opcode-lookbehind mode is small, and this is arguably better than making non-pushdata opcodes use data lookahead, because this erodes the consistency of the stack machine execution model.

The argument here seems to boil down to complexity vs model consistency.

Reducing consistency just externalizes the complexity outside: to the users of the script and to the tools that operate on it.

To illustrate:

    outputs_hash = hash256(b"".join(o.serialize() for o in outputs)
    
    # constructing a bytes array, will probably abstracted away as ConstructCOSHV(ohash) or something
    CScript(bytes([OP_CHECKOUTPUTSHASHVERIFY, 0x20]) + outputs_hash))
    # vs
    # working with a script as usual, no need for any abstractions or special bytes-construction
    CScript([outputs_hash, OP_CHECKOUTPUTSHASHVERIFY, OP_TRUE])

regarding OP_TRUE: it is needed, because CHECKOUTPUTSHASHVERIFY pops the hash, does not push any result on the stack, and TRUE is required on the stack after the script execution. If there would be CHECKOUTPUTSHASH (non-verify), that itself pushes TRUE or FALSE to the stack, there would be no need for extra TRUE, but then it is a whole opcode to waste :-/. Alternative might be to only have non-VERIFY opcode, but then if it is not at the end of the script, you will need additional OP_VERIFY to act on the result.

While opcode-lookbehind also encumbers the execution model somewhat, by introducing inter-opcode dependency, this encumberance is small in my opinion (because only one step back), and is in line with imposing restrictions on execution for the opcodes of bitcoin script, without challenging the consistency of the execution model.

This way also allows to lift the restriction by just skipping the prev_opcode check, if this is deemed safe in the future.

[dgpv]

Similar issue regarding *VERIFY and script success check rule was discussed here: ElementsProject/elements#202 (comment)

[dgpv]

A conversation with Russel O'Connor about this made me realize that because there are fundamental distinction in Bitcoin script between 'commitment time' and 'redemption time', having immediate values for opcodes makes sense. The cost of mental switch between 'stack mode' and 'immediate mode' is offset by additional information gained: the opcode with immediate argument indicates "this is pre-committed value, this may bear some additional meaning".

I am closing this pull request.