An Introduction to Bitcoin Script

Key Takeaways

Bitcoin Script is the stack-based programming language that governs how transactions are validated on the Bitcoin network, defining the conditions under which funds can be spent.
Script uses a system of opcodes (instructions) and data elements processed in a stack structure, where the scriptPubKey (lock) and scriptSig (key) combine to validate whether a transaction is authorized.
Taproot (activated November 2021) introduced Schnorr signatures and Tapscript, enabling more private and efficient complex transactions through Merklized Alternative Script Trees (MAST).
Bitcoin Script is intentionally limited (not Turing-complete) to prioritize security and predictability, though proposals like OP_CAT (BIP 347) aim to expand its expressiveness for advanced use cases.

Introduction

Bitcoin is sometimes referred to as programmable money. Because of its digital nature, it allows users a degree of flexibility when it comes to setting conditions for how funds can be spent.

When discussing Bitcoin, discussions often revolve around wallets and coins. But try thinking of wallets as keys, coins as checks, and the blockchain as row after row of locked safes. Each safe has a thin slot in it, such that anyone can deposit checks or look in to see how much value the safe holds. However, only the key holder will be able to access the inside.

In this article, let's look at Script, the programming language interpreted by nodes on the Bitcoin network. Script is what governs the locking and unlocking mechanism for Bitcoin transactions.

How Does Bitcoin Work?

There are two parts to every transaction: a key (to unlock your funds) and a lock. You use your key to open the box that contains the check you want to send, and then you add a fresh one to a new box with a different lock. To spend from the new box, you need another key.

Some locks require that you provide multiple keys, and others need you to prove that you know a secret. There are various conditions that users can set.

The key is what we call a scriptSig. The lock is the scriptPubKey. Looking at those components in more detail, you'll find that they are made up of bits of data and blocks of code. When combined, they create a small program.

When you make a transaction, you broadcast that combination to the network. Each node that receives it checks the program to determine whether the transaction is valid. If not, it is discarded, and you cannot spend the locked funds.

The funds you hold are called unspent transaction outputs (UTXOs). Anyone that can provide the key that fits the lock can use them. Specifically, the key is the scriptSig and the lock is the scriptPubKey.

If the UTXOs are in your wallet, they likely have a condition that says: only the person who can prove ownership of this public key can unlock these funds. To unlock it, you provide a scriptSig that includes a digital signature, using the private key that maps to the public key specified in the scriptPubKey.

Understanding the Bitcoin Stack

Script is what is known as a stack-based language. This means that when you read a set of instructions, you can thinkk of them as being placed in a vertical column. The list A, B, C, for example, would result in a stack with A at the bottom and C at the top. When the instructions tell you to do something, you can operate on one or more elements beginning at the top of the stack.

Elements A, B, and C being added and “popped” from the stack.

Pay-to-Pubkey (P2PK)

Pay-to-Pubkey (P2PK) is the simplest script type. It involves locking funds to a particular public key. If you wanted to receive funds in this manner, you would provide the sender with your public key rather than a Bitcoin address.

The very first transaction between Satoshi Nakamoto and Hal Finney in 2009 was a P2PK transaction. The structure was heavily used in the early days of Bitcoin, but nowadays, Pay-to-Pubkey-Hash (P2PKH) has largely replaced it.

The locking script for a P2PK transaction follows the format:

<public key> OP_CHECKSIG.

The OP_CHECKSIG opcode checks for a signature against the provided public key. The scriptSig is simply the sender's <signature>.

A signature gets added to the stack, followed by a public key. OP_CHECKSIG pops them both and verifies the signature against the public key. If they match, it adds a <1> to the stack. Otherwise, it adds a <0>

Pay-to-Pubkey-Hash (P2PKH)

Pay-to-Pubkey-Hash (P2PKH) is the most common legacy transaction type. The scriptPubKey is:

OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG.

The key opcodes work as follows:

OP_DUP: duplicates the top element on the stack.
OP_HASH160: hashes the top element with SHA-256 followed by RIPEMD-160.
OP_EQUALVERIFY: checks that the top two elements match, failing the transaction if they do not.

check that the public key matches the hash in the script

The scriptSig for P2PKH requires both a signature and the corresponding public key. The public key is hashed and compared against the hash in the scriptPubKey.

In a P2PKH locking script, the public key is not visible until the funds are spent. This provides a layer of privacy and could offer some additional protection against quantum computing attacks, since the public key is only revealed at the moment of spending.

Pay-to-Script-Hash (P2SH)

Pay-to-Script-Hash (P2SH) allows the sender to lock funds to the hash of a script without needing to know what the script actually does. The spender must provide the script (called the redeemScript) that matches the hash and satisfy the conditions within that script.

The scriptPubKey for P2SH is:

OP_HASH160 <redeemScript hash> OP_EQUAL.

The scriptSig typically includes signatures, public keys, and the redeemScript itself.

End of this mini-program, and the top element is non-zero. Validity confirmed.
The elements preceding the redeemScript are not used at this point. The mini-program has come to an end, and the top element is non-zero. That means it’s valid.

However, that doesn't mean you're fully done. Network nodes recognize this structure as P2SH, so they’ve actually got the scriptSig’s elements waiting in another stack. That’s where the signature and public key will be used.

So far, the redeemScript has been used as an element. But now, it’ll be interpreted as instructions, which could be anything. Let’s take the example of a P2PKH locking script, to which we must provide the <signature> and <public key> that matches a <public key hash> inside the <redeemScript>.

Once your redeemScript has been expanded, you can see that we have a situation that looks exactly like a regular P2PKH transaction.

