Bitcoin Script

Bitcoin Script is a small, stack-based programming language. Each output carries a locking script that sets the conditions for spending it. A spend supplies an unlocking script that meets those conditions. A node runs the two together and accepts the spend only when the script ends with a true value on top of the stack.

Script has no loops, so every script finishes in a bounded number of steps. This section explains how the language works, the opcodes you will meet in hex, and the script types built from it.

How does a locking script work?

Every output has a locking script, called the scriptPubKey. It is written when the output is created, and it says what it takes to spend the coins.

To spend the output, a later transaction supplies an unlocking script in its input. Legacy types use the scriptSig, and SegWit and Taproot types use the witness. The node joins the two and runs them as one program.

What is the stack?

The stack is a list that holds data while a script runs. Data is pushed onto the top, and opcodes take items off the top. An opcode can work on the items it takes, then push a result back.

A script is valid when its top item is true, meaning any non-zero value. The usual true value is OP_1. An empty stack, or a false item on top, makes the script invalid.

Nodes also want exactly one item left, so extra items make a spend non-standard. Legacy consensus allows extra items, so such a spend can still be mined, but nodes do not relay it. SegWit and Taproot scripts must leave exactly one true item, as BIP 141 and BIP 342 require.

Which opcodes come up most often?

An opcode is one byte of a script, and each one has a name and a hex value. Data reaches the stack through push opcodes. OP_PUSHBYTES_X (01 to 4b) pushes the next X bytes. OP_PUSHDATA1 (4c), OP_PUSHDATA2 (4d) and OP_PUSHDATA4 (4e) push longer items, with a length field of 1, 2 or 4 bytes. The numbers 0 to 16 have their own opcodes: OP_0 is 00, and OP_1 to OP_16 are 51 to 60.

Nodes also expect the smallest push that fits. A transaction that pushes an item with a longer opcode than needed is not relayed, as BIP 62 sets out.

Opcode	Hex	What it does
OP_0	00	pushes an empty item, the number zero
OP_1 to OP_16	51 to 60	push the numbers 1 to 16
OP_IF	63	runs the next block only if the top item is true
OP_ELSE	67	starts the other branch of an OP_IF
OP_ENDIF	68	ends an OP_IF block
OP_VERIFY	69	fails the script if the top item is false
OP_RETURN	6a	fails the script at once, used by data outputs
OP_DROP	75	removes the top item
OP_DUP	76	copies the top item
OP_SWAP	7c	swaps the top two items
OP_SIZE	82	pushes the byte length of the top item
OP_EQUAL	87	pushes true if the top two items are equal
OP_EQUALVERIFY	88	OP_EQUAL, then OP_VERIFY
OP_ADD	93	adds the top two numbers
OP_RIPEMD160	a6	RIPEMD-160 hash of the top item
OP_SHA256	a8	SHA-256 hash of the top item
OP_HASH160	a9	SHA-256, then RIPEMD-160
OP_HASH256	aa	SHA-256 applied twice
OP_CHECKSIG	ac	checks a signature against a public key
OP_CHECKSIGVERIFY	ad	OP_CHECKSIG, then OP_VERIFY
OP_CHECKMULTISIG	ae	checks m signatures against n public keys
OP_CHECKMULTISIGVERIFY	af	OP_CHECKMULTISIG, then OP_VERIFY
OP_CHECKLOCKTIMEVERIFY	b1	fails unless a locktime has passed
OP_CHECKSEQUENCEVERIFY	b2	fails unless a relative time lock has passed
OP_CHECKSIGADD	ba	adds 1 to a counter when a Taproot signature is valid

How do the two scripts run together?

The unlocking script always runs first, even though the locking script was stored with the output when it was created. Both scripts share one stack. For a SegWit spend, the witness takes the place of the scriptSig.

What limits does Script have?

Script limits apply when a script runs. A locking script that breaks one can still be created, but nobody can ever spend it. The validity limits are these:

Limit	Value
Size of one script	10,000 bytes
Opcodes that are not data pushes	201
Size of one stack item	520 bytes
Items on the stack at once	1,000

Nodes also refuse to relay an unlocking script (scriptSig) longer than 1,650 bytes. A miner can still include such a spend, but it is harder to get mined. These numbers come from script.h and policy.h in Bitcoin Core.

Which script types are there?

Most outputs use one of ten patterns. Each one is a fixed template with its own unlocking data. Nodes relay only outputs and spends that pass their standardness checks. Other scripts are valid, but a node may refuse to relay them, because some untested scripts could take a long time to check. These are the pages of this section, in the order to read them. The simplest comes first.

1. P2PK: the oldest form, locked to a raw public key.
2. P2PKH: locked to the hash of a public key, the classic address that starts with 1.
3. P2MS: bare multisig, where m of n keys must sign.
4. P2SH: locked to the hash of a script, so a custom lock can wait until spend time.
5. P2WPKH: P2PKH moved into the witness, with bech32 addresses that start with bc1q.
6. P2WSH: P2SH for SegWit scripts.
7. P2SH-P2WPKH: P2WPKH wrapped in P2SH, for wallets that cannot send to bech32 addresses.
8. P2SH-P2WSH: P2WSH wrapped in P2SH.
9. P2TR: Taproot, the newest type, with one key and optional script paths.
10. OP_RETURN: a data output that can never be spent.

Before SegWit activated in August 2017, at block 481,824, the standard scripts were P2PK, P2PKH, P2MS, P2SH and OP_RETURN. The SegWit and Taproot types came later, and many new payments use them.

Where should you go next?

Start with the P2PK page, then read the P2PKH page, which is the one you will meet most. To see real script data, open a transaction on our explorer. The transaction f4184fc5... from block 170 pays two P2PK outputs, and the explorer shows them with no address.