{ "title": "OP_PUSH_TX_STATE" }


Place information about the current transaction onto the stack

This opcode will change significantly.
In particular, it makes a lot of sense for the transaction data to be merklized and bit-paths to be used to specify and prove aspects of the transaction.
It is essential that push_tx_state also return what portion of the transaction the accessed data comes from, so that an attacker cannot put arbitrary data (say fake outputs) in OP_RETURN and then present a bit-path specifier to that data, rather than the real data.

Syntax and Stack

dataSpecifier OP_PUSH_TX_STATE => ret1…retN?

  • dataSpecifier: An array of bytes describing the state to be pushed
  • ret1…retN: Each item in the dataSpecifier identifies a piece of transaction data, which is pushed to the stack as separate items in the order their specifiers appear.

Binary representation

OP_PUSH_TX_STATE is represented by the single byte 0xea.


Data Specifiers

Note, this list is incomplete; new specifiers will be added as needed. Please see [2] for a more comprehensive list.

Name Number Parameters Description
TX_VERSION 0x1 none The transaction version number
TX_ID 0x2 none The double SHA256 of the serialized transaction, commonly known as the transaction id.
TX_SIGHASH 0x3 flavor The double SHA256 of serialized portions of the transaction.
GROUP_TOKEN_SUPPLY 0x4 GroupId The incoming quantity of tokens contained by GroupId
GROUP_BCH_SUPPLY 0x5 GroupId The incoming quantity of BCH (in satoshis) contained by GroupId


In combination with OP_CDS, this specifier can be used to implement advanced transaction techniques such as described in [3].

TX_SIGHASH flavors

The TX_SIGHASH flavor is a 32 bit little-endian serialized unsigned integer bitfield that specifies pieces of transaction information. A hash is constructed by executing the double SHA256 of the serialized data corresponding to each set bit, and a single byte 0 for every unset bit.

Name Bit Description
Version 0 4 byte LE nVersion of the transaction
PrevoutsHash 1 32 byte hash of the previous outputs (hash and index)
PrevoutsSequenceHash 2 32 byte hash of the previous output sequence numbers
Outpoint 3 The prevout (32 byte hash and 4 byte LE index) being spent
ScriptCode 4 The script being executed, from the most recently executed OP_CODESEPERATOR to the end
PrevoutValue 5 64 byte LE value of the output spent by this input (in Satoshis)
Sequence 6 4 byte LE sequence number of this input
OutputsHash 7 32 byte hash of the tx outputs
NthOutputHash 8 32 byte hash of the nth output where n = this input’s index
LockTime 9 4 byte LE transaction lock time

The above structure is currently very similar to the current Bitcoin Cash sighash algorithm.


[PUSH_TX_STATE.E1] If the number of pushed items, plus the current stack position exceeds the maximum stack size, the script fails.

Implementation notes

Design considerations

CHECKSIG is comprised of two more fundamental primitives, reading transaction data, and verifying a signature over that data. This functionality can now be implemented as follows:


The advantage of providing fundamental primitives is versatility – the primitives can be combined in novel or unanticipated ways to implement new functionality at the script level, rather than requiring a hard fork for each specific new feature.

The disadvantage is errors – the more power script authors are given, the easier it is for them to create incorrect scripts. However, there are already an almost infinite number of incorrect scripts – the decision towards power was made the moment a scripting language was introduced into Bitcoin. Today we have the worst of both choices: all the dangers, complexities, and inefficiencies of a scripting language, and none of its power due to missing/removed functionality. That the language is almost useless is evidenced by the fact that almost all scripts follow 2 patterns (p2pkh and multisig), in the face of other cryptocurrencies that evidence a large variety of scripts.


  1. Group Tokenization. Stone. 2018. https://docs.google.com/document/d/1X-yrqBJNj6oGPku49krZqTMGNNEWnUJBRFjX7fJXvTs/edit?usp=sharing (PUSH_TX_DATA, page 31-)

  2. OP_PUSHSTATE Draft Specification. bitjson. 2019. https://github.com/bitjson/op-pushstate.

  3. eltoo: A Simple Layer2 Protocol for Bitcoin. Decker, Russell, Osuntokun. 2018. https://blockstream.com/eltoo.pdf.