The double-spend and shared-truth problem
The problem
A group of strangers who do not trust each other, and have no shared clock and no referee, must agree on one history of who paid whom — permanently.
Story context
You can already send a photo to a thousand people. Digital data copies perfectly and for free. That is exactly why money cannot be a plain file.
Every working digital payment system in 2008 solved this the same way: put one trusted institution in the middle to keep the authoritative ledger.
That works — until you ask what happens when the institution is unavailable, censoring, compromised, or simply not shared by both parties.
Remove the referee and every hard problem appears at once: copies, ordering, disagreement, and fake identities. This chapter walks into each of them deliberately.
Two people are paid with the same money at the same moment. Who was paid?
Obvious answerWhichever transaction arrived first.
Why it failsThere is no shared clock and no single observer. Each node has its own arrival order, so 'first' is a different answer on every machine.
Therefore requiredThe system needs an agreed ORDER of events that does not depend on any one participant's local view.
A bank solves this instantly. Why not just use a bank?
Obvious answerAppoint a trusted server to decide the order.
Why it failsThat server becomes a single point of failure, censorship and reversal. The problem being solved here is specifically: agreement WITHOUT a privileged party.
Therefore requiredAgreement must survive the absence of any trusted referee.
If there is no referee, why not let the nodes vote?
Obvious answerOne node, one vote — majority wins.
Why it failsNode identities are free to create, so an attacker manufactures a million voters for almost nothing.
Therefore requiredInfluence must be tied to something scarce and costly, not to names.
Once we agree, what stops someone quietly editing the record later?
Obvious answerKeep backups and compare them.
Why it failsBackups are as editable as the original, and comparing them only tells you they differ — not which one is true.
Therefore requiredHistory must be linked so that any edit is detectable, and rewriting it must be expensive.
Commit to an answer before reading on. Your first choice is recorded and locked — a wrong choice is useful here, it shows you exactly which property the system is missing. This stage completes once every step has an attempt, whatever the score.
Step 1
Alice has exactly one unit of digital money. She sends it to Bob for a laptop and, seconds later, sends the same unit to Charlie for a phone. Both messages are genuine and correctly signed by Alice.
What is the actual problem here?
Step 2
You are asked to fix it. Your first instinct is to have each node accept whichever transaction it saw first.
What happens across four nodes on a network with delay?
Step 3
You appoint one trusted server to declare the official order.
Why is this rejected for a permissionless system?
Step 4
No referee, then: the nodes vote and the majority decides the order.
What does an attacker do?
Step 5
You now have four failed attempts and a list of properties each one lacked.
Which combination is the minimum requirement?
Learning objectives
ProblemTwo parties who do not trust each other need to agree that a payment happened.
Why the existing approach failsThe standard answer is a trusted third party holding the master ledger. It genuinely works, and most of the world runs on it. But correctness now depends entirely on that one party: its availability, its honesty, its jurisdiction, and its willingness to serve both parties.
MechanismThe bank's ledger is authoritative because everyone agreed in advance to treat it as authoritative. Nothing cryptographic is doing that work — it is an institutional agreement.
Notice what the central authority actually provides: not secrecy, but ORDER. It decides which transaction came first and therefore which one is valid.
Any system that removes the authority must replace that ordering function with something else. That 'something else' is what we spend this entire chapter constructing.
Engineering note
Frame the whole track this way
ProblemA digital coin is data, and data copies perfectly.
Why the existing approach failsSigning a coin file proves who authorised a spend. It does not stop the same signed coin from being handed to two different people, because both copies are equally valid signatures.
Alice holds one spendable output worth 1 coin. She signs a transfer to Bob. She also signs a transfer of the same output to Charlie. Both signatures verify. Both messages are authentic.
So authenticity is not the missing property. What is missing is a shared answer to: which of these two spends of the same output does the network accept?
Common myth
Myth: cryptography alone prevents double-spending
ProblemIf every node keeps its own copy of the ledger, whose copy is right?
Why the existing approach failsTimestamps do not help: participants have no shared clock and can lie about time. Arrival order does not help either — network latency means different nodes honestly see different transactions first.
MechanismThe network needs a rule that any node can apply independently and arrive at the same answer, without asking anyone's permission and without trusting anyone's claim about time.
Peer-to-peer gossip spreads transactions quickly but not instantly and not in a uniform order. Node A may see TX-A first while Node B sees TX-B first. Neither node is faulty.
This is why 'just use a timestamp' is not an engineering answer. It converts a distributed agreement problem into a trust-the-clock problem.
ProblemIf nodes disagree, why not let them vote?
Why the existing approach failsOn an open network, identities are free. One attacker can create a thousand or a million node identities for close to nothing and outvote every honest participant. This is the Sybil problem.
MechanismParticipation has to cost something that cannot be faked by duplicating identities. In Bitcoin, that cost is computational work: the credential that makes a participant count is the ability to supply hash power, not the ability to claim a name.
Read that carefully: this is resistance to CHEAP IDENTITY CREATION. It is not human identity verification, and it does not make participants trustworthy. It makes influence expensive.
Permissioned systems solve the same problem differently — by controlling membership. That is a legitimate engineering choice, covered later in BCM-I.
MechanismTransactions wait in a pending pool (the mempool). A producer selects a subset into a candidate block, summarises them with a Merkle root, and commits to the previous block's header hash.
Because each header commits to the previous header's hash, editing an old transaction changes its Merkle root, which changes that block's header hash, which breaks the next block's reference. You will do exactly this in the simulator.
That gives DETECTION: any node can cheaply notice that a chain is internally inconsistent.
It does not give PREVENTION on its own. An attacker who can recompute every subsequent header can present an internally consistent alternative chain. What stops that is the cost of producing those headers, plus a rule for choosing between competing chains.
Manual says
Blockchain makes data tampering impossible.
Current practice
Hash linkage makes tampering DETECTABLE and, combined with cumulative proof-of-work and a most-work chain rule, makes rewriting deep history economically impractical. 'Impossible' is not a property any deployed system has.
MechanismA valid block header must hash below a difficulty target. Finding such a header requires many attempts; checking one is a single hash.
This asymmetry is the whole trick. Producing history is expensive; auditing it is nearly free, so even a laptop can independently reject an invalid chain.
Miners do not march through one shared nonce sequence. Each builds a different candidate — different transaction set, timestamp, coinbase/extraNonce — so they explore different search spaces in parallel.
When one succeeds, the block propagates, everyone verifies cheaply, losers discard their candidate and rebuild on the new tip, and transactions that just got confirmed leave the pending pool.
Careful
Ten minutes is a target average, not a deadline
Inclusion in a block is not the end. A competing branch can still appear, and the network follows the chain with the most cumulative work.
Each additional block on top makes a reorganisation that would undo your transaction require redoing more work. Confidence rises; it never becomes a mathematical certainty.
This is why merchants speak about confirmation depth in terms of risk and value, not in terms of 'confirmed / not confirmed'.