Script

From Bitcoin Wiki
Revision as of 16:18, 11 January 2013 by Smtp (talk | contribs) (Bitwise logic)
Jump to: navigation, search

Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.

A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them.

Scripts are big-endian and their sequences of bytes is interpreted as a sequence of opcodes with operands. Only opcodes with byte values less than 0x4f have additional operands.

Scripts and Bitcoin transactions

The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide

  1. a public key that, when hashed, yields destination address D embedded in the script, and
  2. a signature to show evidence 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, or even no keys at all.

A transaction is valid if nothing in the combined script triggers failure and the top stack item exists and is true (non-zero). The party who originally stored the Bitcoins now being spent, dictates the script operations that will occur last in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero) on the stack.
Only the very first transaction in each bitcoin block has no input script (the entry there is called "coinbase"), because the Bitcoins created with the block are created from hot air and not released by a previous recorded script.

Stack

The stacks hold byte vectors (there is the (main) stack and an alternative stack). 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). 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.

Opcode overview

For each opcode is given: its nemonic without the leading OP_, its hexadecimal byte value, the number of stack items needed (poped) during execution, a semicolon and the number of stack items which has been pushed (after execution). A * after the needed stack items indicates that further bytes from the script following the current opcode are needed. A # indicates that items on the alternative stack are poped/pushed. A @ indicates that further (global) data from the transaction is needed. A / indicates alternatives of a value.
Different colors indicate different semantic execution groups of opcodes:

copy a fixed number of bytes but at most 75 onto stack copy bytes onto stack which number is given by a 1, 2 or 4 byte value. copy 1 specific byte onto stack
undefined opcode a pseudo-opcode, unassigned for scripts
NOP or opcode is part of a IF-flow-control construction
(stack conditionally) invalidation of the script this opcode is part of
stack item is moved between main stack and alternate stack stack item(s) is/are moved, copied or deleted
byte vectors are appended or divided or their size is determined byte vectors are interpreted bit-position-independently
byte vectors are interpreted and processed as signed integers
a hash value is computed or a signature checked

Opcode byte-matrix

The opcode value 0x00 with nemonic OP_FALSE is also named OP_0 and the opcode value 0x51 with nemonic OP_1 as also named OP_TRUE.

