Crypto OS
Non-Technical Crypto OSStage 1 · Why Crypto Emerged

Chapter 4 · Why Bitcoin Was Invented

How do we prevent the same money from being spent twice in a digital world?

Capabilities practiced
Mental ModelProtocol Literacy
Hands on
Find a Bitcoin block in a block explorer and determine its transaction count, reward, and difficulty.
AI Lab
Have AI explain mining in pseudocode, then calculate why doubling the hash rate does not make block times faster.

A Real-World Problem

You take a photo and send it to a friend. Afterward, the photo remains on your phone.

This is a basic property of the digital world: copying costs almost nothing, and sending means copying. Music, documents, videos, and code all work this way.

Why, then, are money transfers different?

When you send your friend 100 yuan, your balance falls by 100. The money is moved rather than copied. But the numbers on the screen are also just data. Why can they not be copied?

Chapter 2 gave the answer: an institution subtracts and adds on a single ledger. The institution guarantees movement; the data itself has no special property.

Now remove the institution.

Suppose a file says, “This is a digital coin, serial number 000731.” You send it to A. The file remains on your computer, so you also send it to B.

A has a copy, B has a copy, and you have a copy. All three are identical. Nobody can say which is the real one.

The question is:

How can the same money be prevented from being spent twice in a digital world without a central institution?

Computer science discussed this problem for more than twenty years. Chapter 3 located the difficult layer: ordering, not forgery. This chapter examines the specific answer offered in 2008.

Thought Experiment

Move chapter 1's village online and try successive versions.

Version one: shells become files.

The village turns each shell into a file, such as shell-000731.txt. Whoever holds the file owns the shell.

It fails within three minutes. Copy and paste turns one into two. This version cannot even prevent forgery.

Version two: add chapter 3's secret mark.

Instead of files, people send notes. Everyone has a private seal only they can use. A transfer note says “Number 000731 belongs to B” and bears the owner's seal. Everyone can verify the owner stamped it.

Forgery is solved: without the seal, you cannot produce a valid note.

But you can still write “000731 belongs to B” for B and “000731 belongs to C” for C, stamping both with your genuine seal.

Each note is valid in isolation. B and C each verify their own note and believe they received the shell. This is chapter 3's conflicting announcements in standard digital form.

Version three: use one public ledger and accept whichever is recorded first.

The direction is right, but “first” returns the original problem. The network has no objective order: B sees their note earlier, while C sees theirs earlier. Who announces the order? Whoever does becomes Wang from chapter 2.

Version four: make announcing the order require real expenditure.

The rules become:

  1. Everyone collects received notes in a basket.
  2. Anyone may copy a batch onto a page and append it to the previous page.
  3. For others to accept that page, its author must complete a difficult task: a puzzle solved only by repeated guesses, whose correct answer everyone can immediately verify.
  4. The village accepts the longest sequence of pages. To overturn an earlier page, an attacker must redo the work from that page onward, catch up with everyone else's accumulated work, and exceed it.

Return to version two's double spend. Both notes enter the basket, but a page author may copy only one. Including both invalidates the page because the same shell appears twice, which anyone can detect.

The conflict is resolved because only one note can enter the longest sequence, not because someone judges which note is true.

Notice the ingenuity. This does not establish which note was physically earlier—that question has no answer. Instead, it makes overturning established order require continued expenditure.

Your Decision

The village must formally choose who may write the next page. Four proposals follow.

What Happens

The proposals appear to select writers but actually do the same thing:

Put an unforgeable price on the authority to announce order.

Compare them:

ProposalPrice of authorityCan it be forged?Cost of wrongdoing
HoldingsA recorded balanceNot forged, but concentratedNearly zero
First come, first servedNetwork speedUnlimited spam is possibleZero
Energy expenditureElectricity actually consumedNoAll expenditure is sunk
StakingLocked assetsNoThe stake is confiscated

The last two columns matter most. A sustainable rule needs both a price that cannot be conjured from nothing and a real financial loss for wrongdoing.

Now return to the initial question: how do we prevent money being spent twice? The answer contradicts most people's intuition.

Not by protecting the data. It can still be copied freely; anyone can copy your transaction record.

