ScriptPubKey (Output Script)

What Is ScriptPubKey?

A scriptPubKey (also called an output script, locking script, or pubkey script) is the field in a Bitcoin transaction output that specifies the conditions required to spend the bitcoins it contains. Every UTXO in Bitcoin carries a scriptPubKey that functions as a lock: anyone who wants to spend those funds must provide the correct key in the form of a matching unlocking script.

ScriptPubKey is written in Bitcoin Script, a stack-based, intentionally non-Turing-complete programming language. The language has no loops, making scripts provably finite in execution. When a transaction attempts to spend a UTXO, nodes evaluate the unlocking data against the scriptPubKey. If the combined execution leaves a true (non-zero) value on the stack, the spend is authorized.

The scriptPubKey pattern determines which type of Bitcoin address corresponds to the output. Over Bitcoin's history, several standard patterns have emerged: from the original P2PKH to the modern P2TR (Taproot) format, each improving on efficiency, privacy, or functionality.

How It Works

Every Bitcoin transaction output contains two fields: a value (the amount in satoshis) and a scriptPubKey (the spending conditions). When someone creates a new transaction that spends a UTXO, they must reference the previous transaction by its txid and output index, then provide unlocking data that satisfies the scriptPubKey.

Legacy Validation (P2PKH and P2SH)

For legacy transaction types, the unlocking data is placed in the scriptSig field of the transaction input. Validation follows a two-step process:

1. The scriptSig executes first, leaving data (such as a signature and public key) on the stack
2. The referenced output's scriptPubKey then executes using the values left on the stack by the scriptSig
3. If the scriptPubKey evaluates to true, the spend is valid. If false or if any operation triggers failure, the transaction is rejected

SegWit Validation (P2WPKH and P2WSH)

Segregated Witness transactions moved unlocking data out of the scriptSig and into a separate witness field. Nodes identify a witness program by recognizing a specific scriptPubKey pattern: a version byte (OP_0 for version 0) followed by a data push of 2 to 40 bytes. The scriptSig must be empty for native witness outputs.

This separation fixed transaction malleability and introduced a fee discount for witness data: each witness byte counts as only 0.25 weight units, compared to 1.0 for non-witness bytes.

Taproot Validation (P2TR)

Taproot outputs use witness version 1. The scriptPubKey contains an OP_1 version byte followed by a 32-byte tweaked public key. Spending can occur through two paths: a key-path spend using a single Schnorr signature, or a script-path spend that reveals one branch of a Merklized script tree along with a proof.

Common ScriptPubKey Patterns

Bitcoin has five standard scriptPubKey patterns in active use today. Each pattern defines a different lock structure and corresponds to a specific address format.

P2PKH: Pay-to-Public-Key-Hash

P2PKH was the original standard transaction type. The scriptPubKey contains a hash of the recipient's public key, and the spender must provide both the full public key and a valid signature.

# ScriptPubKey (25 bytes)
OP_DUP OP_HASH160 <20-byte pubkey hash> OP_EQUALVERIFY OP_CHECKSIG

# Hex pattern
76a914<20-byte-hash>88ac

# ScriptSig (unlocking)
<signature> <public_key>

The hash algorithm is RIPEMD-160(SHA-256(pubkey)), commonly called HASH160. P2PKH addresses use Base58Check encoding with version byte 0x00 and start with "1".

P2SH: Pay-to-Script-Hash

P2SH, defined in BIP 16 and activated in 2012, enabled arbitrary spending conditions by hashing a redeem script. The sender only needs the script hash, not the full script. This made multisig wallets practical for everyday use.

# ScriptPubKey (23 bytes)
OP_HASH160 <20-byte script hash> OP_EQUAL

# Hex pattern
a914<20-byte-hash>87

# ScriptSig (unlocking)
<signatures...> <serialized redeem script>

Validation is two-phase: first the redeem script is hashed and compared to the scriptPubKey hash, then the redeem script itself executes with the remaining stack items. P2SH addresses start with "3" and use Base58Check with version byte 0x05. Redeem scripts are limited to 520 bytes.

P2WPKH: Pay-to-Witness-Public-Key-Hash

P2WPKH, introduced with SegWit (BIP 141) in 2017, is the witness equivalent of P2PKH. The scriptPubKey is minimal: just a version byte and a 20-byte hash. All unlocking data moves to the witness field.

# ScriptPubKey (22 bytes)
OP_0 <20-byte pubkey hash>

# Hex pattern
0014<20-byte-hash>

# Witness (unlocking)
<signature> <compressed public key>

P2WPKH requires compressed public keys only (33 bytes) and uses Bech32 address encoding. Addresses start with "bc1q" and are 42 characters long.

P2WSH: Pay-to-Witness-Script-Hash

P2WSH is the witness equivalent of P2SH. It uses a 32-byte SHA-256 hash (instead of the 20-byte HASH160 used by P2SH), providing 128-bit collision resistance compared to P2SH's 80-bit level.

# ScriptPubKey (34 bytes)
OP_0 <32-byte script hash>

# Hex pattern
0020<32-byte-hash>

# Witness (unlocking)
<script inputs...> <witness script>

