A guided course: from fingerprints to shared history#

Start with Start here: a blockchain without the jargon and install using Your first payment, step by step. You need Python variables, lists, loops, functions, and assert. You do not need prior cryptography. Read the Glossary as needed; leave equations for a second pass. The times below are planning estimates, including exercises.

For each lesson: predict the result, run the notebook from its first cell, change one input, and explain the result in your own words. Consult Exercises after trying the exercise. A passed assertion checks a specific claim; it is not proof that a complete system is secure.

Beginner route#

Lesson

Read and run

You should be able to explain

Prerequisite / time

1

SHA-256 and the avalanche effect (FIPS 180-2, 2002), then Coin flipping by telephone: hash commitments (Blum 1981)

Why fingerprints detect changes but do not hide guessable messages

Start here / 30 min

2

Merkle trees: authenticate one item with a short proof (Merkle 1979)

How ordered sibling hashes reconstruct a trusted root

Lesson 1 / 40 min

3

Diffie-Hellman: agreeing on a secret over a public channel (1976) and RSA: a public trapdoor (Rivest, Shamir and Adleman 1978), then Elliptic-curve cryptography: a finite group you can draw (Miller and Koblitz 1985)

Public versus private values; why tiny examples can be broken

Python loops / 60 min

4

Schnorr signatures: short, fast, and linear (1989-1991), Nonce reuse in practice, and deterministic nonces (2010-2013) and Your first payment, step by step

What a signature checks and why signing nonces must not be reused

Lessons 1 and 3 / 60 min

5

Hashcash: proof of work you can verify in one hash (Back 1997) and Discrete-event simulation: a network on an event queue (GPSS 1961, Simula 1965)

Why finding a block takes work and why peers temporarily disagree

Lesson 1 / 50 min

6

Nakamoto consensus: a payment, a fork, and a reorganization (2008), then One payment from signature to reorganization and reinclusion

Pending versus included payments; how a fork changes balances and queues

Lessons 2, 4, 5 / 60 min

7

Ethereum: a replicated computer metered by gas (Buterin 2014)

Stack operations, execution budgets, and committing state only on success

Python lists / 40 min

Further investigations#

After lesson 3, explore Shamir’s secret sharing: reconstruct a secret without storing it whole (1979) and Chaum’s blind signatures: authenticate a message the signer cannot see (1982): recovering a secret and authorizing hidden information solve different problems. After lesson 6, explore Proof of stake: a stake-weighted proposer lottery (Peercoin 2012): a fair proposer lottery still needs agreement rules. Read History alongside these lessons for the origins and limits of each breakthrough; its chronological order differs from this prerequisite order deliberately.

Check your understanding#

Before moving on, answer these without code:

  • If Alice signs two conflicting payments, can both signatures verify?

  • Does an inclusion proof establish that a payment is funded or final?

  • Can two honest peers have different pending queues or selected histories?

  • Does reconnecting a link automatically send all old messages in this model?

  • Why can a payment return to a queue after a reorganization?

Answers: yes; no; yes; no (explicit synchronization is needed); and because its effect may have disappeared from the selected state, making its sequence number and balance requirements valid again. Recheck eligibility rather than assuming every displaced payment is still spendable.

A capstone experiment#

Run One payment from signature to reorganization and reinclusion. Draw its two branches on paper, label Bob’s balance at each block, and compare your predictions with the balance and queue table. Then make the winning branch contain a conflicting payment. Explain why a valid signature is insufficient to restore the original payment to a pending queue. See Exercises: ledgers and data structures (problem 7) for a checked conflict example, and Life of a payment for the same story told step by step.

The lifecycle queue handles one candidate payment per peer. Extending it to many dependent payments requires validating an ordered batch against a provisional state, plus explicit policies for conflicts and replacement. These policies are outside this lesson, not hidden behavior of the simulator.