By making everyone agree on order and making that order expensive to overturn. Only one of your two notes enters the longest sequence. The other is not destroyed; it is simply never accepted.

Read that several times. It is Bitcoin's design core, and explains why the system must be slow, costly, and reward its participants.

Build a Model

A transfer takes this path before becoming effective:

  1. A sealed note
  2. Broadcast to everyone
  3. Waiting in the public basket
  4. Copied into a new page
  5. Appended to the previous page
  6. More pages follow it
The final box provides confidence. Completing the first five is not the end; chapter 6 explains why.

The second model explains long-term stability through a negative feedback loop:

  1. More puzzle solvers join → pages arrive faster
  2. Periodically, the system checks whether recent pages arrived faster or slower than the target
  3. Faster pages make the puzzle harder; slower pages make it easier
  4. Production returns to its target rhythm

One counterintuitive consequence deserves attention:

Doubling network computation does not increase page production speed. It makes the puzzle twice as hard while maintaining the rhythm.

In other words, computation buys the probability of writing during a period and the expense of rewriting history, not speed. Beginners often misunderstand this; the AI lab tests it specifically.

The third model concerns scarcity. Physical scarcity comes from matter itself. Digital systems lack that condition and need three supports:

ConditionQuestion it answersWho can change it
Supply rulesMaximum supply and issuance rhythmRules live in everyone's software
Change pathWhat changing supply requiresPersuading most participants to change software together
Verification costWhether ordinary people can inspect all historyIf everyone can verify, rules cannot deceive them

The third is easily overlooked but underpins the first two. If only a few supercomputers can verify the ledger, you must trust their claims about whether rules changed secretly. This is why a full node running on a home computer matters so much: it determines your position on chapter 3's trust scale.

Finally, how are assets recorded? This system does not store account balances. It records individual unspent notes:

  • Receiving money adds a note addressed to you.
  • Spending invalidates whole old notes and creates a new note for the recipient and a change note for yourself.
  • Your balance is the sum of your unspent notes, not a number stored somewhere.

One direct benefit: checking whether money was spent only requires checking whether its note remains in the unspent set, not replaying all history. Double-spend verification becomes a lookup.

What It Is Called

Now name the mechanisms.

Double SpendingDouble Spending

Successfully spending the same money twice.

It is digital money's fundamental challenge: data can be copied, signatures can authorize two recipients, and each transfer is valid independently.

Centralized systems prevent it by having an institution debit balances; without that institution, agreement on order must prevent it.

Digital ScarcityDigital Scarcity

Constraining quantity with verifiable rules in a world where copying costs nothing.

The data is still easy to copy. A network-maintained record determines which copy counts, and changing that record is extremely expensive.

Proof of WorkProof of Work

Qualifying to write a page requires computation that genuinely consumes resources: repeated attempts until a result meets a condition.

Two properties matter: slow to produce, fast to verify. Machines spend a long time finding an answer, but anyone receiving it can confirm it almost instantly.

This asymmetry underpins the mechanism: wrongdoing requires real expenditure, while checking it is nearly free.

MiningMining

Competing in proof of work to write the next page and earn rewards.

The metaphor can mislead. Miners provide ordering services for the network; new coins are payment for that service, rather than something they literally dig out.

Payment has two parts: newly minted coins permitted by the rules and transaction fees from the page. The first decreases on a fixed schedule; the second is expected to become the main long-term revenue source.

Difficulty AdjustmentDifficulty Adjustment

After a fixed number of pages, the system checks their production rhythm and adjusts puzzle difficulty to keep it near the target.

This is the negative feedback loop. It keeps block-production rhythm independent of network computation, allowing issuance speed to be specified in advance.

HalvingHalving

After a fixed number of pages, the reward for minting new coins falls by half.

Notice the trigger: page count, not the calendar. The exact date depends on actual block production and can be estimated but not scheduled.

Unspent Transaction OutputUTXO

The notes that have not yet been spent.

A transaction invalidates old notes and creates new ones. Your balance is the sum of unspent notes belonging to you.

This model and account balances have different trade-offs, compared in chapter 9.

Bring it together:

Bitcoin is the first digitally scarce asset without an issuer, rather than merely a better payment method.

Real resource expenditure buys agreement on one history among strangers without an administrator.