_FALSE
0x00
0 ; 1(0)
-
0x01
0 *; 1(1)
-
0x02
0 *; 1(2)
-
0x03
0 *; 1(3)
-
0x04
0 *; 1(4)
-
0x04
0 *; 1(5)
-
0x06
0 *; 1(6)
-
0x07
0 *; 1(7)
-
0x08
0 *; 1(8)
-
0x09
0 *; 1(9)
-
0x0a
0 *; 1(10)
-
0x0b
0 *; 1(11)
-
0x0c
0 *; 1(12)
-
0x0d
0 *; 1(13)
-
0x0e
0 *; 1(14)
-
0x0f
0 *; 1(15)
-
0x10
0 *; 1(16)
-
0x11
0 *; 1(17)
-
0x12
0 *; 1(18)
-
0x13
0 *; 1(19)
-
0x14
0 *; 1(20)
-
0x15
0 *; 1(21)
-
0x16
0 *; 1(22)
-
0x17
0 *; 1(23)
-
0x18
0 *; 1(24)
-
0x19
0 *; 1(25)
-
0x1a
0 *; 1(26)
-
0x1b
0 *; 1(27)
-
0x1c
0 *; 1(28)
-
0x1d
0 *; 1(29)
-
0x1e
0 *; 1(30)
-
0x1f
0 *; 1(31)
-
0x20
0 *; 1(32)
-
0x21
0 *; 1(33)
-
0x22
0 *; 1(34)
-
0x23
0 *; 1(35)
-
0x24
0 *; 1(36)
-
0x25
0 *; 1(37)
-
0x26
0 *; 1(38)
-
0x27
0 *; 1(39)
-
0x28
0 *; 1(40)
-
0x29
0 *; 1(41)
-
0x2a
0 *; 1(42)
-
0x2b
0 *; 1(43)
-
0x2c
0 *; 1(44)
-
0x2d
0 *; 1(45)
-
0x2e
0 *; 1(46)
-
0x2f
0 *; 1(47)
-
0x30
0 *; 1(48)
-
0x31
0 *; 1(49)
-
0x32
0 *; 1(50)
-
0x33
0 *; 1(51)
-
0x34
0 *; 1(52)
-
0x35
0 *; 1(53)
-
0x36
0 *; 1(54)
-
0x37
0 *; 1(55)
-
0x38
0 *; 1(56)
-
0x39
0 *; 1(57)
-
0x3a
0 *; 1(58)
-
0x3b
0 *; 1(59)
-
0x3c
0 *; 1(60)
-
0x3d
0 *; 1(61)
-
0x3e
0 *; 1(62)
-
0x3f
0 *; 1(63)
-
0x40
0 *; 1(64)
-
0x41
0 *; 1(65)
-
0x42
0 *; 1(66)
-
0x43
0 *; 1(67)
-
0x44
0 *; 1(68)
-
0x45
0 *; 1(69)
-
0x46
0 *; 1(70)
-
0x47
0 *; 1(71)
-
0x48
0 *; 1(72)
-
0x49
0 *; 1(73)
-
0x4a
0 *; 1(74)
-
0x4b
0 *; 1(75)
_PUSHDATA1
0x4c
0 *; 1(0 - 255)
_PUSHDATA2
0x4d
0 *; 1(0 - 2^16-1)
_PUSHDATA4
0x4e
0 *; 1(0 - 2^32-1)
_1NEGATE
0x4f
0 ; 1(1)
_RESERVED
0x50
_1
0x51
0 ; 1(1)
_2
0x52
0 ; 1(1)
_3
0x53
0 ; 1(1)
_4
0x54
0 ; 1(1)
_5
0x55
0 ; 1(1)
_6
0x56
0 ; 1(1)
_7
0x57
0 ; 1(1)
_8
0x58
0 ; 1(1)
_9
0x59
0 ; 1(1)
_10
0x5a
0 ; 1(1)
_11
0x5b
0 ; 1(1)
_12
0x5c
0 ; 1(1)
_13
0x5d
0 ; 1(1)
_14
0x5e
0 ; 1(1)
_15
0x5f
0 ; 1(1)
_16
0x60
0 ; 1(1)
_NOP
0x61
0 ; 0
_VER
0x62
_IF
0x63
1 ; 0
_NOTIF
0x64
1 ; 0
_VERIF
0x65
_VERNOTIF
0x66
_ELSE
0x67
0 ; 0
_ENDIF
0x68
0 ; 0
_VERIFY
0x69
1 ; 0/1
_RETURN
0x6a
0 ; 0
_TOALTSTACK
0x6b
1 ; 0
_FROMALTSTACK
0x6c
0 #; 1
_2DROP
0x6d
2 ; 0
_2DUP
0x6e
2 ; 4
_3DUP
0x6f
3 ; 6
_2OVER
0x70
4 ; 6
_2ROT
0x71
6 ; 6
_2SWAP
0x72
4 ; 4
_IFDUP
0x73
1 ; 1/2
_DEPTH
0x74
0 ; 1
_DROP
0x75
1 ; 0
_DUP
0x76
1 ; 2
_NIP
0x77
2 ; 1
_OVER
0x78
2 ; 3
_PICK
0x79
1+n+1 ; n+2
_ROLL
0x7a
1+n+1 ; n+1
_ROT
0x7b
3 ; 3
_SWAP
0x7c
2 ; 2
_TUCK
0x7d
2 ; 3
_CAT
0x7e
2 ; 1
_SUBSTR
0x7f
3 ; 1
_LEFT
0x80
2 ; 1
_RIGHT
0x81
2 ; 1
_SIZE
0x82
1 ; 2
_INVERT
0x83
1 ; 1
_AND
0x84
2 ; 1
_OR
0x85
2 ; 1
_XOR
0x86
2 ; 1
_EQUAL
0x87
2 ; 1
_EQUALVERIFY
0x88
2 ; 0/1
_RESERVED1
0x89
_RESERVED2
0x8a
_1ADD
0x8b
1 ; 1
_1SUB
0x8c
1 ; 1
_2MUL
0x8d
1 ; 1
_2DIV
0x8e
1 ; 1
_NEGATE
0x8f
1 ; 1
_ABS
0x90
1 ; 1
_NOT
0x91
1 ; 1
_0NOTEQUAL
0x92
1 ; 1
_ADD
0x93
2 ; 1
_SUB
0x94
2 ; 1
_MUL
0x95
2 ; 1
_DIV
0x96
2 ; 1
_MOD
0x97
2 ; 1
_LSHIFT
0x98
2 ; 1
_RSHIFT
0x99
2 ; 1
_BOOLAND
0x9a
2 ; 1
_BOOLOR
0x9b
2 ; 1
_NUMEQUAL
0x9c
2 ; 1
_NUMEQUALVERIFY
0x9d
2 ; 0/1
_NUMNOTEQUAL
0x9e
2 ; 1
_LESSTHAN
0x9f
2 ; 1
_GREATERTHAN
0xa0
2 ; 1
_LESSTHANOREQUAL
0xa1
2 ; 1
_GREATERTHANOREQUAL
0xa2
2 ; 1
_MIN
0xa3
2 ; 1
_MAX
0xa4
2 ; 1
_WITHIN
0xa5
3 ; 1
_RIPEMD160
0xa6
1 ; 1
_SHA1
0xa7
1 ; 1
_SHA256
0xa8
1 ; 1
_HASH160
0xa9
1 ; 1
_HASH256
0xaa
1 ; 1
_CODESEPARATOR
0xab
0 ; 0
_CHECKSIG
0xac
2 @; 1
_CHECKSIGVERIFY
0xad
2 @; 0/1
_CHECKMULTISIG
0xae
2n+2 @; 1
_CHECKMULTISIGVERIFY
0xaf
2n+2 @; 0/1
_NOP1
0xb0
0 ; 0
_NOP2
0xb1
0 ; 0
_NOP3
0xb2
0 ; 0
_NOP4
0xb3
0 ; 0
_NOP5
0xb4
0 ; 0
_NOP6
0xb5
0 ; 0
_NOP7
0xb6
0 ; 0
_NOP8
0xb7
0 ; 0
_NOP9
0xb8
0 ; 0
_NOP10
0xb9
0 ; 0
-
0xba
-
0xbb
-
0xbc
-
0xbd
-
0xbe
-
0xbf
-
0xc0
-
0xc1
-
0xc2
-
0xc3
-
0xc4
-
0xc5
-
0xc6
-
0xc7
-
0xc8
-
0xc9
-
0xca
-
0xcb
-
0xcc
-
0xcd
-
0xce
-
0xcf
-
0xd0
-
0xd1
-
0xd2
-
0xd3
-
0xd4
-
0xd5
-
0xd6
-
0xd7
-
0xd8
-
0xd9
-
0xda
-
0xdb
-
0xdc
-
0xdd
-
0xde
-
0xdf
-
0xe0
-
0xe1
-
0xe2
-
0xe3
-
0xe4
-
0xe5
-
0xe6
-
0xe7
-
0xe8
-
0xe9
-
0xea
-
0xeb
-
0xec
-
0xed
-
0xee
-
0xef
-
0xf0
-
0xf1
-
0xf2
-
0xf3
-
0xf4
-
0xf5
-
0xf6
-
0xf7
-
0xf8
-
0xf9
-
0xfa
_SMALLINTEGER
0xfb
_PUBKEYS
0xfc
_PUBKEYHASH
0xfd
_PUBKEY
0xfe
_INVALIDOPCODE
0xff