Once your redeemScript has been expanded, you can see that we have a situation that looks exactly like a regular P2PKH transaction. From there, you can run it as you would a normal one.

P2SH is particularly useful for complex spending conditions like multisignature wallets and SegWit-compatible transactions. With P2SH, it does not matter how complex the spending conditions are. The redeemScript hash is always of a fixed size, and the costs are passed onto the user who unlocks the funds rather than the sender.

SegWit Transactions (P2WPKH and P2WSH)

SegWit (Segregated Witness) was a soft fork that changed the transaction format by introducing a new field called the witness. The data previously stored in the scriptSig is moved to the witness, leaving the scriptSig empty.

Pay-to-Witness-Pubkey-Hash (P2WPKH)

P2WPKH is the SegWit version of P2PKH. The witness contains the signature and public key. The scriptPubKey is:

<OP_0> <public key hash>.

Nodes that understand SegWit recognize this format and validate it like a P2PKH transaction. Non-upgraded nodes see an empty scriptSig and some data, which they mark as valid, making SegWit backward-compatible.

Pay-to-Witness-Script-Hash (P2WSH)

P2WSH is the SegWit version of P2SH. The witness contains the elements that would normally be in the scriptSig, and the scriptPubKey is: <OP_0> <script hash>. SegWit nodes determine the script type by the length of the hash and validate accordingly.

SegWit addresses begin with "bc1q" (bech32 format) and provide fee savings because witness data receives a weight discount.

Taproot and the Evolution of Bitcoin Script (2021-2025)

Taproot (BIPs 340-342), activated in November 2021, introduced the most significant upgrade to Bitcoin Script since SegWit. It brought three key innovations: Schnorr signatures (BIP 340), Pay-to-Taproot outputs (P2TR, BIP 341), and Tapscript (BIP 342), a new script version used inside P2TR.

How P2TR works

A P2TR output (identified by bech32m addresses starting with "bc1p") can be spent in two ways:

Key path spend: uses a single Schnorr signature against the internal public key. On-chain, this looks identical to a simple single-signature spend regardless of how many parties are involved (if using key aggregation like MuSig2).
Script path spend (Tapscript): reveals one branch of a Merklized Alternative Script Tree (MAST). Only the executed condition is exposed, while other possible spending paths remain hidden.

Why Taproot matters

Taproot provides several advantages for Bitcoin programmability that bring it closer to smart contract functionality:

Privacy: complex multisig setups and simple single-sig transactions look identical on-chain when using key-path spending.
Efficiency: multisig transactions that would previously require revealing all public keys and signatures can be compressed into a single Schnorr signature through key aggregation.
Flexibility: MAST allows embedding multiple spending conditions in a Merkle tree, revealing only the path that is used.

Future proposals: OP_CAT and beyond

The Bitcoin development community continues to discuss expanding Script's capabilities. BIP 347 proposes reintroducing OP_CAT for Tapscript, which would concatenate the top two stack items. This relatively simple operation could enable more expressive constructions including covenant-like contracts that restrict how coins may be spent, Merkle proof verification inside scripts, and advanced vault designs for institutional custody.

Script Type Summary

The main Bitcoin Script types in use today include:

Pay-to-Pubkey (P2PK): locks funds to a public key directly. Rarely used since early Bitcoin.
Pay-to-Pubkey-Hash (P2PKH): locks funds to a public key hash (a Bitcoin address). The original standard transaction type.
Pay-to-Script-Hash (P2SH): locks funds to a script hash. The recipient provides the full script when spending.
Pay-to-Witness-Pubkey-Hash (P2WPKH): the SegWit version of P2PKH with witness data separated.
Pay-to-Witness-Script-Hash (P2WSH): the SegWit version of P2SH.
Pay-to-Taproot (P2TR): the Taproot output type supporting key-path spends (Schnorr) and script-path spends (Tapscript with MAST).

FAQ

What is Bitcoin Script?

Bitcoin Script is the stack-based programming language used to define and validate transaction conditions on the Bitcoin network. It determines the rules for how funds can be spent by combining opcodes (instructions) and data elements that evaluate to either True (valid) or False (invalid).

Is Bitcoin Script Turing-complete?

No. Bitcoin Script is intentionally not Turing-complete. It lacks loops and has limited operations, which prevents infinite execution and reduces the attack surface. This design choice prioritizes security and predictability over general-purpose programmability.

What is the difference between scriptSig and scriptPubKey?

The scriptPubKey is the locking script that defines the conditions required to spend funds. The scriptSig is the unlocking script that provides the data (like signatures and public keys) needed to satisfy those conditions. When combined and executed, they must evaluate to True for the transaction to be valid.

What is Tapscript?

Tapscript is the script system used inside Taproot (P2TR) script-path spends. It is defined by BIP 342 and introduces modified rules compared to legacy Script, including support for Schnorr signatures and new opcode versioning that allows future upgrades without hard forks.

Why are there so many script types?

Each script type represents an evolution in Bitcoin's capabilities. P2PKH improved on P2PK by adding privacy through hashing. P2SH enabled complex spending conditions without burdening senders. SegWit reduced fees and fixed transaction malleability. Taproot added privacy, efficiency, and more expressive scripting. Each remains valid on the network for backward compatibility.

Closing Thoughts

Bitcoin Script provides the foundation for all transaction validation on the Bitcoin network. From simple single-signature payments to complex multi-party contracts, the scripting system defines what is possible within Bitcoin's consensus rules.

Understanding the progression from P2PK through P2TR illustrates how Bitcoin's programmability has evolved while maintaining its core security properties.