How Bitcoin Works
Paper Summary: “Bitcoin: A Peer-to-Peer Electronic Cash System”
Paper by: Satoshi Nakamoto
Abstract:
Goal: To send money without any third parties, in a peer-to-peer fashion. We can use digital signatures, but we still need to solve the double-spending problem. Bitcoin is a solution to that problem.
We’re able to create a ledger of transactions by chaining blocks of hashes — build through proof of work. As long as the majority of people aren’t colluding to attack the network, the longest chain (which represents the majority of the CPU voting power), can be trusted.
The structure isn’t that complicated — messages are broadcasted through a best-effort basis + nodes leave & join at will. When nodes join back they just use the longest chain.
Introduction:
Finance on the Internet is built upon financial institutions. This works well, but there are still lots of problems — namely the cost of transactions + reversible payments.
Financial institutions have to mediate disputes → Which comes at a cost (transaction costs) → meaning we can’t do little small casual transactions. The ability to reverse transactions means the need for trust spreads. Merchants have to get more information from their customers.
What we need is not trust, but cryptographic proof. That way 2 parties can transact with each other without any third party. We can protect both sellers (must be computationally valid transactions) and buyers (escrow mechanisms).
Bitcoin is a solution to the double-spending problem through a peer-to-peer distributed ledger of computational proofs. The system is secure as long as colluding attackers don’t take up more than 50% of the system.
Transactions:
We transfer the coin to the next owner by doing this process:
Previous Transaction + Next Owner’s Public key → Hash it together → Sign with current owner’s signature.
We can verify that the whole chain is correct by verifying the signatures of the chain computationally — that’s where the “trust” comes from.
But how do we make sure that the previous owner didn’t already send this token out (double spending)? The common solution is to have a centralized authority that checks for all of this — but then the whole financial system relies on the bank not screwing things over.
Bitcoin overcomes this problem by being aware of all transactions that took place — thus we must publicly broadcast all transactions to the entire network, and have all the nodes agree on a single history.
Timestamp Server:
How do we know which transactions came in which order? That’s what this timestamp server is for. It works like this:
Previous Hash + current block → Hash it = new hash. The new hash is fed into the next block which is fed into the next block etc etc.
Now we have a chain of blocks, which is the order in which the transactions are executed. But we want something more complex than that (because we want…)
Proof of Work:
But we won’t be hashing the blocks in whatever way we want — that would be too easy! We have to implement proof of work.
Hashing works by taking all the block data + the previous hash + a nonce (which is like the seed for random numbers) and then hashing it to a value. But we want the hash to begin with a certain number of 0 bits.
Our goal is to find the nonce that produces that number of 0 bits. There’s no other way to do it except brute force. So we have to expend a ton of CPU power in order to find the nonce with the correct number of leading 0’s.
Why does this make the blockchain immutable? If we wanted to change the transactions inside of the block, that means we need to go through the same brute force process to find the new nonce.
Since we’re including the previous hash, all the blocks are chained together. This means that if we’re changing one block, we end up having to change all the blocks that are chained to it (since its hash is included in future blocks).
Thus, if an attacker wanted to change an old block, an attack has to redo the proof of work for that block, all the blocks after it, catch up with the longest chain, and surpass the honest node’s work! The probability of an attacker doing that diminishes exponentially, the older the block is.
Another system in-lieu of proof of work is majority decision making — where it’s one-IP-address-one-vote. But attackers would just have to spawn a ton of IPs to get a majority and they’d win. Proof of work is one-CPU-one-vote. So it’s much harder for an attacker to get the majority.
Also since hardware speeds up + interest in mining will vary, we can adjust the difficulty of the hash problem. It turns out that as you increase the number of leading 0’s in the hash, the problem becomes exponentially harder to solve.
Thus we just keep track of the moving average of blocks per hour and adjust the number of leading 0’s accordingly to make sure there’s a constant mining rate.
Network:
There are 6 steps to run the network:
- Transaction is broadcast to all nodes
- Nodes batch transactions into a block
- Nodes try and solve the hash problem for their batch
- When a node finds a solution, they broadcast it to all the nodes
- Nodes verify the hash + verify that the transactions are valid & not spent
- Nodes that accept the block start working on the next block (where they use the accepted hash in their next block)
We always assume that the longest chain is the correct one and work on that one. But what if two (or more) nodes find their hash and broadcast it out? Nodes will work on the first one they receive — but if it happens that the other one gets longer, then they’ll switch over to the longest chain.
If some communication is dropped it’s okay. As long as a transaction reaches lots of nodes it will still get on the blockchain. If a node misses a block, it will just request the missing blocks.
Incentive:
Every block starts with a special transaction — to mint some coins and give them to the owner of the block! It’s an incentive for nodes to support the network and to distribute the coins into circulation! There will be a steady amount of coins that go into circulation.
Another way is transaction fees — if the output value of a transaction is less than the input value, the difference will be transaction fees. Once a specific amount of coins enter into circulation, the incentive will be entirely transaction fees — so it’s still an incentive without the inflation!
This also incentives people to stay honest. A majority attacker could use their power to steal back the money from their payments, or play by the rules and make lots of money that way!
Reclaiming Disk Space:
We don’t want to store all the transaction histories — that would be too much memory! We want to discard the spent transactions without breaking the block’s hash → So we hash everything in a Merkle Tree.
Transactions are first hashed together — then their hashes are hashed together, we do this until we get 1 hash (the root hash). But we can also prune the Merkle Tree by taking out everything we don’t need to re-compute.
If blocks are generated every 10 minutes, that would mean it would only grow by 4.2 MB per year → Which is a good size since Moore’s Law says growth will be 1.2GB per year (for RAM).
Simplified Payment Verification:
We don’t have to run a full network node to verify payments. What we do instead is get the blockheads of the longest proof of work chain + get the Merkle branch. But you can’t check the transactions themselves — you just trust that others have validated it in the past (since there have been many blocks built on it already).
But we’re more vulnerable to attacks — since we can be fooled by the attacker if the attack overpowers the network. We can protect against it by accepting alerts that there was an invalid block → getting nodes to download the full block and actually verifying the transactions. But if you’re receiving frequent payments, you should probably run full nodes.
Combining and Splitting Value:
Bitcoin handles money like physical cash — in the sense where you have $5, $10, $20, etc bills. So when you’re transacting money it looks like:
You can have multiple inputs — this could be made up of lots of little transactions that sum up to the desired amount, or a single input from a previous transaction.
There are always 2 outputs, 1 output for the payment, another for the change (returned to the owner). Side note: if you have a transaction that depends on other transactions, you don’t need to copy the transactions history.
Privacy:
How do we maintain privacy when everyone is announcing transactions publically? We can keep public keys anonymous! We just see that someone is sending someone else some money but we don’t know who.
Additionally, we can have a new key pair for each transaction — linking in a multi-input transaction will still show that they have the same owner.
Calculations:
Even if there is an attacker in the system — they can never create money out of thin air nor steal money from other accounts. The attackers are only able to reverse transactions that they made in the past.
We can formulate the probability that an attacker wins through the Gambler’s Ruin problem. I don’t really understand it, but here’s the mathy part which shows that it’s really hard for an attacker to win:
Assuming p > q, there’s an exponentially lower chance in which the attacker catches up as z increases.
They have some additional confusing probability math that I don’t understand, but the problem asks how many blocks does it take until the receiver should be comfortable knowing it’s almost impossible to reverse. We can see that there’s an exponential decrease as z increases:
We can also find the number of z blocks given the q:
Conclusion:
Bitcoin! A system for electronic transactions not based on trust, coins with signatures, but overcome the double-spending problem through proof of work of the public ledger. It’s a robust yet simple system. Nodes work all at once but need little coordination + you can communicate to anonymous nodes. Nodes vote with CPU power to build on the longest chain, reject invalid blocks. That’s Bitcoin!
Bonus Insights:
I was talking with Sebastien about the paper and got a ton of insights from him — namely some clarifications on how the Merkle Trees and transactions work.
Merkle Trees are there for each block. They’re there to take all the transactions and compress them down into a hash while still allowing for someone to query the Merkle tree to verify that their transaction is there.
But wait, doesn’t that destroy the ledger component? How do we remember who transferred what to who + what the balance of each account is?
Well, the blockchain doesn’t actually remember that per-say → that’s why the transactions are designed in such a way that we refer to the previous transactions.
When we refer to the previous transactions — we have to look up that previous transaction we have to go back into the blockchain, grab the block and verify that the transaction was actually there — that’s exactly what Merkle Trees are for!
If you want to find out more: Read the paper here!
Thanks for reading! I’m Dickson, an 18-year-old Crypto enthusiast who’s excited to use it to impact billions of people 🌎
If you want to follow along on my journey, you can join my monthly newsletter, check out my website, and connect on LinkedIn or Twitter 😃
