Script: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
Smtp (talk | contribs)
Capsqrl (talk | contribs)
→‎External Links: Remove dead link, webbtc.com has changed owner (Hi, Reddit)
 
(93 intermediate revisions by 37 users not shown)
Line 1: Line 1:
Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.
Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, '''Script''' is simple, stack-based, and processed from left to right. It is intentionally 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.
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.  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 prove ownership of the private key corresponding to the public key just provided.


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


== Scripts and Bitcoin transactions ==
A transaction is valid if nothing in the combined script triggers failure and the top stack item is True (non-zero) when the script exits.  The party that originally ''sent'' 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 the combined script completing execution with a true value on the top of the stack.
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
This document is for information purposes only. De facto, Bitcoin script is defined by the code run by the network to check the validity of blocks.
# 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.
The stacks hold byte vectors.
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.


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.<br>
Leading zeros in an integer and negative zero are allowed in blocks but get rejected by the stricter requirements which standard full nodes put on transactions before retransmitting them.
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 txout-script.
Byte vectors on the stack are not allowed to be more than 520 bytes long. 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.


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


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.
There are some words which existed in very early versions of Bitcoin but were removed out of concern that the client might have a bug in their implementation. This fear was motivated by a bug found in OP_LSHIFT that could crash any Bitcoin node if exploited and by other bugs that allowed anyone to spend anyone's bitcoins. The removed opcodes are sometimes said to be "disabled", but this is something of a misnomer because there is ''absolutely no way'' for anyone using Bitcoin to use these opcodes (they simply ''do not exist anymore'' in the protocol), and there are also no solid plans to ever re-enable all of these opcodes. They are listed here for historical interest only.