Witness scripts can be up to 10,000 bytes, far exceeding the 520-byte limit for P2SH redeem scripts. P2WSH addresses also use Bech32 encoding and start with "bc1q", but are 62 characters long.

P2TR: Pay-to-Taproot

P2TR, activated in November 2021 via BIPs 340, 341, and 342, represents the current state of the art. The scriptPubKey contains a 32-byte x-only tweaked public key (omitting the y-coordinate parity byte used in compressed keys).

# ScriptPubKey (34 bytes)
OP_1 <32-byte tweaked x-only pubkey>

# Hex pattern
5120<32-byte-key>

# Key-path spend (witness)
<64-byte Schnorr signature>

# Script-path spend (witness)
<script inputs> <leaf script> <control block>

Key-path spends are indistinguishable on-chain from simple single-signature transactions, even when the underlying key was constructed through multi-party aggregation. Script-path spends reveal only the branch used, keeping alternative conditions private. P2TR addresses use Bech32m encoding (BIP 350) and start with "bc1p".

Script Types and Address Formats

The scriptPubKey pattern directly determines the address format used to represent an output. An address is simply an encoded form of the scriptPubKey data that humans can share.

Base58Check encoding uses a 58-character alphabet that excludes visually ambiguous characters (0, O, I, l). Bech32 and Bech32m are case-insensitive and include error-detection codes. Bech32m (BIP 350) corrected a checksum vulnerability in original Bech32 for witness versions 1 and above.

The Evolution of ScriptPubKey

Bitcoin's scriptPubKey patterns have evolved through four generations, each addressing limitations of the previous design. For a comprehensive walkthrough, see the Bitcoin address types deep dive.

• P2PK (2009): Satoshi's original design placed the full public key directly in the scriptPubKey. This exposed the public key before spending and produced large outputs (35 to 67 bytes).
• P2PKH (2009): replaced raw public keys with hashes, reducing scriptPubKey size to 25 bytes and hiding the public key until spend time.
• P2SH (2012): enabled arbitrary spending conditions by committing to a hash of the full script. This shifted complexity from the output to the input and made multisig wallets practical.
• SegWit v0 (2017): moved unlocking data to a separate witness field, fixing transaction malleability and introducing fee discounts. Upgraded the script hash from 160-bit to 256-bit for P2WSH.
• Taproot (2021): introduced Schnorr signatures, x-only public keys, and Merklized script trees (MAST). Complex spending conditions became indistinguishable from single-sig transactions on-chain.

As of 2025, SegWit v0 outputs account for the majority of transactions, with Taproot usage growing steadily. All five generations of scriptPubKey remain valid and spendable on the network.

Use Cases

Standard Payments

The most common use of scriptPubKey is simple value transfer. A sender creates an output with a P2WPKH or P2TR scriptPubKey locked to the recipient's public key hash. The recipient later spends it by providing their signature and public key in the witness field.

Multisig and Threshold Spending

P2SH and P2WSH scriptPubKey patterns enable multisig wallets where m-of-n signatures are required to spend. With Taproot, threshold spending can use FROST or MuSig2 key aggregation in the key-path, making multisig outputs look identical to single-sig on-chain.

Time-Locked Outputs

ScriptPubKey can incorporate OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY to enforce time-based spending conditions. These opcodes are used in Lightning Network HTLCs, vault designs, and inheritance schemes.

Data Embedding

OP_RETURN scriptPubKey patterns create provably unspendable outputs that embed up to 80 bytes of arbitrary data. This is used for timestamping, asset protocols, and anchoring external data to the blockchain without polluting the UTXO set.

Programmable Spending Policies

Advanced users can define complex spending policies using Miniscript and output descriptors to generate scriptPubKey patterns with multiple conditions, fallback paths, and timelocked recovery options. Taproot script trees allow committing to many such conditions while only revealing the one used at spend time.

Risks and Considerations

Address Reuse and Privacy

Reusing the same scriptPubKey (receiving to the same address repeatedly) creates a privacy risk. It links multiple transactions to the same entity and, for P2PKH and P2WPKH, exposes the public key after the first spend. Modern wallets generate fresh addresses for each transaction using HD wallet derivation to mitigate this.

Public Key Exposure

P2PKH and P2WPKH hide the public key behind a hash until spend time, providing a theoretical buffer against future quantum computing attacks. P2TR stores the public key directly in the scriptPubKey, trading this buffer for efficiency and privacy gains. The practical quantum threat to secp256k1 remains distant, but it is worth understanding the tradeoff.

Script Complexity and Standardness

While Bitcoin Script allows many scriptPubKey patterns, nodes enforce "standardness" rules that restrict which patterns they will relay in unconfirmed transactions. Non-standard scripts can still be mined directly by cooperating miners but will not propagate through the mempool under default policy. This distinction matters for anyone designing custom spending conditions.

Forward Compatibility

Witness versions 2 through 16 are reserved for future upgrades. Sending funds to an unknown witness version creates an output that anyone can spend under current consensus rules (the "anyone-can-spend" softfork upgrade mechanism). Wallets should only generate scriptPubKey patterns they fully understand.

For a deeper look at how scriptPubKey fits into the broader transaction lifecycle, see the Bitcoin transaction lifecycle explainer and the Bitcoin Script programmability guide.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.