What stops the same coin being spent twice?

Alice owns one digital coin. In the same second, she pays Bob for a coffee and Charlie for a pastry with that very coin. Both of them walk away holding a signature that checks out perfectly. So who actually got paid? Let's slow that down. Satoshi Nakamoto defined an electronic coin in a plain way: a chain of digital signatures. A chain of digital signatures. Each owner passes the coin along by signing a hash of the previous transaction together with the public key of the next owner, then attaching that signature to the end of the coin. A hash is just a short fingerprint of data. So Alice signs the coin over to Bob's public key with her private key. Bob checks the signature, and it verifies. He can follow the chain back through every earlier owner and confirm the coin passed hand to hand. Signatures prove who owns the coin. They say nothing about whether the coin was already spent. Digital data copies for free. Alice duplicates the coin, signs the copy over to Charlie's public key, and sends both at once. Bob's chain is valid, and so is Charlie's, because Alice really did sign both. This is the double-spending problem. The double-spending problem: the same coin spent twice, with nothing in the signatures able to catch it. A paper bill never does this, because once you hand it over, you no longer have it. A digital coin has no such limit. The old fix is a trusted third party. Nakamoto's paper calls it a mint. A mint is a central authority that checks every transaction against one master ledger. After each payment, the coin goes back to the mint, which issues a fresh one, and only coins straight from the mint are trusted. When Alice tries to pay Charlie, the mint says that coin already went to Bob, and rejects it. That works. Nakamoto's complaint is that the fate of the entire money system depends on the company running the mint, with every transaction going through them, just like a bank. So he set a harder goal: no mint at all. And that exposes what the mint was really doing. Holding the coins was not its power. Its power was knowing every transaction and deciding which one came first. Only the earliest transaction counts, so if Bob's coffee came first, Alice's later attempt to pay Charlie is just noise. Nakamoto points out that the only way to confirm a transaction is absent is to be aware of all transactions. Without a mint, that means transactions must be publicly announced, and everyone must agree on a single history of the order in which they arrived. The payee needs proof that, at the time of the payment, a majority of nodes agreed it was the first one received. Now picture the difficulty. Strangers on the internet, who have no reason to trust each other, must agree on what happened first, and nobody holds a clock that everyone believes. That is the job of the next module, the Proof-of-Work Engine, where we look at how Nakamoto's network builds that shared history by making it costly to rewrite. For now, keep this in mind. A chain of digital signatures proves who owns a coin, and it cannot stop the double-spending problem. A mint solved that by being the one authority that sees everything. Nakamoto wanted the same result with no trusted third party, and that means the whole network has to agree on whose transaction came first.

Picture a computer guessing a number, hashing it, checking the result, failing, and guessing again. It repeats this millions of times for a single block of payments. Nakamoto built his whole network on that effort. Let's see why. Last time we ended on a problem: strangers must agree on which transaction came first. Nakamoto's answer is a peer-to-peer timestamp server. New transactions are broadcast to everyone. Computers on the network, called nodes, collect them into a block. Then the nodes race. The race is called proof-of-work. Proof-of-work means a node proves it spent real computing effort on its block. The task goes like this. The node takes the block's data and adds a number called a nonce. It runs everything through SHA-256, which produces a fingerprint, and that fingerprint must begin with a set number of zero bits. Almost every nonce fails, so the node adds one and tries again. It's a lottery paid for with CPU power and electricity. Checking a winner is cheap, though. Everyone else verifies the answer with a single hash. So why make it hard? Because it creates one-CPU-one-vote. One-CPU-one-vote: your say in the network equals the computing power you actually spend. Nakamoto rejected one-IP-address-one-vote, since anyone who can allocate many addresses could stuff the ballot box. Computing power can't be faked that way. The first node to solve the puzzle broadcasts its block. Other nodes check that every transaction is valid and not already spent. If the block passes, they show acceptance by building the next block on top of it, using its hash as the link. That links blocks into a chain, and the rule is short. The longest chain is the truth. Say Alice wants to erase her coffee payment to Bob from an old block. Changing it changes that block's hash, which breaks the link in the block after it, so she must redo the proof-of-work for that block and every block after it, while honest nodes keep adding new ones at the far end. Each new block piles more cumulative work onto the history, and that cumulative work sets the past in cryptographic amber. Nodes follow the longest chain because it holds the most work. If honest nodes control most of the computing power, the honest chain grows fastest and stays ahead. That raises a practical question. How many blocks should Bob wait for before he hands over the coffee? The next module, The Mathematics of Waiting, answers it with numbers, showing how an attacker's odds of catching up shrink with every block added. Until then, remember that finding a nonce takes millions of guesses, checking it takes one hash, and the longest chain, heavy with cumulative work, wins.