Money, Trust And Ledgers
You learn what problem blockchains were invented to solve: sending digital value without a central referee. You finish able to explain double spending, intermediaries and shared ledgers in plain words.
You Will Be Able To
- Explain the three jobs of money: medium of exchange, store of value and unit of account.
- Describe why copying digital files makes digital cash hard to build.
- Define double spending and show how a ledger prevents it.
- Name the roles an intermediary plays in a payment and the costs it adds.
- Build a tiny ledger in Python and watch it reject an overspend.
What Money Does
Money is a tool that lets strangers trade without needing to match each other's wants exactly. Imagine you grow apples and need shoes. The shoemaker may not want apples today. Barter fails when wants do not line up. Money solves this because both sides accept the same token in the middle.
Economists describe three jobs for money. First, a medium of exchange: people accept it as payment. Second, a store of value: it keeps its worth long enough to be useful tomorrow. Third, a unit of account: prices are quoted in it, so you can compare a coffee and a bus ticket quickly.
Shells, gold, silver coins, paper notes and bank balances have all done these jobs. What they share is a common belief. Everyone expects other people to accept the token later. That shared expectation is a form of trust, and the rest of this course is about how to build it with mathematics and networks instead of with a single institution.
Money Is A Record Of Who Owns What
A gold coin carries its value in the metal. You can hand it over, and the coin itself proves the transfer happened. Most modern money works differently. Your bank balance is an entry in a database. When you pay a friend, the bank subtracts a number from your row and adds it to theirs.
That database is a ledger: an ordered list of records that says who owns what and who paid whom. Accountants have kept ledgers for thousands of years. The key question for any ledger is simple. Who is allowed to write to it, and why should anyone believe what it says?
For card payments and bank transfers the answer is the bank or the payment company. They keep the books, and the law and their reputation give you reasons to believe them. This works well in many countries. It also places one party in the middle of every payment.
| Job | What it means | Everyday example |
|---|---|---|
| Medium of exchange | Accepted in trade so you avoid barter | Paying for bread with coins or a card |
| Unit of account | A common yardstick for prices | Pricing a coffee and a flat in the same currency |
| Store of value | Keeps purchasing power over time | Saving salary for next month |
Any ledger-based money has to do these jobs well enough for people to trust it. Source: Standard economics textbook definition of money
Why Digital Cash Is Hard: Copying
Physical objects are scarce by nature. If you give me a coin, you no longer have it. Digital files behave differently. A photo, a song or a PDF can be copied with no loss, and the copy is identical to the original.
Suppose digital cash were a file containing the text 'this file is worth 10 euros'. You could pay a shop with it, keep a copy, and pay a second shop with the copy. The shops cannot tell which file is the original. Each one believes it was paid, and only one of them actually was.
This is the central difficulty of digital money. A digital token needs a rule that makes sure it can be spent only once, even though bits are trivial to duplicate.
- Alice holds one digital coin
- She sends it to Bob
- She sends the same copy to Carol
- Both payments look valid
- A shared ledger accepts only the first
Copyable digital data needs a referee, or a ledger everyone agrees on.
Double Spending
Double spending means using the same unit of value in two different payments. It is the digital version of counterfeiting, and any digital cash system has to prevent it.
The classic fix is a trusted ledger keeper. When you pay, the shop asks the bank, 'Does this person have 10 euros?' The bank checks the balance, deducts the amount and records it. If you try to pay a second shop with the same 10 euros, the bank sees a zero balance and refuses. The ledger keeper is the referee that makes spending happen in a single agreed order.
Order is the important idea. Two payments that each look valid alone cannot both be valid if together they spend more than you own. Someone has to decide which one came first. In a bank, the bank decides. In a blockchain, thousands of independent computers must agree on that order without one boss.
- A payment is valid only if the sender owns enough value at that moment.
- Once value is spent, later payments from the same value must fail.
- Every participant must see the same order of events, or they will disagree about balances.
Intermediaries And Their Costs
An intermediary is a middle party between payer and payee. Banks, card networks, payment apps and clearing houses are all intermediaries. They provide real services: they check identities, hold funds safely, settle disputes and absorb fraud losses.
They also add costs. There are fees, often a few percent on card payments. There are delays: an international transfer can take days to settle. There are opening hours and cut-off times. There are rules about who may hold an account, so some people are excluded entirely. And there is concentration of power: the intermediary can freeze, reverse or refuse a payment, sometimes for good reasons and sometimes by mistake.
None of this makes intermediaries wrong. It means that for some uses, such as small cross-border payments or services open to anyone with an internet connection, a design without a required middle party has value. Your task as a student is to see the trade-offs clearly and judge each use case on its merits.
Attempts Before Bitcoin
Digital cash was a research topic long before 2008. In the 1980s the cryptographer David Chaum proposed anonymous electronic cash and later founded a company called DigiCash. It relied on a central issuer, and the company eventually ended. In 1997 Adam Back described Hashcash, a way to attach a small computational cost to an email so that bulk spam becomes expensive. That proof-of-work idea returns in week 3.
In the late 1990s and 2000s other proposals appeared, including Wei Dai's b-money and Nick Szabo's bit gold. Each contributed ideas about scarcity, ledgers kept by many parties, and costly puzzles. None became a working, widely used system. What was missing was a way for a crowd of strangers to agree on one ledger without a central owner.
On 31 October 2008 a person or group using the name Satoshi Nakamoto announced a paper titled 'Bitcoin: A Peer-to-Peer Electronic Cash System' to a cryptography mailing list. It combined earlier ideas into one design. We study it closely in week 3.
| Year | Proposal | Idea |
|---|---|---|
| 1989 | DigiCash (David Chaum) | Private digital cash run by a company |
| 1997 | Hashcash (Adam Back) | Proof of work to stamp messages |
| 1998 | b-money (Wei Dai) | Proposal for a decentralised money system |
| 2008 | Bitcoin (Satoshi Nakamoto) | Peer to peer cash with a shared ledger |
Each step solved part of the puzzle; Bitcoin combined the pieces. Source: Original papers and proposals by the named authors
The Blockchain Idea In One Picture
Replace the single ledger keeper with many copies of the ledger, held by many computers called nodes. Anyone can run a node. Each node stores the full history of payments and checks new payments against the rules.
Payments are collected into groups called blocks. Each block contains a fingerprint of the previous block, so the blocks form a chain. Changing an old payment would change its block's fingerprint, which would break every later link. The chain is therefore easy to extend and very costly to rewrite.
The network follows shared rules about which block to accept next. Because every node can verify the rules itself, nobody needs to take a central party's word. Weeks 2 to 4 explain the pieces: cryptographic fingerprints, digital signatures and consensus.
Fit For Purpose, And How To Use This Course
A shared ledger run by strangers suits cases where participants do not trust one another, where no single party should control the record, and where open access matters. It is slower and costlier than a normal database for tasks where one trusted owner already exists. A good engineer asks first: is a regular database enough? If yes, use it.
Over 12 weeks you move from concepts to code. Weeks 1 to 4 build the foundations: money, cryptography, Bitcoin and consensus. Weeks 5 and 6 introduce Ethereum and your first smart contract. Later weeks continue from there. Each week has a study document, a slide deck, key terms and one hands-on exercise.
Work with a laptop, Python 3 and a code editor. Everything used in this module is free. Type the code yourself instead of pasting it. The small mistakes you fix along the way are where much of the learning happens.
Key Terms
- Ledger
- An ordered record of transactions that shows who owns what.
- Double spending
- Using the same unit of digital value in two separate payments.
- Intermediary
- A middle party, such as a bank or card network, that processes payments between two people.
- Medium of exchange
- A token that people accept as payment for goods and services.
- Store of value
- An asset that keeps its worth over time.
- Node
- A computer that keeps a copy of the ledger and checks new transactions against the rules.
- Block
- A group of transactions bundled together and linked to the block before it.
- Blockchain
- A ledger made of linked blocks, copied across many computers that follow shared rules.
- Trust
- A willingness to rely on another party to behave as expected.
Exercise: Build A Tiny Ledger And Stop A Double Spend
- Install Python 3 and create a file named ledger.py.
- Create a dictionary of starting balances: Alice 10, Bob 0, Carol 0.
- Write a function pay(sender, receiver, amount) that checks the sender's balance, then moves the amount, and appends a record to a list called history.
- Make pay raise a ValueError when the sender lacks funds, then call it twice with Alice sending 10 to Bob and 10 to Carol.
- Catch the error with try and except, print the message, and print the final balances and history.
- Write three sentences: who plays the referee in your code, what that costs, and what would break if two copies of the ledger were kept by different people.
Further Reading
- Bitcoin: A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto, 2008 whitepaper (sections 1 and 2)
- Money: The Unauthorized Biography, Felix Martin, The Bodley Head, 2013
- Bitcoin and Cryptocurrency Technologies, Arvind Narayanan et al., Princeton University Press, chapter 1
- Hashcash: A Denial of Service Counter-Measure, Adam Back, 2002 technical report