Opcodes used in Bitcoin Script

Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. The script inside transaction outputs is intentionally not Turing-complete and has no jump instructions to prevent the formation of loops, however with the use of an off-chain agent turing-complete processes can be built using the ledger as a ticker tape to store computational results.

A transaction output script is a predicate formed by a list of instructions that describe how the next person wanting to transfer the tokens locked in the script must unlock them. The script for a typical P2PKH script to Bitcoin address D simply encumbers future spending of the bitcoins with the provision of two things:

1. a public key that, when hashed, yields destination address D embedded in the script, and
2. a signature to prove ownership of the private key corresponding to the public key just provided.

Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several keys, or even no keys at all. The tokens are unlocked if the solution provided by the spending party leaves a non-zero value on the top of the stack when the script terminates.

De facto, Bitcoin script is defined by the code run by the nodes building the Block chain. Nodes collectively agree on the opcode set that is available for use, and how to process those opcodes. Throughout the history of Bitcoin there have been numerous changes to the way script is processed including the addition of new opcodes and disablement or outright removal of opcodes from the set.

The nodes checking Bitcoin script process transaction inputs in a script evaluation engine. The engine is comprised of three stacks which are:

• The main stack
• The alt stack
• The For-loop stack

The main and alt stacks hold byte vectors which can be used by Bitcoin opcodes to process script outcomes. When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Positive 0 is represented by a null-length vector. Byte vectors are interpreted as Booleans where False is represented by any representation of zero and True is represented by any representation of non-zero.

Currently byte vectors on the stack are not allowed to be more than 520 bytes long however in the unbounded bitcoin protocol while pushdata opcodes are limited to pushing 4.3GB onto the stack it is theoretically possible to concatenate multiple objects on the stack to form larger singular data items for processing.

Currently Opcodes which take integers and bools off the stack require that they be no more than 4 bytes long, but addition and subtraction can overflow and result in a 5 byte integer being put on the stack. After the Genesis upgrade in early 2020, miners will be free to mine transactions with data items of any size possible within protocol rules. These will be usable with mathematical functions within script. At this time, Miners will collectively agree on appropriate data limits rather than allowing a centralised committee to form a set of default constraints.

Opcodes

This is a list of all Script words, also known as opcodes, commands, or functions.

OP_NOP1-OP_NOP10 were originally set aside to be used when HASH and other security functions become insecure due to improvements in computing.

False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.

Constants

When talking about scripts, these value-pushing words are usually omitted.

Word	Opcode	Hex	Input	Output	Description
OP_0, OP_FALSE	0	0x00	Nothing.	(empty value)	An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
N/A	1-75	0x01-0x4b	(special)	data	The next opcode bytes is data to be pushed onto the stack
OP_PUSHDATA1	76	0x4c	(special)	data	The next byte contains the number of bytes to be pushed onto the stack.
OP_PUSHDATA2	77	0x4d	(special)	data	The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.
OP_PUSHDATA4	78	0x4e	(special)	data	The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.
OP_1NEGATE	79	0x4f	Nothing.	-1	The number -1 is pushed onto the stack.
OP_1, OP_TRUE	81	0x51	Nothing.	1	The number 1 is pushed onto the stack.
OP_2-OP_16	82-96	0x52-0x60	Nothing.	2-16	The number in the word name (2-16) is pushed onto the stack.

Flow control