Except later pseudo-opcode changes, the definition of OP_NOP1 - OP_NOP10 and the change of the evaluation of OP_RETURN (did no invalidation previously) which both occured in bitcoin version 0.3.6 in July 2010 were the last changes regarding opcodes [1] [2] [3].

Opcode descriptions

It follows for each opcode less than decimal 185 (hexa 0xba) a description for its usage. The columns entitled nemonic, decimal and Hex should be evident. The column input gives the needed items of the stack (and the alternate stack) and the column output indicates the resulting items on the stack (and the alternate stack). Stack-top is always the right most item. The naming of the entries in these two columns is chosen to reflect their interpretation. x, x0, x1, ... means arbitrary or no interpretation, i0, i1 and i2 a signed integer value, n,index,size and depth non-negative (unsigned) integer values, Boolean as either a true or false.

Some of the more complicated opcodes are disabled out of concern that the client might have (and has) a bug in the current implementation due to the historically not as 2-complement interpretations of the byte vectors as numerical values (the most significant byte holds the sign of the byte vectors).

Push data from instruction onto stack

Nemonic Decimal Hex Input Output Description
OP_FALSE, OP_0 0 0x00 Nothing Empty string A byte vector of length 0 is pushed onto the stack. (Thus, it is not a no-op!)
(no official nemonics) 1 - 75 0x01 - 0x4b (operand) x The next <opcode>-many bytes are to be pushed onto the stack.
OP_PUSHDATA1 76 0x4c (operands) x The next byte contains the number of bytes to be pushed onto the stack which follow this byte.
OP_PUSHDATA2 77 0x4d (operands) x The next two bytes contain the number of bytes to be pushed onto the stack which follow theses 2 bytes.
OP_PUSHDATA4 78 0x4e (operands) x The next four bytes contain the number of bytes to be pushed onto the stack which follow theses 4 bytes.
OP_1NEGATE 79 0x4f Nothing -1 The byte with value -1 is pushed onto the stack.
OP_1, OP_TRUE 81 0x51 Nothing 1 The byte with value 1 is pushed onto the stack.
OP_2 - OP_16 82 - 96 0x52 - 0x60 Nothing 2-16 The byte with value <opcode>-80 (thus, one of 2 - 16) is pushed onto the stack.

