Direct Introspection
OP_TX or individual opcodes
Links
Introduction
A straightforward way to achieve covenants is to give the Script of a transaction's inputs direct access into the entire transaction's data. If the script can inspect any part of the transaction, it is by definition introspective and can enforce any possible constraint on the transaction's properties.
Technically, there are two ways direct transaction introspection can be realized, either through various opcodes to query different aspects of the transaction, to be put onto the stack by the script execution engine; or by introducing a single opcode together with an additional specifier of what parts of the transaction you want.
Individual opcodes
An example of the former was introduced into Elements in the shape of the following opcodes (excluding the ones only relevant for Elements):
OP_INSPECTINPUTOUTPOINTOP_INSPECTINPUTVALUEOP_INSPECTINPUTSCRIPTPUBKEYOP_INSPECTINPUTSEQUENCEOP_PUSHCURRENTINPUTINDEXOP_INSPECTOUTPUTVALUEOP_INSPECTOUTPUTSCRIPTPUBKEYOP_INSPECTVERSIONOP_INSPECTLOCKTIMEOP_INSPECTNUMINPUTSOP_INSPECTNUMOUTPUTSOP_TXWEIGHT
Implementation and usage of these opcodes is rather straightforward.
General opcode
An example of the latter approach would be OP_TX, a single opcode that takes a specifier from the
stack that the user can use to indicate what parts of the transaction they want. The benefits of
this approach are that more transaction data be requested using fewer script bytes.
A potential implementation of OP_TX could be based on the specification of OP_TXHASH as
described in this section where the same specifier can be
used but instead of the individual elements being hashed together for OP_TXHASH, they can be
pushed onto the stack with OP_TX.