Key Question
How can two parties transact online without trusting each other or a third party?
Deep Dive
The double-spending problem: digital money is just bits — you can copy them. If I send you a file called “1coin.txt,” I can still have it. I can send it to someone else too. Before Bitcoin, every digital cash system required a central bank to prevent this.
Double-spending problem:
┌──────┐ "I send you 1 BTC" ┌──────┐
│Bob │──────────────────────→│Alice │
│ │ │ │
│ │ "I also send the │ │
│ │ same 1 BTC to Eve" │ │
└──────┘ └──────┘
│ │
│ │
▼ ▼
┌───┐ ┌───┐
│Eve│ │ │ ← Who gets the money?
└───┘ └───┘Bitcoin (Nakamoto, 2008) solved this. Each transaction is a chain of digital signatures:
Transaction chain:
Tx0: Coinbase (created from mining)
│
│ "I, Owner0, give 1 BTC to Owner1"
│ [Signed by Owner0]
▼
Tx1: Owner1 → Owner2
│
│ Hash of Tx0 + Owner2's public key
│ [Signed by Owner1]
▼
Tx2: Owner2 → Owner3
│
│ Hash of Tx1 + Owner3's public key
│ [Signed by Owner2]
▼
...When Alice wants to pay Bob: she creates a transaction referencing a previous transaction where she received coins, includes Bob’s public key, and signs it with her private key. Bob can verify: “Alice’s signature checks out, and the previous transaction did send to Alice.”
But there’s still a problem: how does Bob know Alice didn’t sign the same coin to Charlie? Pre-Bitcoin answer: ask the bank. Bitcoin’s answer: a public, timestamped, immutable ledger — the blockchain.
Every transaction is broadcast to every node. Nodes batch transactions into blocks. Blocks are chained together cryptographically. Once a transaction is buried under enough blocks (6 confirmations is standard), it’s effectively irreversible.
Bitcoin's solution:
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│Block │→│Block │→│Block │→│Block │→│Block │
│ 100 │ │ 101 │ │ 102 │ │ 103 │ │ 104 │
└──────┘ └──────┘ └──────┘ └──────┘ └──────┘
│ │ │ │ │
Tx:A→B Tx:B→C Tx:C→D Tx:D→E Tx:E→F
(Alice's (Bob's (deep in (probabil-
payment) payment) chain → istically
confirmed) final)Bob waits for confirmations. The more blocks built on top of his transaction, the more energy (and time) it would take to rewrite history. No central authority needed.
Check Your Understanding
- What is the double-spending problem in one sentence?
- How does a transaction prove that the sender actually received those coins?
- Why does Bob wait for 6 confirmations instead of accepting the transaction immediately?
The “So What?”
Bitcoin’s real invention isn’t digital cash (that existed). It’s the proof that two strangers can transact securely with no trusted intermediary, using only cryptographic proofs and economic incentives. That insight spawned an entire field of decentralized systems.
✏️ Exercises
Exercises: Blockchain & Proof of Work
Exercise 1
If the Bitcoin network has 200 EH/s (2 × 10^20 hashes per second) and you have 1 PH/s (10^15 hashes per second), what is your probability of mining the next block?
Exercise 2
What prevents someone from changing a transaction in block #100,000? Be specific — mention the cryptographic structures involved.
Exercise 3
Why is selfish mining with 25% hashpower dangerous? What revenue advantage does the attacker gain?
Exercise 4 (Challenge)
Suppose Bitcoin’s block time is 10 minutes on average. You’re a merchant who waits for 6 confirmations before shipping. If the attacker has 40% of the total hashpower, what’s the probability they could produce a longer chain than the honest miners after 6 blocks? Assume the honest miners have 60% and blocks follow a Poisson process. (Hint: this is a variant of the “gambler’s ruin” / race problem described in the Bitcoin whitepaper.)
👁️ View Solutions
Solutions: Blockchain & Proof of Work
Exercise 1
Probability of mining the next block.
P = your_hashpower / total_hashpower P = (1 × 10^15) / (200 × 10^18) P = 1 / 200,000 P = 0.000005 = 0.0005%
In plain terms: you’d expect to mine a block once every 200,000 blocks. At 10 min/block, that’s about 3.8 years of continuous mining.
Exercise 2
Why block #100,000 transactions can’t be changed.
Each block contains the hash of the previous block in its header. Block #100,000 links to block #99,999’s hash. Changing a transaction in block #100,000 changes the Merkle root of the transaction tree, which changes the block header, which changes the block’s hash. That hash is referenced by block #100,001. You’d need to:
- Recompute PoW for block #100,000 (new nonce)
- Recompute PoW for block #100,001 (different prev_hash now)
- Recompute PoW for all blocks up to the current tip (~857,000+ blocks)
That’s more than 757,000 blocks of PoW — computationally infeasible without >50% of the total network’s hashpower.
Exercise 3
Selfish mining danger.
With 25% hashpower, the selfish miner can gain more than 25% of block rewards by:
- Withholding found blocks instead of broadcasting immediately
- Letting honest miners waste work on competing blocks
- Broadcasting their private chain at the right moment to orphan honest blocks
This breaks the core security assumption (“one-CPU-one-vote” means fair share). A rational miner with 25% hashpower is incentivized to become selfish, which degrades network security for everyone. At 33% hashpower, the attacker earns ~40% of rewards — a significant unfair advantage.
Exercise 4 (Challenge)
Attacker probability after 6 confirmations with 40% hashpower.
This is Nakamoto’s race: attacker catches up from z blocks behind, where z=6.
q = attacker hashpower = 0.4 p = honest hashpower = 0.6
Probability attacker catches up from z blocks behind:
P = (q/p)^z when q < p
P = 1 when q ≥ pP(attacker catches up from 6 behind) = (0.4/0.6)^6 = (0.667)^6 ≈ 0.0879 ≈ 8.8%
That’s an uncomfortably high probability for a $10M transaction. This is why:
- Exchanges wait 30+ confirmations for large deposits
- Zero-confirmation transactions are risky with >0% attacker hashpower
- The whitepaper formula assumes the attacker works continuously; real attackers may be less patient
With q=0.3 (30%), P = (0.3/0.7)^6 = (0.429)^6 ≈ 0.62% — much safer.