Flow control

Nemonic Decimal Hex Input Output Description
OP_NOP 97 0x61 Nothing Nothing Does nothing.
OP_IF 99 0x63 Boolean Nothing If the top stack value is not 0, the statements are executed. The top stack value is removed. Lead in a logcial <value> then [statements] [else [statements]] endif expression
OP_NOTIF 100 0x64 Boolean Nothing If the top stack value is 0, the statements are executed. The top stack value is removed. Lead in a logcial <value> then [statements] [else [statements]] endif expression
OP_ELSE 103 0x67 Nothing Nothing If the preceeding 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 Nothing Nothing Ends a logcial If <value> then [statements] [else [statements]] expression
OP_VERIFY 105 0x69 Boolean Nothing / False If top stack value is not true then marks transaction as invalid . A value true is removed, but false is not.
OP_RETURN 106 0x6a Nothing Nothing Marks transaction as invalid.

Stack item organization

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

Splice

Nemonic Decimal Hex Input Output Description
OP_CAT 126 0x7e x2 x1 out Appends stack-top item at second-to top item. Concatenates two strings resp. byte vectors. Currently disabled.
OP_SUBSTR 127 0x7f x3 index size out Returns the section started at position <index> and of length <size> of a string resp. byte vector. Currently disabled.
OP_LEFT 128 0x80 x2 index out Keeps only characters left of the specified point in second-to top item. Currently disabled.
OP_RIGHT 129 0x81 x2 index out Keeps only characters right of the specified point in second-to top item. Currently disabled.
OP_SIZE 130 0x82 x1 x1 size Returns the length of the input string resp. byte vector resp. top-stack item.

Bitwise logic

Nemonic Decimal Hex Input Output Description
OP_INVERT 131 0x83 x1 x0 Flips all of the bits in the input. Currently disabled.
OP_AND 132 0x84 x2 x1 x0 Boolean and between each bit in the inputs. Currently disabled.
OP_OR 133 0x85 x2 x1 x0 Boolean or between each bit in the inputs. Currently disabled.
OP_XOR 134 0x86 x2 x1 x0 Boolean exclusive or between each bit in the inputs. Currently disabled.
OP_EQUAL 135 0x87 x2 x1 Boolean Returns 1 if the inputs have the same length and are byte-wise equal, 0 otherwise.
OP_EQUALVERIFY 136 0x88 x2 x1 Nothing / false Same as OP_EQUAL, but runs OP_VERIFY afterward.

Arithmetic

(In very early versions, the implemented arithmetic opcodes were limited to maximal 4 byte vectors.)

