Lecture 5: Blockchain Basics & Transactions, UTXO and Script Code

What this lecture covers

This lecture finishes the design of Bitcoin's transaction system after earlier sessions covered cryptography and consensus. It answers how a Bitcoin transaction is structured, how new coins enter circulation, what the scripting language can and cannot do, and how the unspent transaction output (UTXO) database keeps the network efficient. It sits near the end of a three-part arc: cryptographic primitives, consensus, and now transaction mechanics.

After watching, you should be able to describe how inputs and outputs chain together, explain the coinbase reward and its 100-block maturity rule, distinguish Bitcoin's transaction-based ledger from an account-based one, and summarize why Nakamoto consensus is considered the paper's real innovation.

Key ideas

• Transaction input: a reference to a previous transaction's output (by block and index) plus a digital signature, not an account balance.
• Coinbase transaction: the reward a miner receives for solving proof-of-work; it started at 50 BTC, halves roughly every four years, and cannot be spent for 100 blocks.
• Lock time: an optional condition in a transaction that prevents it from being valid until a specified future time.
• UTXO (unspent transaction output): a database, kept separately from the blockchain in a levelDB store, that tracks only the outputs that have not yet been spent, so software does not have to rescan the whole chain.
• Script: Bitcoin's stack-based, intentionally not Turing-complete programming language, used for conditions such as multi-signature requirements.
• Transaction fee: the difference between inputs and outputs, paid to miners; it is market-based rather than fixed like a bank fee.
• Nakamoto consensus: the incentive structure combining proof-of-work and the transaction ledger, described as the genuinely novel contribution of Satoshi Nakamoto's paper.

Walkthrough

Transaction format and inputs (4:08)

The lecture opens by recapping that a Bitcoin transaction has an input (the ID of a prior output plus a digital signature) and an output (a Bitcoin address and a value). Every transaction traces back to a coinbase transaction, the freshly minted reward a miner earns for solving proof-of-work. Lock time is introduced as an optional field letting a sender condition a transaction on a future time, verified strictly by the network rather than loosely as on a paper check.

Multiple inputs, outputs and fees (13:17)

Using a worked example, the instructor shows combining three inputs to cover a payment, sending part to one recipient and returning change to the sender, with the leftover amount left as a fee for miners. Inputs must be greater than or equal to outputs for a transaction to validate, and once spent, inputs are removed from the active dataset. The class discusses how market-based mining fees differ from a bank's fixed fee schedule, and how decentralization changes where transaction revenue flows.

Coinbase economics and mining incentives (18:25)

The coinbase reward is explained as the miner's payment for solving the proof-of-work puzzle, currently 12.5 BTC per block plus fees. The 100-block maturity rule prevents miners from spending a reward until 100 blocks have passed, giving the network time to settle on which chain is the accepted one. The lecture notes that miners can embed up to 100 bytes of arbitrary data in a coinbase transaction, as Nakamoto did in the Genesis block with a newspaper headline.

The unspent transaction output database (29:49)

The UTXO set is described as a database of transaction outputs that have not yet been spent, stored separately from the blockchain to speed up validation. At the time of the lecture there were roughly 340 million total transaction outputs, of which about 54 million remained unspent; roughly half of those were called "dust," amounts too small to be worth the fee to redeem.

Script code and its limits (37:59)

Bitcoin's scripting language is introduced as stack-based and deliberately not Turing-complete, trading flexibility for security by reducing attack vectors. A cited academic study of the UTXO set breaks down script types: most outputs go to a hash of a Bitcoin address, a growing share go to hashed conditional scripts, and a small fraction use multi-signature conditions. This limited scripting is framed as groundwork for the next lecture on smart contracts.

Review, hash functions and finality (44:05)

The lecture reviews hash functions as a compression and commitment mechanism, revisiting how they support proof-of-work, Merkle trees and Bitcoin addresses. A student question about waiting ten minutes for confirmation leads to a discussion of counterparty risk, zero-confirmation acceptance, and why multiple confirmations reduce (but do not eliminate) the risk of a transaction being reversed by a chain reorganization.

Nakamoto consensus and closing debate (59:29)

Responding to a student's question about what is actually novel in Satoshi Nakamoto's paper, the instructor and a guest lawyer argue that the genius lies not in any single invented component (hash functions, proof-of-work, and digital signatures all predate Bitcoin) but in combining them into an incentive structure now called Nakamoto consensus. The session closes with student tables debating candidates for Satoshi Nakamoto's identity, including Hal Finney, Nick Szabo, and Craig Wright, without a resolution.

Before you watch

• Review the earlier lecture on cryptographic primitives, especially hash functions and digital signatures, since this lecture assumes familiarity with both.
• Recall how proof-of-work and consensus protocols were introduced, since this session builds directly on them.
• No programming background is required, but understanding basic conditional logic will help with the script discussion.

Check your understanding

1. What must be true about a transaction's inputs and outputs for it to validate?
2. Why does a coinbase reward stay unusable for 100 blocks?
3. What is the UTXO set, and why is it stored separately from the full blockchain?
4. Why is Bitcoin's scripting language deliberately not Turing-complete?
5. According to the lecture, what specifically made Satoshi Nakamoto's paper novel?