How Bitcoin Transactions Work: UTXOs, Scripts & the Blockchain
Understanding how Bitcoin transactions work is essential for anyone evaluating cryptocurrency as an asset class, payment rail, or technology investment. Unlike traditional banking systems that track account balances, Bitcoin uses a fundamentally different model: the blockchain records individual transaction outputs that can only be spent once. This guide covers the UTXO model, Bitcoin Script, block structure, network consensus mechanisms, and how transactions achieve finality.
The UTXO Model vs Account-Based Model
Bitcoin does not maintain account balances the way a bank does. Instead, it tracks unspent transaction outputs (UTXOs) — discrete chunks of bitcoin that can be spent in future transactions.
A UTXO (Unspent Transaction Output) is like an unspent check made out to you. Each check has a specific amount, and when you spend it, you must use the entire check — sending any excess back to yourself as change.
In the account-based model used by banks (and Ethereum), the system tracks a single running balance per account. Debits and credits adjust that balance. In the UTXO model, there is no running balance — only a collection of unspent outputs that your private keys can unlock.
Why does Bitcoin use UTXOs? The model enables efficient verification. Nodes maintain the current UTXO set (disk-backed with caching), allowing them to quickly check whether a transaction input references a valid, unspent output. There’s no need to replay the entire transaction history — just look up the referenced output in the current UTXO set.
How a Bitcoin Transaction Moves Through the Network
Before diving into the technical components, it helps to understand the end-to-end lifecycle of a Bitcoin transaction:
- Wallet creates the transaction: Your wallet software selects one or more UTXOs as inputs (totaling at least the amount you want to send) and specifies the outputs (recipient address and amount, plus a change output back to yourself).
- Transaction is signed: For each input, your wallet uses the corresponding private key to create a digital signature. This proves you control the UTXOs being spent.
- Broadcast to the network: The signed transaction is sent to connected Bitcoin nodes, which validate it and propagate it to their peers.
- Transaction enters the mempool: Valid transactions wait in the memory pool (mempool) of each node until a miner includes them in a block.
- Miner includes transaction in a block: Miners select transactions from their mempool, bundle them into a candidate block, and compete to find a valid proof-of-work.
- Block is mined and propagated: Once a miner finds a valid block, it’s broadcast to the network. Nodes verify the block and add it to their copy of the blockchain.
- Confirmations accumulate: Each subsequent block added on top of your transaction’s block counts as an additional confirmation. More confirmations mean higher confidence in finality.
Transaction Anatomy: Inputs, Outputs, and Change
Every Bitcoin transaction consists of inputs and outputs. Understanding this structure is fundamental to how the system works.
Inputs are references to previous transaction outputs that you’re spending. Each input contains:
- A transaction ID (hash of the prior transaction)
- An output index (which output from that transaction)
- A scriptSig (unlocking script — in legacy transactions, contains signature and public key; in SegWit/Taproot transactions, this field is empty and signatures go in a separate witness structure)
Outputs specify where the bitcoin goes. Each output contains:
- A value (amount in satoshis)
- A scriptPubKey (locking script specifying conditions for spending)
The sum of outputs must be less than or equal to the sum of inputs. The difference is the transaction fee, collected by the miner who includes the transaction in a block.
Suppose you have a UTXO worth 3 BTC and want to send 1 BTC to a merchant:
| Component | Amount | Destination |
|---|---|---|
| Input | 3.0000 BTC | (your UTXO being spent) |
| Output 1 | 1.0000 BTC | Merchant’s address |
| Output 2 | 1.9999 BTC | Your change address |
| Implied fee | 0.0001 BTC | Miner |
You must consume the entire 3 BTC input — you can’t partially spend it. The 1.9999 BTC goes back to an address you control.
Bitcoin Script: Stack-Based and Non-Turing-Complete
Bitcoin transactions are validated using a simple scripting language called Bitcoin Script. This language determines under what conditions a UTXO can be spent.
Key characteristics of Bitcoin Script:
- Stack-based: Operations push and pop values from a stack (similar to Forth or PostScript)
- Non-Turing-complete: No loops or recursion — scripts always terminate
- 256 opcodes: One byte each; some are disabled or reserved
Why is Bitcoin Script intentionally limited? Because miners must execute every script to validate transactions. A Turing-complete language would allow infinite loops, enabling denial-of-service attacks. By keeping scripts simple and terminating, Bitcoin ensures predictable validation times.
To spend a UTXO, the spender provides a scriptSig (unlocking script) that, when concatenated with the UTXO’s scriptPubKey (locking script) and executed, must evaluate to true. If execution succeeds, the spend is valid; if it errors, the transaction is rejected.
Pay-to-PubKey-Hash (P2PKH)
The most common legacy transaction type is Pay-to-PubKey-Hash (P2PKH). While modern transactions increasingly use SegWit and Taproot formats, P2PKH illustrates how Bitcoin Script works.
A P2PKH output’s locking script (scriptPubKey) looks like:
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
To unlock this output, the spender provides a scriptSig containing their signature and public key:
<signature> <publicKey>
The execution flow:
- Push signature onto stack
- Push public key onto stack
OP_DUP: Duplicate the public keyOP_HASH160: Hash the duplicate (SHA-256, then RIPEMD-160)- Push the expected pubKeyHash from the locking script
OP_EQUALVERIFY: Check that the computed hash matches; fail if notOP_CHECKSIG: Verify the signature against the full transaction
Other script types include P2SH (Pay-to-Script-Hash) for multisig and complex conditions, P2WPKH (SegWit), and P2TR (Taproot). Each has different characteristics, but all follow the same fundamental pattern: a locking script that specifies spending conditions and an unlocking script that satisfies them.
Block Structure: Header, Merkle Root, Nonce
Bitcoin’s blockchain is a chain of blocks, each containing a batch of transactions. Understanding block structure is essential to understanding transaction finality.
Each block has two main components:
Block Header (80 bytes, the only part hashed during mining):
- Version: Protocol version
- Previous block hash: Hash pointer to the prior block header
- Merkle root: Root hash of the Merkle tree of all transactions in this block
- Timestamp: Approximate block creation time
- Bits: Difficulty target
- Nonce: Value miners adjust to find a valid hash
Transaction List: All transactions in the block, organized into a Merkle tree. The Merkle root in the header commits to this entire list.
The first transaction in every block is the coinbase transaction — a special transaction that creates new bitcoin. Unlike regular transactions, the coinbase has one input with a null previous outpoint (not referencing any prior UTXO). Its output value equals the block reward (which halves approximately every four years) plus the sum of all transaction fees in the block.
The Genesis Block
Block 0, the genesis block, was mined by Satoshi Nakamoto on January 3, 2009. Its coinbase transaction includes a famous embedded message:
“The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”
This headline from The Times of London serves two purposes: it timestamps the genesis block (proving it wasn’t pre-mined before that date) and provides commentary on the financial system Bitcoin was designed to operate alongside.
The genesis block’s 50 BTC reward is unspendable — whether by design or due to a quirk in the original code is debated. The address (1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa) has received additional bitcoin over the years from users sending symbolic tributes.
Hard Forks vs Soft Forks
Bitcoin’s rules can evolve over time, but changing a decentralized protocol is complex. Two types of upgrades exist: hard forks and soft forks.
Hard Fork
- Expands the set of valid blocks/transactions
- Previously invalid things become valid
- Old nodes reject new-style blocks
- Creates permanent chain split if not all nodes upgrade
- Examples: adding new opcodes, increasing block size
Soft Fork
- Restricts the set of valid blocks/transactions
- Previously valid things may become invalid
- Old nodes still accept upgraded blocks
- No permanent split if upgraded miners have majority hashpower
- Examples: P2SH, SegWit
The key distinction: in a soft fork, upgraded blocks remain valid under old rules, so non-upgraded nodes follow the same chain. In a hard fork, upgraded blocks violate old rules, causing non-upgraded nodes to fork onto a separate chain.
P2SH (Pay-to-Script-Hash) was introduced as a soft fork. Old nodes validated the basic hash check but didn’t perform the second-stage redemption script validation that upgraded nodes enforce. Because upgraded blocks remained valid under old rules (they just applied stricter checks), both old and new nodes converged on the same longest chain.
SPV Clients: Lightweight Verification
Not every Bitcoin user runs a full node. SPV (Simplified Payment Verification) allows lightweight clients to verify transactions without downloading the entire blockchain.
| Characteristic | Full Node | SPV Client |
|---|---|---|
| Storage required | Hundreds of GB (full blockchain) | ~80 MB+ (headers only, 80 bytes each) |
| Validates | Every transaction and block fully | Header chain PoW + Merkle inclusion (not full script validation) |
| Knows UTXO set | Yes | No |
| Trust model | Trustless (verifies everything) | Trusts that miners validated blocks |
SPV clients download only block headers and request Merkle proofs for their transactions. A Merkle proof is a path of hashes (O(log n) in block size) proving a transaction is included in a block’s Merkle tree. The client verifies the proof against the Merkle root in the header, confirming inclusion without seeing every transaction.
Many mobile wallets advertise as “SPV” but actually rely on trusted servers (like Electrum servers) rather than pure peer-to-peer SPV. True SPV clients connect directly to the Bitcoin network; server-based wallets trade some trust assumptions for convenience.
Legacy P2PKH Address Generation
This section covers how legacy P2PKH addresses (starting with “1”) are generated. Other address types — P2SH (“3”), SegWit (“bc1q”), and Taproot (“bc1p”) — use different derivation paths.
The pipeline for generating a legacy Bitcoin address:
- Generate a private key: A random 256-bit scalar on the secp256k1 elliptic curve
- Derive the public key: Elliptic curve multiplication produces the public key (65 bytes uncompressed, or 33 bytes compressed)
- Hash the public key: Apply SHA-256, then RIPEMD-160 (this combination is called HASH160)
- Encode in Base58Check: Add a version byte, compute a checksum, and convert to Base58
Base58 encoding uses 58 characters — alphanumerics minus easily-confused characters (0, O, I, l). This makes addresses easier to transcribe without errors.
Why hash the public key instead of using it directly? The hash is shorter (160 bits vs 512 bits) and provides an additional security layer: even if ECDSA were broken, attackers couldn’t immediately spend from addresses that have never been used (because the public key hasn’t been revealed).
A vanity address is a Bitcoin address with a custom prefix (e.g., “1RYAN…”). Generating one requires brute-force: repeatedly generating keys until the address matches. The calculator above estimates how many attempts — and how long — you’d need for a given prefix length.
Bitcoin Transactions vs Traditional Bank Transfers
For finance professionals, it’s useful to compare Bitcoin transaction mechanics to familiar payment rails.
Bitcoin Transactions
- Ledger model: UTXO (discrete outputs)
- Settlement: 10-60 minutes (1-6 confirmations)
- Finality: Probabilistic (more confirmations = higher confidence)
- Verification: Decentralized (any node)
- Reversibility: Practically irreversible once confirmed
Traditional Bank Transfers
- Ledger model: Account-based (running balance)
- Settlement: ACH 1-3 days, wire same-day to next-day
- Finality: ACH/cards reversible for disputes; wires generally final
- Verification: Centralized (bank/clearinghouse)
- Reversibility: Consumer protections allow chargebacks
The tradeoffs are significant: Bitcoin provides faster settlement and near-irreversibility (valuable for merchants concerned about fraud), but lacks consumer protections. Traditional rails offer dispute resolution but slower finality. For a broader comparison of digital payment systems, see our article on Central Bank Digital Currencies and Digital Payment Systems.
Common Mistakes About Bitcoin Transactions
Many misconceptions exist about how Bitcoin transactions work. Here are the most common:
“Bitcoin uses account balances like a bank.” No — Bitcoin uses the UTXO model. Your “balance” is the sum of unspent outputs your keys can unlock, not a running total in an account.
“Bitcoin transactions are instant.” Transactions propagate quickly, but confirmation requires being included in a mined block (~10 minutes on average). Merchants typically wait for multiple confirmations before considering payment final.
“Bitcoin Script can run any program.” Bitcoin Script is intentionally non-Turing-complete. It cannot loop, recurse, or run arbitrary computation. This is a security feature, not a limitation.
“You can undo a confirmed transaction.” Once a transaction has sufficient confirmations, reversing it would require controlling majority hashpower and reorganizing the blockchain — economically infeasible in practice.
“All Bitcoin addresses work the same way.” Legacy (P2PKH), P2SH, SegWit (P2WPKH/P2WSH), and Taproot (P2TR) addresses have different script structures, fee characteristics, and capabilities.
“Address reuse is harmless.” Reusing addresses degrades privacy (observers can link your transactions) and slightly weakens security (your public key is exposed after the first spend from that address).
Limitations of Bitcoin’s Transaction Model
Understanding Bitcoin’s technical constraints helps set realistic expectations.
Bitcoin’s base layer processes roughly 3-7 transactions per second — far below Visa’s peak capacity of thousands per second. This limitation stems from the ~10-minute block interval and historical block size constraints.
Fixed cryptographic algorithms: Bitcoin’s legacy scripts rely on ECDSA (secp256k1 curve), SHA-256, and RIPEMD-160. Adding new algorithms is possible via soft fork (Taproot added Schnorr signatures this way), but replacing or removing existing algorithms network-wide would require a hard fork with broad consensus.
Protocol parameters are difficult to change: Block size, block interval, and reward schedule are deeply embedded. Attempts to change them (e.g., the block size debate) have historically been contentious.
Layer-2 solutions: The Lightning Network and other second-layer protocols address throughput limitations by moving transactions off-chain, settling periodically to the base layer. These add complexity and their own tradeoffs.
For analysis of how transaction fees vary across different payment networks, see our Payment Cost Calculator.
Frequently Asked Questions
Disclaimer
This article is for educational purposes only and does not constitute investment or financial advice. Bitcoin and cryptocurrency investments carry significant risks. Technical details described here reflect Bitcoin’s design as of the Princeton textbook’s publication and subsequent protocol upgrades; always verify current specifications. Consult qualified professionals before making investment decisions.