Nemonic Decimal Hex Input Output Description
OP_1ADD 139 0x8b i1 i0 1 is added to the input.
OP_1SUB 140 0x8c i1 i0 1 is subtracted from the input.
OP_2MUL 141 0x8d i1 i0 The input is multiplied by 2. Currently disabled.
OP_2DIV 142 0x8e i1 i0 The input is divided by 2 (round down). Currently disabled.
OP_NEGATE 143 0x8f i1 i0 The sign of the input is flipped. Numerically the value is multiplied by -1
OP_ABS 144 0x90 i1 i0 The input is negative, its sign is flipped.
OP_NOT 145 0x91 i1 Boolean If the input is 0 or 1, it is flipped. Otherwise the output will be 0. Test whether its value equals 0
OP_0NOTEQUAL 146 0x92 i1 Boolean Returns 0 if the input is 0. 1 otherwise. Test whether its value is unequal 0
OP_ADD 147 0x93 i2 i1 i0 stack-top i1 is added to i2.
OP_SUB 148 0x94 i2 i1 i0 stack-top i1 is subtracted from i2.
OP_MUL 149 0x95 i2 i1 i0 i2 is multiplied with stack-top i1. Currently disabled.
OP_DIV 150 0x96 i2 i1 i0 i2 is divided by stack-top i1 (divisor should be not 0). Currently disabled.
OP_MOD 151 0x97 i2 i1 i0 Returns the remainder after dividing i2 by stack-top i1 (divisor should be not 0). Currently disabled.
OP_LSHIFT 152 0x98 i2 i1 i0 Shifts i2 left by i1 bits, preserving sign of i2 (i1 >= 0). Currently disabled.
OP_RSHIFT 153 0x99 i2 i1 i0 Shifts i2 right by i1 bits, preserving sign of i2 (i1 >= 0). Currently disabled.
OP_BOOLAND 154 0x9a i2 i1 Boolean If both i2 and i1 are not 0, the output is 1. Otherwise 0.
OP_BOOLOR 155 0x9b i2 i1 Boolean If i2 or i1 is not 0, the output is 1. Otherwise 0.
OP_NUMEQUAL 156 0x9c i2 i1 Boolean Returns 1 if i2 and i1 are numerically equal, 0 otherwise.
OP_NUMEQUALVERIFY 157 0x9d i2 i1 Nothing / False Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
OP_NUMNOTEQUAL 158 0x9e i2 i1 Boolean Returns 1 if i2 and i1 are numerically not equal, 0 otherwise.
OP_LESSTHAN 159 0x9f i2 i1 Boolean Returns 1 if i2 is less than stack-top item i1, 0 otherwise.
OP_GREATERTHAN 160 0xa0 i2 i1 Boolean Returns 1 if i2 is greater than stack-top item i1, 0 otherwise.
OP_LESSTHANOREQUAL 161 0xa1 i2 i1 Boolean Returns 1 if i2 is less than or equal to stack-top item i1, 0 otherwise.
OP_GREATERTHANOREQUAL 162 0xa2 i2 i1 Boolean Returns 1 if i2 is greater than or equal to stack-top item i1, 0 otherwise.
OP_MIN 163 0xa3 i2 i1 i2 / i1 Returns the smaller of i2 and i1.
OP_MAX 164 0xa4 i2 i1 i2 / i1 Returns the larger of i2 and i1.
OP_WITHIN 165 0xa5 i3 i2 i1 Boolean Returns 1 if i3 >= i2 and i3 < i1, 0 otherwise. Thus if i2 > i1 returns always 0.

Crypto

Nemonic Decimal Hex Input Output Description
OP_RIPEMD160 166 0xa6 x hash20 The input is hashed using RIPEMD-160.
OP_SHA1 167 0xa7 x hash20 The input is hashed using SHA-1.
OP_SHA256 168 0xa8 x hash32 The input is hashed using SHA-256.
OP_HASH160 169 0xa9 x hash20 The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
OP_HASH256 170 0xaa x hash32 The input is hashed two times with SHA-256.
OP_CODESEPARATOR 171 0xab Nothing Nothing All of the signature checking opcodes will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
OP_CHECKSIG 172 0xac sig pubkey Boolean 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 a further, extern specified hash and the given public key. If it is, 1 is returned, 0 otherwise.
OP_CHECKSIGVERIFY 173 0xad sig pubkey Nothing / False Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
OP_CHECKMULTISIG 174 0xae sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys> Boolean For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. 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 sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys> Nothing / False Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.

Expansion opcodes

Nemonic Decimal Hex Description
OP_NOP1-OP_NOP10 176-185 0xb0-0xb9 The opcode has no effect.

Version opcodes

Version opcodes are disabled since bitcoin 0.2.0 and should not be used (maybe reassigned in the future).

Nemonic Decimal Hex Description
OP_VER 98 0x62 Script evalution is triggered invalid (Formerly pushed the bitcoin-serialize version onto stack).
OP_VERIF 101 0x65 Script evalution is triggered invalid (Formerly top stack item was popped and =< compared to present version)
OP_VERNOTIF 102 0x66 Script evalution is triggered invalid (Formerly top stack item was popped and > compared to present version)

Reserved opcodes

Each opcode not assigned (currently also every opcode value > 185) is also reserved. Using any unassigned opcode triggers the script evaluation to be invalid.

Nemonic Decimal Hex Description
OP_RESERVED 80 0x50 Script evalution is triggered invalid-
OP_RESERVED1 137 0x89 Script evalution is triggered invalid.
OP_RESERVED2 138 0x8a Script evalution is triggered invalid.

