Difference between revisions of "Opcodes used in Bitcoin Script"
 
(59 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
Bitcoin uses a scripting system for [[Bitcoin_Transactions|transactions]]. [[Wikipedia:FORTH|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:
 
−
# a public key that, when hashed, yields destination address D embedded in the script, and
 
−
# 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.
 
This is a list of all Script words, also known as opcodes, commands, or functions.
  
Line 51: Line 24:
 
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
 
|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
+
|[[Pushdata Opcodes|Pushdata Bytelength]]
 
|1-75
 
|1-75
 
|0x01-0x4b
 
|0x01-0x4b
Line 58: Line 31:
 
|The next ''opcode'' bytes is data to be pushed onto the stack
 
|The next ''opcode'' bytes is data to be pushed onto the stack
 
|-
 
|-
−
|OP_PUSHDATA1
+
|[[Pushdata Opcodes|OP_PUSHDATA1]]
 
|76
 
|76
 
|0x4c
 
|0x4c
Line 65: Line 38:
 
|The next byte contains the number of bytes to be pushed onto the stack.
 
|The next byte contains the number of bytes to be pushed onto the stack.
 
|-
 
|-
−
|OP_PUSHDATA2
+
|[[Pushdata Opcodes|OP_PUSHDATA2]]
 
|77
 
|77
 
|0x4d
 
|0x4d
Line 72: Line 45:
 
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.
 
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.
 
|-
 
|-
−
|OP_PUSHDATA4
+
|[[Pushdata Opcodes|OP_PUSHDATA4]]
 
|78
 
|78
 
|0x4e
 
|0x4e
Line 119: Line 92:
 
|Does nothing.
 
|Does nothing.
 
|-
 
|-
−
|OP_VER
+
|OP_VER '''DISABLED'''
 
|98
 
|98
 
|0x62
 
|0x62
 
|Nothing
 
|Nothing
−
|Transaction version
+
|Protocol version
−
|Puts the version of the transaction onto the stack '''DISABLED'''
+
|Puts the version of the protocol under which this transaction will be evaluated onto the stack.
 
|-
 
|-
 
|OP_IF
 
|OP_IF
 
|99
 
|99
 
|0x63
 
|0x63
−
| colspan="2"|<expression> if [statements] [else [statements]]* endif
+
| colspan="2"|
−
|If the top stack value is not False, the statements are executed. The top stack value is removed.
+
<code>
 +
[expression] IF
 +
    [statement 1]
 +
ENDIF
 +
</code>
 +
</br>OR
 +
</br><code>
 +
[expression] IF
 +
    [statement 1]
 +
ELSE
 +
    [statement 2]
 +
ENDIF
 +
</code>
 +
|If the top stack value is TRUE, statement 1 is executed.
 +
If the top stack value is FALSE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br>
 +
The top stack value is removed.</br>
 
|-
 
|-
 
|OP_NOTIF
 
|OP_NOTIF
 
|100
 
|100
 
|0x64
 
|0x64
−
| colspan="2"|<expression> notif [statements] [else [statements]]* endif
+
| colspan="2"|
−
|If the top stack value is False, the statements are executed. The top stack value is removed.
+
<code>
 +
[expression] NOTIF
 +
    [statement 1]
 +
ENDIF
 +
</code></br>OR
 +
</br><code>
 +
[expression] IF
 +
    [statement 1]
 +
ELSE
 +
    [statement 2]
 +
ENDIF
 +
</code>
 +
|If the top stack value is FALSE, statement 1 is executed.
 +
If the top stack value is TRUE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br>
 +
The top stack value is removed.</br>
 
|-
 
|-
−
|OP_VERIF
+
|OP_VERIF '''DISABLED'''
 
|101
 
|101
 
|0x65
 
|0x65
−
|Version
+
|colspan="2"| '''DISABLED'''
−
|<version> verif [statements] [else [statements]]* endif
+
| '''DISABLED'''
−
|If the top stack value is EQUAL to the version of the transaction, the statements are executed. The top stack value is removed. '''DISABLED'''
 
 
|-
 
|-
−
|OP_VERNOTIF
+
|OP_VERNOTIF '''DISABLED'''
 
|102
 
|102
 
|0x66
 
|0x66
−
|Version
+
|colspan="2"| '''DISABLED'''
−
|<version> vernotif [statements] [else [statements]]* endif
+
| '''DISABLED'''
−
|If the top stack value is NOT EQUAL to the version of the transaction, the statements are executed. The top stack value is removed. '''DISABLED'''
 
 
|-
 
|-
 
|OP_ELSE
 
|OP_ELSE
 
|103
 
|103
 
|0x67
 
|0x67
−
| colspan="2"|<expression> if [statements] [else [statements]]* endif
+
| colspan="2"|
−
|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.  
+
<code>
 +
[expression] IF
 +
    [statement 1]
 +
ELSE
 +
    [statement 2]
 +
ENDIF </code>
 +
|If the preceding IF or NOTIF check was not valid then statement 2 is executed.
 
|-
 
|-
 
|OP_ENDIF
 
|OP_ENDIF
 
|104
 
|104
 
|0x68
 
|0x68
−
| colspan="2"|<expression> if [statements] [else [statements]]* endif
+
| colspan="2"|
−
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without OP_IF earlier is also '''invalid'''.
+
<code>
 +
[expression]
 +
IF
 +
    [statements]
 +
ELSE
 +
    [statements]
 +
ENDIF
 +
</code>
 +
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without a prior matching OP_IF or OP_NOTIF is also '''invalid'''.
 
|-
 
|-
 
|OP_VERIFY
 
|OP_VERIFY
Line 203: Line 217:
 
|x1
 
|x1
 
|Puts the input onto the top of the main stack. Removes it from the alt stack.
 
|Puts the input onto the top of the main stack. Removes it from the alt stack.
 +
|-
 +
|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.
 
|-
 
|-
 
|OP_IFDUP
 
|OP_IFDUP
Line 216: Line 272:
 
|Nothing
 
|Nothing
 
|<Stack size>
 
|<Stack size>
−
|Puts the number of stack items onto the stack.
+
|Counts the number of stack items onto the stack and places the value on the top
 
|-
 
|-
 
|OP_DROP
 
|OP_DROP
Line 280: Line 336:
 
|x2 x1 x2
 
|x2 x1 x2
 
|The item at the top of the stack is copied and inserted before the second-to-top item.
 
|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.
 
 
|}
 
|}
  
 +
===Data Manipulation===
  
 
{| class="wikitable"  
 
{| class="wikitable"  
Line 344: Line 359:
 
|127
 
|127
 
|0x7f
 
|0x7f
−
|in size
+
|x n
−
|out
+
|x1 x2
−
|Breaks a string into two sections of length 'size' and the remainder.
+
|Splits byte sequence x at position n.
 +
|-
 +
|OP_NUM2BIN
 +
|128
 +
|0x80
 +
|a b
 +
| out
 +
|Converts numeric value a into byte sequence of length b.
 +
|-
 +
|OP_BIN2NUM
 +
|129
 +
|0x81
 +
| x
 +
| out
 +
|Converts byte sequence x into a numeric value.
 
|-
 
|-
 
|OP_SIZE
 
|OP_SIZE
Line 412: Line 441:
 
=== Arithmetic ===
 
=== Arithmetic ===
  
−
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.
+
BitcoinScript supports arithmetic on bignum values
 +
A bignum is a byte sequence that represents a numeric value. The length of the byte sequence must be less than or equal to 750,000 bytes. Byte sequences larger than 750,000 bytes are valid in Bitcoin however current rules dictate that they are not recognised as a valid numeric value.
  
−
If any input value for any of these commands is longer than 4 bytes, the script must abort and fail.  
+
Note that while some operations require parameters to be valid numeric values, they may produce byte sequences which are not valid numeric values (for example, OP_MUL may produce a byte sequence which is too large to validly represent a numeric value).
  
 
{| class="wikitable"  
 
{| class="wikitable"  
Line 439: Line 469:
 
|1 is subtracted from the input.
 
|1 is subtracted from the input.
 
|-
 
|-
−
|OP_2MUL
+
|OP_2MUL '''DISABLED'''
 
|141
 
|141
 
|0x8d
 
|0x8d
 
|in
 
|in
 
|out
 
|out
−
|The input is multiplied by 2.
+
|The input is multiplied by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)
 
|-
 
|-
−
|OP_2DIV
+
|OP_2DIV '''DISABLED'''
 
|142
 
|142
 
|0x8e
 
|0x8e
 
|in
 
|in
 
|out
 
|out
−
|The input is divided by 2.
+
|The input is divided by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)
 
|-
 
|-
 
|OP_NEGATE
 
|OP_NEGATE
Line 521: Line 551:
 
|a b
 
|a b
 
|out
 
|out
−
|Shifts a left b bits, preserving sign.
+
|Logical left shift b bits. Sign data is discarded
 
|-
 
|-
 
|OP_RSHIFT
 
|OP_RSHIFT
Line 528: Line 558:
 
|a b
 
|a b
 
|out
 
|out
−
|Shifts a right b bits, preserving sign.
+
|Logical right shift b bits. Sign data is discarded
 
|-
 
|-
 
|OP_BOOLAND
 
|OP_BOOLAND
Line 615: Line 645:
 
|}
 
|}
  
−
=== Crypto ===
+
=== Cryptography ===
  
 
{| class="wikitable"  
 
{| class="wikitable"  
Line 661: Line 691:
 
|The input is hashed two times with SHA-256.
 
|The input is hashed two times with SHA-256.
 
|-
 
|-
−
|OP_CODESEPARATOR
+
|[[OP_CODESEPARATOR]]
 
|171
 
|171
 
|0xab
 
|0xab
Line 687: Line 717:
 
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
 
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
 
|True / False
 
|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.
+
|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, an extra unused value (x) is removed from the stack. Script spenders must account for this by adding a junk value (typically zero) to the stack.
 
|-
 
|-
 
|OP_CHECKMULTISIGVERIFY
 
|OP_CHECKMULTISIGVERIFY
Line 697: Line 727:
 
|}
 
|}
  
−
=== Locktime ===
+
=== Used NOP opcode identifiers ===
 +
In Bitcoin's history, new opcodes were added that used reserved NO_OP opcode identifiers. These opcodes have been reverted to the original OP_NOP functionality.
 +
 
 
{| class="wikitable"  
 
{| class="wikitable"  
 
|-
 
|-
−
!Word
+
!Word                                
 
!Opcode
 
!Opcode
 
!Hex
 
!Hex
Line 707: Line 739:
 
!Description
 
!Description
 
|-
 
|-
−
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)
+
|OP_NOP2
 +
 
 +
(previously OP_CHECKLOCKTIMEVERIFY)
 
|177
 
|177
 
|0xb1
 
|0xb1
−
|x
+
|Nothing
−
|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 [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 0065].
+
(Previously: x)
 +
|Nothing
 +
 
 +
(Previously: x or fail)
 +
|NO OPERATION
 +
 
 +
''Evaluation process for UTXOs that pre-date genesis: Mark 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 [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 0065]. ''
 
|-
 
|-
−
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)
+
|OP_NOP3
 +
 
 +
(previously OP_CHECKSEQUENCEVERIFY)
 
|178
 
|178
 
|0xb2
 
|0xb2
−
|x
+
|Nothing
−
|x / ''fail''
+
 
−
|'''Marks transaction as invalid''' if the relative lock time of the input (enforced by [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 0068] with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 0112].
+
(Previously: x)
 +
|Nothing
 +
 
 +
(Previously: x or fail)
 +
|NO OPERATION
 +
 
 +
''Evaluation process for UTXOs that pre-date genesis: Mark transaction as invalid if the relative lock time of the input (enforced by [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 0068] with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 0112]. ''
 
|}
 
