← Back to course
Lecture 03 · Bitcoin Protocol

L03: Bitcoin Protocol

Technical Deep Dive
From UTXO accounting to the halving schedule: how Bitcoin achieves trustless digital scarcity, why its mining lottery self-regulates, and what the 80-byte block header encodes about the entire history of the chain.
Level: BSc Year 2 Prerequisites: L01 Intro, L02 Cryptography Slides: 10 core · 38 extended Charts: 12

Gold is scarce because mining it is expensive. Banknotes are scarce because a central bank controls the press. Digital files are not scarce at all — a JPEG costs nothing to copy a billion times. This asymmetry was the fundamental obstacle to digital money for three decades: any digital token representing value can be duplicated without cost, destroying its monetary properties the instant a recipient cannot verify uniqueness.

Satoshi Nakamoto’s insight, published in the October 2008 white paper, was to reframe scarcity. Instead of preventing copying, make each unit’s entire lineage publicly auditable. A bitcoin is valid not because a bank says so but because every full node on the network can independently verify that (a) the coins were created through legitimate block rewards, and (b) every subsequent transfer was authorized by the rightful owner and has never been spent before. Scarcity is enforced not by physical rarity or institutional fiat but by a globally replicated, cryptographically linked ledger that any participant can audit in full.

The double-spend problem restated: Alice has 1 BTC. She tries to send it to both Bob and Carol simultaneously. In a centralized system the bank catches this. In a decentralized system the network must reach consensus on which transaction is canonical — without anyone in charge. Bitcoin solves this with proof-of-work ordering.
Bitcoin opening cartoon
Fig 3.1 — The double-spend problem: why digital cash needs a consensus mechanism, not just cryptography

What makes Bitcoin remarkable as an engineering artifact is that it solves this coordination problem with no trusted coordinator. The rules are encoded in open-source software. The ledger is replicated across tens of thousands of independent nodes worldwide. Participation is permissionless — anyone can join, validate, or mine without asking anyone’s permission. The monetary policy (21 million coin cap, halving schedule) is baked into the protocol itself, immune to discretionary intervention. Understanding exactly how these properties are achieved mechanically is the goal of this lecture.

Most people intuitively model money as account balances: Alice has $100 in her account, she sends $40 to Bob, she now has $60. Bitcoin uses a fundamentally different abstraction called the Unspent Transaction Output (UTXO) model. There are no accounts and no balances. There are only individual coins — discrete chunks of value — each locked to a particular cryptographic condition and either unspent (available) or consumed (gone forever).

A transaction does not deduct from a balance. It destroys one or more existing UTXOs and creates one or more new ones. Alice’s wallet balance is computed on demand by summing every UTXO that Alice’s private keys can unlock. This is slightly more computationally expensive than a balance lookup, but it carries profound advantages: transactions are structurally independent (no global nonce sequencing required), and privacy is improved because nothing forces address reuse — a well-designed wallet generates a fresh address for every incoming payment.

UTXO set: The database of all currently unspent outputs is called the UTXO set. As of 2025 it contains roughly 150–180 million UTXOs and fits in a few gigabytes of RAM. Every full node maintains this set; it is the only state needed to validate new transactions.
UTXO model diagram
Fig 3.2 — UTXO lifecycle: coins are created by transactions and consumed exactly once

The transaction fee emerges naturally from this model. A transaction’s inputs must equal its outputs plus the fee. There is no explicit fee field: the miner who includes the transaction collects the difference between total input value and total output value. This means wallets must be careful when constructing transactions — accidentally sending too little change back to yourself is a valid transaction, and the overpayment becomes a tip to the miner.

Transaction anatomy
Fig 3.3 — Transaction anatomy: inputs reference previous UTXOs; outputs create new ones locked to recipient addresses
PropertyUTXO Model (Bitcoin)Account Model (Ethereum)
State unitIndividual unspent outputAccount balance
Balance querySum of unlockable UTXOsSingle value lookup
ParallelismHigh (independent UTXOs)Sequential nonce required
Privacy potentialHigh (fresh addresses)Lower (reused address)
Smart contract stateAwkward (stateless scripts)Natural (persistent storage)
Fee mechanismImplicit (input − output)Explicit gas field

