Mastering Bitcoin: Understanding Transactions and the UTXO Model

Bitcoin transactions are the lifeblood of the network, serving as the fundamental mechanism for value transfer. Every aspect of Bitcoin—from mining to wallet design—is built around ensuring that transactions can be created, propagated, verified, and permanently recorded on the blockchain. At their core, transactions are data structures that encode the movement of value between participants. Each transaction becomes a public entry in the global ledger, forming an immutable chain of ownership.

In this chapter, we explore how transactions work under the hood: their structure, creation, validation, and role in maintaining the blockchain. When we refer to a "wallet," we mean the software responsible for constructing transactions—not just a key storage system.

Transaction Structure: Inputs, Outputs, and Script Logic

The Anatomy of a Bitcoin Transaction

A typical transaction consists of inputs and outputs. Inputs reference previously unspent transaction outputs (UTXOs), proving ownership through cryptographic signatures. Outputs define new UTXOs—bitcoins locked with conditions that must be met to spend them.

Consider Alice paying Bob for coffee. A blockchain explorer might show a simple transfer from Alice’s address to Bob’s. But behind this simplified view lies a more complex reality: addresses and balances don’t exist in the raw transaction data. Instead, what you see is reconstructed by higher-level applications.

Here’s a decoded version of Alice’s transaction:

{
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
      "vout": 0,
      "scriptSig": "30450221...[ALL] 0484ecc...",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.01500000,
      "scriptPubKey": "OP_DUP OP_HASH160 ab6802... OP_EQUALVERIFY OP_CHECKSIG"
    },
    {
      "value": 0.08450000,
      "scriptPubKey": "OP_DUP OP_HASH160 7f9b1a... OP_EQUALVERIFY OP_CHECKSIG"
    }
  ]
}

You won’t find Alice’s or Bob’s addresses here. Instead, you see scripts—cryptographic puzzles that control access to funds.

👉 Discover how wallets build secure transactions from raw UTXOs

Unspent Transaction Outputs (UTXOs)

The UTXO model is central to Bitcoin’s design. Each output represents a discrete amount of bitcoin—measured in satoshis (1 BTC = 100,000,000 satoshis)—that can only be spent entirely. Once consumed, it disappears from the UTXO set and new outputs are created.

When your wallet shows a “balance,” it’s summing all UTXOs you can spend using your private keys. This balance isn’t stored on-chain; it’s computed dynamically by scanning the blockchain.

If you want to spend 1 BTC but only have a 2 BTC UTXO, your transaction must consume the full 2 BTC and create two outputs:

• One sending 1 BTC to the recipient
• Another returning 1 BTC as change to your wallet

This change output ensures leftover funds remain accessible.

Transaction Inputs: Spending UTXOs

Each input references a specific UTXO via:

• txid: The ID of the transaction that created the UTXO
• vout: The index of the output within that transaction

It also includes a scriptSig—a script satisfying the spending conditions set in the original output’s scriptPubKey. Most commonly, this includes a digital signature and public key.

Inputs do not contain the value or locking conditions of the referenced UTXO. To verify a transaction, nodes must retrieve the referenced UTXO from the blockchain to check its value and script.

Serialized Format: How Transactions Travel

Transactions are serialized before being broadcast across the network. Serialization converts structured data into a byte stream for efficient transmission and hashing.

Output Serialization

Input Serialization

Transaction Fees: Incentives and Prioritization

Fees incentivize miners to include transactions in blocks. They’re calculated based on transaction size (in vB), not value. Larger transactions—like those with many inputs—require higher fees.

Fees are implied:

Fee = Sum(All Inputs) – Sum(All Outputs)

No explicit fee field exists. If inputs exceed outputs, the difference goes to the miner.

Wallets typically estimate fees using real-time mempool data. For example:

curl https://bitcoinfees.21.co/api/v1/fees/recommended
{"fastestFee":80,"halfHourFee":80,"hourFee":60}

This returns recommended fees in sat/vB:

• 80 sat/vB: Likely confirmed in next block
• 60 sat/vB: Expected within six blocks

