Bitcoin Cash transactions make use of a scripting language to authorize and secure transfers. While, colloquially, there is a tendency to refer to transactions as "sending" Bitcoin Cash to "an address", that is merely an abstraction. In fact, the only thing that permits the spending of existing UTXOs is the successful execution of a script. The only thing preventing the spending of newly created UTXOs is the difficulty of producing a successfully executing script. Through the use of cryptographic signatures and hash functions, such scripts are often designed specifically to be difficult to produce unless you are the intended spender of a given UTXO, though that need not necessarily be the case.
For more information on how Transactions are commonly secured, see Locking Script.
This page will focus on how the scripts are run, what they are capable of, and what limitations they have.
Scripts are executed using a stack-based memory model and have an intentionally restricted set of available operations. Unlike the common general-purpose programming languages your are probably aware of, Script (the term for the language itself) does not allow for loops, persistent state/memory across script executions, or the definition of functions. Instead, scripts are expected to contain whatever data they need and use the available operations to prove transaction validity.
In addition to the primary stack ("the stack"), there is a secondary stack, referred to as the "alt-stack", which data can be moved to temporarily. Any data left on the alt-stack is lost when a given sub-script finishes execution. In effect, any data moved to the alt-stack by an unlocking script is not present when the locking script runs.
There are a large number of op-codes that support everything from simple stack-manipulation, to mathematical calculations, to complex cryptographic processes. In terms of control structures there are only basic conditional branching (IF/ELSE) operations available.
Scripts are run when validating transactions, and successful execution of all of the scripts defined by the transaction is a necessary, but not sufficient, condition for transaction validity. See Transaction Validation for more details.
As a part of validating a transaction, a script is built for each input spent by the transaction. Each script is the sequential execution (carrying over the same stack, but not alt-stack) of the unlocking script provided with the input definition (which is used that the beginning of the script) and the locking script provided by the previous output being referenced. The exception to this is pay to script hash, which has an altered execution workflow. In general, though, this combined unlocking/locking script is then executed and considered successful if and only if the following conditions are met:
- Non-Zero Value - after execution the top of the stack must contain a non-zero (TRUE) value.
- No Stack Overflows - no operation should attempt to pop a value from the stack when the stack is empty. An overflow of the alt-stack is also disallowed.
- Clean Stack - after execution the stack must only contain a single value, which must be non-zero (TRUE). Added in HF-20181115. The alt-stack is exempt from this.
Additionally, in order for the combined script to be valid, the following must be true:
- Non-Empty Scripts - both the locking and unlocking scripts must be non-empty.
- Max Script Length - the locking and unlocking script must each be less than the max script length of 10,000 bytes (for a combined script maximum of 20,000 bytes).
- Contained Control Flow - an IF/ELSE block cannot start in the unlocking script and end in the locking script, the script must be in the top-level scope when the locking script execution begins.
- Permitted Operations Only - the locking script must not include operations that are disallowed and must not execute operations that are disabled..
- Push Only - the unlocking script must contain only push operations (i.e. those with op codes 0x60 or less). Added in HF-20181115.
Operation codes (opcodes)
The table below lists the currently allocated op codes. Op codes marked with (ignored) are permitted but will do nothing when executed. Op codes marked with (disabled) are permitted in scripts so long as they are not executed. Op codes marked with (do not use) are disallowed and will make a transaction invalid merely be being present.
|OP_0, OP_FALSE||0||0x00||0||An empty array of bytes is pushed onto the stack. See also OP_X|
|N/A||1-75||0x01-0x4b||The next value bytes is data to be pushed onto the stack. See also OP_DATA_X|
|OP_PUSHDATA1||76||0x4c||The next byte contains the number of bytes to be pushed onto the stack.|
|OP_PUSHDATA2||77||0x4d||The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.|
|OP_PUSHDATA4||78||0x4e||The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.|
|OP_1NEGATE||79||0x4f||-1||The number -1 is pushed onto the stack.|
|OP_1, OP_TRUE||81||0x51||1||The number 1 is pushed onto the stack.|
|OP_2-OP_16||82-96||0x52-0x60||2-16||The number (2-16) is pushed onto the stack.|
|OP_CAT||126||0x7e||x1 x2||out||Concatenates two byte sequences|
|OP_SPLIT||127||0x7f||x n||x1 x2||Splits byte sequence x at position n. Known as OP_SUBSTR before 2018-05-15.|
|OP_NUM2BIN||128||0x80||a b||out||Converts numeric value a into byte sequence of length b. Known as OP_LEFT before 2018-05-15.|
|OP_BIN2NUM||129||0x81||x||out||Converts byte sequence x into a numeric value. Known as OP_RIGHT before 2018-05-15.|
|OP_SIZE||130||0x82||x||x size||Pushes the string length of the top element of the stack (without popping it).|
|OP_AND||132||0x84||x1 x2||out||Boolean AND between each bit of the inputs|
|OP_OR||133||0x85||x1 x2||out||Boolean OR between each bit of the inputs.|
|OP_XOR||134||0x86||x1 x2||out||Boolean EXCLUSIVE OR between each bit of the inputs.|
|OP_EQUAL||135||0x87||x1 x2||true / false||Returns 1 if the inputs are exactly equal, 0 otherwise.|
|OP_EQUALVERIFY||136||0x88||x1 x2||Nothing / fail||Same as OP_EQUAL, but runs OP_VERIFY afterward.|
|OP_DIV||150||0x96||a b||out||a is divided by b|
|OP_MOD||151||0x97||a b||out||return the remainder after a is divided by b|
|OP_RIPEMD160||0xa6||in||hash||Hashes input with RIPEMD-160.|
|OP_SHA1||0xa7||in||hash||Hashes input with SHA-1.|
|OP_SHA256||0xa8||in||hash||Hashes input with SHA-256.|
|OP_HASH160||0xa9||in||hash||Hashes input with SHA-256 and then with RIPEMD-160.|
|OP_HASH256||0xaa||in||hash||Hashes input twice with SHA-256.|
|OP_CHECKDATASIG||186||0xba||sig msg pubkey||true / false||Check if signature is valid for message and a public key. See spec|
|OP_CHECKDATASIGVERIFY||187||0xbb||sig msg pubkey||nothing / fail||Same as OP_CHECKDATASIG, but runs OP_VERIFY afterward.|
|OP_CHECKLOCKTIMEVERIFY||177||0xb1||x||x / fail||Marks transaction as invalid if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in BIP65.|
|OP_CHECKSEQUENCEVERIFY||178||0xb2||x||x / fail||Marks transaction as invalid if the relative lock time of the input (enforced by BIP68 with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in BIP112.|
|OP_NOP1||176||0xb0||Previously reserved for OP_EVAL (BIP12).|
|OP_NOP4-OP_NOP10||179-185||0b3-0xb9||Ignored. Does not mark transaction as invalid.|
Please help improve this article by catigorizing and describing the following up codes.
|0x65||OP_VERIF (do not use)|
|0x66||OP_VERNOTIF (do not use)|
|0x89||OP_RESERVED1 (do not use)|
|0x8A||OP_RESERVED2 (do not use)|
|0xBC - 0xFF||Unused (disabled)|
Some node implementations define custom op codes.
|Op Code Range||Name|
|Op Code Range||Name|
|Op Code Range||Name|
Flowee the Hub
|Op Code Range||Name|