Word	Opcode	Hex	Input	Output	Description
OP_NOP	97	0x61	Nothing	Nothing	Does nothing.
OP_VER DISABLED	98	0x62	Nothing	Transaction version	Puts the version of the transaction onto the stack
OP_IF	99	0x63	<expression> if [statements] [else [statements]]* endif		If the top stack value is not False, the statements are executed. The top stack value is removed.
OP_NOTIF	100	0x64	<expression> notif [statements] [else [statements]]* endif		If the top stack value is False, the statements are executed. The top stack value is removed.
OP_VERIF DISABLED	101	0x65	Version	<version> verif [statements] [else [statements]]* endif	If the top stack value is EQUAL to the version of the transaction, the statements are executed. The top stack value is removed.
OP_VERNOTIF DISABLED	102	0x66	Version	<version> vernotif [statements] [else [statements]]* endif	If the top stack value is NOT EQUAL to the version of the transaction, the statements are executed. The top stack value is removed.
OP_ELSE	103	0x67	<expression> if [statements] [else [statements]]* endif		If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not.
OP_ENDIF	104	0x68	<expression> if [statements] [else [statements]]* endif		Ends an if/else block. All blocks must end, or the transaction is invalid. An OP_ENDIF without OP_IF earlier is also invalid.
OP_VERIFY	105	0x69	True / false	Nothing / fail	Marks transaction as invalid if top stack value is not true. The top stack value is removed.
OP_RETURN	106	0x6a	Nothing	Ends script with top value on stack as final result	OP_RETURN can also be used to create "False Return" outputs with a scriptPubKey consisting of OP_FALSE OP_RETURN followed by data. Such outputs are provably unspendable and should be given a value of zero Satoshis. These outputs can be pruned from storage in the UTXO set, reducing its size. Currently the BitcoinSV network supports multiple FALSE RETURN outputs in a given transaction with each one capable of holding up to 100kB of data. After the Genesis upgrade in 2020 miners will be free to mine transactions containing FALSE RETURN outputs of any size.

Stack

Word	Opcode	Hex	Input	Output	Description
OP_TOALTSTACK	107	0x6b	x1	(alt)x1	Puts the input onto the top of the alt stack. Removes it from the main stack.
OP_FROMALTSTACK	108	0x6c	(alt)x1	x1	Puts the input onto the top of the main stack. Removes it from the alt stack.
OP_IFDUP	115	0x73	x	x / x x	If the top stack value is not 0, duplicate it.
OP_DEPTH	116	0x74	Nothing	<Stack size>	Puts the number of stack items onto the stack.
OP_DROP	117	0x75	x	Nothing	Removes the top stack item.
OP_DUP	118	0x76	x	x x	Duplicates the top stack item.
OP_NIP	119	0x77	x1 x2	x2	Removes the second-to-top stack item.
OP_OVER	120	0x78	x1 x2	x1 x2 x1	Copies the second-to-top stack item to the top.
OP_PICK	121	0x79	xn ... x2 x1 x0 <n>	xn ... x2 x1 x0 xn	The item n back in the stack is copied to the top.
OP_ROLL	122	0x7a	xn ... x2 x1 x0 <n>	... x2 x1 x0 xn	The item n back in the stack is moved to the top.
OP_ROT	123	0x7b	x1 x2 x3	x2 x3 x1	The top three items on the stack are rotated to the left.
OP_SWAP	124	0x7c	x1 x2	x2 x1	The top two items on the stack are swapped.
OP_TUCK	125	0x7d	x1 x2	x2 x1 x2	The item at the top of the stack is copied and inserted before the second-to-top item.
OP_2DROP	109	0x6d	x1 x2	Nothing	Removes the top two stack items.
OP_2DUP	110	0x6e	x1 x2	x1 x2 x1 x2	Duplicates the top two stack items.
OP_3DUP	111	0x6f	x1 x2 x3	x1 x2 x3 x1 x2 x3	Duplicates the top three stack items.
OP_2OVER	112	0x70	x1 x2 x3 x4	x1 x2 x3 x4 x1 x2	Copies the pair of items two spaces back in the stack to the front.
OP_2ROT	113	0x71	x1 x2 x3 x4 x5 x6	x3 x4 x5 x6 x1 x2	The fifth and sixth items back are moved to the top of the stack.
OP_2SWAP	114	0x72	x1 x2 x3 x4	x3 x4 x1 x2	Swaps the top two pairs of items.

Word	Opcode	Hex	Input	Output	Description
OP_CAT	126	0x7e	x1 x2	out	Concatenates two strings.
OP_SPLIT	127	0x7f	in size	x1 x2	Breaks a string into two sections of length 'size' and the remainder.
OP_SIZE	130	0x82	in	in size	Pushes the string length of the top element of the stack (without popping it).

Bitwise logic

Word	Opcode	Hex	Input	Output	Description
OP_INVERT	131	0x83	in	out	Flips all of the bits in the input.
OP_AND	132	0x84	x1 x2	out	Boolean and between each bit in the inputs.
OP_OR	133	0x85	x1 x2	out	Boolean or between each bit in the inputs.
OP_XOR	134	0x86	x1 x2	out	Boolean exclusive or between each bit in 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.

