Bitcoin from first principles

12 min readMar 15, 2022

Explaining Bitcoin as simply and concisely as possible. Note to purists: we ignore the UTXO concept; see the end for further reading.

A simple mental model

Imagine kids in a schoolyard with an imaginary points system, where everyone just keeps the points balances in their head. Transactions involve one of the kids announcing “I, Alice, am giving 10 of my points to Bob” and everyone mentally updating their mapping to decrement 10 points from Alice and increment 10 points for Bob.

That’s pretty much what it means to ‘own’ cryptocurrency. There is nothing physical to own, there is simply consensus among others that a certain number of points/tokens are yours. Think of it as a giant dictionary mapping names to balances, which each kid keeps in their head.

Some problems with this system are:

How can we verify that it was actually Alice who said “I, Alice, am giving 10 of my points to Bob” instead of an impostor (e.g. Bob)?
If a new kid joins the playground, then to get the current balances they need to replay every transaction from the start of time. Not great.
If a kid announces a transaction but does so very quietly, so that only their nearest neighbor hears it, has that transaction really occurred?

Solving problem (1) / transaction verification

We can solve problem (1) with asymmetric key cryptography:

In asymmetric key cryptography, each user maintains a private key (known only to them) and a related public key (which they announce to the world).
A sender who wants to prove untampered authorship of a message can then follow a particular procedure that combines the message with the sender’s private key to create a digital signature.
Anyone with the sender’s corresponding public key can combine that message with a claimed digital signature; if the signature matches the message, the origin of the message is verified (i.e., it must have been made by the owner of the corresponding private key).

In other words, asymmetric key cryptography relies on the fact that, given a public key and a message, it is very hard to create a signature that “matches” that public key and message (unless you have the private key corresponding to that public key), but it is very easy to verify that that signature does indeed match the (public key, message) pair.

For further explanation on how asymmetric cryptography allows for these digital signatures, see this article.

Asymmetric cryptography is used in many applications in computers and networking; in this context, the application is pretty straightforward. We’ll have each kid maintain a private key as well as a public key that everyone knows. When Alice wants to send Bob 10 points, she broadcasts a message announcing “I, Alice, give Bob 10 of my points”, and includes a signature for that exact message which only she could have generated.

Solving problem (2) and (3)/ adding a trusted third party

We can solve problem (2) (how to know the summary state of the world?) and (3) (how to know if a transaction has really executed?) by having a trusted third party. This third party will listen to all the transactions, maintain a running tally of everyone’s balances, and occasionally publish a “block” containing a bunch of recently-observed transactions as well as the state of the world after applying those transactions. Kids could consider a transaction as “executed” rather than simply “pending” after hearing it included in a block. (Sort of — more on that later.)

Conventionally, that trusted third party might be a big financial institution or tech provider (JPMorgan or Google). But what if we don’t want to trust them?

We need a decentralized system that incentivizes a decentralized committee of third party volunteers to produce correct “blocks”. A correct block means, a block that only contains valid transactions, and which has the correct set of balances after the transactions are applied.

The decentralized version

We will use the following scheme:

anyone can “volunteer” to be a block producer. These block producers are referred to as miners. One miner will be chosen via a lottery system roughly every 10 minutes to produce the next block.
blocks include valid transactions that the miner who produced it observed
a miner spends a small amount of (traditional) money to volunteer. The more money they spend, the more likely they are to win the lottery.
the miner who is chosen to produce the next block is allowed to include a transaction that grants themself a fixed number of points (say 25). These points come out of thin air rather than being transferred from someone
each block that is produced must designate another (previously-generated) block as its parent. The parent block must be valid in order for the child block to be valid.
if a miner hears about a new block xyz but doesn’t think that that block is valid, then instead of attempting to produce a block that descends from xyz, they will pretend that xyz didn’t exist and will re-mine the transactions that they’ve observed that haven’t been included in a valid block yet (i.e., generally the transactions that were in xyz)
there are a few more rules but this is good for now

The key here is that the miner pays a little bit of money to maybe win the lottery, and if they win, then they get a big reward (25 points) if they produced a valid block. But producing the next block incorrectly yields no reward (because everyone else will just ignore the block and re-mine those transactions). This creates an incentive to follow the rules and create valid blocks.