== Opcode overview ==
New opcodes can be added by means of a carefully designed and executed [[softfork]] using OP_NOP1-OP_NOP10.


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. <br/>
Zero, negative zero (using any number of bytes), and empty array are all treated as false. Anything else is treated as true.
Different colors indicate different semantic execution groups of opcodes:
{| style="background:none; font-size:100%; padding:0; border-collapse:collapse; text-align:center; line-height:2em;" border="0" align="center"
|-
| style="border:1px solid #aaaaaa; background-color:gold;" | copy a fixed number of bytes but at most 75 onto stack
| style="border:1px solid #aaaaaa; background-color:#ffff00;" | copy bytes onto stack which number is given by a 1, 2 or 4 byte value.
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | copy 1 specific byte onto stack
|-
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | undefined opcode
| style="border:1px solid #aaaaaa; background-color:#f0f0f0;" | a pseudo-opcode, unassigned for scripts
|-
| style="border:1px solid #aaaaaa; background-color:#00d000;" | NOP or opcode is part of a IF-flow-control construction
|-
| style="border:1px solid #aaaaaa; background-color:#00ff00;" | (stack conditionally) invalidation of the script this opcode is part of
|-
| style="border:1px solid #aaaaaa; background-color:#ff8080;" | stack item is moved between main stack and alternate stack
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | stack item(s) is/are moved, copied or deleted
|-
| style="border:1px solid #aaaaaa; background-color:#f000f0;" | byte vectors are appended or divided or their size is determined
| style="border:1px solid #aaaaaa; background-color:#c000ff;" | byte vectors are interpreted bit-position-independently
|-
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | byte vectors are interpreted and processed as signed integers
|-
| style="border:1px solid #aaaaaa; background-color:#00c0f0;" | a hash value is computed or a signature checked
|}
<p>
===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.
{| style="background:none; font-size:100%; padding:0; border-collapse:collapse; text-align:center; line-height:2em;" border="0" align="center"
|-
| style="border:1px solid #aaaaaa; background-color:gold;" |_FALSE<br/> 0x00 <br/> 0 ; 1(0)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x01<br/> 0 *; 1(1)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x02<br/> 0 *; 1(2)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x03<br/> 0 *; 1(3)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x04<br/> 0 *; 1(4)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x04<br/> 0 *; 1(5)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x06<br/> 0 *; 1(6)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x07<br/> 0 *; 1(7)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x08<br/> 0 *; 1(8)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x09<br/> 0 *; 1(9)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x0a<br/> 0 *; 1(10)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x0b<br/> 0 *; 1(11)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x0c<br/> 0 *; 1(12)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x0d<br/> 0 *; 1(13)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x0e<br/> 0 *; 1(14)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x0f<br/> 0 *; 1(15)
|-
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x10 <br/> 0 *; 1(16)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x11 <br/> 0 *; 1(17)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x12 <br/> 0 *; 1(18)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x13 <br/> 0 *; 1(19)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x14 <br/> 0 *; 1(20)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x15 <br/> 0 *; 1(21)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x16 <br/> 0 *; 1(22)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x17 <br/> 0 *; 1(23)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x18 <br/> 0 *; 1(24)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x19 <br/> 0 *; 1(25)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x1a <br/> 0 *; 1(26)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x1b <br/> 0 *; 1(27)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x1c <br/> 0 *; 1(28)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x1d <br/> 0 *; 1(29)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x1e <br/> 0 *; 1(30)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x1f <br/> 0 *; 1(31)
|-
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x20 <br/> 0 *; 1(32)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x21 <br/> 0 *; 1(33)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x22 <br/> 0 *; 1(34)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x23 <br/> 0 *; 1(35)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x24 <br/> 0 *; 1(36)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x25 <br/> 0 *; 1(37)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x26 <br/> 0 *; 1(38)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x27 <br/> 0 *; 1(39)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x28 <br/> 0 *; 1(40)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x29 <br/> 0 *; 1(41)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x2a <br/> 0 *; 1(42)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x2b <br/> 0 *; 1(43)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x2c <br/> 0 *; 1(44)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x2d <br/> 0 *; 1(45)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x2e <br/> 0 *; 1(46)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x2f <br/> 0 *; 1(47)
|-
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x30 <br/> 0 *; 1(48)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x31 <br/> 0 *; 1(49)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x32 <br/> 0 *; 1(50)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x33 <br/> 0 *; 1(51)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x34 <br/> 0 *; 1(52)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x35 <br/> 0 *; 1(53)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x36 <br/> 0 *; 1(54)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x37 <br/> 0 *; 1(55)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x38 <br/> 0 *; 1(56)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x39 <br/> 0 *; 1(57)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x3a <br/> 0 *; 1(58)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x3b <br/> 0 *; 1(59)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x3c <br/> 0 *; 1(60)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x3d <br/> 0 *; 1(61)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x3e <br/> 0 *; 1(62)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x3f <br/> 0 *; 1(63)
|-
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x40 <br/> 0 *; 1(64)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x41 <br/> 0 *; 1(65)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x42 <br/> 0 *; 1(66)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x43 <br/> 0 *; 1(67)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x44 <br/> 0 *; 1(68)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x45 <br/> 0 *; 1(69)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x46 <br/> 0 *; 1(70)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x47 <br/> 0 *; 1(71)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x48 <br/> 0 *; 1(72)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x49 <br/> 0 *; 1(73)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x4a <br/> 0 *; 1(74)
| style="border:1px solid #aaaaaa; background-color:gold;" | - <br/> 0x4b <br/> 0 *; 1(75)
| style="border:1px solid #aaaaaa; background-color:#ffff00;" | _PUSHDATA1 <br/> 0x4c <br/> 0 *; 1(0 - 255)
| style="border:1px solid #aaaaaa; background-color:#ffff00;" | _PUSHDATA2 <br/> 0x4d <br/> 0 *; 1(0 - 2^16-1)
| style="border:1px solid #aaaaaa; background-color:#ffff00;" | _PUSHDATA4 <br/> 0x4e <br/> 0 *; 1(0 - 2^32-1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _1NEGATE <br/> 0x4f <br/> 0 ; 1(1)
|-
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | _RESERVED <br/> 0x50 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _1 <br/> 0x51 <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _2 <br/> 0x52 <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _3 <br/> 0x53 <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _4 <br/> 0x54 <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _5 <br/> 0x55 <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _6 <br/> 0x56 <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _7 <br/> 0x57 <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _8 <br/> 0x58 <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _9 <br/> 0x59 <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _10 <br/> 0x5a <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _11 <br/> 0x5b <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _12 <br/> 0x5c <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _13 <br/> 0x5d <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _14 <br/> 0x5e <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _15 <br/> 0x5f <br/> 0 ; 1(1)
|-
| style="border:1px solid #aaaaaa; background-color:#ffb000;" | _16 <br/> 0x60 <br/> 0 ; 1(1)
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _NOP <br/> 0x61 <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | _VER <br/> 0x62 <br/>
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _IF <br/> 0x63 <br/> 1 ; 0
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _NOTIF <br/> 0x64 <br/> 1 ; 0
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | _VERIF <br/> 0x65 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | _VERNOTIF <br/> 0x66 <br/>
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _ELSE <br/> 0x67 <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _ENDIF <br/> 0x68 <br/> 0 ; 0
| style="border:3px solid #808080; background-color:#00ff00;" | _VERIFY <br/> 0x69 <br/> 1 ; 0/1
| style="border:3px solid #808080; background-color:#00ff00;" | _RETURN <br/> 0x6a <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#ff8080;" | _TOALTSTACK <br/> 0x6b <br/> 1 ; 0
| style="border:1px solid #aaaaaa; background-color:#ff8080;" | _FROMALTSTACK <br/> 0x6c <br/> 0 #; 1
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _2DROP <br/> 0x6d <br/> 2 ; 0
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _2DUP <br/> 0x6e <br/> 2 ; 4
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _3DUP <br/> 0x6f <br/> 3 ; 6
|-
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _2OVER <br/> 0x70 <br/> 4 ; 6
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _2ROT <br/> 0x71 <br/> 6 ; 6
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _2SWAP <br/> 0x72 <br/> 4 ; 4
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _IFDUP <br/> 0x73 <br/> 1 ; 1/2
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _DEPTH <br/> 0x74 <br/> 0 ; 1
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _DROP <br/> 0x75 <br/> 1 ; 0
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _DUP <br/> 0x76 <br/> 1 ; 2
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _NIP <br/> 0x77 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _OVER <br/> 0x78 <br/> 2 ; 3
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _PICK <br/> 0x79 <br/> 1+n+1 ; n+2
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _ROLL <br/> 0x7a <br/> 1+n+1 ; n+1
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _ROT <br/> 0x7b <br/> 3 ; 3
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _SWAP <br/> 0x7c <br/> 2 ; 2
| style="border:1px solid #aaaaaa; background-color:#ff4040;" | _TUCK <br/> 0x7d <br/> 2 ; 3
| style="border:1px solid #aaaaaa; background-color:#f000f0; color:white" | _CAT <br/> 0x7e <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#f000f0; color:white" | _SUBSTR <br/> 0x7f <br/> 3 ; 1
|-
| style="border:1px solid #aaaaaa; background-color:#f000f0; color:white" | _LEFT <br/> 0x80 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#f000f0; color:white" | _RIGHT <br/> 0x81 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#f000f0;" | _SIZE <br/> 0x82 <br/> 1 ; 2
| style="border:1px solid #aaaaaa; background-color:#c000ff; color:white" | _INVERT <br/> 0x83 <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#c000ff; color:white" | _AND <br/> 0x84 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#c000ff; color:white" | _OR <br/> 0x85 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#c000ff; color:white" | _XOR <br/> 0x86 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#c000ff;" | _EQUAL <br/> 0x87 <br/> 2 ; 1
| style="border:3px solid #808080; background-color:#c080ff;" | _EQUALVERIFY <br/> 0x88 <br/> 2 ; 0/1
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | _RESERVED1 <br/> 0x89 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | _RESERVED2 <br/> 0x8a <br/>
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _1ADD <br/> 0x8b <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _1SUB <br/> 0x8c <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff; color:white" | _2MUL <br/> 0x8d <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff; color:white" | _2DIV <br/> 0x8e <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _NEGATE <br/> 0x8f <br/> 1 ; 1
|-
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _ABS <br/> 0x90 <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _NOT <br/> 0x91 <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _0NOTEQUAL <br/> 0x92 <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _ADD <br/> 0x93 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _SUB <br/> 0x94 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff; color:white" | _MUL <br/> 0x95 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff; color:white" | _DIV <br/> 0x96 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff; color:white" | _MOD <br/> 0x97 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff; color:white" | _LSHIFT <br/> 0x98 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff; color:white" | _RSHIFT <br/> 0x99 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _BOOLAND <br/> 0x9a <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _BOOLOR <br/> 0x9b <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _NUMEQUAL <br/> 0x9c <br/> 2 ; 1
| style="border:3px solid #808080; background-color:#8080ff;" | _NUMEQUALVERIFY <br/> 0x9d <br/> 2 ; 0/1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _NUMNOTEQUAL <br/> 0x9e <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _LESSTHAN <br/> 0x9f <br/> 2 ; 1
|-
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _GREATERTHAN <br/> 0xa0 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _LESSTHANOREQUAL <br/> 0xa1 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _GREATERTHANOREQUAL <br/> 0xa2 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _MIN <br/> 0xa3 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _MAX <br/> 0xa4 <br/> 2 ; 1
| style="border:1px solid #aaaaaa; background-color:#8000ff;" | _WITHIN <br/> 0xa5 <br/> 3 ; 1
| style="border:1px solid #aaaaaa; background-color:#00c0f0;" | _RIPEMD160 <br/> 0xa6 <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#00c0f0;" | _SHA1 <br/> 0xa7 <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#00c0f0;" | _SHA256 <br/> 0xa8 <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#00c0f0;" | _HASH160 <br/> 0xa9 <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#00c0f0;" | _HASH256 <br/> 0xaa <br/> 1 ; 1
| style="border:1px solid #aaaaaa; background-color:#00c0f0;" | _CODESEPARATOR  <br/> 0xab <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#00c0f0;" | _CHECKSIG <br/> 0xac <br/> 2 @; 1
| style="border:3px solid #808080; background-color:#a0d0ff;" | _CHECKSIGVERIFY <br/> 0xad <br/> 2 @; 0/1
| style="border:1px solid #aaaaaa; background-color:#00c0f0;" | _CHECKMULTISIG <br/> 0xae <br/> 2n+2 @; 1
| style="border:3px solid #808080; background-color:#a0d0ff;" | _CHECKMULTISIGVERIFY <br/> 0xaf <br/> 2n+2 @; 0/1
|-
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _NOP1 <br/> 0xb0 <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _NOP2 <br/> 0xb1 <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _NOP3 <br/> 0xb2 <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _NOP4 <br/> 0xb3 <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _NOP5 <br/> 0xb4 <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _NOP6 <br/> 0xb5 <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _NOP7 <br/> 0xb6 <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _NOP8 <br/> 0xb7 <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _NOP9 <br/> 0xb8 <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#00d000;" | _NOP10 <br/> 0xb9 <br/> 0 ; 0
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xba <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xbb <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xbc <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xbd <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xbe <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xbf <br/>
|-
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xc0 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xc1 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xc2 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xc3 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xc4 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xc5 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xc6 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xc7 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xc8 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xc9 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xca <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xcb <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xcc <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xcd <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xce <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xcf <br/>
|-
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xd0 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xd1 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xd2 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xd3 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xd4 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xd5 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xd6 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xd7 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xd8 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xd9 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xda <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xdb <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xdc <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xdd <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xde <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xdf <br/>
|-
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xe0 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xe1 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xe2 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xe3 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xe4 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xe5 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xe6 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xe7 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xe8 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xe9 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xea <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xeb <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xec <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xed <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xee <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xef <br/>
|-
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xf0 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xf1 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xf2 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xf3 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xf4 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xf5 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xf6 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xf7 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xf8 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xf9 <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | - <br/> 0xfa <br/>
| style="border:1px solid #aaaaaa; background-color:#f0f0f0;" | _SMALLINTEGER <br/> 0xfb <br/>
| style="border:1px solid #aaaaaa; background-color:#f0f0f0;" | _PUBKEYS <br/> 0xfc <br/>
| style="border:1px solid #aaaaaa; background-color:#f0f0f0;" | _PUBKEYHASH  <br/> 0xfd <br/>
| style="border:1px solid #aaaaaa; background-color:#f0f0f0;" | _PUBKEY <br/> 0xfe <br/>
| style="border:1px solid #aaaaaa; background-color:#ffffff;" | _INVALIDOPCODE <br/> 0xff <br/>
|}<br>
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 <ref>[http://mirror.transact.net.au/pub/sourceforge/b/project/bi/bitcoin/Bitcoin/bitcoin-0.2.0/bitcoin-0.2.0-linux.tar.gz file src/srcipt.cpp in bitcoin-0.2.0]</ref> <ref>[http://mirror.transact.net.au/pub/sourceforge/b/project/bi/bitcoin/Bitcoin/bitcoin-0.3.3/bitcoin-0.3.3-linux.tar.gz file src/srcipt.cpp in bitcoin-0.3.3]</ref> <ref>[http://mirror.transact.net.au/pub/sourceforge/b/project/bi/bitcoin/Bitcoin/bitcoin-0.3.6/bitcoin-0.3.6-linux.tar.gz file src/srcipt.cpp in bitcoin-0.3.6]</ref>.


== Opcode descriptions ==
=== Notation on this page ===
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.<br>


Some of the more complicated opcodes are disabled since version 0.3.10 out of concern that the client might have 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). Furthermore how some of theses opcodes should work precisely is disputable.
In the tables below, the inputs and outputs are both described by items as if they were pushed on the stack in that order. So for example, "x1 x2" indicates pushing value x1 on the stack, then x2, such that x1 is at the bottom of the stack, and x2 is at the top. When writing scripts as human-readable opcodes, the push opcodes and the associated data are usually written as <code>&lt;data&gt;</code>. For example, a P2SH script would be written as <code>OP_HASH160 &lt;data&gt; OP_EQUAL</code>, where <code>&lt;data&gt;</code> in this context means the byte <code>0x20</code> followed by the 20 bytes of the data itself. You should also ensure that you use the appropriate push instruction if your data is very large. See the table below for details.


=== Push data from instruction onto stack ===
=== Constants ===
When talking about scripts, these value-pushing words are usually omitted.


{| class="wikitable"
{| class="wikitable"
|-
|-
!Nemonic
!Word
!Decimal
!Opcode
!Hex
!Hex
!Input
!Input
Line 341: Line 46:
!Description
!Description
|-
|-
|OP_FALSE, OP_0
|OP_0, OP_FALSE
|0
|0
|0x00
|0x00
|Nothing
|Nothing.
|Empty string
|(empty value)
|A byte vector of length 0 is pushed onto the stack. (Thus, it is not a no-op!)
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
|-
|-
|(no official nemonics)
|N/A
|1 - 75
|1-75
|0x01 - 0x4b
|0x01-0x4b
|(operand)
|(special)
|x
|data
|The next <opcode>-many bytes are to be pushed onto the stack.
|The next ''opcode'' bytes is data to be pushed onto the stack
|-
|-
|OP_PUSHDATA1
|OP_PUSHDATA1
|76
|76
|0x4c
|0x4c
|(operands)
|(special)
|x
|data
|The next byte contains the number of bytes to be pushed onto the stack which follow this byte.
|The next byte contains the number of bytes to be pushed onto the stack.
|-
|-
|OP_PUSHDATA2
|OP_PUSHDATA2
|77
|77
|0x4d
|0x4d
|(operands)
|(special)
|x
|data
|The next two bytes contain the number of bytes to be pushed onto the stack which follow theses 2 bytes.
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|-
|OP_PUSHDATA4
|OP_PUSHDATA4
|78
|78
|0x4e
|0x4e
|(operands)
|(special)
|x
|data
|The next four bytes contain the number of bytes to be pushed onto the stack which follow theses 4 bytes.
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|-
|OP_1NEGATE
|OP_1NEGATE
|79
|79
|0x4f
|0x4f
|Nothing
|Nothing.
| -1
| -1
|The byte with value -1 is pushed onto the stack.
|The number -1 is pushed onto the stack.
|-
|-
|OP_1, OP_TRUE
|OP_1, OP_TRUE
|81
|81
|0x51
|0x51
|Nothing
|Nothing.
|1
|1
|The byte with value 1 is pushed onto the stack.
|The number 1 is pushed onto the stack.
|-
|-
|OP_2 - OP_16
|OP_2-OP_16
|82 - 96
|82-96
|0x52 - 0x60
|0x52-0x60
|Nothing
|Nothing.
|2-16
|2-16
|The byte with value <opcode>-80 (thus, one of 2 - 16) is pushed onto the stack.
|The number in the word name (2-16) is pushed onto the stack.
|}
|}


Line 402: Line 107:
{| class="wikitable"
{| class="wikitable"
|-
|-
!Nemonic
!Word
!Decimal
!Opcode
!Hex
!Hex
!Input
!Input
Line 419: Line 124:
|99
|99
|0x63
|0x63
|Boolean
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Nothing
|If the top stack value is not False, the statements are executed. The top stack value is removed.
|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
|OP_NOTIF
|100
|100
|0x64
|0x64
|Boolean
| colspan="2"|<expression> notif [statements] [else [statements]]* endif
|Nothing
|If the top stack value is False, the statements are executed. The top stack value is removed.
|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
|OP_ELSE
|103
|103
|0x67
|0x67
|Nothing
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Nothing
|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.  
|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
|OP_ENDIF
|104
|104
|0x68
|0x68
|Nothing
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Nothing
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without OP_IF earlier is also '''invalid'''.
|Ends a logcial ''If <value> then [statements] [else [statements]] '' expression
|-
|-
|OP_VERIFY
|OP_VERIFY
|105
|105
|0x69
|0x69
|Boolean
|True / false
|Nothing / False
|Nothing / ''fail''
|If top stack value is not true then marks transaction as '''invalid''' . A value true is removed, but false is not.
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.
|-
|-
|OP_RETURN
|[[OP_RETURN]]
|106
|106
|0x6a
|0x6a
|Nothing
|Nothing
|Nothing
|''fail''
|Marks transaction as '''invalid'''.  
|'''Marks transaction as invalid'''. Since bitcoin 0.9, a standard way of attaching extra data to transactions is to add a zero-value output with a scriptPubKey consisting of OP_RETURN followed by data. Such outputs are provably unspendable and specially discarded from storage in the UTXO set, reducing their cost to the network. Since [https://bitcoin.org/en/release/v0.12.0#relay-any-sequence-of-pushdatas-in-opreturn-outputs-now-allowed 0.12], standard relay rules allow a single output with OP_RETURN, that contains any sequence of push statements (or OP_RESERVED<ref>see code for IsPushOnly [https://github.com/bitcoin/bitcoin/blob/bccb4d29a8080bf1ecda1fc235415a11d903a680/src/script/script.cpp#L232]</ref>) after the OP_RETURN provided the total scriptPubKey length is at most 83 bytes.
|}
|}


===Stack item organization===
=== Stack ===


{| class="wikitable"  
{| class="wikitable"  
|-
|-
!Nemonic
!Word
!Decimal
!Opcode
!Hex
!Hex
!Input
!Input
Line 473: Line 174:
|107
|107
|0x6b
|0x6b
|x1 (alt)
|x1
|(alt x1)
|(alt)x1
|Puts the input onto the top of the alt stack. Removes it from the (main) stack.
|Puts the input onto the top of the alt stack. Removes it from the main stack.
|-
|-
|OP_FROMALTSTACK
|OP_FROMALTSTACK
|108
|108
|0x6c
|0x6c
|(alt x1)
|(alt)x1
|x1 (alt)
|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
|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
|OP_IFDUP
|115
|115
|0x73
|0x73
|x1
|x
|x1 / x1 x1
|x / x x
|If the top stack value is not 0, duplicate it.
|If the top stack value is not 0, duplicate it.
|-
|-
Line 537: Line 196:
|0x74
|0x74
|Nothing
|Nothing
|depth
|<Stack size>
|Puts the number of stack items onto the stack as one little-endian coded byte-vector
|Puts the number of stack items onto the stack.
|-
|-
|OP_DROP
|OP_DROP
|117
|117
|0x75
|0x75
|x1
|x
|Nothing
|Nothing
|Removes the top stack item.
|Removes the top stack item.
Line 550: Line 209:
|118
|118
|0x76
|0x76
|x1
|x
|x1 x1
|x x
|Duplicates the top stack item.
|Duplicates the top stack item.
|-
|-
Line 557: Line 216:
|119
|119
|0x77
|0x77
|x2 x1
|x1 x2
|x1
|x2
|Removes the second-to-top stack item.
|Removes the second-to-top stack item.
|-
|-
Line 564: Line 223:
|120
|120
|0x78
|0x78
|x2 x1
|x1 x2
|x2 x1 x2
|x1 x2 x1
|Copies the second-to-top stack item to the top.
|Copies the second-to-top stack item to the top.
|-
|-
Line 573: Line 232:
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 xn
|xn ... x2 x1 x0 xn
|<n> is removed and the item ''n'' back in the stack is copied to the top.
|The item ''n'' back in the stack is copied to the top.
|-
|-
|OP_ROLL
|OP_ROLL
Line 580: Line 239:
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 <n>
|... x2 x1 x0 xn
|... x2 x1 x0 xn
|<n> is removed and the item ''n'' back in the stack is moved to the top.
|The item ''n'' back in the stack is moved to the top.
|-
|-
|OP_ROT
|OP_ROT
|123
|123
|0x7b
|0x7b
|x3 x2 x1
|x1 x2 x3
|x2 x1 x3
|x2 x3 x1
|The top three items on the stack are rotated to the left.
|The 3rd item down the stack is moved to the top.
|-
|-
|OP_SWAP
|OP_SWAP
|124
|124
|0x7c
|0x7c
|x1 x2
|x2 x1
|x2 x1
|x1 x2
|The top two items on the stack are swapped.
|The top two items on the stack are swapped resp. rotated.
|-
|-
|OP_TUCK
|OP_TUCK
|125
|125
|0x7d
|0x7d
|x2 x1
|x1 x2
|x1 x2 x1
|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.
|}
|}


=== Splice ===
=== Splice ===
If any opcode marked as disabled is present in a script, it must abort and fail.


{| class="wikitable"  
{| class="wikitable"  
|-
|-
!Nemonic
!Word
!Decimal
!Opcode
!Hex
!Hex
!Input
!Input
Line 618: Line 321:
|126
|126
|0x7e
|0x7e
|x2 x1
|x1 x2
|out
|out
|Appends stack-top item at second-to top item. Concatenates two strings resp. byte vectors. ''Currently disabled.''
|style="background:#D97171;"|Concatenates two strings. ''disabled.''
|-
|-
|OP_SUBSTR
|OP_SUBSTR
|127
|127
|0x7f
|0x7f
|x3 index size
|in begin size
|out
|out
|Returns the section started at position <index> and of length <size> of a string resp. byte vector. ''Currently disabled.''
|style="background:#D97171;"|Returns a section of a string. ''disabled.''
|-
|-
|OP_LEFT
|OP_LEFT
|128
|128
|0x80
|0x80
|x2 index
|in size
|out
|out
|Keeps only characters left of the specified point in second-to top item. ''Currently disabled.''
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''
|-
|-
|OP_RIGHT
|OP_RIGHT
|129
|129
|0x81
|0x81
|x2 index
|in size
|out
|out
|Keeps only characters right of the specified point in second-to top item. ''Currently disabled.''
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''
|-
|-
|OP_SIZE
|OP_SIZE
|130
|130
|0x82
|0x82
|x1
|in
|x1 size
|in size
|Returns the length of the input string resp. byte vector resp. top-stack item.
|Pushes the string length of the top element of the stack (without popping it).
|}
|}


=== Bitwise logic ===
=== Bitwise logic ===
If any opcode marked as disabled is present in a script, it must abort and fail.


{| class="wikitable"  
{| class="wikitable"  
|-
|-
!Nemonic
!Word
!Decimal
!Opcode
!Hex
!Hex
!Input
!Input
Line 665: Line 370:
|131
|131
|0x83
|0x83
|x1
|in
|x0
|out
|Flips all of the bits in the input. ''Currently disabled.''
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''
|-
|-
|OP_AND
|OP_AND
|132
|132
|0x84
|0x84
|x2 x1
|x1 x2
|x0
|out
|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''
|-
|-
|OP_OR
|OP_OR
|133
|133
|0x85
|0x85
|x2 x1
|x1 x2
|x0
|out
|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''
|-
|-
|OP_XOR
|OP_XOR
|134
|134
|0x86
|0x86
|x2 x1
|x1 x2
|x0
|out
|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''
|-
|-
|OP_EQUAL
|OP_EQUAL
|135
|135
|0x87
|0x87
|x2 x1
|x1 x2
|Boolean
|True / false
|Returns 1 if the inputs have the same length and are byte-wise equal, 0 otherwise.
|Returns 1 if the inputs are exactly equal, 0 otherwise.
|-
|-
|OP_EQUALVERIFY
|OP_EQUALVERIFY
|136
|136
|0x88
|0x88
|x2 x1
|x1 x2
|Nothing / false
|Nothing / ''fail''
|Same as OP_EQUAL, but runs OP_VERIFY afterward.
|Same as OP_EQUAL, but runs OP_VERIFY afterward.
|}
|}
Line 707: Line 412:
=== Arithmetic ===
=== Arithmetic ===


Since version 0.3.10 the implemented arithmetic opcodes are limited to maximal 4 byte vectors (|value| < 2^31), in version 0.3.6 up to 0.3.8 they were limited to 258 byte vectors and prior to 0.3.6 unrestricted.
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.
 
If any input value for any of these commands is longer than 4 bytes, the script must abort and fail.
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.
 
{| class="wikitable"  
{| class="wikitable"  
|-
|-
!Nemonic
!Word
!Decimal
!Opcode
!Hex
!Hex
!Input
!Input
Line 720: Line 429:
|139
|139
|0x8b
|0x8b
|i1
|in
|i0
|out
|1 is added to the input.
|1 is added to the input.
|-
|-
Line 727: Line 436:
|140
|140
|0x8c
|0x8c
|i1
|in
|i0
|out
|1 is subtracted from the input.
|1 is subtracted from the input.
|-
|-
Line 734: Line 443:
|141
|141
|0x8d
|0x8d
|i1
|in
|i0
|out
|The input is multiplied by 2. ''Currently disabled.''
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''
|-
|-
|OP_2DIV
|OP_2DIV
|142
|142
|0x8e
|0x8e
|i1
|in
|i0
|out
|The input is divided by 2 (round down). ''Currently disabled.''
|style="background:#D97171;"|The input is divided by 2. ''disabled.''
|-
|-
|OP_NEGATE
|OP_NEGATE
|143
|143
|0x8f
|0x8f
|i1
|in
|i0
|out
|The sign of the input is flipped. Numerically the value is multiplied by -1
|The sign of the input is flipped.
|-
|-
|OP_ABS
|OP_ABS
|144
|144
|0x90
|0x90
|i1
|in
|i0
|out
|The input is negative, its sign is flipped.
|The input is made positive.
|-
|-
|OP_NOT
|OP_NOT
|145
|145
|0x91
|0x91
|i1
|in
|Boolean
|out
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0. Test whether its value equals 0
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.
|-
|-
|OP_0NOTEQUAL
|OP_0NOTEQUAL
|146
|146
|0x92
|0x92
|i1
|in
|Boolean
|out
|Returns 0 if the input is 0. 1 otherwise. Test whether its value is unequal 0
|Returns 0 if the input is 0. 1 otherwise.
|-
|-
|OP_ADD
|OP_ADD
|147
|147
|0x93
|0x93
|i2 i1
|a b
|i0
|out
|stack-top i1 is added to i2.
|a is added to b.
|-
|-
|OP_SUB
|OP_SUB
|148
|148
|0x94
|0x94
|i2 i1
|a b
|i0
|out
|stack-top i1 is subtracted from i2.
|b is subtracted from a.
|-
|-
|OP_MUL
|OP_MUL
|149
|149
|0x95
|0x95
|i2 i1
|a b
|i0
|out
|i2 is multiplied with stack-top i1. ''Currently disabled.''
|style="background:#D97171;"|a is multiplied by b. ''disabled.''
|-
|-
|OP_DIV
|OP_DIV
|150
|150
|0x96
|0x96
|i2 i1
|a b
|i0
|out
|i2 is divided by stack-top i1 (divisor should be not 0). ''Currently disabled.''
|style="background:#D97171;"|a is divided by b. ''disabled.''
|-
|-
|OP_MOD
|OP_MOD
|151
|151
|0x97
|0x97
|i2 i1
|a b
|i0
|out
|Returns the remainder after dividing i2 by stack-top i1 (divisor should be not 0). ''Currently disabled.''
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''
|-
|-
|OP_LSHIFT
|OP_LSHIFT
|152
|152
|0x98
|0x98
|i2 i1
|a b
|i0
|out
|Shifts i2 left by i1 bits, preserving sign of i2 (i1 >= 0). ''Currently disabled.''
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''
|-
|-
|OP_RSHIFT
|OP_RSHIFT
|153
|153
|0x99
|0x99
|i2 i1
|a b
|i0
|out
|Shifts i2 right by i1 bits, preserving sign of i2 (i1 >= 0). ''Currently disabled.''
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''
|-
|-
|OP_BOOLAND
|OP_BOOLAND
|154
|154
|0x9a
|0x9a
|i2 i1
|a b
|Boolean
|out
|If both i2 and i1 are not 0, the output is 1. Otherwise 0.
|If both a and b are not 0, the output is 1. Otherwise 0.
|-
|-
|OP_BOOLOR
|OP_BOOLOR
|155
|155
|0x9b
|0x9b
|i2 i1
|a b
|Boolean
|out
|If i2 or i1 is not 0, the output is 1. Otherwise 0.
|If a or b is not 0, the output is 1. Otherwise 0.
|-
|-
|OP_NUMEQUAL
|OP_NUMEQUAL
|156
|156
|0x9c
|0x9c
|i2 i1
|a b
|Boolean
|out
|Returns 1 if i2 and i1 are numerically equal, 0 otherwise.
|Returns 1 if the numbers are equal, 0 otherwise.
|-
|-
|OP_NUMEQUALVERIFY
|OP_NUMEQUALVERIFY
|157
|157
|0x9d
|0x9d
|i2 i1
|a b
|Nothing / False
|Nothing / ''fail''
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
|-
|-
Line 853: Line 562:
|158
|158
|0x9e
|0x9e
|i2 i1
|a b
|Boolean
|out
|Returns 1 if i2 and i1 are numerically not equal, 0 otherwise.
|Returns 1 if the numbers are not equal, 0 otherwise.
|-
|-
|OP_LESSTHAN
|OP_LESSTHAN
|159
|159
|0x9f
|0x9f
|i2 i1
|a b
|Boolean
|out
|Returns 1 if i2 is less than stack-top item i1, 0 otherwise.
|Returns 1 if a is less than b, 0 otherwise.
|-
|-
|OP_GREATERTHAN
|OP_GREATERTHAN
|160
|160
|0xa0
|0xa0
|i2 i1
|a b
|Boolean
|out
|Returns 1 if i2 is greater than stack-top item i1, 0 otherwise.
|Returns 1 if a is greater than b, 0 otherwise.
|-
|-
|OP_LESSTHANOREQUAL
|OP_LESSTHANOREQUAL
|161
|161
|0xa1
|0xa1
|i2 i1
|a b
|Boolean
|out
|Returns 1 if i2 is less than or equal to stack-top item i1, 0 otherwise.
|Returns 1 if a is less than or equal to b, 0 otherwise.
|-
|-
|OP_GREATERTHANOREQUAL
|OP_GREATERTHANOREQUAL
|162
|162
|0xa2
|0xa2
|i2 i1
|a b
|Boolean
|out
|Returns 1 if i2 is greater than or equal to stack-top item i1, 0 otherwise.
|Returns 1 if a is greater than or equal to b, 0 otherwise.
|-
|-
|OP_MIN
|OP_MIN
|163
|163
|0xa3
|0xa3
|i2 i1
|a b
|i2 / i1
|out
|Returns the smaller of i2 and i1.
|Returns the smaller of a and b.
|-
|-
|OP_MAX
|OP_MAX
|164
|164
|0xa4
|0xa4
|i2 i1
|a b
|i2 / i1
|out
|Returns the larger of i2 and i1.
|Returns the larger of a and b.
|-
|-
|OP_WITHIN
|OP_WITHIN
|165
|165
|0xa5
|0xa5
|i3 i2 i1
|x min max
|Boolean
|out
|Returns 1 if i3  >= i2 and i3 < i1, 0 otherwise. Thus if i2 > i1 returns always 0.
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.
|}
|}


Line 911: Line 620:
{| class="wikitable"  
{| class="wikitable"  
|-
|-
!Nemonic
!Word
!Decimal
!Opcode
!Hex
!Hex
!Input
!Input
Line 921: Line 630:
|166
|166
|0xa6
|0xa6
|x
|in
|hash20
|hash
|The input is hashed using RIPEMD-160.
|The input is hashed using RIPEMD-160.
|-
|-
Line 928: Line 637:
|167
|167
|0xa7
|0xa7
|x
|in
|hash20
|hash
|The input is hashed using SHA-1.
|The input is hashed using SHA-1.
|-
|-
Line 935: Line 644:
|168
|168
|0xa8
|0xa8
|x
|in
|hash32
|hash
|The input is hashed using SHA-256.
|The input is hashed using SHA-256.
|-
|-
Line 942: Line 651:
|169
|169
|0xa9
|0xa9
|x
|in
|hash20
|hash
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
|-
|-
Line 949: Line 658:
|170
|170
|0xaa
|0xaa
|x
|in
|hash32
|hash
|The input is hashed two times with SHA-256.
|The input is hashed two times with SHA-256.
|-
|-
Line 958: Line 667:
|Nothing
|Nothing
|Nothing
|Nothing
|All of the signature checking opcodes will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
|-
|-
|[[OP_CHECKSIG]]
|[[OP_CHECKSIG]]
Line 964: Line 673:
|0xac
|0xac
|sig pubkey
|sig pubkey
|Boolean
|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 a further, extern specified hash and the given public key. If it is, 1 is returned, 0 otherwise.
|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
|OP_CHECKSIGVERIFY
Line 971: Line 680:
|0xad
|0xad
|sig pubkey
|sig pubkey
|Nothing / False
|Nothing / ''fail''
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
|-
|-
Line 977: Line 686:
|174
|174
|0xae
|0xae
|sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
|Boolean
|True / False
|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.
|Compares the first signature against each public key until it finds an ECDSA match. Starting with the subsequent public key, it compares the second signature against each remaining public key until it finds an ECDSA match. The process is repeated until all signatures have been checked or not enough public keys remain to produce a successful result. All signatures need to match a public key. Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the scriptSig using the same order as their corresponding public keys were placed in the scriptPubKey or redeemScript.  If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.
|-
|-
|OP_CHECKMULTISIGVERIFY
|OP_CHECKMULTISIGVERIFY
|175
|175
|0xaf
|0xaf
|sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>
|Nothing / False
|Nothing / ''fail''
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
|-
|OP_CHECKSIGADD
|186
|0xba
|sig n pub
|out
|Three values are popped from the stack.  The integer n is incremented by one and returned to the stack if the signature is valid for the public key and transaction.  The integer n is returned to the stack unchanged if the signature is the empty vector (OP_0).  In any other case, the script is invalid.  This opcode is only available in tapscript.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki BIP342]</ref>
|}
|}


=== Expansion opcodes ===
=== Locktime ===
{| class="wikitable"
{| class="wikitable"  
|-
|-
!Nemonic
!Word
!Decimal
!Opcode
!Hex
!Hex
!Input
!Output
!Description
!Description
|-
|-
|OP_NOP1-OP_NOP10
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)
|176-185
|177
|0xb0-0xb9
|0xb1
|The opcode has no effect.
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 0065].
|-
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)
|178
|0xb2
|x
|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].
|}
|}