|}
  
Line 778: Line 826:
 
|}
 
|}
  
−
== Script examples ==
+
==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:
 
−
<pre>  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</pre>
 
−
 
 
−
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:
 
−
{| class="wikitable"
 
−
|-
 
−
! 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.
 
−
|}
 
−
 
 
−
=== Obsolete 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:
 
−
{| class="wikitable"
 
−
|-
 
−
! 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}
 
−
 
 
−
=== Transaction puzzle ===
 
−
 
 
−
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.
 
−
 
 
−
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL
 
−
scriptSig: <data>
 
−
 
 
−
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.
 
−
 
 
−
{| class="wikitable"
 
−
|-
 
−
! Stack
 
−
! Script
 
−
! Description
 
−
|-
 
−
|Empty.
 
−
|<data> OP_HASH256 <given_hash> OP_EQUAL
 
−
|
 
−
|-
 
−
|<data>
 
−
|OP_HASH256 <given_hash> OP_EQUAL
 
−
|scriptSig added to the stack.
 
−
|-
 
−
|<data_hash>
 
−
|<given_hash> OP_EQUAL
 
−
|The data is hashed.
 
−
|-
 
−
|<data_hash> <given_hash>
 
−
|OP_EQUAL
 
−
|The given hash is pushed to the stack.
 
−
|-
 
−
|true
 
−
|Empty.
 
−
|The hashes are compared, leaving true on the stack.
 
−
|}
 