Pseudo-opcodes

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

Nemonic Decimal 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.

Scripts in bitcoin transactions

It follows a list of important (most occuring) scripts to see opcodes "at work". Keep in mind that all constants actually use the data-pushing instructions above. At start of a (transaction input) script evaluation, the stack is always empty.

Standard transaction to bitcoin address

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 storing transaction, i.e. its "available bitcoins".

Here is how each instruction 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.

Transaction to IP address (and generation transaction)

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.

In the case of a coin generation transaction (the first transaction of each block), there is no scriptSig, resp. its code ("coinbase") is completly ignored for the transaction. Only the scriptPubKey is used.

Transaction with a message

It's possible to add arbitrary data to any transaction by just adding some data along with OP_DROP.

scriptPubKey: <message> OP_DROP <pubKey> OP_CHECKSIG
scriptSig: <sig>
Stack Script Description
Empty. <sig> <message> OP_DROP <pubKey> OP_CHECKSIG
<sig> <message> OP_DROP <pubKey> OP_CHECKSIG scriptSig added to the stack.
<sig> <message> OP_DROP <pubKey> OP_CHECKSIG The message has been put.
<sig> <pubKey> OP_CHECKSIG Top stack item has been removed.
<sig> <pubKey> OP_CHECKSIG Checking signature against the public key.
true Empty. Stack holds the value of signature check now.

Examples of non standard transaction on Testnet

These two links below show a non standard transaction. It just prepends the hex of "bob" and the operation OP_DROP which just removes it. As you can see they can be spent as normal.

Input non-std transaction: http://blockexplorer.com/testnet/t/6ttfeb55B1

Spent by: http://blockexplorer.com/testnet/t/AFdRB1CHS3

Script validation

A script evaluation is considered invalid, if any of these conditions meets:

  • the total size of the script exceeds (currently) 10000 bytes
  • there are more than (currently) 201 opcodes of opcode value > 0x60 in the script
  • each instruction is (currently) limited to maximal 520 bytes. This effects only the opcodes OP_PUSHDATA2 and OP_PUSHDATA4
  • the executed opcode of the script has insufficient input (from stack, from script or from anywhere)
  • the opcode is not defined (for execution) - indicated by white or light gray background color in the table
  • the opcode is disabled (currently 15 opcodes) - indicated by white font color in the opcode overview matrix
  • stack overflow occurs during execution of the opcode (currently the number of items on the stack and on the alternate stack is limited to 1000)
  • the opcodes OP_VERIF and OP_NOTVERIF invalidate a script which contains this opcode (even if this opcode is not executed!)
  • the opcodes OP_ELSE or OP_ENDIF has no matching OP_IF
  • the script execution has been finished but there is (at least) an unmatched OP_IF
  • the opcodes OP_VERIFY, OP_EQUALVERIFY, OP_NUMEQUALVERIFY, OP_CHECKSIGVERIFY and OP_CHECKMULTISIGVERIFY invalidate the script if the stack-top item is false
  • the execution of OP_RETURN
  • the numerical value of the top-stack item is negative or greater than the number of items - 2 on the stack if OP_PICK or OP_ROLL shall be executed
  • an item used as public key or signature for each of the opcodes OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY can be neither a public key or signature (for the given hash)
  • the number of signature items or the number of public key items on the stack is negative for OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY
  • there or more signatures items than public key items on the stack for OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY
  • there are (currently) more than 20 public key items on the stack for OP_CHECKMULTISIG or CHECKMULTISIGVERIFY
  • the sum of opcodes > 0x60 and the number of public keys in all executed OP_CHECKMULTISIG or CHECKMULTISIGVERIFY exceeds (currently) 201
  • the script execution has been finished and the stack is empty or the top-stack item is false (numerical value 0)

else the script evaluation is considered to be valid.[4] If invalidation of a script is triggered then the script is immediately finished. These arbitrary looking limitations of 10000, 201, 520, 1000 and 20 might be increased in the future -- they serve to prevent strong slow down of the evaluation of a script while not restricting its practical usage really.

Withdrawn and drafted opcodes

  • byte value 0x89 OP_NOTEQUAL defined in pre-0.1.0 bitcoin versions. Since 0.1.0 removed because of security concerns.
  • byte value 0xb1 OP_EVAL withdraw - poll was triggered but insufficient support.
  • byte value 0xb2 OP_CHECKHASHVERIFY withdraw - poll was triggered but insufficient support.

See Also

References