Hands-on

Hands onUnpack a Bitcoin block yourselfAny Bitcoin block explorerFree; observation only, no wallet or assets needed

No account or assets are needed. Allow twenty minutes.

Open a block explorer and find the latest block. Search for a Bitcoin block explorer and choose any accessible one; most display similar fields.

Record four numbers: block height, transaction count, block size, and block time.

Find the block reward. The first transaction in its list differs from the rest: it has no source.

This mints new coins. Record its two parts: the amount minted under the rules and the total transaction fees in the block.

Calculate the latter's share of the total reward. This is an interesting long-term metric revisited in chapter 26.

Record current difficulty and the blocks remaining until the next adjustment.

Look back through several adjustments. Difficulty fluctuates, but average block intervals remain within the same order of magnitude. You are watching the feedback loop operate.

Inspect ten consecutive block timestamps and calculate adjacent intervals.

Some may be a minute and others half an hour. The average is stable; individual intervals are random.

This matters in chapter 6: waiting for one confirmation involves uncertain waiting time itself.

Finally, travel back in time. Set block height to 1 and inspect the earliest blocks.

Record three differences: transaction count, block size, and minting reward. Their changes condense more than a decade of system history.

Write the five steps' results on half a page. This is your stage artifact's first actual on-chain dataset.

AI Lab

AI LabAsk AI for mining pseudocode, then test it with arithmeticLevel 2 · AI Copilot

Use two steps. The second is the real test.

First, ask for pseudocode:

Describe a miner’s work in no more than twenty lines of pseudocode.
Include candidate block assembly, what is attempted repeatedly, the success condition,
what is broadcast after success, and how other nodes verify it.

Use logic only, not specific library or language APIs.
Add an English comment to every line explaining what it does.

Second, ask a question it may answer incorrectly:

Assume network hashrate permanently doubles tomorrow and all other conditions remain unchanged.

Question 1: In the long run, what fraction of its previous value will average block time become?
Question 2: Will blocks arrive faster before the next difficulty adjustment?
Question 3: How does doubled hashrate affect the cost of overturning an existing block?

Show the derivation for every answer, not just the conclusion.

The second question is key. The correct answer is unchanged in the long run, but temporarily faster before the next adjustment. Both statements are required; either alone is incomplete.

Many models answer “half” to question one, treating computation as production capacity. Capacity doubles but output remains unchanged: that is the system's counterintuitive property. Difficulty adjustment absorbs changes in computation through negative feedback.

Inspect question three too. Doubled computation does not change block speed, but doubles the cost of rewriting history. Answering all three correctly demonstrates understanding. A wrong answer is a learning opportunity: questioning the model is more effective than rereading the definition ten times.

Verify these points yourself after using AI

  • Check for an incrementing nonce and a test that the result is below a target; without them, the pseudocode is not mining
  • Check the feedback direction: difficulty affects block time, and block time triggers difficulty adjustment
  • The long-term answer must be unchanged; if it says twice as fast, reject it and ask when difficulty adjusts
  • Ask about the pre-adjustment period: blocks temporarily arrive faster until the next adjustment; unchanged alone is incomplete
  • Check that block verification distinguishes slow answer discovery from fast answer checking
  • Check dates on every specific reward, difficulty, interval, or hashrate; undated numbers are unverified

Real-World Case

The sentence in the first block2008–2009

In October 2008, a nine-page paper titled “A Peer-to-Peer Electronic Cash System” appeared on a cryptography mailing list. It introduced no entirely new component: proof of work, digital signatures, and hash chains already existed.

Its contribution was combining those components, using the longest chain plus proof of work to solve the ordering problem that had remained open for over twenty years.

The first block was created in January 2009 with a newspaper headline about bank bailouts embedded inside. The sentence had no technical function; it was a timestamp and a statement of intent.

Notice the historical setting. This was an answer to chapter 1 and 2's questions erupting at a particular moment, rather than merely the start of a technology story.

Coins created from nothing, and the hours spent fixing them2010

An early version had an integer-overflow vulnerability. An attacker constructed a transaction creating far more coins than the supply limit allowed, and it was included normally in a block.

Within hours, the flaw was discovered and fixed, a new client released, and the network moved to a branch without that transaction.