The UTXO model interacts with Bitcoin’s privacy design. The protocol permits sending to a different address in every transaction, which theoretically breaks the trivial chain-following attack where an analyst simply traces an address across time. In practice, common-input-ownership heuristics, exchange KYC, and chain analysis tools have substantially eroded on-chain privacy, motivating mixing protocols like CoinJoin and off-chain solutions like the Lightning Network.

A Bitcoin block has a deceptively simple structure. The header is exactly 80 bytes. The body contains a variable number of transactions, typically 1,500–3,000 in a modern block. Everything that makes Bitcoin tamper-resistant flows from the header’s six fields and how they are hashed together.

Bitcoin block structure
Fig 3.4 — Bitcoin block structure: the 80-byte header commits to the entire transaction set via the Merkle root

The previous block hash field is the chain’s backbone. It makes the hash of every block depend on the hash of the block before it, all the way back to the genesis block mined on 3 January 2009. Altering any transaction in any historical block changes that block’s Merkle root, which changes the block’s header hash, which invalidates the next block’s reference, cascading forward to the chain tip. An attacker cannot silently rewrite history; the break is immediately visible to every node.

The Merkle root: Rather than hashing all transactions sequentially, Bitcoin uses a binary hash tree. Each transaction is hashed individually; pairs of hashes are hashed together; this continues up to a single 32-byte root. Changing any single transaction changes the root. A lightweight node (SPV client) can verify that a specific transaction is in a block by checking only O(log n) sibling hashes rather than downloading the entire 1–2 MB block body.

The nonce is the 4-byte field miners iterate through during proof-of-work. The goal is to find a nonce such that SHA256(SHA256(header)) produces a hash numerically less than a target value — a number beginning with a required number of leading zero bits. With only 4 billion possible nonce values and modern ASIC hash rates in the exahash range, miners exhaust the nonce space in milliseconds and must vary other header fields (typically the coinbase transaction’s extranonce, which changes the Merkle root) to continue the search.

The timestamp is loosely enforced: nodes accept blocks whose timestamp falls within a two-hour window of their local clock. This tolerance prevents network partitions caused by minor clock drift while still allowing the difficulty adjustment algorithm to measure elapsed time accurately over the 2016-block adjustment window.

UTXO flow diagram
Fig 3.5 — UTXO flow: how value moves through a chain of transactions from coinbase creation to final spend

Bitcoin mining is a probabilistic race. Miners repeatedly compute SHA256(SHA256(header)) with different nonce values, hoping the result falls below the current target. The probability of success on any single hash attempt is astronomically small — on the order of 1 in 1022 at recent difficulty levels — but miners collectively perform trillions of such attempts per second, so a valid block appears on average every ten minutes. This is not a coincidence: the difficulty target automatically adjusts to maintain the ten-minute average regardless of how much hash power joins or leaves the network.

The difficulty adjustment is one of Bitcoin’s most elegant self-regulating mechanisms. Every 2016 blocks (nominally two weeks), each full node independently computes the ratio of the actual time elapsed to the ideal 20,160 minutes and scales the difficulty proportionally. No central authority makes this decision. All nodes applying the same rule arrive at the same new target deterministically. The adjustment is capped at a factor of 4 in either direction per period to prevent manipulation through strategic hash rate withholding.

Difficulty formula:
Dnew = Dold × (Tactual / Ttarget)
where Ttarget = 2016 × 10 min = 20,160 min.
Capped at 4× increase or 0.25× decrease.
Difficulty adjustment
Fig 3.6 — Difficulty adjustment over time as hash rate grew from megahashes to exahashes

The block reward consists of two components: the block subsidy (newly created bitcoin) and transaction fees. The subsidy began at 50 BTC per block in 2009 and halves every 210,000 blocks — approximately four years. This halving schedule is hard-coded in the protocol and enforces Bitcoin’s 21 million coin cap with mathematical precision. No discretionary monetary authority can expand supply.