Arithmetic

Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.

If any input value for any of these commands is longer than 4 bytes, the script must abort and fail.

Word	Opcode	Hex	Input	Output	Description
OP_1ADD	139	0x8b	in	out	1 is added to the input.
OP_1SUB	140	0x8c	in	out	1 is subtracted from the input.
OP_2MUL	141	0x8d	in	out	The input is multiplied by 2.
OP_2DIV	142	0x8e	in	out	The input is divided by 2.
OP_NEGATE	143	0x8f	in	out	The sign of the input is flipped.
OP_ABS	144	0x90	in	out	The input is made positive.
OP_NOT	145	0x91	in	out	If the input is 0 or 1, it is flipped. Otherwise the output will be 0.
OP_0NOTEQUAL	146	0x92	in	out	Returns 0 if the input is 0. 1 otherwise.
OP_ADD	147	0x93	a b	out	a is added to b.
OP_SUB	148	0x94	a b	out	b is subtracted from a.
OP_MUL	149	0x95	a b	out	a is multiplied by b.
OP_DIV	150	0x96	a b	out	a is divided by b.
OP_MOD	151	0x97	a b	out	Returns the remainder after dividing a by b.
OP_LSHIFT	152	0x98	a b	out	Shifts a left b bits, preserving sign.
OP_RSHIFT	153	0x99	a b	out	Shifts a right b bits, preserving sign.
OP_BOOLAND	154	0x9a	a b	out	If both a and b are not 0, the output is 1. Otherwise 0.
OP_BOOLOR	155	0x9b	a b	out	If a or b is not 0, the output is 1. Otherwise 0.
OP_NUMEQUAL	156	0x9c	a b	out	Returns 1 if the numbers are equal, 0 otherwise.
OP_NUMEQUALVERIFY	157	0x9d	a b	Nothing / fail	Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
OP_NUMNOTEQUAL	158	0x9e	a b	out	Returns 1 if the numbers are not equal, 0 otherwise.
OP_LESSTHAN	159	0x9f	a b	out	Returns 1 if a is less than b, 0 otherwise.
OP_GREATERTHAN	160	0xa0	a b	out	Returns 1 if a is greater than b, 0 otherwise.
OP_LESSTHANOREQUAL	161	0xa1	a b	out	Returns 1 if a is less than or equal to b, 0 otherwise.
OP_GREATERTHANOREQUAL	162	0xa2	a b	out	Returns 1 if a is greater than or equal to b, 0 otherwise.
OP_MIN	163	0xa3	a b	out	Returns the smaller of a and b.
OP_MAX	164	0xa4	a b	out	Returns the larger of a and b.
OP_WITHIN	165	0xa5	x min max	out	Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.

Crypto

Word	Opcode	Hex	Input	Output	Description
OP_RIPEMD160	166	0xa6	in	hash	The input is hashed using RIPEMD-160.
OP_SHA1	167	0xa7	in	hash	The input is hashed using SHA-1.
OP_SHA256	168	0xa8	in	hash	The input is hashed using SHA-256.
OP_HASH160	169	0xa9	in	hash	The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
OP_HASH256	170	0xaa	in	hash	The input is hashed two times with SHA-256.
OP_CODESEPARATOR	171	0xab	Nothing	Nothing	All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
OP_CHECKSIG	172	0xac	sig pubkey	True / false	The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.
OP_CHECKSIGVERIFY	173	0xad	sig pubkey	Nothing / fail	Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
OP_CHECKMULTISIG	174	0xae	x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>	True / False	Compares the first signature against each public key until it finds an ECDSA match. Starting with the subsequent public key, it compares the second signature against each remaining public key until it finds an ECDSA match. The process is repeated until all signatures have been checked or not enough public keys remain to produce a successful result. All signatures need to match a public key. Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the scriptSig using the same order as their corresponding public keys were placed in the scriptPubKey or redeemScript. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.
OP_CHECKMULTISIGVERIFY	175	0xaf	x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>	Nothing / fail	Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.

Locktime

