Bitcoin is the first chain you'll meet in detail and the chain every other chain measures itself against, for the simple reason that it came first and proved the model worked. To understand any later chain, you start by understanding what Bitcoin chose and why. The design choices look strange in isolation. Ten-minute blocks. A scripting language that can't loop. A money supply hardcoded to stop at twenty-one million. None of these are arbitrary. Each one falls out of a tight chain of reasoning that starts with a single question and ends with a working system. This lesson walks that reasoning end to end.

In late 2008, an unsigned paper appeared on a cryptography mailing list, proposing a system that almost everyone with the relevant background would have said was impossible the month before. The author used the pseudonym Satoshi Nakamoto, and the paper was titled "Bitcoin: A Peer-to-Peer Electronic Cash System."

The title contains the whole question. Each word matters.

Electronic ruled out paper currency and required a system that could exist purely as data, transmitted over the internet. Cash ruled out anything that required a third party to clear the transaction, which is what makes physical cash different from a bank transfer. Two people standing in a room exchanging cash do not need permission from a bank to complete the exchange. Cash settles immediately and irrevocably and without an intermediary. Peer-to-Peer ruled out a central server that the transaction flows through. The two parties have to be able to transact directly, with no operator in the middle. System meant the whole apparatus had to work, end to end, at internet scale, with strangers, indefinitely.

Putting it together: a way for any two parties anywhere in the world to exchange digital value, directly, without permission from any third party, in a system that runs itself.

This had been an open problem in computer science for over twenty years before 2008. Several serious attempts had been made. All of them had failed at the same point: how do you prevent the same digital coin from being spent twice in two different places, when there's no central server keeping the books? This is called the double-spend problem, and it is the core obstacle that every previous digital-cash design crashed into.

Bitcoin's contribution was an answer to this question that nobody had thought of before. The rest of the design follows from how that answer worked.

Once you commit to "no central operator," a whole cascade of constraints follows. There's one meta-constraint that motivates all the others: the system has to survive adversarial conditions. With no operator to ban attackers, the system has to keep running while bad actors try to break it from the inside. Liars, cheaters, attackers with millions of dollars to spend on breaking it: all welcome to participate, because there's no gatekeeper to keep them out. Every design choice that follows is made under the assumption that an unknown fraction of participants are hostile.

That meta-constraint produces five operational ones.

Sybil resistance without identity. In any open system, the obvious attack is to spin up a million fake participants and outvote the honest ones. If the system uses identity to prevent this , it needs a way to identify people, which requires a central authority. So the system can't use identity. It needs some other way to make participation costly enough that creating a million fake participants is not economically feasible.

Public verifiability. Without a trusted operator to vouch for transactions, every participant has to be able to verify every transaction themselves. This means the rules must be simple enough to compute, the data must be available to everyone, and the verification must produce the same answer on every honest node. No "trust me, I'm the bank."

Convergence despite network delay. Information traveling across the internet doesn't arrive everywhere at the same instant. Two participants on opposite sides of the world might see different events first. The system has to handle this gracefully, with all honest participants eventually agreeing on the same history, despite never having a synchronized clock or instant global broadcast.

Censorship resistance. If any single party can prevent a transaction from being processed, that party is effectively the operator. The system has to be structured so that no single point of failure can stop anyone from transacting.

Permanence. A transaction that settled yesterday has to be just as settled tomorrow. There's no operator to "reverse" it. If the system can selectively forget or rewrite history, the entire trustless guarantee evaporates.

Each of these constraints kills a category of possible designs. A system with a membership list violates Sybil resistance without identity. A system with encrypted state violates public verifiability. A system that relies on a global synchronous clock violates convergence under delay. A system where a gatekeeper can drop transactions violates censorship resistance. A system with mutable history violates permanence. All of these are out.

What's left, after killing every design that fails any constraint, is a very narrow space. Bitcoin's specific shape is what fits inside it.

Now the constraints are the input and Bitcoin's design is the output. Each major choice in Bitcoin's design is a direct response to a specific constraint.

The ledger is append-only and hash-linked. Each block carries the hash of the previous one, the structure you've already seen in detail. This is the answer to permanence: rewriting a single old block invalidates every block after it.

Sybil resistance comes from proof of work. The right to add to the ledger is sold to whoever can demonstrate the most computational work. Computation costs electricity. Electricity costs the same regardless of how many identities you control. A million fake participants pay a million times the bill. This is the answer to Sybil resistance without identity, and it's specifically a hardware-and-energy answer to a problem that previous designs tried to solve with cryptography alone.

Validation is deterministic and simple. Every transaction can be checked by running a small piece of code against the chain's state. The code is intentionally not Turing-complete. There are no loops. There is no recursion. There is no external state. This is the answer to public verifiability: every node, anywhere, running honest software, reaches the same answer on the same input.

Block times are slow on purpose. Ten minutes between blocks is not a performance choice. It's a margin of safety for the network. A new block has to propagate to most of the planet before the next one is produced, so that everyone is working on the same tip. Faster block times mean more chain forks and more wasted work. Ten minutes is conservative on purpose. This is the answer to convergence under delay.

The money supply is capped. Twenty-one million bitcoins, ever. Block rewards halve every 210,000 blocks which is about every four years, so the rate of new issuance slows over time and eventually stops. This is not a technical constraint of the underlying machinery. It's a deliberate economic choice, intended to make Bitcoin a credible store of value in a world where every other currency has been inflated. Whether that choice was right is a debate for another time. That the choice is deliberate, and built into the protocol so that no one can change it, is what matters here.

The system changes slowly. No central party can update the rules. Any change has to be accepted by the people who run nodes. They have strong reasons to be conservative. The system is intentionally hard to upgrade, and developers have a strong deference to backwards compatibility because anything else risks breaking the trustlessness that's the whole point.

Every later lesson in this module is going to keep coming back to this list. Why does Bitcoin use a model where coins are tracked individually rather than as account balances? Survival under adversarial conditions and public verifiability. Why is Script intentionally limited? Public verifiability and validation simplicity. Why is the block reward halving? Permanence of the monetary policy. Once you have the constraints in your head, the answers stop being arbitrary.

The design has costs. They're worth naming up front because the rest of the module will not pretend they don't exist.

Bitcoin is slow. Settlement takes minutes for a payment and hours for high-value transactions. Bitcoin is expensive at scale, because every node has to validate every transaction and there's a hard limit on how many can fit in a block. Bitcoin is inflexible. The intentional restrictions on Script mean it can't be used to build the complex applications that later chains support. Bitcoin is conservative. Changes that other chains ship in months take Bitcoin years, sometimes decades.

These are not bugs. They are the cost of the trustlessness the whole system is built around. Other chains made different trades, and the rest of this course visits some of them. For the rest of this module, the question is how the specific Bitcoin design works, top to bottom.