How Bitcoin Outputs Work (Locking Scripts)

While transaction inputs represent the past (destroying existing UTXOs), Outputs represent the future. An output creates a new unspent transaction output (UTXO) that sits in the global ledger waiting to be spent by its future owner.

An output is a combination of a currency value and a cryptographic lock.

---

🗃️ The 2 Fields of a Transaction Output

A transaction output consists of exactly two fields serialized into binary:

Field Name	Size (Bytes)	Description
Value	8	The amount of satoshis being sent to this output.
scriptPubKey (Locking Script)	Variable	The cryptographic code that defines what conditions must be met to spend this output.

┌────────────────────────────────────────────────────────┐
│                   TRANSACTION OUTPUT                   │
├───────────────────────────────┬────────────────────────┤
│ Value (8-Byte Uint64 satoshis)│ scriptPubKey           │
│ (8 Bytes)                     │ (Variable)             │
└───────────────────────────────┴────────────────────────┘

---

🔍 Understanding the Output Fields

1. The Value Field (8 Bytes)

Bitcoin's software is built entirely around integer math. There are no decimals in raw Bitcoin transactions. * The Value field is an 8-byte (64-bit) unsigned integer representing the amount in Satoshis. * $1 \text{ Satoshi} = 0.00000001 \text{ BTC}$. * When you send 1.5 BTC, the transaction output is serialized as 150000000 satoshis. * An 8-byte integer can store values up to $18.44\text{ billion}$ BTC. Bitcoin's hard cap of 21 million BTC fits comfortably inside this variable limit, preventing overflow bugs.

2. scriptPubKey (Locking Script)

The scriptPubKey is the lock. It is a sequence of operation codes (Opcodes) written in Bitcoin’s programming language, Script.

---

🔒 Common Types of scriptPubKey Locking Scripts

The Bitcoin protocol supports several standardized locking script patterns:

1. P2PKH (Pay-to-Public-Key-Hash) — Legacy

This is the standard legacy address pattern (addresses starting with 1). * The Script: OP_DUP OP_HASH160 <20-Byte-PubKey-Hash> OP_EQUALVERIFY OP_CHECKSIG * The Lock: It hashes the receiver's public key. To spend these coins, the receiver must reveal their public key and provide a signature proving they own the private key.

2. P2SH (Pay-to-Script-Hash) — Multisig / Escrows

Introduced in 2012 (addresses starting with 3), P2SH shifts the burden of complex scripts from the sender to the receiver. * The Script: OP_HASH160 <20-Byte-RedeemScript-Hash> OP_EQUAL * The Lock: Instead of locking to a public key, the coins are locked to the hash of a custom script (the Redeem Script). When spending, the receiver reveals the Redeem Script (e.g., a 2-of-3 multisig lock) and satisfies its conditions.

3. P2WPKH (Pay-to-Witness-Public-Key-Hash) — Native SegWit

The standard modern SegWit address format (Bech32 addresses starting with bc1q). * The Script: OP_0 <20-Byte-PubKey-Hash> * The Lock: A cleaner, more efficient script format that removes signature validation data from the main block to the witness section, saving weight and reducing fees.

4. OP_RETURN — The Null Data Output

OP_RETURN is a special output used to record arbitrary data on the blockchain. * The Script: OP_RETURN <Up to 80 Bytes of Data> * The Lock: By beginning with OP_RETURN, the script is declared provably unspendable by consensus. Because these outputs can never be spent, nodes do not need to keep them in their RAM (UTXO Set). They can prune them to disk, allowing developers to timestamp data (like document hashes) without bloat!