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.
dataSpecifier OP_PUSH_TX_STATE => ret1…retN?
OP_PUSH_TX_STATE is represented by the single byte 0xea.
Note, this list is incomplete; new specifiers will be added as needed. Please see  for a more comprehensive list.
|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 .
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.
|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.
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:
sig PUSH(TX_SIGHASH, selector) OP_PUSH_TX_STATE pubkey OP_CHECKDATASIG
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.
Group Tokenization. Stone. 2018. https://docs.google.com/document/d/1X-yrqBJNj6oGPku49krZqTMGNNEWnUJBRFjX7fJXvTs/edit?usp=sharing (PUSH_TX_DATA, page 31-)
OP_PUSHSTATE Draft Specification. bitjson. 2019. https://github.com/bitjson/op-pushstate.
eltoo: A Simple Layer2 Protocol for Bitcoin. Decker, Russell, Osuntokun. 2018. https://blockstream.com/eltoo.pdf.