−
 
 
−
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash in the script was the genesis block header hashed twice with SHA-256. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.
 
−
 
 
−
=== 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>[https://bitcointalk.org/index.php?topic=293382.0 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==
+
For examples of common Bitcoin transaction scripts please see [[Bitcoin Transactions]]
  
−
* [[Bitcoin Transactions]]
+
==Attribution==
 +
This content is based on content sourced from https://en.bitcoin.it/wiki/Script under [https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. Although it may have been extensively revised and updated we acknowledge the original authors.

Latest revision as of 02:54, 9 October 2022

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.)
Pushdata Bytelength 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 Protocol version Puts the version of the protocol under which this transaction will be evaluated onto the stack.
OP_IF 99 0x63

[expression] IF 

   [statement 1]

ENDIF
OR
[expression] IF 

   [statement 1]

ELSE 

   [statement 2]

ENDIF

If the top stack value is TRUE, statement 1 is executed.

If the top stack value is FALSE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.
The top stack value is removed.

OP_NOTIF 100 0x64

[expression] NOTIF 

   [statement 1]

ENDIF
OR
[expression] IF 

   [statement 1]

ELSE 

   [statement 2]

ENDIF

If the top stack value is FALSE, statement 1 is executed.

If the top stack value is TRUE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.
The top stack value is removed.

