Lecture 3: Blockchain Basics and Cryptography

What this lecture covers

This lecture opens a three-class technical deep dive into Bitcoin's design, starting with cryptography. Gary Gensler and the class work through the two cryptographic primitives at the heart of blockchain: hash functions (which fingerprint data into a fixed size, one-way and collision-resistant) and asymmetric cryptography (the public/private key system behind digital signatures). Students help build a running list of design features from Satoshi Nakamoto's paper — hash functions, timestamps, Merkle trees, private/public keys, Bitcoin addresses, and more — before the lecture works through each in turn.

After watching, you should be able to explain what makes a cryptographic hash function useful (deterministic, one-way, collision-resistant), describe how a digital signature lets someone verify a message came from a specific sender without revealing that sender's private key, and explain why block headers store only a small summary (via Merkle roots) rather than every transaction.

Key ideas

• Hash function properties: a cryptographic hash function maps any input to a fixed-size output, is deterministic, computed efficiently, and is (practically) one-way and collision-resistant — meaning it's infeasible, not impossible, to reverse or to find two inputs producing the same output.
• Infeasible versus impossible: cryptographic security relies on making attacks computationally infeasible (for SHA-256, roughly 1 in 2^128) rather than mathematically impossible, since brute-force attempts are always technically possible.
• Merkle trees: transactions in a block are paired and hashed repeatedly up a binary tree until a single Merkle root summarizes potentially thousands of transactions, keeping the block header small (around 80 bytes) while still securing all the underlying data.
• Block header contents: each header holds five pieces of information — the version, the previous block's hash, the Merkle root, a timestamp, and a difficulty target plus a nonce — which is what a lightweight ("light") node can download instead of the full transaction history.
• Asymmetric cryptography and digital signatures: a private key and public key are generated together from a random number; a message signed with a private key can be verified by anyone holding the corresponding public key, without ever exposing the private key.
• Public keys versus Bitcoin addresses: a Bitcoin address is not the same as a public key — it's the public key hashed twice (via SHA-256 and another function) and shortened, mainly for compactness and added security.
• Native currency as design feature: Nakamoto embedded an economic incentive directly into the protocol — miners who successfully add a block receive newly created bitcoin, tying the cryptography to an incentive system.
• Blockchain predates Bitcoin's name: Stuart Haber and colleagues built timestamped, hash-linked document chains in the early 1990s and published hashes weekly in the New York Times classifieds — a working example of the same idea decades before Nakamoto's paper, which itself never uses the word "blockchain."

Walkthrough

Framing the next three lectures (1:02)

Gensler explains that the next three classes cover blockchain's technical underpinnings through the lens of Bitcoin, since Bitcoin was the first application of the technology. He previews the study questions: cryptography, append-only timestamps, blocks, distributed consensus, and networking, noting that around 10 specific design features will come out of discussion.

Reviewing money and ledgers, then listing Bitcoin's design features (9:12)

After a brief recap of money as social consensus and ledgers as transaction or balance records, the class builds a list of design features mentioned in Nakamoto's paper through open discussion: hash functions, private/public keys, Bitcoin addresses, timestamp servers, the double-spend solution, proof-of-work/mining, full versus lightweight nodes, Merkle tree structure, the nonce, and peer-to-peer networking. Gensler groups these into three buckets for the coming lectures: cryptography (today), consensus (next Tuesday), and transactions (next Thursday).

The native currency as an incentive system (19:22)

The lecture highlights that Bitcoin's native currency isn't incidental — mining rewards (initially 50 BTC per block, halving over time to 12.5 BTC by the time of the lecture, with a hard cap of 21 million bitcoin) function as the economic incentive that makes proof-of-work mining worthwhile. The discussion touches on mining pools and electricity costs as practical constraints on who can mine profitably.

What a hash function is and its cryptographic properties (26:30)

Using zip codes as a loose, non-secure analogy for fixed-size mapping, Gensler defines a cryptographic hash function's key properties: it's one-way (preimage resistant, infeasible to reverse), collision-resistant (infeasible for two different inputs to produce the same output), and exhibits an avalanche effect where a tiny input change drastically alters the output. He notes SHA-256 security is roughly 1 in 2^128, not literally unbreakable, and that Nakamoto anticipated hash functions could eventually need replacing.

Block headers and Merkle trees (39:39)

The lecture details the five fields in a Bitcoin block header (version, previous block hash, Merkle root, timestamp, difficulty target, plus a nonce) and explains how a Merkle tree compresses potentially thousands of transactions into a single root hash, keeping headers around 80 bytes each so lightweight nodes can sync without downloading the full 180-gigabyte transaction history.

Digital signatures and asymmetric cryptography (54:50)

Through a classroom demonstration (Kelly signing a message for Isabella to verify), the class works through key generation, signing, and verification functions. A student summarizes the process: the message is hashed and encrypted with the sender's private key to form a signature; the recipient re-hashes the message, decrypts the signature with the sender's public key, and compares the two hashes to confirm authenticity and integrity.

Bitcoin addresses and transaction basics (1:07:05)

Gensler clarifies that a Bitcoin address is derived by hashing a public key twice and shortening it, distinct from the public key itself, largely for security and compactness. He closes with a brief look at transaction structure (inputs, outputs, and values denominated in satoshis, the smallest Bitcoin unit) before summarizing the lecture's three pillars: cryptography, consensus, and transactions.

Before you watch

• Review Lecture 1's introduction to hash functions and asymmetric cryptography and Lecture 2's coverage of ledgers, since this lecture builds directly on both.
• No computer science background is assumed, but a rough sense of what "encryption" means will make the digital signature walkthrough easier to follow.
• Nakamoto's original Bitcoin paper is assumed reading; the lecture references it throughout without summarizing it fully.

Check your understanding

1. What does it mean for a hash function to be "collision-resistant," and why does the lecture describe this as infeasible rather than impossible?
2. How does a Merkle root let a block header stay small while still securing thousands of transactions?
3. Walk through the steps of creating and verifying a digital signature, using the classroom example of Kelly signing a message for Isabella.
4. What is the difference between a Bitcoin public key and a Bitcoin address, and why does Nakamoto's design hash the public key twice?
5. Why does the lecture describe Bitcoin's native currency as a deliberate design feature rather than just a side effect of the protocol?