Two lessons are inseparable. Rules execute through code, and code can have bugs: mathematical guarantees do not ensure correct implementation. Also, recovery required enough participants voluntarily upgrading software; nobody could compel it.

Together, they foreshadow chapter 3's 2016 case. A chain's rules are the code most people currently run, not words carved in stone.

Small chains actually attackedRepeatedly since 2018

Several small proof-of-work public chains have suffered deep reorganizations. Attackers controlled more than half the network computation, reversed confirmed transactions, and double-spent.

The shared explanation is economics, not a new technical breakthrough. These networks had little computation, so temporarily renting enough from hashrate markets could cost less than the proceeds.

This is the concrete form of chapter 3's question about surviving token prices going to zero. Security has a price: what reversing history costs versus what it earns. Their difference is the security margin.

Exchanges subsequently raised confirmation requirements for affected assets. There is no fixed answer for how many confirmations to wait. Chapter 6 explains the judgment.

Change One Variable

What ifBlock time changes from ten minutes to ten seconds

The benefit is obvious: faster confirmations and a better experience.

The cost hides in network latency. A block takes time to travel worldwide. When its interval approaches propagation time, two miners frequently produce blocks nearly simultaneously, forcing the network between competing branches.

Each confirmation then provides much less security. Thirty confirmations may be needed to match one old confirmation. Total waiting time may not shrink, while uncertainty increases considerably.

This explains chains' different choices for this parameter and the consequences attached to each. Chapter 8 lays them out.

What ifThe supply limit disappears and rewards never decline

Miners gain guaranteed long-term revenue, and network security no longer depends on a fee market. This addresses a real long-term problem.

The cost is scarcity. An asset with continuing issuance is no longer positioned as digital gold, so its narratives and holding rationales must change.

More importantly, the change itself requires most participants to switch software. Existing holders would resist. The thought experiment reveals that rule stability comes from holders' and miners' interests, not code alone. Chapter 20 uses this perspective on all token supply designs.

What ifMining replaces electricity expenditure with staked assets

Energy consumption is addressed, participation becomes easier, and writing costs fall sharply.

But wrongdoing now risks confiscated stakes rather than spent electricity. The stake is an on-chain asset whose value depends on that chain's market. A sharp price decline also shrinks its security budget.

Electricity costs are external and real, without a direct peg to the chain's token price. Stake costs are internal and self-referential. These are different risk structures, not a universally better choice. Chapter 8 compares them directly.

What ifOnly one miner remains worldwide

This reveals several things at once.

Blocks continue, because difficulty falls to what that miner can handle. The system does not stop.

But ordering security disappears. The miner can reorder transactions, rewrite history, and double-spend without opposition. They still cannot create coins from nothing or spend other people's money: signatures and rules prohibit that, and each user performs verification independently.

The distinction is crucial: consensus protects ordering; cryptography protects ownership. Miners can attack the former, not the latter. Chapter 5 explains the latter.

Takeaway Questions

Choose three of the Eighteen Questions for this chapter.

3
Why do we need a token?

Bitcoin gives a clean answer: without the token, the mechanism cannot operate.

Miners need payment in something the chain can create and transfer under its own rules. Fiat payment would require a bank account and payroll operator, collapsing the design into centralization.

Use this baseline for other projects: is the token necessary for the mechanism, or an added layer of fundraising and points? Most projects fail this test.

5
Who is paying?

Who pays for chain security?

Two parties do. New coin issuance is borne by all holders through dilution. Transaction fees are borne by users.

The first declines by design and the second must gradually replace it. Whether that transition succeeds is a long-term open question, with no answer available today. Chapter 7 explains the fee market.

10
What is the incentive?

The system's stability rests on honest mining being more profitable than attacking the network.

There are three supports: honest mining gives steady revenue, attacks require large upfront expenditure, and a successful attack reduces chain value, depreciating the attacker's equipment and coins.

The third support is crucial and fragile. It fails if attackers hold no assets on the chain or have short positions elsewhere. Most small-chain attacks involve this failure.

Chapter Check

Key idea

Bitcoin created a scarce digital asset with no central issuer.

Finished this chapter’s lab? Mark it completeView all progress

On this page