https://en.bitcoin.it/w/api.php?action=feedcontributions&user=MarkBLundeberg&feedformat=atomBitcoin Wiki - User contributions [en]2021-10-17T09:33:28ZUser contributionsMediaWiki 1.30.0https://en.bitcoin.it/w/index.php?title=Difficulty&diff=67046Difficulty2019-11-25T05:11:52Z<p>MarkBLundeberg: expand on target signedness / byte order</p>
<hr />
<div>''See also: [[target]]''<br />
<br />
=== What is "difficulty"? ===<br />
<br />
Difficulty is a measure of how difficult it is to find a hash below a given target.<br />
<br />
The Bitcoin network has a global block difficulty. Valid blocks must have a hash below this target.<br />
Mining pools also have a pool-specific share difficulty setting a lower limit for shares.<br />
<br />
=== How often does the network difficulty change? ===<br />
<br />
Every 2016 [[block|blocks]].<br />
<br />
=== What is the formula for difficulty? ===<br />
<br />
difficulty = difficulty_1_target / current_target <br />
<br />
(target is a 256 bit number)<br />
<br />
difficulty_1_target can be different for various ways to measure difficulty.<br />
Traditionally, it represents a hash where the leading 32 bits are zero and the rest are one (this is known as "pool difficulty" or "pdiff").<br />
The Bitcoin protocol represents targets as a custom floating point type with limited precision; as a result, Bitcoin clients often approximate difficulty based on this (this is known as "bdiff").<br />
<br />
===How is difficulty stored in blocks?===<br />
<br />
Each block stores a packed representation (called "Bits") for its actual hexadecimal [[target]]. The target can be derived from it via a predefined formula. For example, if the packed target in the block is 0x1b0404cb (stored in little-endian order: <code>cb 04 04 1b</code>), the hexadecimal target is<br />
0x0404cb * 2**(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000<br />
<br />
Note that this packed format contains a sign bit in the 24th bit, and for example the negation of the above target would be 0x1b<b>8</b>404cb in packed format. Since targets are never negative in practive, however, this means the largest legal value for the lower 24 bits is 0x7fffff. Additionally, 0x008000 is the smallest legal value for the lower 24 bits since targets are always stored with the lowest possible exponent.<br />
<br />
===How is difficulty calculated? What is the difference between bdiff and pdiff?===<br />
<br />
The highest possible target (difficulty 1) is defined as 0x1d00ffff, which gives us a hex target of<br />
0x00ffff * 2**(8*(0x1d - 3)) = 0x00000000FFFF0000000000000000000000000000000000000000000000000000<br />
<br />
It should be noted that pooled mining often uses non-truncated targets, which puts "pool difficulty 1" at<br />
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
<br />
So the difficulty at 0x1b0404cb is therefore:<br />
0x00000000FFFF0000000000000000000000000000000000000000000000000000 /<br />
0x00000000000404CB000000000000000000000000000000000000000000000000 <br />
= 16307.420938523983 (bdiff)<br />
And:<br />
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF /<br />
0x00000000000404CB000000000000000000000000000000000000000000000000 <br />
= 16307.669773817162 (pdiff)<br />
<br />
Here's a fast way to calculate bitcoin difficulty. It uses a modified Taylor series for the logarithm (you can see tutorials on flipcode and wikipedia) and relies on logs to transform the difficulty calculation:<br />
<br />
<source lang="cpp"><br />
#include <iostream><br />
#include <cmath><br />
<br />
inline float fast_log(float val)<br />
{<br />
int * const exp_ptr = reinterpret_cast <int *>(&val);<br />
int x = *exp_ptr;<br />
const int log_2 = ((x >> 23) & 255) - 128;<br />
x &= ~(255 << 23);<br />
x += 127 << 23;<br />
*exp_ptr = x;<br />
<br />
val = ((-1.0f/3) * val + 2) * val - 2.0f/3;<br />
return ((val + log_2) * 0.69314718f);<br />
} <br />
<br />
float difficulty(unsigned int bits)<br />
{<br />
static double max_body = fast_log(0x00ffff), scaland = fast_log(256);<br />
return exp(max_body - fast_log(bits & 0x00ffffff) + scaland * (0x1d - ((bits & 0xff000000) >> 24)));<br />
}<br />
<br />
int main()<br />
{<br />
std::cout << difficulty(0x1b0404cb) << std::endl;<br />
return 0;<br />
}<br />
</source><br />
<br />
To see the math to go from the normal difficulty calculations (which require large big ints bigger than the space in any normal integer) to the calculation above, here's some python:<br />
<br />
<source lang="python"><br />
import decimal, math<br />
l = math.log<br />
e = math.e<br />
<br />
print 0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3)))<br />
print l(0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3))))<br />
print l(0x00ffff * 2**(8*(0x1d - 3))) - l(0x0404cb * 2**(8*(0x1b - 3)))<br />
print l(0x00ffff) + l(2**(8*(0x1d - 3))) - l(0x0404cb) - l(2**(8*(0x1b - 3)))<br />
print l(0x00ffff) + (8*(0x1d - 3))*l(2) - l(0x0404cb) - (8*(0x1b - 3))*l(2)<br />
print l(0x00ffff / float(0x0404cb)) + (8*(0x1d - 3))*l(2) - (8*(0x1b - 3))*l(2)<br />
print l(0x00ffff / float(0x0404cb)) + (0x1d - 0x1b)*l(2**8)<br />
</source><br />
<br />
=== What is the current difficulty? ===<br />
[http://blockexplorer.com/q/getdifficulty Current difficulty], as output by Bitcoin's getDifficulty.<br />
<br />
[http://bitcoin.sipa.be Graphs]<br />
<br />
=== What is the maximum difficulty? ===<br />
<br />
There is no minimum target. The maximum difficulty is roughly: maximum_target / 1 (since 0 would result in infinity), which is a ridiculously huge number (about 2^224).<br />
<br />
The actual maximum difficulty is when current_target=0, but we would not be able to calculate the difficulty if that happened. (fortunately it never will, so we're ok.)<br />
<br />
=== Can the network difficulty go down? ===<br />
Yes it can. See discussion in [[target]].<br />
<br />
=== What is the minimum difficulty? ===<br />
The minimum difficulty, when the target is at the maximum allowed value, is 1.<br />
<br />
=== What network hash rate results in a given difficulty? ===<br />
The difficulty is adjusted every 2016 blocks based on the [[Block_timestamp|time]] it took to find the previous 2016 blocks. At the desired rate of one block each 10 minutes, 2016 blocks would take exactly two weeks to find. If the previous 2016 blocks took more than two weeks to find, the difficulty is reduced. If they took less than two weeks, the difficulty is increased. The change in difficulty is in proportion to the amount of time over or under two weeks the previous 2016 blocks took to find.<br />
<br />
To find a block, the hash must be less than the target. The hash is effectively a random number between 0 and 2**256-1. The offset for difficulty 1 is<br />
0xffff * 2**208<br />
and for difficulty D is<br />
(0xffff * 2**208)/D<br />
<br />
The expected number of hashes we need to calculate to find a block with difficulty D is therefore<br />
D * 2**256 / (0xffff * 2**208)<br />
or just<br />
D * 2**48 / 0xffff<br />
<br />
The difficulty is set such that the previous 2016 blocks would have been found at the rate of one every 10 minutes, so we were calculating (D * 2**48 / 0xffff) hashes in 600 seconds. That means the hash rate of the network was<br />
D * 2**48 / 0xffff / 600<br />
over the previous 2016 blocks. Can be further simplified to<br />
D * 2**32 / 600<br />
without much loss of accuracy.<br />
<br />
At difficulty 1, that is around 7 Mhashes per second.<br />
<br />
At the time of writing, the difficulty is 22012.4941572, which means that over the previous set of 2016 blocks found the average network hash rate was<br />
22012.4941572 * 2**32 / 600 = around 157 Ghashes per second.<br />
<br />
=== How soon might I expect to generate a block? ===<br />
(The [https://www.bitcointalk.org/index.php?topic=1682.0 eternal question].)<br />
<br />
The average time to find a block can be approximated by calculating:<br />
time = difficulty * 2**32 / hashrate<br />
where difficulty is the current difficulty, hashrate is the number of hashes your miner calculates per second, and time is the average in seconds between the blocks you find.<br />
<br />
For example, using Python we calculate the average time to generate a block using a 1Ghash/s mining rig when the difficulty is 20000:<br />
$ python -c "print 20000 * 2**32 / 10**9 / 60 / 60.0"<br />
23.85<br />
and find that it takes just under 24 hours on average.<br />
<br />
* Any one grinding of the hash stands the same chance of "winning" as any other. The numbers game is how many attempts your hardware can make per second.<br />
* You need to know the difficulty (above) and your khash/sec rate (reported by the client).<br />
** [[Mining Hardware Comparison]] has some stats that may help you predict what you could get.<br />
* Visit a calculator or perform the maths yourself,<br />
** http://www.alloscomp.com/bitcoin/calculator.php<br />
** http://www.vnbitcoin.org/bitcoincalculator.php<br />
** https://bitknock.com/calculator<br />
**https://99bitcoins.com/bitcoin-mining-calculator<br />
* Remember it's just probability! There are no guarantees you will win every N days.<br />
<br />
==Related Links==<br />
<br />
* [https://docs.google.com/spreadsheet/ccc?key=0AiFMBvXvL2dtdEZkR2J4eU5rS3B4ei1iUmJxSWNlQ0E Bitcoin Difficulty History]<br />
* [https://www.bitcoinmining.com/what-is-bitcoin-mining-difficulty/ What is Bitcoin Mining Difficulty?]<br />
* See also: [[target]]<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]<br />
<br />
[[pl:Trudność]]</div>MarkBLundeberghttps://en.bitcoin.it/w/index.php?title=NLockTime&diff=66983NLockTime2019-11-06T16:15:49Z<p>MarkBLundeberg: Clarify that nLockTime cannot equal to the height of the block in which it is mined, and that the MTP is based on prior blocks only.</p>
<hr />
<div>{{stub}}<br />
<br />
'''nLockTime''' is a parameter of a transaction, that, if any input indicates so (by having nSequence not equal to UINT_MAX), mandates a minimal time (specified in either unix time or block height), before which the transaction cannot be accepted into a block. If all inputs in a transaction have nSequence equal to UINT_MAX, then nLockTime is ignored.<br />
<br />
* If <code>nLockTime < 500000000</code><br />
** Specifies the block number after which this transaction can be included in a block.<br />
* Otherwise<br />
** Specifies the UNIX timestamp after which this transaction can be included in a block.<br />
<br />
Note that since the adoption of BIP 113, the time-based nLockTime is compared to the 11-block [[median time past]] (the median timestamp of the 11 blocks preceding the block in which the transaction is mined), and not the block time itself. The median time past tends to lag the current unix time by about one hour (give or take), but unlike block time it increases monotonically.<br />
<br />
For transaction relay, nLockTime must be <= the current block's height (block-based) or <= the current median time past (if time based). This ensures that the transaction can be included in the next block.<br />
<br />
==See Also==<br />
* lock_time in [[Protocol_specification#tx|the protocol specification]]<br />
* [[Timelock]]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP113]<br />
* The CHECKLOCKTIMEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]<br />
<br />
[[Category:Technical]]<br />
{{lowercase}}</div>MarkBLundeberghttps://en.bitcoin.it/w/index.php?title=Timelock&diff=66982Timelock2019-11-06T16:02:34Z<p>MarkBLundeberg: expand history of nLockTime, also note that block N can only contain transactions with nlocktime *strictly less* than N.</p>
<hr />
<div>A '''Timelock''' is a type of smart contract primitive that restricts the spending of some bitcoins until a specified future time or block height. Timelocks feature prominently in many Bitcoin [[Contracts|smart contracts]], including [[payment channels]] and [[Hashed Timelock Contracts|hashed timelock contracts]]. It can also be used to lock-up bitcoins held as an investment for a period of months or years. Time lock is also used to make [[fee sniping]] less profitable, and for [[Techniques_to_reduce_transaction_fees#Pre-computed_fee_bumping|trustless precomputed fee bumping]].<br />
<br />
== Primitives ==<br />
<br />
=== nLockTime ===<br />
<br />
''Main article: [[nLockTime]]''<br />
<br />
In the original Bitcoin release, nodes would not relay nor mine transactions with nLockTime equal to or greater than the current block height (unless all inputs' sequence numbers were 0xffffffff), however they would accept blocks containing transactions with any value of nLockTime. In Bitcoin 0.1.6, the interpretation of nLockTime was adjusted to also allow time-based locking.<ref>https://github.com/bitcoin/bitcoin/commit/dd519206a684c772a4a06ceecc87c665ad09d8be#diff-23cfe05393c8433e384d2c385f06ab93R406</ref> Then, starting from block 31001 (December of 2009), the nLockTime restrictions were activated as a rule that also applied to block acceptance.<ref>https://github.com/bitcoin/bitcoin/commit/dd519206a684c772a4a06ceecc87c665ad09d8be#diff-118fcbaaba162ba17933c7893247df3aR1222</ref> Later, in July of 2016, the time based locks were changed to operate on the [[median time past]] instead of the block's timestamp.<ref>https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki</ref><br />
<br />
Although every transaction contains the nLockTime field, every wallet up until recently set nLockTime to <code>0</code>, meaning the transaction was valid in any block. Starting with [[Bitcoin Core]] 0.11.0, every normal transaction automatically generated by began including an nLockTime set to a recent block height as a way to make hypothesized [[fee sniping]] less profitable<ref name="anti_fee_sniping"/>; other wallets are recommended to do the same. Approximately 20% of all bitcoin transactions set a nLockTime value different from zero<ref>https://p2sh.info/dashboard/db/blocks-statistics?panelId=4&fullscreen&orgId=1</ref> as of early-2019.<br />
<br />
=== CheckLockTimeVerify ===<br />
<br />
In late 2015, the BIP65 soft fork<ref name="bip65"/> redefined the NOP2 opcode as the [[CheckLockTimeVerify]] (CLTV) opcode, allowing transaction outputs (rather than whole transactions) to be encumbered by a timelock. When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or greater than the time parameter provided to the CLTV opcode. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block.<br />
<br />
CLTV is currently used in [[CLTV-style payment channels]].<br />
<br />
=== Relative locktime ===<br />
<br />
In mid-2016, the BIP68/112/113 soft fork gave consensus-enforced meaning to some values in the [[nSequence]] field<ref name="bip68"/> that is a part of every transaction input, creating a "relative locktime"{{citation needed}}. This allowed an input to specify the earliest time it can be added to a block based on how long ago the output being spent by that input was included in a block on the block chain.<br />
<br />
=== CheckSequenceVerify ===<br />
<br />
Also part of the BIP68/112/113 soft fork was the [[CheckSequenceVerify]] opcode<ref name="bip112"/>, which provides for relative locktime the same feature CLTV provides for absolute locktime. When the CSV opcode is called, it will cause the script to fail unless the nSequence on the transaction indicates an equal or greater amount of relative locktime has passed than the parameter provided to the CSV opcode. Since an input may only be included in a valid block if its relative locktime is expired, this ensures the CSV-based timelock has expired before the transaction may be included in a valid block.<br />
<br />
CSV is used by [[Lightning Network]] transactions.<br />
<br />
== Far-future locks ==<br />
<br />
It is not advised to lock up bitcoins into the far future because it takes on risk of the bitcoin network changing. For example, if there were an ECDSA or RIPEMD160 algorithm break that made any coins spendable with a few months of CPU time, the network might need to to prohibit moving old unspent coins after some transition, but long locktimed coins could not make such a transition.<br />
<br />
OP_CheckSequenceVerify allows locking for at most 65535 blocks (about 455 days) or for at most 65535*512 seconds (about 388 days). OP_CheckLockTimeVerify could be used to lock up coins for several centuries.<br />
<br />
== See Also ==<br />
<br />
* [https://coinb.in/#newTimeLocked coinb.in's time-locked page] javascript page for creating time-locked bitcoin wallets.<br />
* [https://www.reddit.com/r/Bitcoin/comments/4p4klg/bitcoin_core_project_the_csv_soft_fork_has/d4i01he/ Reddit discussion of the possible uses OP_CHECKSEQUENCEVERIFY]<br />
<br />
== References ==<br />
<references><br />
<ref name="bip65">[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: OP_CHECKLOCKTIMEVERIFY]<br>Peter Todd<br>Retrieved 2016-04-12</ref><br />
<ref name="bip68">[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Relative lock-time using consensus-enforced sequence numbers]<br>Mark Friedenbach, BtcDrak, Nicolas Dorier, and kinoshitajona<br>Retrieved 2016-04-12</ref><br />
<ref name="bip112">[https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112: CHECKSEQUENCEVERIFY]<br>BtcDrak, Mark Friedenbach, Eric Lombrozo<br>Retrieved 2016-04-12</ref><br />
<ref name="anti_fee_sniping">[https://bitcoin.org/en/release/v0.11.0 Bitcoin Core 0.11.0 release notes]<br>Bitcoin.org<br>Retrieved 2016-11-06</ref><br />
</references><br />
<br />
[[Category:Technical]]</div>MarkBLundeberghttps://en.bitcoin.it/w/index.php?title=NLockTime&diff=66969NLockTime2019-10-24T14:51:36Z<p>MarkBLundeberg: emphasise it's at-or-after</p>
<hr />
<div>{{stub}}<br />
<br />
'''nLockTime''' is a parameter of a transaction, that, if any input indicates so (by having nSequence not equal to UINT_MAX), mandates a minimal time (specified in either unix time or block height), before which the transaction cannot be accepted into a block. If all inputs in a transaction have nSequence equal to UINT_MAX, then nLockTime is ignored.<br />
<br />
* If <code>nLockTime < 500000000</code><br />
** Specifies the block number at (or after) which this transaction can be spent.<br />
* Otherwise<br />
** Specifies the UNIX timestamp at (or after) which this transaction can be spent.<br />
<br />
Note that since the adoption of BIP 113, the time-based nLockTime is compared to the 11-block [[median time past]], and not the block time itself. The median time past tends to lag the current unix time by about one hour (give or take), but unlike block time it increases monotonically.<br />
<br />
==See Also==<br />
* lock_time in [[Protocol_specification#tx|the protocol specification]]<br />
* [[Timelock]]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP113]<br />
* The CHECKLOCKTIMEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]<br />
<br />
[[Category:Technical]]<br />
{{lowercase}}</div>MarkBLundeberghttps://en.bitcoin.it/w/index.php?title=NLockTime&diff=66968NLockTime2019-10-24T14:48:51Z<p>MarkBLundeberg: This page was erroneously attributing sequence lock time mechanics to the lock time. Fixed, and expanded regarding BIP 113.</p>
<hr />
<div>{{stub}}<br />
<br />
'''nLockTime''' is a parameter of a transaction, that, if any input indicates so (by having nSequence not equal to UINT_MAX), mandates a minimal time (specified in either unix time or block height), before which the transaction cannot be accepted into a block. If all inputs in a transaction have nSequence equal to UINT_MAX, then nLockTime is ignored.<br />
<br />
* If <code>nLockTime < 500000000</code><br />
** Specifies the block number at which this transaction can be spent.<br />
* Otherwise<br />
** Specifies the UNIX timestamp at which this transaction can be spent.<br />
<br />
Note that since the adoption of BIP 113, the time-based nLockTime is compared to the 11-block [[median time past]], and not the block time itself. The median time past tends to lag the current unix time by about one hour (give or take), but unlike block time it increases monotonically.<br />
<br />
==See Also==<br />
* lock_time in [[Protocol_specification#tx|the protocol specification]]<br />
* [[Timelock]]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP113]<br />
* The CHECKLOCKTIMEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]<br />
<br />
[[Category:Technical]]<br />
{{lowercase}}</div>MarkBLundeberghttps://en.bitcoin.it/w/index.php?title=Script&diff=66580Script2019-06-16T04:40:10Z<p>MarkBLundeberg: revert 22:55, 31 January 2018 by Bram ; the original was correct.</p>
<hr />
<div>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.<br />
<br />
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<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to prove ownership of the private key corresponding to the public key just provided.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
The stacks hold byte vectors.<br />
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.<br />
Thus 0x81 represents -1.<br />
0x80 is another representation of zero (so called negative 0).<br />
Positive 0 is represented by a null-length vector.<br />
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.<br />
<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.<br />
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.<br />
<br />
== Opcodes ==<br />
This is a list of all Script words, also known as opcodes, commands, or functions.<br />
<br />
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.<br />
<br />
New opcodes can be added by means of a carefully designed and executed [[softfork]] using OP_NOP1-OP_NOP10.<br />
<br />
False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not False, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> notif [statements] [else [statements]]* endif<br />
|If the top stack value is False, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|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. <br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without OP_IF earlier is also '''invalid'''.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / ''fail''<br />
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.<br />
|-<br />
|[[OP_RETURN]]<br />
|106<br />
|0x6a<br />
|Nothing<br />
|''fail''<br />
|'''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.<br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
If any opcode marked as disabled is present in a script, it must abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Concatenates two strings. ''disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Pushes the string length of the top element of the stack (without popping it).<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
If any opcode marked as disabled is present in a script, it must abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|Nothing / ''fail''<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script must abort and fail. <br />
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is multiplied by b. ''disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|Nothing / ''fail''<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|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.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|Nothing / ''fail''<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|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.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|Nothing / ''fail''<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
=== Locktime ===<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)<br />
|177<br />
|0xb1<br />
|x<br />
|x / ''fail''<br />
|'''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].<br />
|-<br />
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)<br />
|178<br />
|0xb2<br />
|x<br />
|x / ''fail''<br />
|'''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].<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VER<br />
|98<br />
|0x62<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1, OP_NOP4-OP_NOP10<br />
|176, 179-185<br />
|0xb0, 0xb3-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
== Script examples ==<br />
The following is a list of interesting scripts.<br />
When notating scripts, data to be pushed to the stack is generally enclosed in angle brackets<br />
and data push commands are omitted.<br />
Non-bracketed words are opcodes.<br />
These examples include the “OP_” prefix, but it is permissible to omit it.<br />
Thus<br />
“<pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG”<br />
may be abbreviated to<br />
“<pubkey1> <pubkey2> 2 CHECKMULTISIG”.<br />
Note that there is a small number of standard script forms that are relayed from node to node;<br />
non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Obsolete pay-to-pubkey transaction ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key.<br />
This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced.<br />
scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core.<br />
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.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
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. [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.<br />
<br />
=== Freezing funds until a time in the future ===<br />
<br />
Using OP_CHECKLOCKTIMEVERIFY it is possible to make funds provably unspendable until a certain point in the future.<br />
<br />
scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey> <expiry time><br />
| OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <expiry time><br />
| OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is checked against the current time or block height.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is removed.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
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.<br />
<br />
=== Incentivized finding of hash collisions ===<br />
<br />
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.<br />
<br />
For example the SHA1 script:<br />
<br />
scriptPubKey: OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL<br />
scriptSig: <preimage1> <preimage2><br />
<br />
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.<br />
<br />
In February 2017 the SHA1 bounty worth 2.48 bitcoins was claimed.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
== External Links ==<br />
*[https://github.com/siminchen/bitcoinIDE Bitcoin IDE] – Bitcoin Script for dummies<br />
*[https://webbtc.com/script Bitcoin Debug Script Execution] – web tool which executes a script opcode-by-opcode<br />
*[http://www.crmarsh.com/script-playground/ Script Playground] — convert Script to JavaScript<br />
*[https://bitauth.com/ide BitAuth IDE] — an Integrated Development Environment for Bitcoin Authentication<br />
<sup>(cf. "[http://bitcoin.stackexchange.com/q/42576/4334 Online Bitcoin Script simulator or debugger?]")</sup><br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]<br />
<br />
{{Bitcoin Core documentation}}</div>MarkBLundeberghttps://en.bitcoin.it/w/index.php?title=Script&diff=66293Script2019-03-27T16:10:43Z<p>MarkBLundeberg: update description of OP_RETURN (was out-of-date since early 2016!)</p>
<hr />
<div>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.<br />
<br />
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<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to prove ownership of the private key corresponding to the public key just provided.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
The stacks hold byte vectors.<br />
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.<br />
Thus 0x81 represents -1.<br />
0x80 is another representation of zero (so called negative 0).<br />
Positive 0 is represented by a null-length vector.<br />
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.<br />
<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.<br />
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.<br />
<br />
== Opcodes ==<br />
This is a list of all Script words, also known as opcodes, commands, or functions.<br />
<br />
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.<br />
<br />
New opcodes can be added by means of a carefully designed and executed [[softfork]] using OP_NOP1-OP_NOP10.<br />
<br />
False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not False, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> notif [statements] [else [statements]]* endif<br />
|If the top stack value is False, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|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. <br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without OP_IF earlier is also '''invalid'''.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / ''fail''<br />
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.<br />
|-<br />
|[[OP_RETURN]]<br />
|106<br />
|0x6a<br />
|Nothing<br />
|''fail''<br />
|'''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.<br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
If any opcode marked as disabled is present in a script, it must abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Concatenates two strings. ''disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Pushes the string length of the top element of the stack (without popping it).<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
If any opcode marked as disabled is present in a script, it must abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|Nothing / ''fail''<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script must abort and fail. <br />
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is multiplied by b. ''disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not "" (null string), the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not "" (null string), the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|Nothing / ''fail''<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|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.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|Nothing / ''fail''<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|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.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|Nothing / ''fail''<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
=== Locktime ===<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)<br />
|177<br />
|0xb1<br />
|x<br />
|x / ''fail''<br />
|'''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].<br />
|-<br />
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)<br />
|178<br />
|0xb2<br />
|x<br />
|x / ''fail''<br />
|'''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].<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VER<br />
|98<br />
|0x62<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1, OP_NOP4-OP_NOP10<br />
|176, 179-185<br />
|0xb0, 0xb3-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
== Script examples ==<br />
The following is a list of interesting scripts.<br />
When notating scripts, data to be pushed to the stack is generally enclosed in angle brackets<br />
and data push commands are omitted.<br />
Non-bracketed words are opcodes.<br />
These examples include the “OP_” prefix, but it is permissible to omit it.<br />
Thus<br />
“<pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG”<br />
may be abbreviated to<br />
“<pubkey1> <pubkey2> 2 CHECKMULTISIG”.<br />
Note that there is a small number of standard script forms that are relayed from node to node;<br />
non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Obsolete pay-to-pubkey transaction ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key.<br />
This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced.<br />
scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core.<br />
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.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
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. [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.<br />
<br />
=== Anyone-Can-Spend Outputs ===<br />
<br />
Conversely a transaction can be made spendable by anyone at all:<br />
<br />
scriptPubKey: (empty)<br />
scriptSig: OP_TRUE<br />
<br />
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.<br />
<br />
Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.<br />
<br />
=== Freezing funds until a time in the future ===<br />
<br />
Using OP_CHECKLOCKTIMEVERIFY it is possible to make funds provably unspendable until a certain point in the future.<br />
<br />
scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey> <expiry time><br />
| OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <expiry time><br />
| OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is checked against the current time or block height.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is removed.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
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.<br />
<br />
=== Incentivized finding of hash collisions ===<br />
<br />
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.<br />
<br />
For example the SHA1 script:<br />
<br />
scriptPubKey: OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL<br />
scriptSig: <preimage1> <preimage2><br />
<br />
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.<br />
<br />
In February 2017 the SHA1 bounty worth 2.48 bitcoins was claimed.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
== External Links ==<br />
*[https://github.com/siminchen/bitcoinIDE Bitcoin IDE] – Bitcoin Script for dummies<br />
*[https://webbtc.com/script Bitcoin Debug Script Execution] – web tool which executes a script opcode-by-opcode<br />
*[http://www.crmarsh.com/script-playground/ Script Playground] — convert Script to JavaScript<br />
*[https://bitauth.com/ide BitAuth IDE] — an Integrated Development Environment for Bitcoin Authentication<br />
<sup>(cf. "[http://bitcoin.stackexchange.com/q/42576/4334 Online Bitcoin Script simulator or debugger?]")</sup><br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]<br />
<br />
{{Bitcoin Core documentation}}</div>MarkBLundeberg