=== Version opcodes ===
 
Version opcodes are disabled since bitcoin 0.2.0 and should not be used (maybe reassigned in the future).
=== Reserved words ===
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.
 
{| class="wikitable"  
{| class="wikitable"  
|-
|-
!Nemonic
!Word
!Decimal
!Opcode
!Hex
!Hex
!Description
!When used...
|-
|OP_RESERVED
|80
|0x50
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|-
|OP_VER
|OP_VER
|98
|98
|0x62
|0x62
|Script evalution is triggered invalid (Formerly pushed the bitcoin-serialize version onto stack).
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|-
|OP_VERIF
|OP_VERIF
|101
|101
|0x65
|0x65
|Script evalution is triggered invalid (Formerly top stack item was popped and =< compared to present version)
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''
|-
|-
|OP_VERNOTIF
|OP_VERNOTIF
|102
|102
|0x66
|0x66
|Script evalution is triggered invalid (Formerly top stack item was popped and > compared to present version)
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''
|}
 
=== 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.
{| class="wikitable"
|-
!Nemonic
!Decimal
!Hex
!Description
|-
|OP_RESERVED
|80
|0x50
|Script evalution is triggered invalid-
|-
|-
|OP_RESERVED1
|OP_RESERVED1
|137
|137
|0x89
|0x89
|Script evalution is triggered invalid.
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|-
|OP_RESERVED2
|OP_RESERVED2
|138
|138
|0x8a
|0x8a
|Script evalution is triggered invalid.
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|}
 
===Pseudo-opcodes===
These nemonics are used internally for assisting with transaction matching. They are invalid if used in actual scripts.
{| class="wikitable"
|-
|-
!Nemonic
|OP_NOP1, OP_NOP4-OP_NOP10
!Decimal
|176, 179-185
!Hex
|0xb0, 0xb3-0xb9
!Description
|The word is ignored. Does not mark transaction as invalid.
|-
|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==
== Script examples ==
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. Currently less than 0.01 % of all txout-scripts / scriptPubKeys in the main block chain are not of the following two standard scripts.
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===
=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===


  scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
  scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Line 1,093: Line 802:
                       Data to push                    OP_EQUALVERIFY OP_CHECKSIG</pre>
                       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 storing transaction, i.e. its "available bitcoins".
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 instruction is processed:
Here is how each word is processed:
{| class="wikitable"  
{| class="wikitable"  
|-
|-
Line 1,131: Line 840:
|}
|}


===Transaction to IP address (and generation transaction)===
=== 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
  scriptPubKey: <pubKey> OP_CHECKSIG
Line 1,156: Line 870:
|}
|}


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.
=== Provably Unspendable/Prunable Outputs ===
 
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:
 
  scriptPubKey: OP_RETURN {zero or more ops}
 
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the [[UTXO|UTXO set]] even if it has not been spent. [http://blockexplorer.com/tx/eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29] is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; [[P2Pool]] does this with the share chain hash txout in the coinbase of blocks it creates.


===Transaction with a message===
=== Freezing funds until a time in the future ===


It's possible to add arbitrary data to any transaction by just adding some data along with OP_DROP.  
Using OP_CHECKLOCKTIMEVERIFY it is possible to make funds provably unspendable until a certain point in the future.
  scriptPubKey: <message> OP_DROP <pubKey> OP_CHECKSIG
 
  scriptSig: <sig>
  scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
  scriptSig: <sig> <pubKey>


{| class="wikitable"  
{| class="wikitable"  
Line 1,171: Line 892:
|-
|-
|Empty.
|Empty.
|<sig> <message> OP_DROP <pubKey> OP_CHECKSIG
| <sig> <pubKey> <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
|
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey> <expiry time>
| OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <expiry time>
| OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG  
| Top stack item is checked against the current time or block height.
|-
|-
|<sig>
|<sig> <pubKey>
|<message> OP_DROP <pubKey> OP_CHECKSIG
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG  
|scriptSig added to the stack.
| Top stack item is removed.
|-
|-
|<sig> <message>
|<sig> <pubKey> <pubKey>
|OP_DROP <pubKey> OP_CHECKSIG
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG  
|The message has been put.
| Top stack item is duplicated.
|-
|-
|<sig>
|<sig> <pubKey> <pubHashA>
|<pubKey> OP_CHECKSIG
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
|Top stack item has been removed.
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|-
|<sig> <pubKey>
|<sig> <pubKey>
|OP_CHECKSIG
|OP_CHECKSIG
|Checking signature against the public key.
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}
 
=== 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
|true
|Empty.
|Empty.
|Stack holds the value of signature check now.
|The hashes are compared, leaving true on the stack.
|}
|}