EraBlock SubsidyApprox. Supply MinedCumulative % of Cap
2009–201250 BTC10,500,000 BTC50%
2012–201625 BTC5,250,000 BTC75%
2016–202012.5 BTC2,625,000 BTC87.5%
2020–20246.25 BTC1,312,500 BTC93.75%
2024–20283.125 BTC656,250 BTC96.875%
2140 onward0 BTC100% (21M)
Mining reward schedule
Fig 3.7 — Bitcoin supply schedule: the geometric series converges to exactly 21 million BTC

The fee market is where Bitcoin’s long-run security model rests. As subsidies approach zero after the year 2140, miners must be compensated entirely through transaction fees. Miners rank mempool transactions by fee rate (satoshis per virtual byte, sat/vB) and fill blocks greedily from the top. When block space is scarce, a fee auction emerges: users who need fast confirmation overbid each other, while low-urgency transactions wait. During the 2023 Ordinals inscription boom, average fees exceeded 500 sat/vB, demonstrating that significant fee revenue is achievable even without a subsidy — though the long-run adequacy of fee-only security remains an open research question.

Fee market dynamics
Fig 3.8 — Fee market: mempool congestion drives competitive fee auctions for limited block space

Every Bitcoin UTXO is locked by a locking script (ScriptPubKey) and unlocked by a spending script (ScriptSig or witness). Together these form a two-part program that the network evaluates to determine whether a spend is authorized. Bitcoin Script is a deliberately limited, stack-based language with approximately 100 opcodes — intentionally non-Turing-complete. There are no loops, no recursion, no unbounded computation. This design choice makes scripts analytically simple and rules out entire categories of bugs that plague Turing-complete systems like the Ethereum EVM.

Bitcoin Script opcodes
Fig 3.9 — Bitcoin Script execution: a stack machine evaluates the concatenated locking and spending scripts

The most common script pattern is P2PKH (Pay to Public Key Hash), which locks coins to the hash of a public key. The spender must provide the preimage (public key) and a valid ECDSA signature. More complex patterns enable multi-signature custody and time-locked contracts.

P2PKH — Pay to Public Key Hash

1... (legacy)

Standard single-sig. Lock to hash of pubkey; spend with pubkey + signature. Most widely supported.

P2SH — Pay to Script Hash

3... (P2SH)

Lock to hash of a redeem script. Spending reveals the full script. Enables multisig without bloating outputs.

P2WPKH — Native SegWit

bc1q... (bech32)

Witness data separated from the main block. Fixes transaction malleability; enables Lightning Network.

P2TR — Taproot (2021)

bc1p... (bech32m)

Schnorr signatures, MAST. All spends look identical on-chain; complex scripts indistinguishable from simple ones.

SegWit (Segregated Witness, 2017) was a soft-fork upgrade that moved signature witness data outside the main transaction block and redefined the size limit as 4 million weight units rather than 1 megabyte. This made transactions cheaper (witness data costs 1 weight unit per byte versus 4 for non-witness data), fixed transaction malleability (enabling reliable off-chain payment channels), and created the versioning hooks later used by Taproot. SegWit adoption grew steadily after Lightning Network adoption drove demand for bc1q addresses.

Taproot (2021) introduced Schnorr signatures as a replacement for ECDSA. Schnorr signatures are linear, enabling key aggregation: n-of-n multisig produces a single signature indistinguishable on-chain from a simple single-sig spend. Taproot also introduced MAST (Merkelized Abstract Syntax Trees), allowing complex spending conditions to be hidden behind a single public key, revealing only the executed branch. The privacy and efficiency gains are substantial for complex custody arrangements.

Transaction types evolution
Fig 3.10 — Evolution of Bitcoin transaction types: the shift from legacy P2PKH toward SegWit and Taproot address formats

