Difference between revisions of "OP PUSH TX"
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
− | OP_PUSH_TX is a catch-all name for techniques that use [[ECDSA]] signature messages to enforce | + | OP_PUSH_TX is a catch-all name for techniques that use [[ECDSA]] signature messages to access and enforce transactional states and other conditions in [[Script|Bitcoin script]]. The technique requires the user or process that is using the UTXO to push the transaction pre-image message that is used to generate the signature onto the stack as part of the input scriptSig. |
This message can be pushed as a single contiguous blob, as multiple separate elements, or as a partial set, with the remaining elements of the message set via the output's scriptPubKey. | This message can be pushed as a single contiguous blob, as multiple separate elements, or as a partial set, with the remaining elements of the message set via the output's scriptPubKey. | ||
− | The technique allows the process to | + | The technique allows the process to enforce several elements of the transaction including (but not limited to): |
− | |||
# The number of inputs in the transaction | # The number of inputs in the transaction | ||
# The nSequence values of those inputs | # The nSequence values of those inputs |
Latest revision as of 08:05, 4 April 2022
OP_PUSH_TX is a catch-all name for techniques that use ECDSA signature messages to access and enforce transactional states and other conditions in Bitcoin script. The technique requires the user or process that is using the UTXO to push the transaction pre-image message that is used to generate the signature onto the stack as part of the input scriptSig.
This message can be pushed as a single contiguous blob, as multiple separate elements, or as a partial set, with the remaining elements of the message set via the output's scriptPubKey.
The technique allows the process to enforce several elements of the transaction including (but not limited to):
- The number of inputs in the transaction
- The nSequence values of those inputs
- The value of the input being spent
- The value and script of any outputs being generated
- The nLocktime condition set for the transaction
In addition, the technique allows users to enforce the script into which the tokens the UTXO being spent will go, which is a crucial step in the creation of Turing complete machines. This is achieved by taking the current script (part of the message) and using it to build an image of the next script in the chain before re-inserting it into the message hash and performing an EC signature in script. When the signature is tested using OP_CHECKSIG or any of its variants, the interpreters in the consensus layer will validate that the message and its conditions are a true representation of the transaction being processed, enabling the enforcement of next state conditions at the consensus layer.
A significant shortcut has been developed that generates a signature using the keypair that corresponds to a private key of 1. In this situation, the signature is simply the hashed message with some simple byte-wise transformations performed.