Script: Difference between revisions
Line 1,077: | Line 1,077: | ||
|} | |} | ||
==Scripts in bitcoin | ==Scripts in bitcoin transactions== | ||
This is a list of | This is a list of important scripts to see op-codes "at work". Keep in mind that all constants actually use the data-pushing commands above. At start of a (transaction input) script evaluation, the stack is always empty. | ||
=== Standard Transaction to Bitcoin address === | ===Standard Transaction to Bitcoin address=== | ||
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | ||
Line 1,130: | Line 1,130: | ||
|} | |} | ||
=== | ===Transaction to IP address (generation transaction)=== | ||
scriptPubKey: <pubKey> OP_CHECKSIG | scriptPubKey: <pubKey> OP_CHECKSIG | ||
Line 1,155: | Line 1,155: | ||
|} | |} | ||
=== Transaction with a message === | In the case of a '''Coin generation transaction''' (the first transaction of each block), there is no txin-script, resp. this code (coinbase) is completle ignored for the transaction. Only the txout-script / 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. | It's possible to add arbitrary data to any transaction by just adding some data along with OP_DROP. |
Revision as of 13:34, 5 January 2013
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
- a public key that, when hashed, yields destination address D embedded in the script, and
- 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
_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 |
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.
Except pseudo-ops and the definition of OP_NOP1 - OP_NOP10 since bitcoin version 0.3.6, no further opcode interpretation seems to have changed since bitcoin version 0.2.0 [1] of 17th december 2009.
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). The naming of the entries in these two columns is chosen to reflect their interpretation. x,x0,x1,... means arbitrary or no interpretation, a, b and c as a signed integer value, n,index,size and depth non-negative 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 | 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 | depth | Puts the number of stack items onto the stack as one little-endian coded byte-vector |
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. |
Splice
Nemonic | Decimal | Hex | Input | Output | Description |
---|---|---|---|---|---|
OP_CAT | 126 | 0x7e | x1 x2 | out | Concatenates two strings resp. byte vectors. Currently disabled. |
OP_SUBSTR | 127 | 0x7f | x 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 | x index | out | Keeps only characters left of the specified point in a string. Currently disabled. |
OP_RIGHT | 129 | 0x81 | x index | out | Keeps only characters right of the specified point in a string. Currently disabled. |
OP_SIZE | 130 | 0x82 | x | x size | Returns the length of the input string resp. byte vector resp. 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 | x1 x2 | x0 | Boolean and between each bit in the inputs. Currently disabled. |
OP_OR | 133 | 0x85 | x1 x2 | x0 | Boolean or between each bit in the inputs. Currently disabled. |
OP_XOR | 134 | 0x86 | x1 x2 | x0 | Boolean exclusive or between each bit in the inputs. Currently disabled. |
OP_EQUAL | 135 | 0x87 | x1 x2 | Boolean | Returns 1 if the inputs are byte-wise equal, 0 otherwise. |
OP_EQUALVERIFY | 136 | 0x88 | x1 x2 | 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 | a | c | 1 is added to the input. |
OP_1SUB | 140 | 0x8c | a | c | 1 is subtracted from the input. |
OP_2MUL | 141 | 0x8d | a | c | The input is multiplied by 2. Currently disabled. |
OP_2DIV | 142 | 0x8e | a | c | The input is divided by 2. Currently disabled. |
OP_NEGATE | 143 | 0x8f | a | c | The sign of the input is flipped. Numerically the value is multiplied by -1 |
OP_ABS | 144 | 0x90 | a | c | The input is negative, its sign is flipped. |
OP_NOT | 145 | 0x91 | a | 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 | a | Boolean | Returns 0 if the input is 0. 1 otherwise. Test whether its value is unequal 0 |
OP_ADD | 147 | 0x93 | a b | c | a is added to b. |
OP_SUB | 148 | 0x94 | a b | c | b is subtracted from a. |
OP_MUL | 149 | 0x95 | a b | c | a is multiplied by b. Currently disabled. |
OP_DIV | 150 | 0x96 | a b | c | a is divided by b (b should be not 0). Currently disabled. |
OP_MOD | 151 | 0x97 | a b | c | Returns the remainder after dividing a by b (b should be not 0). Currently disabled. |
OP_LSHIFT | 152 | 0x98 | a b | c | Shifts a left by b bits, preserving sign. Currently disabled. |
OP_RSHIFT | 153 | 0x99 | a b | c | Shifts a right by b bits, preserving sign. Currently disabled. |
OP_BOOLAND | 154 | 0x9a | a b | Boolean | If both a and b are not 0, the output is 1. Otherwise 0. |
OP_BOOLOR | 155 | 0x9b | a b | Boolean | If a or b is not 0, the output is 1. Otherwise 0. |
OP_NUMEQUAL | 156 | 0x9c | a b | Boolean | Returns 1 if the numbers are equal, 0 otherwise. |
OP_NUMEQUALVERIFY | 157 | 0x9d | a b | Nothing / False | Same as OP_NUMEQUAL, but runs OP_VERIFY afterward. |
OP_NUMNOTEQUAL | 158 | 0x9e | a b | Boolean | Returns 1 if the numbers are not equal, 0 otherwise. |
OP_LESSTHAN | 159 | 0x9f | a b | Boolean | Returns 1 if a is less than b, 0 otherwise. |
OP_GREATERTHAN | 160 | 0xa0 | a b | Boolean | Returns 1 if a is greater than b, 0 otherwise. |
OP_LESSTHANOREQUAL | 161 | 0xa1 | a b | Boolean | Returns 1 if a is less than or equal to b, 0 otherwise. |
OP_GREATERTHANOREQUAL | 162 | 0xa2 | a b | Boolean | Returns 1 if a is greater than or equal to b, 0 otherwise. |
OP_MIN | 163 | 0xa3 | a b | a / b | Returns the smaller of a and b. |
OP_MAX | 164 | 0xa4 | a b | a / b | Returns the larger of a and b. |
OP_WITHIN | 165 | 0xa5 | x min max | Boolean | Returns 1 if x is within the specified range (left-inclusive) , 0 otherwise. min may be greater than max |
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. |
Transparent 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
This is a list of important scripts to see op-codes "at work". Keep in mind that all constants actually use the data-pushing commands 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 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. |
Transaction to IP address (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 txin-script, resp. this code (coinbase) is completle ignored for the transaction. Only the txout-script / 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. |
Example non standard transaction on Testnet
These 2 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.[2] If invalidation of a script is triggered, 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 the total script while not restricting its practical usage really.
See Also
References
- ↑ file src/srcipt.cpp in [1]
- ↑ file src/src/script.cpp in bitcoin-0.7.1