===Examples of non standard transaction on Testnet===
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.


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


Input non-std transaction:
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.
http://blockexplorer.com/testnet/t/6ttfeb55B1


Spent by:
For example the SHA1 script:
http://blockexplorer.com/testnet/t/AFdRB1CHS3


==Script validation==
scriptPubKey: OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL
A script evaluation is considered invalid, if any of these conditions meets:<br>
  scriptSig: <preimage1> <preimage2>
<ul>
<li>the total size of the script exceeds (currently) 10000 bytes
<li>there are more than (currently) 201 opcodes of opcode value > 0x60 in the script
<li>each instruction is (currently) limited to maximal 520 bytes. This effects only the opcodes OP_PUSHDATA2 and OP_PUSHDATA4
<li>the executed opcode of the script has insufficient input (from stack, from script or from anywhere)
<li>the opcode is not defined (for execution) - indicated by white or light gray background color in the table
<li>the opcode is disabled (currently 15 opcodes) - indicated by white font color in the opcode overview matrix
<li>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)
<li>the opcodes OP_VERIF and OP_NOTVERIF invalidate a script which contains this opcode (even if this opcode is not executed!)
<li>the opcodes OP_ELSE or OP_ENDIF has no matching OP_IF<br>
<li>the script execution has been finished but there is (at least) an unmatched OP_IF<br>
<li>the opcodes OP_VERIFY, OP_EQUALVERIFY, OP_NUMEQUALVERIFY, OP_CHECKSIGVERIFY and OP_CHECKMULTISIGVERIFY invalidate the script if the stack-top item is false
<li>the execution of OP_RETURN
<!--li>alt stack overflow occurs (only possible during execution of OP_TOALTSTACK)-->
<li>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
<li>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)
<li>the number of signature items or the number of public key items on the stack is negative for OP_CHECKMULTISIG or  OP_CHECKMULTISIGVERIFY
<li>there or more signatures items than public key items on the stack for OP_CHECKMULTISIG or  OP_CHECKMULTISIGVERIFY
<li>there are (currently) more than 20 public key items on the stack for OP_CHECKMULTISIG or CHECKMULTISIGVERIFY
<li>the sum of opcodes > 0x60 and the number of public keys in all executed OP_CHECKMULTISIG or CHECKMULTISIGVERIFY exceeds (currently) 201
<li>the script execution has been finished and the stack is empty or the top-stack item is false (numerical value 0)
</ul>
else the script evaluation is considered to be valid.<ref>[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.1/bitcoin-0.7.1-linux.tar.gz file src/src/script.cpp in bitcoin-0.7.1]</ref>
'''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==
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.


<ul>
In February 2017 the SHA1 bounty worth 2.48 bitcoins was claimed.
<li> byte value 0x89 OP_NOTEQUAL  defined in pre-0.1.0 bitcoin versions. Since 0.1.0 removed because of security concerns.
<li> byte value 0xb1 [[BIP 0012 | OP_EVAL]]  withdraw - poll was triggered but insufficient support.
<li> byte value 0xb2 [[BIP 0017 | OP_CHECKHASHVERIFY]]  withdraw - poll was triggered but insufficient support.
</ul>


==See Also==
==See Also==
* [[Transactions]]
* [[Transactions]]
* [[Contracts]]
* [[Contracts]]
== External Links ==
*[https://bitide.qedprotocol.com/ BitIDE] - BitIDE: A web based Bitcoin Script IDE with built in debugger, meta-scripting, virtual op-codes, and local testnet.
*[https://bitcoin.sipa.be/miniscript] - Miniscript: a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more.
*[https://github.com/siminchen/bitcoinIDE Bitcoin IDE] – Bitcoin Script for dummies
*[http://www.crmarsh.com/script-playground/ Script Playground] — convert Script to JavaScript
*[https://bitauth.com/ide BitAuth IDE] — an Integrated Development Environment for Bitcoin Authentication
<sup>(cf. "[http://bitcoin.stackexchange.com/q/42576/4334 Online Bitcoin Script simulator or debugger?]")</sup>


==References==
==References==
<references/>
<references />
<ul>
 
<li>[http://www.zorinaq.com/pub/bitcoin-0.1.0.tgz file src/script.cpp in bitcoin-0.1.0]</li>
</ul>
[[Category:Technical]]
[[Category:Technical]]
[[Category:Vocabulary]]
[[Category:Vocabulary]]
{{Bitcoin Core documentation}}

Latest revision as of 06:29, 2 July 2024

Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is intentionally 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. 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 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.

A transaction is valid if nothing in the combined script triggers failure and the top stack item is True (non-zero) when the script exits. The party that originally sent 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 the combined script completing execution with a true value on the top of the stack.

This document is for information purposes only. De facto, Bitcoin script is defined by the code run by the network to check the validity of blocks.

The stacks hold byte vectors. 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.

Leading zeros in an integer and negative zero are allowed in blocks but get rejected by the stricter requirements which standard full nodes put on transactions before retransmitting them. Byte vectors on the stack are not allowed to be more than 520 bytes long. 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.

Opcodes

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

There are some words which existed in very early versions of Bitcoin but were removed out of concern that the client might have a bug in their implementation. This fear was motivated by a bug found in OP_LSHIFT that could crash any Bitcoin node if exploited and by other bugs that allowed anyone to spend anyone's bitcoins. The removed opcodes are sometimes said to be "disabled", but this is something of a misnomer because there is absolutely no way for anyone using Bitcoin to use these opcodes (they simply do not exist anymore in the protocol), and there are also no solid plans to ever re-enable all of these opcodes. They are listed here for historical interest only.

New opcodes can be added by means of a carefully designed and executed softfork using OP_NOP1-OP_NOP10.

Zero, negative zero (using any number of bytes), and empty array are all treated as false. Anything else is treated as true.

Notation on this page

In the tables below, the inputs and outputs are both described by items as if they were pushed on the stack in that order. So for example, "x1 x2" indicates pushing value x1 on the stack, then x2, such that x1 is at the bottom of the stack, and x2 is at the top. When writing scripts as human-readable opcodes, the push opcodes and the associated data are usually written as <data>. For example, a P2SH script would be written as OP_HASH160 <data> OP_EQUAL, where <data> in this context means the byte 0x20 followed by the 20 bytes of the data itself. You should also ensure that you use the appropriate push instruction if your data is very large. See the table below for details.

Constants

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

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

Flow control

Word Opcode Hex Input Output Description
OP_NOP 97 0x61 Nothing Nothing Does nothing.
OP_IF 99 0x63 <expression> if [statements] [else [statements]]* endif If the top stack value is not False, the statements are executed. The top stack value is removed.
OP_NOTIF 100 0x64 <expression> notif [statements] [else [statements]]* endif If the top stack value is False, the statements are executed. The top stack value is removed.
OP_ELSE 103 0x67 <expression> if [statements] [else [statements]]* endif If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not.
OP_ENDIF 104 0x68 <expression> if [statements] [else [statements]]* endif Ends an if/else block. All blocks must end, or the transaction is invalid. An OP_ENDIF without OP_IF earlier is also invalid.
OP_VERIFY 105 0x69 True / false Nothing / fail Marks transaction as invalid if top stack value is not true. The top stack value is removed.
OP_RETURN 106 0x6a Nothing fail Marks transaction as invalid. Since bitcoin 0.9, a standard way of attaching extra data to transactions is to add a zero-value output with a scriptPubKey consisting of OP_RETURN followed by data. Such outputs are provably unspendable and specially discarded from storage in the UTXO set, reducing their cost to the network. Since 0.12, standard relay rules allow a single output with OP_RETURN, that contains any sequence of push statements (or OP_RESERVED[1]) after the OP_RETURN provided the total scriptPubKey length is at most 83 bytes.

Stack

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

Splice

If any opcode marked as disabled is present in a script, it must abort and fail.

Word Opcode Hex Input Output Description
OP_CAT 126 0x7e x1 x2 out Concatenates two strings. disabled.
OP_SUBSTR 127 0x7f in begin size out Returns a section of a string. disabled.
OP_LEFT 128 0x80 in size out Keeps only characters left of the specified point in a string. disabled.
OP_RIGHT 129 0x81 in size out Keeps only characters right of the specified point in a string. disabled.
OP_SIZE 130 0x82 in in size Pushes the string length of the top element of the stack (without popping it).

Bitwise logic

If any opcode marked as disabled is present in a script, it must abort and fail.

Word Opcode Hex Input Output Description
OP_INVERT 131 0x83 in out Flips all of the bits in the input. disabled.
OP_AND 132 0x84 x1 x2 out Boolean and between each bit in the inputs. disabled.
OP_OR 133 0x85 x1 x2 out Boolean or between each bit in the inputs. disabled.
OP_XOR 134 0x86 x1 x2 out Boolean exclusive or between each bit in the inputs. disabled.
OP_EQUAL 135 0x87 x1 x2 True / false Returns 1 if the inputs are exactly equal, 0 otherwise.
OP_EQUALVERIFY 136 0x88 x1 x2 Nothing / fail Same as OP_EQUAL, but runs OP_VERIFY afterward.

Arithmetic

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

If any input value for any of these commands is longer than 4 bytes, the script must abort and fail. If any opcode marked as disabled is present in a script - it must also abort and fail.

Word Opcode Hex Input Output Description
OP_1ADD 139 0x8b in out 1 is added to the input.
OP_1SUB 140 0x8c in out 1 is subtracted from the input.
OP_2MUL 141 0x8d in out The input is multiplied by 2. disabled.
OP_2DIV 142 0x8e in out The input is divided by 2. disabled.
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. disabled.
OP_DIV 150 0x96 a b out a is divided by b. disabled.
OP_MOD 151 0x97 a b out Returns the remainder after dividing a by b. disabled.
OP_LSHIFT 152 0x98 a b out Shifts a left b bits, preserving sign. disabled.
OP_RSHIFT 153 0x99 a b out Shifts a right b bits, preserving sign. disabled.
OP_BOOLAND 154 0x9a a b out If both a and b are not 0, the output is 1. Otherwise 0.
OP_BOOLOR 155 0x9b a b out If a or b is not 0, the output is 1. Otherwise 0.
OP_NUMEQUAL 156 0x9c a b out Returns 1 if the numbers are equal, 0 otherwise.
OP_NUMEQUALVERIFY 157 0x9d a b Nothing / fail Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
OP_NUMNOTEQUAL 158 0x9e a b out Returns 1 if the numbers are not equal, 0 otherwise.
OP_LESSTHAN 159 0x9f a b out Returns 1 if a is less than b, 0 otherwise.
OP_GREATERTHAN 160 0xa0 a b out Returns 1 if a is greater than b, 0 otherwise.
OP_LESSTHANOREQUAL 161 0xa1 a b out Returns 1 if a is less than or equal to b, 0 otherwise.
OP_GREATERTHANOREQUAL 162 0xa2 a b out Returns 1 if a is greater than or equal to b, 0 otherwise.
OP_MIN 163 0xa3 a b out Returns the smaller of a and b.
OP_MAX 164 0xa4 a b out Returns the larger of a and b.
OP_WITHIN 165 0xa5 x min max out Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.

Crypto

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

Locktime

Word Opcode Hex Input Output Description
OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2) 177 0xb1 x x / fail Marks transaction as invalid if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in BIP 0065.
OP_CHECKSEQUENCEVERIFY (previously OP_NOP3) 178 0xb2 x x / fail Marks transaction as invalid if the relative lock time of the input (enforced by BIP 0068 with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in BIP 0112.


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_VER 98 0x62 Transaction is invalid unless occuring in an unexecuted OP_IF branch
OP_VERIF 101 0x65 Transaction is invalid even when occuring in an unexecuted OP_IF branch
OP_VERNOTIF 102 0x66 Transaction is invalid even when occuring in an unexecuted OP_IF branch
OP_RESERVED1 137 0x89 Transaction is invalid unless occuring in an unexecuted OP_IF branch
OP_RESERVED2 138 0x8a Transaction is invalid unless occuring in an unexecuted OP_IF branch
OP_NOP1, OP_NOP4-OP_NOP10 176, 179-185 0xb0, 0xb3-0xb9 The word is ignored. Does not mark transaction as invalid.

Script examples

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

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

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

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

  76       A9             14
OP_DUP OP_HASH160    Bytes to push

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

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

Here is how each word is processed:

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

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:

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 scriptPubKey of the following form:

 scriptPubKey: OP_RETURN {zero or more ops}

OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; P2Pool does this with the share chain hash txout in the coinbase of blocks it creates.

Freezing funds until a time in the future

Using OP_CHECKLOCKTIMEVERIFY it is possible to make funds provably unspendable until a certain point in the future.

scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
Stack Script Description
Empty. <sig> <pubKey> <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG scriptSig and scriptPubKey are combined.
<sig> <pubKey> <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG Constants are added to the stack.
<sig> <pubKey> <expiry time> OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG Top stack item is checked against the current time or block height.
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG Top stack item is removed.
<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 puzzle

Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.

scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL
scriptSig: 

To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.

Stack Script Description
Empty. OP_HASH256 <given_hash> OP_EQUAL
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 [3] and reddit thread[4] for more details.

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

See Also

External Links

  • BitIDE - BitIDE: A web based Bitcoin Script IDE with built in debugger, meta-scripting, virtual op-codes, and local testnet.
  • [2] - Miniscript: a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more.
  • Bitcoin IDE – Bitcoin Script for dummies
  • Script Playground — convert Script to JavaScript
  • BitAuth IDE — an Integrated Development Environment for Bitcoin Authentication

(cf. "Online Bitcoin Script simulator or debugger?")

References