Additionally, the need to reference a parent (and the transitivity of invalidity from parent to child) means that future block producers must vote with their feet. Naming a block as your block’s parent is a vote of confidence for its correctness; if that parent was incorrect, you will get no reward (even if you did everything else correctly).

Note that the 25 points for the block reward came out of thin air; they weren’t transferred from anyone else; they are causing the total point count to inflate. And note that they only ‘exist’ in the sense that the miner producing that block says that her count has increased, and everyone goes along with it. But also, that’s how all of the points work; all ownership of points is strictly via consensus. Also note that if the miner producing that block had been greedy and decided to award themselves 30 points, then everyone else would have just rejected the block and tried to re-mine it. So, compliance with all of the rules of the system (including the self-reward mechanism) is enforced through consensus.

Time (and electricity) is money

The only other refinement needed is that instead of paying money into the lottery, the miner is actually paying electricity and compute time (generally on an ASIC), because the lottery is actually a brute force number search to find a number with a very unlikely special property. Each time a number satisfying this special property is found, the miner who found it is able to produce a block.

The special property

The miner is looking for a number (called the ‘nonce’) which, when concatenated with the other information in the block (the parent hash, each of the transactions, etc), produces a string that, when fed into the sha256 hashing algorithm, produces string output starting with k 0s.

There is no known inversion of sha256, so the only known way to solve this problem is by trying nonces at random. The more nonces tried, the greater likelihood of solving this problem.

k is a system parameter which auto-adjusts. The higher k is, the slower the miners in aggregate will produce blocks.

Why is this useful? Because the aggregate hashpower (i.e. total number of sha256s computable per second) of all miners might increase over time, and we still want blocks to be produced at a roughly 10 minute interval. So, we’ll have the miners follow the rule that they will observe the average block time over recent history, and if it is less than 10 minutes, k will increase, while if it is greater than 10 minutes, k will decrease.

Zooming out — consensus-based systems

At this point it will help to consider what we’ve described.

We have a virtual points/currency system, which processes transactions, verifying signatures, and updates a global ledger that maps public keys to token counts.

The system state is maintained by miners. A miner produces a block, which contains a list of transactions and the consequent ledger balances. The block must follow the rules that other miners believe are the rules of the system, otherwise the other miners will ignore that block and re-mine it.

The ability of other miners to re-mine the block (if they disagree) is crucial to enforcing all of the rules of the system in a decentralized manner. It allows all the behaviors of the system to be enforced without a centralized authority.

For example, consider the difficulty parameter k. In a traditional tech environment, there might be a centralized computer that is responsible for observing recent block times and adjusting k. But in Bitcoin, we just require the miner to include their computed value of k in the block (in addition to the nonce and all of the other information). Other miners have their own estimate of k, and if they feel the new block had an incorrect estimate (allowing for a bit of pre-defined wiggle room), then they should re-mine that block.

But also! If a miner David hears about a new block (say, block 123) produced by miner Cecilia, and it is correct, but David decides to re-mine that block anyway out of jealousy, then that will also be bad for David because even if he does manage to find another nonce, all of the other miners will be trying to mine block 124 based on Cecilia’s block, so it is very likely that David’s work will be orphaned. It is thus in David’s interest to accept correct blocks and mine on top of them.

Lastly, note that the consensus system allows for some leeway that arises from differences in individual miners, for example geography. Different miners might observe different transaction orderings; in fact, there might even be differences in the set of transactions that two miners are including when attempting to mine the same next block. That is completely allowed! The protocol is underspecified with respect to transaction inclusion and ordering; the other miners will accept a block (mine on top of it) if the block satisfied rules about transaction validity.

Due to messaging latencies between miners, it is possible in this system for two competing blocks (say, at height 1000) to be mined nearly simultaneously. This situation is referred to as a fork, and when it happens, miners of the next block (at height 1001) must choose which block to support. Each will choose the block they heard about first, because that is the most likely one to prevail. Most likely, one of the forks will have a block mined at height 1001 before the other does, at which point all miners will converge on that fork to mine block 1002. But it is possible that the two forks produce block 1001 at the same time, in which case the tie will have to be settled at block 1002 or beyond. In general, in order to feel confident that a block is definitively in the canonical blockchain, you need to wait for a few more blocks to be mined on top of it to be sure that no fork prior to that block ends up dominating.