A median-sized transaction (~226 bytes) at 80 sat/vB costs about 18,080 satoshis (0.0001808 BTC).

⚠️ Warning: Forgetting to add a change output means the leftover amount becomes a fee. “Keep the change!” might not be your intention.

👉 Learn how fee estimation impacts confirmation speed

Bitcoin Script: The Language of Ownership

Bitcoin uses a stack-based scripting language called Script, inspired by Forth. It enables programmable money by allowing flexible spending conditions.

Key Features of Script

• Not Turing-complete: No loops or infinite execution paths
• Stateless execution: All required data is included in the script
• Predictable runtime: Prevents denial-of-service attacks during validation

Each transaction validates ownership by combining:

• Locking script (scriptPubKey): Set when creating a UTXO
• Unlocking script (scriptSig): Provided when spending it

Nodes execute both scripts together. If the final stack evaluates to TRUE, the input is valid.

Pay-to-Public-Key-Hash (P2PKH)

Most Bitcoin transactions use P2PKH. The locking script looks like:

OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

To spend it, provide:

<Signature> <Public Key>

Execution steps:

1. Push public key and signature onto stack
2. Duplicate public key (OP_DUP)
3. Hash it (OP_HASH160) and compare to stored hash
4. Verify signature matches public key (OP_CHECKSIG)

Only someone with the private key can generate a valid signature.

Digital Signatures (ECDSA): Proving Ownership Without Revealing Secrets

Bitcoin uses ECDSA (Elliptic Curve Digital Signature Algorithm) for signing transactions.

How ECDSA Works

1. A hash of the transaction (or part of it) is created
2. Using the private key, a signature (R, S) is generated
3. Anyone can verify the signature using the public key

Signatures are encoded using DER (Distinguished Encoding Rules). Example:

30450221...[ALL]

• 30: DER sequence start
• 45: Length (69 bytes)
• 02: Integer marker
• 21: R length (33 bytes)
• R value
• 02: Next integer
• 20: S length (32 bytes)
• S value
• 01: SIGHASH_ALL flag

SIGHASH Flags: Controlling What’s Signed

Different SIGHASH types allow granular control over what parts of a transaction are signed:

Combinations like ALL|ANYONECANPAY enable crowdfunding: contributors sign one input while leaving room for others.

🔐 Tip: Always use deterministic k-values (RFC 6979) when generating signatures. Reusing k exposes your private key.

From Raw Data to User-Friendly Abstractions

Blockchain explorers and wallets create familiar concepts like “addresses” and “balances” from raw transaction data.

An address like 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa is derived by:

1. Taking a public key
2. Hashing it with SHA-256 then RIPEMD-160
3. Applying Base58Check encoding

“Balances” are computed by summing all UTXOs linked to your public key hashes.

These abstractions simplify interaction but hide complexity. Most tools assume standard P2PKH scripts and SIGHASH_ALL. Non-standard transactions may appear confusing or even invalid in basic interfaces—but they’re often perfectly valid and powerful.

Frequently Asked Questions (FAQ)

Q: What is a UTXO?
A: A UTXO (Unspent Transaction Output) is a discrete unit of bitcoin that hasn’t been spent yet. It represents spendable value locked by a script.

Q: Why does my wallet show an address if it's not in the transaction?
A: Addresses are derived from public key hashes found in locking scripts. Wallets decode these hashes into readable addresses using Base58Check.

Q: How are transaction fees calculated?
A: Fees = Total Inputs – Total Outputs. They’re measured in satoshis per virtual byte (sat/vB) and influence confirmation speed.

Q: Can I create custom spending conditions?
A: Yes! Bitcoin Script supports multi-signature wallets, time-locked contracts, and more through custom locking scripts.

Q: What happens if I don’t include a change output?
A: The excess funds become a transaction fee—paid entirely to the miner.

Q: Are all Bitcoin transactions peer-to-peer transfers?
A: Not necessarily. Many support advanced use cases like escrow, atomic swaps, or decentralized finance via smart contract-like scripts.

👉 Explore advanced transaction types and scripting capabilities