Bitcoin’s security model has held remarkably well since 2009, but it is not unconditional. The canonical attack is the 51% attack (more precisely, a >50% hash rate attack): an entity controlling the majority of hash power can mine a private fork faster than the honest network builds the public chain. Once the private fork overtakes the public chain in cumulative proof-of-work, it becomes the canonical chain under the longest-chain rule, potentially reversing recently confirmed transactions. The attacker cannot steal coins from arbitrary addresses (private keys are still required) but can double-spend their own coins — paying an exchange, receiving the goods, then orphaning the deposit transaction.

51% attack economics on Bitcoin: At 2025 hash rates near 1 ZH/s (1,000+ EH/s), acquiring 50% of the network’s hash power would require purchasing millions of ASICs and consuming on the order of 85 TWh/year of electricity — a capital and operating expenditure in the tens of billions of dollars annually. Expected profit from double-spending is constrained by liquidity at exchanges. The attack is economically irrational at current scale. This is not a mathematical guarantee; it is a market equilibrium argument.

The energy consumption debate is genuine. Bitcoin mining consumed approximately 120–170 TWh/year in 2024 — comparable to Poland or Argentina. Critics note that this energy expenditure is structurally required by PoW: reducing it proportionally reduces security. Proponents argue that (a) an increasing fraction comes from stranded or curtailable renewable energy that would otherwise be wasted, (b) the comparison should be against the full energy footprint of the legacy financial system it claims to replace, and (c) this is a deliberate design choice, not an inefficiency. The energy mix matters: mining with excess hydropower is categorically different from mining with coal, and the grid composition of mining is heterogeneous and contested in public data.

Bitcoin energy mix breakdown
Fig 3.11 — Estimated Bitcoin mining energy mix: the share of renewables is contested but growing

Beyond external attacks, Bitcoin faces two structural protocol limits that generate ongoing research debate. The block size limit constrains base-layer throughput to roughly 7 transactions per second for simple payments, rising to approximately 15–20 TPS with full SegWit adoption. This is intentional — larger blocks propagate more slowly, granting latency advantages to well-connected mining pools and eroding decentralization. The tradeoff between throughput and decentralization is not engineering laziness; it is the trilemma in action. The long-run fee market question asks whether voluntary transaction fees will generate enough revenue to sustain current security levels once the block subsidy approaches zero. Empirical evidence is sparse because we are still operating primarily on subsidy revenue.

Bitcoin fork history timeline
Fig 3.12 — Bitcoin fork timeline: governance disputes have produced notable hard forks but the original chain retains dominant hash rate and value

Bitcoin’s peer-to-peer network is heterogeneous. Full nodes download and independently validate every block and transaction against the complete ruleset. As of 2025, approximately 18,000–25,000 reachable full nodes operate globally, with the majority running Bitcoin Core. Full node operators enforce consensus rules: they reject invalid blocks regardless of how much hash power backs them. This is why “economic nodes” matter — a miner that produces an invalid block wastes real electricity and earns nothing because full nodes will not relay or build on it.

SPV (Simple Payment Verification) clients — most mobile wallets — download only block headers and verify the proof-of-work chain without checking transaction validity. They trust that full nodes have done the validation. This is a necessary usability trade-off for resource-constrained devices, but it does reduce the SPV client’s security assumptions.

Hash rate growth: Bitcoin’s hash rate grew from roughly 1 TH/s in 2011 to over 1,000 EH/s (1 ZH/s) by 2025 — a 109 increase in fourteen years. This growth reflects the transition from GPU mining to custom ASICs, the entrance of institutional mining operators, and the continued profitability of block rewards relative to energy and hardware costs.
Bitcoin hash rate history
Fig 3.13 — Bitcoin hash rate 2009–2025: exponential growth with visible corrections after halvings and market downturns

The Lightning Network, Bitcoin’s primary Layer 2 scaling solution, enables off-chain micropayment channels. Two parties lock funds in a 2-of-2 multisig UTXO (the channel), then exchange signed commitment transactions off-chain at arbitrarily high speed and zero fee, settling on-chain only at close. Routing enables payments across multiple channels without direct channel partners. By 2025 the Lightning Network had grown to thousands of nodes and hundreds of millions of dollars in channel capacity, demonstrating that Bitcoin can support everyday-scale payment volumes without altering the base layer’s conservative parameters.