OP_VERIF DISABLED 101 0x65 DISABLED DISABLED
OP_VERNOTIF DISABLED 102 0x66 DISABLED DISABLED
OP_ELSE 103 0x67

[expression] IF 

   [statement 1]

ELSE 

   [statement 2]

ENDIF

If the preceding IF or NOTIF check was not valid then statement 2 is executed.
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 a prior matching OP_IF or OP_NOTIF 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_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.
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> Counts the number of stack items onto the stack and places the value on the top
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.

Data Manipulation

Word Opcode Hex Input Output Description
OP_CAT 126 0x7e x1 x2 out Concatenates two strings.
OP_SPLIT 127 0x7f x n x1 x2 Splits byte sequence x at position n.
OP_NUM2BIN 128 0x80 a b out Converts numeric value a into byte sequence of length b.
OP_BIN2NUM 129 0x81 x out Converts byte sequence x into a numeric value.
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

BitcoinScript supports arithmetic on bignum values A bignum is a byte sequence that represents a numeric value. The length of the byte sequence must be less than or equal to 750,000 bytes. Byte sequences larger than 750,000 bytes are valid in Bitcoin however current rules dictate that they are not recognised as a valid numeric value.

Note that while some operations require parameters to be valid numeric values, they may produce byte sequences which are not valid numeric values (for example, OP_MUL may produce a byte sequence which is too large to validly represent a numeric value).

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 DISABLED 141 0x8d in out The input is multiplied by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)
OP_2DIV DISABLED 142 0x8e in out The input is divided by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)
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 Logical left shift b bits. Sign data is discarded
OP_RSHIFT 153 0x99 a b out Logical right shift b bits. Sign data is discarded
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.

Cryptography

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, an extra unused value (x) is removed from the stack. Script spenders must account for this by adding a junk value (typically zero) to 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.

Used NOP opcode identifiers

In Bitcoin's history, new opcodes were added that used reserved NO_OP opcode identifiers. These opcodes have been reverted to the original OP_NOP functionality.

Word Opcode Hex Input Output Description
OP_NOP2

(previously OP_CHECKLOCKTIMEVERIFY)

177 0xb1 Nothing

(Previously: x)

Nothing

(Previously: x or fail)

NO OPERATION

Evaluation process for UTXOs that pre-date genesis: Mark 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.

OP_NOP3

(previously OP_CHECKSEQUENCEVERIFY)

178 0xb2 Nothing

(Previously: x)

Nothing

(Previously: x or fail)

NO OPERATION

Evaluation process for UTXOs that pre-date genesis: Mark 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.

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.

Examples

For examples of common Bitcoin transaction scripts please see Bitcoin Transactions

Attribution

This content is based on content sourced from https://en.bitcoin.it/wiki/Script under Creative Commons Attribution 3.0. Although it may have been extensively revised and updated we acknowledge the original authors.

Retrieved from "https://wiki.bitcoinsv.io/index.php?title=Opcodes_used_in_Bitcoin_Script&oldid=3079"