Word	Opcode	Hex	Input	Output	Description
OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)	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 BIP 0065. This opcode will be deprecated post activation of the Genesis upgrade. Any UTXOs that incorporate it into their locking script will remain spendable however if it appears in new transactions it will be treated as OP_NOP2
OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)	178	0xb2	x	x / fail	Marks transaction as invalid if the relative lock time of the input (enforced by BIP 0068 with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in BIP 0112. This opcode will be deprecated post activation of the Genesis upgrade. Any UTXOs that incorporate it into their locking script will remain spendable however if it appears in new transactions it will be treated as OP_NOP3

Pseudo-words

These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.

Word	Opcode	Hex	Description
OP_PUBKEYHASH	253	0xfd	Represents a public key hashed with OP_HASH160.
OP_PUBKEY	254	0xfe	Represents a public key compatible with OP_CHECKSIG.
OP_INVALIDOPCODE	255	0xff	Matches any opcode that is not yet assigned.

Reserved words

Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.

Word	Opcode	Hex	When used...
OP_RESERVED	80	0x50	Transaction is invalid unless occuring in an unexecuted OP_IF branch
OP_RESERVED1	137	0x89	Transaction is invalid unless occuring in an unexecuted OP_IF branch
OP_RESERVED2	138	0x8a	Transaction is invalid unless occuring in an unexecuted OP_IF branch
OP_NOP1, OP_NOP4-OP_NOP10	176, 179-185	0xb0, 0xb3-0xb9	The word is ignored. Does not mark transaction as invalid.

Script examples

The following is a list of interesting scripts. When notating scripts, data to be pushed to the stack is generally enclosed in angle brackets and data push commands are omitted. Non-bracketed words are opcodes. These examples include the “OP_” prefix, but it is permissible to omit it. Thus “<pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG” may be abbreviated to “<pubkey1> <pubkey2> 2 CHECKMULTISIG”. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.

Standard Transaction to Bitcoin address (pay-to-pubkey-hash)

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

To demonstrate how scripts look on the wire, here is a raw scriptPubKey:

  76       A9             14
OP_DUP OP_HASH160    Bytes to push

89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA   88         AC
                      Data to push                     OP_EQUALVERIFY OP_CHECKSIG

Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.

Here is how each word is processed:

Stack	Script	Description
Empty.	<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG	scriptSig and scriptPubKey are combined.
<sig> <pubKey>	OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG	Constants are added to the stack.
<sig> <pubKey> <pubKey>	OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG	Top stack item is duplicated.
<sig> <pubKey> <pubHashA>	<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG	Top stack item is hashed.
<sig> <pubKey> <pubHashA> <pubKeyHash>	OP_EQUALVERIFY OP_CHECKSIG	Constant added.
<sig> <pubKey>	OP_CHECKSIG	Equality is checked between the top two stack items.
true	Empty.	Signature is checked for top two stack items.

Pay-to-pubkey transaction

OP_CHECKSIG is used directly without first hashing the public key. This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced. scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core. The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

Checking process:

Stack	Script	Description
Empty.	<sig> <pubKey> OP_CHECKSIG	scriptSig and scriptPubKey are combined.
<sig> <pubKey>	OP_CHECKSIG	Constants are added to the stack.
true	Empty.	Signature is checked for top two stack items.

Provably Unspendable/Prunable Outputs

The standard way to mark a transaction as provably unspendable is with a 'False Return' scriptPubKey of the following form:

 scriptPubKey: OP_FALSE OP_RETURN {zero or more ops}

Incentivized finding of hash collisions

In 2013 Peter Todd created scripts that result in true if a hash collision is found. Bitcoin addresses resulting from these scripts can have money sent to them. If someone finds a hash collision they can spend the bitcoins on that address, so this setup acts as an incentive for somebody to do so.

For example the SHA1 script:

scriptPubKey: OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL
scriptSig: <preimage1> <preimage2>

See the bitcointalk thread <ref>bitcointalk forum thread on the hash collision bounties</ref> and reddit thread<ref>https://www.reddit.com/r/Bitcoin/comments/1mavh9/trustless_bitcoin_bounty_for_sha1_sha256_etc/</ref> for more details.

In February 2017 the SHA1 bounty worth 2.48 bitcoins was claimed.

See Also

• Bitcoin Transactions