Closing thought: the 51% attack

You have probably heard of the phrases “double-spend” or “51% attack” as sort of existential threats to Bitcoin’s legitimacy. I’ll try to explain what they would require.

First of all, note that in this system, unauthorized spends cannot happen. If Alice has 100 points associated with her public key, neither a malicious kid nor a malicious miner could steal her points unless they break extremely-hard-to-break asymmetric key cryptography. Even a miner with 51% of the hashpower of the network could not accomplish this (because transaction signing has nothing to do with hashpower).

So what kind of attack are we trying to defend against? Imagine the following scenario:

Alice has two public keys, 0xalic and 0xefgh . 0xalic has 120 points associated with it, while 0xefgh has zero.
Tesla sells cars for 100 points. That is, Alice walks onto the Tesla lot, the Tesla salesman tells Alice their address 0xtsla, Alice tells them 0xalic, Alice sends them 100 points, Tesla waits to see block 123 with a transaction successfully transferring 100 points from 0xalicto 0xtsla, then they mark down that transaction id as being used, they give Alice the car, and she drives off.
Now Alice immediately sends another transaction sending 100 points from 0xalic to 0xefgh. Note that this transaction is valid (because it was indeed signed by Alice) but also that it will fail (nothing will get transferred) because now Alice only has 20 points left in her balance. Miners include this transaction (which is valid because it had a valid signature, but which encodes a failed transfer) in block 124.
Now Alice immediately turns on her mining rig and tries to re-mine starting from block 123, but she puts her transaction sending 100 points to 0xefgh before the transaction sending 100 points to 0xtsla .
If Alice has enough hashpower, she will be able to re-mine block 123, block 124, and produce block 125 before the remaining miners produce block 125 from the original fork. (Or, perhaps they manage to mine 125, but she then mines 123–126. Et cetera.)
Alice basically needs the majority (51%) of the hashpower in order to overtake the rest of the network and rewrite history that Tesla had considered already settled. If she succeeds, then she gets to “double spend” her 100 points, i.e. gets to spend them on a real Tesla, but also gets to keep them (“spend them back to herself”).

As you can see, the 51% attack is about transaction reordering. Specifically it is about having people make real-world (“off-chain”) actions in response to an assumption that a transaction had been ordered into the blockchain — and thus that its outcome (“successful transfer”) was determined — when in fact the transaction’s order (and thus its outcome) was still alterable.

Note also that in the event that Alice does not have 51% hashpower — say she has 10% hashpower — there is still a certain chance that she can overtake the canonical chain, depending on how deep of a re-mine she needs to do. Thus, the more blocks Tesla waits after observing the successful transfer from 0xalic to 0xtsla before releasing the car, the more sure Tesla can be that that transaction won’t be reordered. A general industry rule of thumb is to wait 6 blocks before considering the transaction ‘finalized’, although of course there is still an infinitesimal probability of forking at that point.

What we didn’t cover

You now have a solid understanding of how Bitcoin works: who the actors are in the system and how they are incentivized to facilitate a decentralized ledger of balances.

A few details to mention, which you could explore in the “Further reading” section:

UTXOs: I simplified and described Bitcoin as mapping addresses to balances. Although most cryptocurrencies (e.g. Ethereum) do this, Bitcoin’s methodology is slightly more complicated; technically Bitcoin balances all live as leaves in a graph of transactions. Please see this article for a description of how balances really work in Bitcoin.
Mining pools: block reward payouts are chunky and miners might want to smooth out their return profiles. They can do this by pooling resources (many computers trying nonces with the pool operator as the reward beneficiary; pool operator shares rewards with individual miners based on their hashpower contribution)
Block reward amount exponentially decays so max supply is capped: Bitcoin (mining) block rewards were initially 50 bitcoin, and every ~2 years the reward halves. The sum of a geometric series is finite, so max supply is finite. This leads to the oft-cited view of Bitcoin as a store of value and a hedge against inflationary fiat currencies.
Why is it important that we don’t rely on a centralized authority for transaction ordering/inclusion/summarization? As we saw earlier, being able to choose the order of transactions is extremely powerful. Transaction inclusion is even more powerful, since a malicious centralized authority could elect to censor all of your transactions, effectively freezing your money. A decentralized system is valuable because it is censorship-resistant and trustless.