Script - Bitcoin Wiki (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.

Flow control

Stack

Splice

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

Bitwise logic

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

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.

Crypto

Locktime

Reserved words

Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction 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 bracketsand 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_CHECKSIGscriptSig: <sig> <pubKey>

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

 76 A9 14OP_DUP OP_HASH160 Bytes to push89 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:

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_CHECKSIGscriptSig: <sig>

Checking process:

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_CHECKSIGscriptSig: <sig> <pubKey>

Transaction puzzle

Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.

scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUALscriptSig: 

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

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_EQUALscriptSig: <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

• Transactions
• Contracts

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