Chapter 6 Key Takeaways

Core Concepts

1. Bitcoin Uses UTXOs, Not Balances

Bitcoin does not maintain account balances. Instead, it maintains a set of Unspent Transaction Outputs (UTXOs). A "balance" is computed by summing all UTXOs locked to a given address. Transactions consume entire UTXOs as inputs and create new UTXOs as outputs. Any excess value is returned as a change output. The UTXO set is Bitcoin's global state.

2. Transaction Fees Are Implicit

There is no "fee" field in a Bitcoin transaction. The fee is the difference between the total input value and the total output value. Any gap between inputs and outputs is automatically claimed by the miner who includes the transaction in a block. This design is simple and tamper-proof, but it means wallet software must be careful to construct correct change outputs — a missing change output results in an enormous accidental fee.

3. UTXOs Cannot Be Partially Spent

Every UTXO must be consumed in its entirety. If you own a 1.0 BTC UTXO and want to send 0.3 BTC, you must spend the entire 1.0 BTC UTXO and create two outputs: 0.3 BTC to the recipient and approximately 0.7 BTC back to yourself as change. This "cash-like" behavior is fundamental to the UTXO model.

4. Bitcoin Script Authorizes Spending

Bitcoin uses a stack-based scripting language (Script) to define spending conditions. The locking script (ScriptPubKey) specifies what is required to spend a UTXO. The unlocking script (ScriptSig) provides the proof. For the most common type (P2PKH), the locking script requires a public key matching a specific hash and a valid signature from the corresponding private key. Script is intentionally not Turing-complete — it cannot loop — ensuring that all scripts terminate in bounded time.

5. The Coinbase Transaction Creates New Bitcoin

Every block's first transaction is the coinbase transaction, which has no real inputs and creates new Bitcoin according to the halving schedule (currently 3.125 BTC per block). The coinbase also collects all transaction fees from the block. Its arbitrary data field has been used for miner identification, extra nonce space, and famously, Satoshi's newspaper headline in the genesis block. Coinbase outputs require 100 confirmations before spending.

6. The Block Header Is 80 Bytes of Critical Data

The block header contains exactly six fields in 80 bytes: version (4), previous block hash (32), Merkle root (32), timestamp (4), difficulty bits (4), and nonce (4). The previous block hash chains blocks together, creating immutability. The Merkle root commits to every transaction. The nonce is what miners iterate to find a valid proof of work. All of Bitcoin's security properties derive from these 80 bytes.

7. SegWit Fixed Malleability and Increased Capacity

Segregated Witness (activated August 2017) moved signature data to a separate "witness" section outside the transaction ID calculation. This fixed transaction malleability (enabling the Lightning Network) and increased effective block capacity through the weight discount: witness data costs 1 weight unit per byte instead of 4. The maximum block weight is 4,000,000 WU, allowing blocks larger than 1 MB when SegWit transactions are used.

8. The UTXO and Account Models Make Different Tradeoffs

The UTXO model (Bitcoin) excels at parallel validation, privacy (natural address non-reuse), and simple double-spend detection. The account model (Ethereum) excels at developer simplicity, smart contract expressiveness, and smaller transaction sizes for simple transfers. Neither is universally superior — each is optimized for its blockchain's specific use case.

Formulas to Remember

Formula Meaning
fee = sum(inputs) - sum(outputs) Transaction fee is implicit
weight = (non-witness * 4) + (witness * 1) SegWit weight calculation
vbytes = weight / 4 Virtual bytes for fee calculation
fee_rate = fee / vbytes Fee rate in sat/vB
reward(h) = 50 * 10^8 / 2^(h/210000) Block reward at height h

Common Mistakes to Avoid

  1. Thinking Bitcoin has "accounts." There are no accounts. There are UTXOs with locking scripts. Addresses are shorthand for locking script patterns, not account identifiers.

  2. Assuming transactions have a "from" field. Transactions have inputs that reference UTXOs. The "sender" is inferred from the locking script of the consumed UTXOs, not from any field in the transaction.

  3. Forgetting the change output. Every UTXO must be fully consumed. Failing to create a change output means the entire difference goes to the miner as a fee.

  4. Confusing block size with block weight. Since SegWit, the relevant limit is 4,000,000 weight units, not 1 MB. Blocks can exceed 1 MB of raw data. Fee calculation uses virtual bytes (weight / 4), not raw bytes.

  5. Assuming SegWit required a hard fork. SegWit was deployed as a soft fork. Old nodes continue to function — they just cannot validate witness data. This backward compatibility is why SegWit could activate without universal node upgrades.

What This Enables

The protocol-level understanding from this chapter is the foundation for everything that follows:

  • Chapter 7 (Networking): Transaction and block propagation through the P2P network depends on the structures defined here.
  • Chapter 10 (Ethereum): Comparing the UTXO model to Ethereum's account model requires deep understanding of both.
  • Chapter 12 (Lightning Network): The Lightning Network's payment channels rely on SegWit's malleability fix and Script's time lock opcodes.
  • Progressive Project: The simplified blockchain we built in Python is the data structure backbone that we will extend with networking, consensus, and smart contract capabilities.