Lightning channel lifecycle
Fig 3.14 — Lightning Network channel lifecycle: open, transact off-chain, close; only two on-chain transactions required regardless of payment count

Adoption has broadened beyond early cypherpunk users. The January 2024 approval of spot Bitcoin ETFs in the United States opened the asset to pension funds, wealth managers, and retail investors through regulated brokerage accounts. El Salvador adopted Bitcoin as legal tender in 2021, offering a real-world experiment in sovereign monetary adoption. Corporate treasury allocations (MicroStrategy, Tesla, and others) and the emergence of Bitcoin-denominated bonds signal deepening integration with traditional capital markets — though price volatility continues to complicate its use as a stable medium of exchange.

Bitcoin adoption metrics
Fig 3.15 — Bitcoin adoption metrics: wallet addresses, exchange volumes, and institutional allocations across key milestones

After working through the mechanics, it is worth stepping back to evaluate Bitcoin as both an engineering system and a monetary experiment. As an engineering artifact, Bitcoin is conservative by design. It has processed billions of transactions since 2009 without a single successful protocol-level breach. Its upgrade process (BIPs, miner signaling, economic node adoption) is slow and contentious, which is a feature rather than a bug: software that controls hundreds of billions of dollars in value should not change quickly. The block size wars of 2015–2017, culminating in the Bitcoin Cash fork, illustrated how contested even modest parameter changes become at scale.

Bitcoin’s core design trade-offs summarized:
Simplicity over expressiveness: Script is intentionally limited. Ethereum chose Turing-completeness; Bitcoin chose auditability.
Decentralization over throughput: 7 TPS base layer is a deliberate ceiling that keeps full node operation cheap enough for individuals.
Predictable policy over flexibility: The halving schedule cannot be amended without a fork. This predictability is the monetary property gold holders find analogous.
Security over speed: 10-minute blocks and 6-confirmation finality (60 minutes) are slow. Finality on Ethereum’s PoS is now ~12 seconds. Bitcoin prioritizes irreversibility over latency.

As a monetary experiment, Bitcoin challenges several central banking assumptions. Its supply schedule is known precisely for the next century. No political actor can discretionarily expand or contract it. These properties are attractive to users in high-inflation economies and to investors seeking a non-correlated store of value — properties empirically observed in the 2021–2022 cycle when Bitcoin’s correlation with technology equities briefly decoupled during inflation spikes. The counter-argument is that Bitcoin’s volatility (routinely ±50% in a calendar year) disqualifies it as a unit of account or stable medium of exchange. Both views have genuine empirical support; the question of what property matters most is partly normative.

The honest assessment for a second-year engineering student: Bitcoin solved a technically difficult problem elegantly, built a system that has operated reliably for fifteen years at massive scale, and created a monetary instrument with genuine novel properties. Its limitations — throughput, energy, privacy, programmability — are real, and later blockchain architectures made different trade-offs addressing each. Understanding Bitcoin’s choices is prerequisite to understanding why every subsequent system is designed the way it is. Every parameter in Ethereum, Solana, and Avalanche is implicitly a response to a Bitcoin decision.

BTC vs fiat supply comparison
Fig 3.16 — Bitcoin supply versus fiat M2 expansion: the contrast in monetary policy discretion is the core of the “digital gold” thesis
Key takeaways for the exam:
• UTXO model: coins, not balances; fee = inputs − outputs
• Block header: 80 bytes; nonce + prev hash + Merkle root + difficulty target
• Mining: SHA256 lottery; difficulty adjusts every 2016 blocks to target 10 minutes
• Supply: 21M cap; halving every 210,000 blocks (≈4 years)
• Script: stack-based, intentionally non-Turing-complete; P2PKH / P2SH / P2WPKH / P2TR
• Confirmation security: 6 confirmations ≈ finality in practice; more confirmations for higher-value transfers
• Chain selection: heaviest cumulative proof-of-work wins, not longest block count
© 2025 BSc Blockchain Course · Bitcoin Protocol · Course Home