The Ledger That Costs Something
A ledger is the most boring object in finance and the most important one. It's a list. Each line records that value moved from one party to another, and the balance anyone holds is nothing more than the sum of the lines that mention them. The clay tablets of Mesopotamia were ledgers. So is the column of figures in your banking app, and so was the IOU Emma kept in her drawer in The Debt Beneath the Debt, right up until it went to Oscar as collateral.
Every ledger in history has had one thing in common, and that thing is a keeper. Someone holds the book, writes the lines, and decides which lines are allowed in. The keeper is what makes a ledger useful, because a list that anyone can scribble into is a list nobody can rely on. The keeper is also the ledger's weakest point. A keeper can be bribed, coerced, careless or simply wrong. A keeper can write a line that never happened, erase one that did, or refuse to write yours at all. Almost every protection we've built around money (auditors, regulators, deposit guarantees, the central bank itself) is, at bottom, an arrangement for watching the keeper.
Digital money makes the keeper harder to remove than physical money ever did. A gold coin can only be in one hand at a time; hand it to me and you no longer have it. A digital token is a file, and files copy perfectly. If I can send you a file worth ten pounds, nothing in the file itself stops me sending an identical copy to someone else a second later. This is the double-spend problem, and for the whole history of electronic payments the answer to it has been the keeper. Your bank checks its ledger, sees the money has already gone, and refuses the second payment. Take the keeper away and the problem comes back in its rawest form.
People tried. David Chaum's DigiCash in the early nineties made payments private, but it still had a central issuer checking for double spends, and it died when the company did. Adam Back's Hashcash (1997) introduced the idea of attaching a costly computation to an email so that spam became expensive to send. Wei Dai's b-money and Nick Szabo's bit gold sketched money built out of computational work, and neither was ever deployed. The pieces were lying around for a decade. Nobody had assembled them into a ledger that could run without a keeper and still be trusted.
In October 2008 a pseudonymous author calling themselves Satoshi Nakamoto published a nine-page paper titled Bitcoin: A Peer-to-Peer Electronic Cash System. On 3 January 2009 the first block of the network was mined, and embedded in it was a line from that day's front page of The Times: "Chancellor on brink of second bailout for banks." Whatever else you think of the project, the timing was deliberate. A ledger without a keeper was launched in the same week the keepers of the existing one were being rescued with money written into existence for the purpose (the mechanics of which I covered in The Dollar as Token, Part II).
This post is about how that ledger actually works, and it's going to be long. Probably the longest thing I've published here, and it needs to be. I've referred to bitcoin constantly on this blog, most recently in Read the Spec Sheet, where an inverse contract is margined and settled in the coin itself, and I've got a series on trading setups and a run of posts on the economics of utility queued up behind it. Every one of those leans on an understanding of what bitcoin is underneath the price, and I keep pushing them back because that foundation has never been laid out properly. So this is me laying it out.
If you've been reading Valeon for a while, none of that will surprise you. A lot of what gets published here is preamble: a post that exists to lay the ground for the next one, which in turn lays the ground for the one after it. Over the past few months I've started linking back to older pieces more deliberately, as reminders of the ideas a new post stands on, and you'll find plenty of that below. Each post is still written to stand on its own, so you don't need to have read anything else to follow this one; the links are there for anyone who wants the longer thread. The cross-referencing is also the thing I'd most like readers to take away from the blog as a whole. Complex ideas are never understood in a vacuum. Bitcoin makes no sense without cryptography, cryptography leans on mathematics, the economics of it leans on the history of money, and the history of money leans on physics more than most economists would care to admit. Understanding comes from crossing those lines, and I'd like you to get into the habit of crossing them too.
We'll start with the two cryptographic primitives the whole system rests on, hashing and digital signatures, because nothing after them makes sense without them. From there we'll build the chain itself, then proof of work, the mechanism that secures it, in as much technical depth as I can manage without losing anyone. Then issuance: where new coins come from and why there will only ever be about 21 million of them. Then what will have to change, because some of the cryptography underneath bitcoin has a shelf life. And finally, the part I actually care about: why tying the cost of a ledger to energy is something no monetary system has done before.
Where the mechanics get dense, I've given two versions. The intuitive one comes first, then the exact one for readers who want it. Skip the second if you like; nothing later depends on it.
Fingerprints for Data
A hash function takes any input at all, a word, a book, a film, the entire contents of a hard drive, and returns a short fixed-length string that acts as a fingerprint for it. Bitcoin uses one called SHA-256, part of the SHA-2 family designed by the NSA and published by NIST in 2001. The 256 is the length of the output in bits, which written out in hexadecimal is always 64 characters, however large or small the input was.
Here is the word "Valeon" run through it:
Valeon 401b6cfba9bbb8c34aeaaa90d5c88355f9ff8b28e56b76994917ce274cc5309d
And here is what happens when I change a single letter to lower case, and then when I add a full stop:
valeon 25f0e3c10aa225134a7121f75881a896158916f3372de24db2d025e73717a0c0
Valeon. 12de0faed24fa9bef10832943da4669c6b4a25d37c7fbba556c049ae9ed7fb33
There is no family resemblance between them. One capital letter changed, and 135 of the 256 output bits flipped, which is about as close to half as you'd expect from a coin toss. That's the first of the properties that make a hash function useful, and there are five worth knowing.
It's deterministic. The same input gives the same output every time, on every machine, forever. Hash "Valeon" on your phone tonight and you will get the string above, character for character.
It's fixed-length. The fingerprint of a single letter and the fingerprint of the complete works of Shakespeare are both 64 characters. That makes a hash a cheap way to refer to something enormous.
It has the avalanche property, which is what you just saw. Any change to the input, however small, scrambles the output completely and unpredictably. You can't nudge an input towards a hash you want, because there's no sense in which a small change produces a small effect.
It's one-way. Given the output, there is no known way to work backwards to the input short of guessing inputs and hashing them until one matches. The technical name is preimage resistance. Running the function forwards takes a fraction of a microsecond; running it backwards is, as far as anyone has ever shown, a matter of brute force.
And it's collision-resistant. Since there are infinitely many possible inputs and only
Put those together and you have something strange and very useful: a fingerprint that anyone can take, nobody can forge, and that betrays any change to the thing it was taken from. If I publish a hash today and the document later, you can check for yourself that I haven't altered a comma in between. That's the whole trick the chain is built on, and we'll get to it shortly.
The Exact Version
SHA-256 is built on what's called the Merkle–Damgård construction. The input is padded (a single 1 bit, then zeros, then the original length as a 64-bit number) until its length is a multiple of 512 bits, and then chopped into 512-bit blocks. The function holds an internal state of eight 32-bit words, starting from fixed constants derived from the square roots of the first eight primes. Each block is fed through a compression function that runs 64 rounds of mixing, every round a blend of additions modulo
None of those operations is exotic. They're the cheapest instructions a processor has, and that will matter a great deal when we get to mining, because a chip that does nothing but those operations, billions of times over in parallel, is very easy to build.
Bitcoin almost never uses SHA-256 once. Block headers and transaction IDs are hashed twice, SHA-256 of SHA-256, usually written SHA-256d. Satoshi never explained the choice. The usual reading is that it closes off a weakness in the Merkle–Damgård design called length extension, where knowing the hash of a message lets you compute the hash of that message with extra data appended without knowing the message itself. Hashing the hash removes the internal state from view. Addresses use a different pairing again, SHA-256 followed by RIPEMD-160, which shortens the fingerprint to 160 bits. Hold onto that one; it becomes important when we talk about quantum computers.
Keys, Signatures and What It Means to Own a Coin
A hash proves that data hasn't changed. It says nothing about who is allowed to change it. For a ledger without a keeper, that second question is the one that matters: if there's nobody at the desk checking your identity, what stops me writing a line that moves your money to me?
The answer is a digital signature, and it starts with a pair of keys. Your private key is a number, chosen at random from a range so large (a little under
With the private key you can sign a message, producing a short string that is unique to both the key and that exact message. With the public key, anyone can verify that the signature was produced by the matching private key, without ever learning what the private key is. Change one byte of the message and the signature no longer verifies. Try to reuse a signature on a different message and it fails. The signature is a proof that whoever wrote it holds the key, and that they approved these precise words and no others.
The distinction from hashing is worth being clear on, because they're often lumped together as "the crypto". Anyone can hash anything; a hash proves integrity. Only the keyholder can sign, and anyone can check; a signature proves authority. Bitcoin needs both, and it encrypts nothing at all. Every transaction ever made sits on the public ledger in plain view. What protects your coins is the fact that nobody else can produce your signature.
Where the Keys come from
Bitcoin's keys live on an elliptic curve called secp256k1, the set of points satisfying
with all the arithmetic done modulo that prime
A computer works that out in a few hundred steps by repeated doubling, even though
Going the other way, from the public point
Bitcoin launched with ECDSA, the Elliptic Curve Digital Signature Algorithm. Since the Taproot upgrade activated in November 2021, it also supports Schnorr signatures (BIP-340) on the same curve, which are simpler to reason about, a fixed 64 bytes, and can be combined so that several signers produce one signature. Both rest on exactly the same hard problem.
Addresses
An address is what you hand someone so they can pay you. In the very first version of Bitcoin, coins were often sent straight to a public key, a format now called pay-to-public-key, or P2PK. That was quickly superseded by pay-to-public-key-hash (P2PKH), where the address is a hash of the public key (the SHA-256 then RIPEMD-160 pairing from the last section) rather than the key itself. The public key only appears on the ledger when you spend, because that's when the network needs it to check your signature. Until then, the world sees only its fingerprint.
That looks like a small detail. It's the difference between a key sitting on the ledger for anyone to attack at leisure and a key that's revealed for a matter of minutes. Remember which coins use which format.
There Are no Balances
The last piece is the one that surprises people. Bitcoin's ledger doesn't record balances. Your wallet shows you one, but it's working it out by adding things up. What the ledger actually records are unspent transaction outputs, usually shortened to UTXOs.
Every transaction takes some existing outputs as inputs, consumes them entirely, and creates new outputs. Each output is an amount of bitcoin locked by a small script, which in the common case says "spendable by whoever can produce a valid signature for the key that hashes to this address". To spend it, you supply the public key and a signature over the new transaction. Nodes check that the key hashes to the address and the signature verifies, and the output is consumed.
Outputs can't be partly spent, in the same way you can't tear a banknote in half and spend one side. Say you hold two outputs, one of 0.3 BTC and one of 0.5 BTC, and you want to pay someone 0.6. Your transaction takes both as inputs (0.8 in total) and creates two new outputs: 0.6 to the recipient, and 0.199 back to an address you control as change. The missing 0.001 isn't assigned to anyone. Whatever the inputs exceed the outputs by is the fee, and the miner who includes the transaction collects it:
The balance you see in your wallet is the sum of all the outputs your keys can unlock. Your bank works the other way round, with one number per account that it edits in place. In Bitcoin nothing is edited. Outputs are created, and later destroyed by being spent, and the history of every coin traces back through an unbroken sequence of signatures to the moment it was minted.
Which brings us back to the problem from the introduction, now in a sharper form. Signatures stop anyone else spending your outputs. They do nothing to stop you. I can sign one transaction sending an output to you and a second transaction sending the same output to someone else, and both signatures will be perfectly valid. Each is legitimate on its own; they just can't both happen. Somebody has to decide which came first, and the whole remaining design of Bitcoin exists to answer that without a keeper.
Chaining the Pages
When you send a bitcoin transaction, it doesn't go to a bank or a server. Your wallet broadcasts it to the handful of nodes it's connected to, each of those checks it (are the inputs real and unspent, do the signatures verify, do the outputs add up to no more than the inputs) and passes it on to the nodes they're connected to. Within a few seconds it has propagated across the network and is sitting in the mempool, the waiting room of valid transactions that haven't yet been written into the ledger.
The ledger itself is written in pages, called blocks. A miner gathers a selection of transactions from the mempool, usually the ones paying the highest fee per byte, and bundles them into a candidate block. Each block holds a few thousand transactions and has two parts: the list of transactions, and an 80-byte header that summarises them.
The header is where everything interesting happens, so here it is in full. These are the real values from the very first block, the one carrying The Times headline:
Field Size Genesis block (3 January 2009)
version 4 bytes 1
previous block hash 32 bytes 0000000000000000000000000000000000000000000000000000000000000000
Merkle root 32 bytes 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
timestamp 4 bytes 1231006505 (18:15:05 UTC)
bits 4 bytes 1d00ffff
nonce 4 bytes 2083236893
--------
80 bytes
Run those 80 bytes through SHA-256 twice and you get the block's identity, its hash:
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
I've checked that myself; you can too, with about ten lines of Python. Notice the zeros at the front. They aren't a coincidence, and they're the subject of the next section. For now, look at the two fields that make the chain a chain.
The Merkle Root
The header doesn't contain the transactions. It contains a single 32-byte hash that commits to all of them, built like a tournament bracket. Every transaction is hashed. The hashes are paired off and each pair is hashed together. Those results are paired and hashed again, and so on up the tree until one hash remains at the top. That's the Merkle root, named after Ralph Merkle, who patented the structure in 1979.
Merkle root
/ \
H(AB) H(CD)
/ \ / \
H(A) H(B) H(C) H(D)
| | | |
tx A tx B tx C tx D
(When a level has an odd number of hashes, the last one is paired with itself.)
Because of the avalanche property, changing any detail of any transaction, a single satoshi on a single output, changes that transaction's hash, which changes its parent, which changes every hash above it up to the root. The header's 32 bytes are a seal over every transaction in the block. The tree has a second benefit: to prove one transaction is in a block of thousands, you only need the handful of sibling hashes on its path to the root, around a dozen for a block of 4,000 transactions, since
The Previous Block Hash
The second field is the one that turns a pile of pages into a book. Every header contains the hash of the header before it. Block 2 commits to block 1, block 1 commits to block 0, and the genesis block, having nothing before it, carries 32 bytes of zeros.
This is a linked list, the kind of data structure every first-year programming course covers, with one change. In an ordinary linked list each node holds a pointer to the next, which is just an address in memory. Here each node holds a hash of the previous one, and a hash is a pointer that also fingerprints what it points to.
Follow what happens if someone tries to edit history. Say they alter a transaction in block 800,000 to redirect a payment to themselves. The transaction's hash changes, so the Merkle root of block 800,000 changes, so its header hash changes. Block 800,001 still contains the old hash in its previous-block field, and it no longer matches. Fix that by updating the field, and block 800,001's own hash changes, which breaks block 800,002, and so on all the way to the tip of the chain. One altered satoshi near the bottom changes every block hash above it, and anyone holding a copy of the real chain can see the mismatch at a glance.
Anyone who uses git already knows this structure. Every commit hash covers the commit's contents and its parent's hash, which is why rewriting an old commit changes every commit hash after it, and why your colleagues notice when you force-push.
And that's exactly the weakness. A hash-linked list makes tampering evident and does nothing to make it hard. Git will let you rebase and rewrite as much history as you like; the hashes just tell everyone you did it. If our forger simply recomputes every block hash from 800,001 to the tip, which a laptop can do in well under a second, they end up with a chain that is perfectly self-consistent. It's different from yours, but internally there's nothing wrong with it.
Now put that next to the double-spend from the last section. I hand you one chain in which my coins went to you, and someone else a chain in which the same coins went to them. Both are internally valid, both carry valid signatures. Which one is the ledger?
With a keeper, the keeper's copy is the ledger by definition. Without one, we need a rule that every node can apply independently and that always picks the same answer, and that rule must make producing an alternative chain expensive rather than merely detectable. Making a block cheap to check but costly to produce is the job of proof of work.
Proof of Work
The rule is almost insultingly simple. A block is only valid if the hash of its header is below a certain number. That's it. Everything else in this section is an explanation of why such a dull requirement secures a ledger worth well over a trillion dollars.
The Intuitive Version
Look at a hash written in hexadecimal. Each character is one of sixteen values, 0 to f, and because the output of SHA-256 is effectively random, each character has a one-in-sixteen chance of being a zero. So a hash that starts with one zero turns up about once in every 16 attempts. Two zeros, once in 256. Three, once in 4,096. Every extra leading zero makes the requirement sixteen times harder to meet. In general, the chance that a single attempt produces at least
Now recall that you can't steer a hash. There's no way to work out in advance which input will produce a hash starting with ten zeros. The only method is to try an input, look at the result, and if it isn't good enough, change the input slightly and try again. That's what the nonce field in the header is for. It's a 32-bit number with no meaning at all (the word comes from "number used once"), and it exists purely so a miner has something to change between attempts.
I ran a toy version of this on my own laptop, single-threaded, in Python, taking the word "Valeon", appending a counter, and hashing until I found results with one, two, three leading zeros and so on:
zeros counter hash
1 51 0cbb4c9c19faf711df247c9b86e36de5b3cade453bb9425e8a73fb6d3c1fe229
2 515 00be75d063a3bb369604edfa28cbf0c8b97b15b5e132db582b54996f8f1958e1
3 1958 000541683d84f74fea7e8dd33481179cdfe84d15a0ada9b1bb109671a76ab520
4 309463 00005ce6323e44e51f85bde642ea8442a88b339c3a3d352a7286e6748e4d1764
5 2737827 00000567363217a3bc60d79d6ef1daa28b039f3111e8360b23aca93a030d6d54
6 13205034 000000005417f344576f0388d83f2a4675f52277ff8a02b66963563cfa1eba96
Six zeros took 13 million attempts and about twenty seconds (and as it happens, that one came out with eight, which is luck rather than skill). The counts don't land exactly on powers of sixteen because each attempt is a fresh roll of the dice; some runs get lucky early and some don't. On average, though, the work grows sixteen-fold with every zero.
The genesis block's hash starts with ten zeros. A block mined this month needs nineteen or twenty. At the rate my laptop managed, roughly 630,000 hashes a second, finding one would take
about twice the current age of the universe. The network as a whole finds one roughly every ten minutes.
That's the trick, and it's an asymmetry. Finding a valid hash takes, on average, an astronomical number of attempts. Checking one takes exactly one: hash the header, look at the zeros. Every node on the network can verify in microseconds work that cost the network as a whole ten minutes of a small country's electricity.
The Exact Version
Leading zeros are a convenient way of describing it, and slightly wrong. The real rule is that the double SHA-256 of the header, read as a 256-bit number, must be less than or equal to a value called the target:
A hash with many leading zeros is simply a small number, so a low target forces leading zeros as a side effect. The target itself can be any value, which means difficulty moves continuously rather than in sixteen-fold jumps.
The target is stored in the header's bits field in a compact floating-point-like format: the first byte is an exponent, the remaining three a mantissa. In general the target is the mantissa multiplied by 256 raised to the exponent minus three, so the genesis block's 1d00ffff decodes as
a 256-bit number with 32 leading zero bits. That's the easiest target Bitcoin has ever had, and the network's difficulty figure is defined relative to it:
In early October 2026 the difficulty stood at about 132.72 trillion (Pickaxe). Plug that in and the expected work per block, and the hashrate needed to find one every ten minutes on average, come out as
The first figure is about
What the Machines Are Actually Doing
It's tempting to describe mining as solving a complex mathematical puzzle, and that description does a lot of damage. Nothing is being solved. No equation is getting closer to an answer. Each attempt is a lottery ticket, and the machine's only job is to buy tickets as fast and as cheaply as physics allows.
One attempt goes like this. The 80-byte header is padded to 128 bytes, two of SHA-256's 64-byte blocks. The nonce sits in the last four bytes of the header, inside the second block, so the first block's compression never changes between attempts and is computed once and cached (the "midstate"). For each new nonce the machine runs the compression function on the second block, 64 rounds, then hashes the 32-byte result once more for the second SHA-256, another 64 rounds. It compares the result to the target. In virtually every case it's too large, and the result is discarded. Increment the nonce, repeat.
That's all a mining rig does: the same 128 rounds of 32-bit additions, rotations and XORs, trillions of times a second, throwing away almost every answer. Mining began on ordinary CPUs in 2009, moved to graphics cards in 2010, and by 2013 to ASICs, application-specific integrated circuits, chips etched to do nothing but double SHA-256. A current-generation ASIC manages a few hundred terahashes per second while drawing a few kilowatts, and it can't do anything else. It can't run a spreadsheet, it can't train a model, it can't mine a coin that uses a different hash function. It is a SHA-256 furnace.
Here's a detail that shows the scale. The nonce is only 32 bits, so there are
If none of them works, which is nearly always, something else in the header has to change to give the machine a fresh range. Miners have several levers:
- The extranonce. The first transaction in every block, the coinbase (more on it in the next section), has an arbitrary data field. Changing a few bytes there changes that transaction's hash, which changes the Merkle root, which gives the header a completely new set of 4.3 billion nonces to try.
- Version rolling. Since 2018 (BIP-320), sixteen bits of the version field are free for miners to use as extra nonce space.
- The timestamp. It can be nudged forward within the rules (it must be later than the median of the previous eleven blocks and no more than two hours ahead of the network's clock).
In practice almost nobody mines alone. Pools hand each machine a slice of the search space and ask it to report "shares", hashes that meet a much easier target, as proof it's working. When one of those shares happens to meet the real target, the pool has found a block and splits the reward in proportion to shares submitted. It smooths out the lottery for the miner, and concentrates block production in a handful of pool operators, which is a weakness I'll leave for another day.
The Difficulty Adjustment
If hashing power doubled and the target stayed fixed, blocks would arrive twice as fast. Bitcoin prevents this with a feedback loop. Every 2,016 blocks, which should take two weeks at ten minutes each, every node looks at how long those blocks actually took and rescales the target so that, at the hashrate just observed, the next 2,016 would take exactly two weeks.
The adjustment is capped at a factor of four in either direction per period. (Satoshi's code actually measures 2,015 block intervals rather than 2,016, an off-by-one error that's been left alone ever since, because fixing it would require a hard fork, and the bug is cheaper than the fork.)
This is the most important single mechanism in the design, and it gets the least attention. It means the cost of producing a block floats with whatever the entire network is collectively willing to spend. Add more machines and blocks get harder. Unplug half of them and blocks get easier. Ten minutes is held constant; the energy spent per block floats. We'll come back to that, because the energy argument at the end of this post rests on it.
Ten minutes is an average, and a loose one. Blocks arrive like decays from a radioactive sample: each hash is an independent trial, so the gaps follow an exponential distribution. Sometimes two arrive a minute apart; occasionally there's a gap of more than an hour.
Which Chain is the Ledger
Now we can answer the question the last section ended on. Every node follows one rule: of all the valid chains it knows about, the real one is the chain with the most accumulated work, the sum of the expected hashes across all its blocks. People usually call it the longest chain, and that's nearly right; what actually counts is total work, which the number of blocks only approximates.
Two miners will occasionally find valid blocks at almost the same moment, and the network briefly splits, half the nodes building on one and half on the other. Whichever branch gets the next block first now has more work, every node switches to it, and the other block is orphaned. Its miner gets nothing. Transactions in the orphaned block go back into the mempool to be picked up again. This is why a payment isn't considered settled when it first appears in a block: each block built on top of it, called a confirmation, buries it deeper. Six confirmations, about an hour, is the long-standing convention for large sums.
The double-spend is resolved the same way. Of my two conflicting transactions, whichever ends up in the most-work chain is the real one. The other references outputs that have already been spent, so every node rejects it as invalid.
What it Costs to Rewrite History
Go back to our forger in block 800,000. On a plain hash-linked chain they could recompute everything in under a second. With proof of work, every block they rewrite has to be mined again, at full difficulty, from scratch. To make their version the real one, they have to redo block 800,000 and every block after it, and then overtake the honest chain, which hasn't stopped growing while they worked.
The Bitcoin paper (section 11) works out the odds. An attacker controlling a fraction
which falls off exponentially with
It's worth being precise about what such an attacker could and couldn't do. They could reverse their own recent payments (spend coins, receive the goods, then mine a chain in which the payment never happened) and they could refuse to include other people's transactions. They couldn't spend anyone else's coins, because they can't forge signatures. They couldn't award themselves extra bitcoin, because every node checks the coinbase against the rules and rejects any block that breaks them. The work buys the power to choose the order of valid transactions and nothing more.
And at today's difficulty, that power means assembling and running more than 950 exahashes per second of dedicated hardware, more than the entire honest network combined, hardware that doesn't exist on the open market in that quantity, plus the power plants to feed it. That's the move that turns a ledger that's tamper-evident into one that's tamper-expensive. In The Benchmark Must Bleed I argued the only honest price is one you can only move by actually trading. This is the same principle applied to history itself. The only way to write a line into this ledger, or rub one out, is to burn real energy doing it, and every node can check the receipt.
The Reward and the Cap
So far I've described miners spending enormous amounts of electricity on lottery tickets, and I haven't said why anyone would. The answer is the first transaction in every block.
The Coinbase
Every block begins with a special transaction called the coinbase (no relation to the exchange, which borrowed the name). It's the only kind of transaction with no inputs. It spends nothing that already exists. It creates new bitcoin from nothing and pays it, along with all the fees from every other transaction in the block, to whatever address the miner chooses. This is the only way new bitcoin ever comes into existence, and it's the reason miners mine. The newly minted coins can't be spent until 100 more blocks have been built on top, so that a block later orphaned can't leave freshly created coins circulating that never officially existed.
This is a neat bit of design worth pausing on. Issuance and security are the same act. The process that distributes new money is the process that protects the ledger, and the person who gets the new money is whoever did the most to secure it in that ten-minute window. There's no issuer, no allocation committee, no founder's treasury. If you want new bitcoin straight from the protocol, the only way to get it is to spend energy defending the chain.
The Schedule
The amount of new bitcoin a block may create is called the subsidy. It started at 50 BTC and halves every 210,000 blocks, roughly every four years:
Halving Block Date (approx.) Subsidy per block
— 0 January 2009 50 BTC
1st 210,000 November 2012 25 BTC
2nd 420,000 July 2016 12.5 BTC
3rd 630,000 May 2020 6.25 BTC
4th 840,000 April 2024 3.125 BTC
5th 1,050,000 around 2028 1.5625 BTC
The schedule is a geometric series. Each era of 210,000 blocks mints half as much as the one before: 10.5 million in the first era, 5.25 million in the second, 2.625 million in the third, and so on, each term half the last. Summed over every era, it converges on 21 million:
The real figure is a hair under that, 20,999,999.9769 BTC, because the code works in satoshis (one hundred-millionth of a bitcoin, the smallest unit) and halving is done by integer division, so fractions of a satoshi are dropped at each step. After 33 halvings the subsidy rounds down to zero, somewhere around the year 2140, and no more bitcoin will ever be created. In practice the usable supply is lower still. The 50 coins in the genesis block can't be spent because of a quirk in how it was coded, a few early miners claimed less than they were entitled to, and a large number of coins have been lost forever to forgotten keys and discarded hard drives. Estimates of the lost supply commonly run to three or four million.
Working the schedule forward to the current block height, a little over 20.1 million have already been mined. The 20 millionth coin came out earlier this year. Over 95% of all the bitcoin that will ever exist is already here, and the remaining 900,000 or so will trickle out over the next 114 years.
Set that next to the dollar as I described it in The Dollar as Token. The dollar has a mint (government spending, and banks lending deposits into existence) and a burn (taxation, loans repaid), and the people who operate both levers adjust them in response to conditions. Bitcoin has a mint whose output was published in 2009 and can be calculated to the satoshi for any future block, and it has no burn at all. Fees are transferred to miners rather than destroyed. The only coins that ever leave circulation are the ones people lose. There's nobody to petition and no meeting to wait for. The supply is a formula.
Who Enforces the Cap
It's easy to say "there will only ever be 21 million" as though it were a law of physics. It's a rule in the software, and it's worth understanding exactly how it's enforced, because that tells you exactly how fixed it really is.
Every full node, every computer running the Bitcoin software and keeping a complete copy of the ledger, independently checks every block it receives. One of those checks is that the coinbase pays out no more than the subsidy for that height plus the fees in the block. If a miner tries to pay themselves a single satoshi too much, every node rejects the block outright. It doesn't matter how much work went into it. A block that breaks the rules is not part of any chain, however heavy. Miners have the power to order transactions; they have no power whatsoever over the rules those transactions must obey. That power sits with whoever runs nodes, which is anyone who wants to.
So the cap holds for exactly as long as the people running the software agree to keep enforcing it. That agreement has been tested. On 15 August 2010, someone exploited a bug in the code that checked whether output values added up. Block 74,638 contained a transaction creating a little over 184 billion bitcoin, in two outputs of about 92 billion each. Within hours a patched version of the software was released, it treated that transaction as invalid, and miners running it built a new chain that overtook the bad one. It remains the only time the rules were actually broken on the main chain, and the response was the network collectively agreeing to rewind and pretend it never happened.
Two things follow from that episode. The cap is code, and code has bugs. And the final defence of the cap was social: people looked at a chain that broke the rules and chose to run software that refused it. The 21 million is as fixed as the shared agreement behind it, which so far has proved very fixed indeed. When we get to quantum computing, that same shared agreement will be asked to do something much harder.
When the Subsidy Runs out
There's a tension built into the schedule that's worth naming now. Miners are paid from two sources, the subsidy and fees. Today the subsidy is most of it; for most of recent years, fees have been a small fraction of miner revenue, spiking only during bouts of congestion. Every halving cuts the subsidy in half. Unless fees rise to replace it, or the price of bitcoin doubles every four years to compensate, the total paid to miners falls, and with it the amount they can afford to spend on hashing.
Remember the difficulty adjustment: the cost of a block floats with whatever miners collectively spend. If miners earn less, they spend less, and the cost of rewriting history falls with it. Bitcoin's security budget is, in the long run, its fee market. Whether that market will be deep enough to defend the chain once the subsidy is negligible is one of the genuinely open questions about the design, and it matters directly to the argument I'll make at the end.
What Will Have to Change
Everything above rests on two assumptions: that SHA-256 behaves like a random function nobody can shortcut, and that deriving a private key from a public key is infeasible. Both hold today. Neither is guaranteed forever, and they fail in very different ways, with very different consequences for what the network would have to do about it. People tend to blur them into a single worry about "quantum breaking Bitcoin", so I'll take them one at a time.
First, two terms. A soft fork tightens the rules: it makes something that used to be valid invalid, or adds restrictions to something that was previously unconstrained. Old nodes that haven't upgraded still accept the new blocks, because everything in them was valid under the old rules too. A hard fork loosens or changes the rules: it makes something valid that old nodes would reject. Old nodes refuse the new blocks and carry on with their own chain, and unless everyone upgrades, the network splits in two. It has happened. In August 2017, after years of argument over block size, a group that wanted larger blocks hard-forked away and became Bitcoin Cash. Both chains still exist.
SHA-256 and the Mining Problem
The hash function first. Against classical computers, SHA-256 is in excellent health. The best published cryptanalysis breaks reduced versions of around 31 of its 64 rounds, and nobody has come close to the full function in the quarter-century since it was published.
Against quantum computers, the relevant tool is Grover's algorithm, which speeds up brute-force search quadratically: a search that would take
The real risks to SHA-256 mining are more mundane, and in one case already present. The first is a classical break: a mathematical shortcut that lets someone find valid hashes far faster than brute force. Whoever found it first, and kept it quiet, would hold a majority of the network's effective hashrate without anyone noticing anything except an unusually lucky miner. The second is the monoculture. An entire global industry, hundreds of exahashes of dedicated hardware, exists to compute one function. That's a tremendous amount of security while the function holds, and a tremendous amount of stranded capital if it ever needs to change.
And changing it would be the hardest upgrade Bitcoin could ever attempt. A new proof-of-work function means blocks whose header hashes are checked against a different algorithm, which old nodes would reject, so it's a hard fork by definition. Worse, it bricks every mining machine on the planet the moment it activates. The ASICs can't be reprogrammed; they're physically etched to do SHA-256 and nothing else. On activation day the network's hashrate on the new algorithm would be whatever general-purpose or freshly manufactured hardware could muster, a minute fraction of what defended the chain the day before. Difficulty would need to be reset to match, and for however long it took the new hardware to arrive, the cost of a 51% attack on the world's largest cryptocurrency would be close to the lowest it has been since about 2010.
Then there's the politics. The miners, the people with the most capital at stake, would be asked to support a change that writes off their entire fleet. If enough of them refused and kept mining the old chain, you'd have a split on the scale of 2017 or larger: one chain with the new hash and the users who upgraded, one with the old hash and all the existing security behind it, and an argument about which one is "Bitcoin" that no protocol rule can settle. Any change to the hash would have to be phased, planned years ahead, and agreed by people with sharply opposed interests. It's the kind of upgrade that's far easier to do calmly a decade early than in a panic a week late.
Signatures and the Ownership Problem
The signatures are where quantum computing actually bites. In 1994 Peter Shor published an algorithm that, on a large enough fault-tolerant quantum computer, solves the discrete logarithm problem in polynomial time, an exponential speedup over anything classical. Applied to secp256k1, it means: give a quantum computer your public key, and it gives back your private key. With the private key, an attacker can sign anything, including a transaction sending your coins to themselves, and the network will have no way to tell the difference.
No machine capable of this exists. Estimates of how many qubits it would take, and how far away that is, have been falling steadily, and 2026 has been a bad year for complacency. A Google Quantum AI resource estimate published this year put a key derivation on a suitably primed superconducting machine at around nine minutes (PostQuantum), inside the average gap between blocks. Nine minutes on a machine nobody has built is still a hypothetical, but it's a hypothetical people are now writing code against.
What's at risk depends entirely on whether a public key is visible, which is why I asked you to remember the address formats.
- Coins in the old pay-to-public-key format have their public key written on the ledger permanently. These are mostly from 2009 and 2010, around 1.7 million BTC, including an estimated 1.1 million attributed to Satoshi, spread across roughly 22,000 outputs.
- Coins at any hashed address that has ever been spent from and then reused have exposed the key, because spending reveals it. Address reuse turns out to account for most of the vulnerable balance in the largest addresses, including big exchange wallets.
- Taproot outputs, for all their other virtues, put a (tweaked) public key directly in the output, so every Taproot address is exposed from the moment it receives coins.
- And every transaction in flight exposes its key in the mempool for the minutes before it's mined. An attacker who could derive a key faster than the next block could race the owner to spend it.
Add it up and estimates put somewhere between 6 and 7 million BTC, roughly a third of all bitcoin, behind public keys that are already visible. The BIP-361 authors put the figure at over 34% (Decrypt).
The defence is new signature schemes that quantum computers can't break. NIST finalised the first standards for them in 2024, including ML-DSA (formerly Dilithium) and SLH-DSA (formerly SPHINCS+). The catch is size. A Schnorr signature is 64 bytes with a 32-byte public key. An ML-DSA-44 signature is 2,420 bytes with a 1,312-byte public key, and the smallest SLH-DSA variant produces signatures of nearly 8,000 bytes. Block space is the scarcest resource Bitcoin has, and post-quantum signatures eat it at thirty to a hundred times the rate.
Unlike the hash, the signature problem can probably be handled with soft forks, because adding a new kind of output with new spending rules is a tightening (old nodes see it as something they don't understand and leave alone). The first concrete step is BIP-360, merged into the proposals repository in February 2026, which defines a new output type called pay-to-Merkle-root. It works like Taproot with the key-path spend removed, so no classical public key ever appears on chain, and it leaves room for post-quantum signature checks to be added by later soft forks. Migration under BIP-360 is voluntary: you move your coins to the new kind of address when you choose to.
Voluntary migration solves the problem for everyone who's paying attention and still holds their keys. It does nothing for the coins whose owners are gone. Nobody can migrate Satoshi's 1.1 million coins except whoever holds Satoshi's keys, and if that person is dead, has lost them, or simply never intends to move them, those coins will sit there with their public keys exposed until someone with a quantum computer helps themselves.
That's the decision the network will eventually have to make, and there's no comfortable answer to it. In April 2026 Jameson Lopp and five co-authors published BIP-361, "Post Quantum Migration and Legacy Signature Sunset". Roughly three years after activation, sending coins to vulnerable address types would be blocked. Two years after that, coins still sitting behind the old signature schemes would be frozen, with a possible future recovery path using zero-knowledge proofs for owners who can prove they hold the key. Lopp himself said he doesn't like it, and wrote it because he likes the alternative even less.
The alternative is to do nothing and let the vulnerable coins be taken. The first actor with a capable machine, most plausibly a state, collects up to a third of the supply, including the single largest identifiable holding, and is free to sell it into the market. Holders who did everything right watch the value of their coins fall because someone else's were stolen.
Now look at what freezing actually is. Making previously valid spends invalid is a tightening of the rules, which makes it, technically, a soft fork. The most confiscatory change ever proposed for Bitcoin is, in protocol terms, one of the gentlest kinds of upgrade it can make. Either way, the network has to decide by agreement whether coins that have sat untouched for more than fifteen years still belong to the person who holds the key. That's exactly the shared agreement I said holds up the 21 million cap, now asked to rule on ownership itself. No upgrade has ever frozen coins that were validly created and held. Every path through this involves the network collectively deciding something it was designed so that nobody would ever have to decide, and the longer it waits, the less time it has to decide it calmly.
Energy as the Anchor
Strip any economy down far enough and you hit energy. Food is energy. Transport is energy. Heat, light, refrigeration, steel, fertiliser, the servers this post is hosted on, all of it is energy being converted from one form into another, with something useful extracted along the way. Anyone who has done delivery work knows this in the most literal way possible: the first cost of every shift is fuel, before a single order has been accepted (I wrote about how that cost hides in The Tangible Cost of Dead Miles). You can swap one fuel for another, oil for gas, gas for solar. You can't swap energy for something else. There is no substitute for it, and no human being, household, business or state that doesn't depend on it continuously.
It also has a property physics students learn early and most people never think about. Using energy degrades it rather than destroying it. The second law of thermodynamics guarantees that once useful energy has done its work, it ends up as low-grade heat, spread thin and unrecoverable. You can spend a joule exactly once.
Gold, and the Promise that Replaced it
Gold was money for most of recorded history, and it had good reasons to be. It's scarce, it doesn't corrode, it divides cleanly and it's expensive to dig up, which itself is a cost paid largely in energy. But gold's usefulness was always mostly conventional. The bulk of the world's gold demand is jewellery, central bank reserves and bars and coins bought as stores of value, with industrial use a small slice. Nobody needs gold to eat or keep warm. Its value rested on a very old, very widespread agreement that it was valuable.
Look closely and the twentieth-century dollar was anchored less to gold than to a promise: under Bretton Woods, foreign governments could exchange dollars for gold at $35 an ounce. What held the dollar in place was the willingness of the United States to honour that promise. On 15 August 1971 it stopped. Nixon closed the window by announcement, and the anchor that had defined the world's monetary system for a quarter of a century was suspended on television on a Sunday evening. As I put it in The Debt Beneath the Debt, the floor became a promise like all the others, and the chain of obligations has ended ever since in work not yet performed.
That's the weakness every anchor before Bitcoin shared. Whether it was gold redeemable on demand or the full faith and credit of a government, there was always someone who could change the terms: a keeper who could close the window.
What Exactly is Tied to Energy
This is where I need to be careful, because the popular version of the argument goes too far. It's often said that bitcoin's price is backed by the energy spent mining it, as though the electricity were stored inside the coins like charge in a battery. That gets the causality backwards.
Recall the difficulty adjustment. Miners compete for the block reward, and they'll keep adding machines as long as the reward is worth more than the electricity and hardware it takes to win it. As more machines join, difficulty rises, and the cost of each block climbs until it roughly meets the value of the reward. If the price of bitcoin doubles, the reward is worth twice as much, more machines switch on, and the energy spent per block rises to meet it. If the price halves, the least efficient machines lose money and switch off, difficulty falls, and the energy spent per block falls with it. Price drives hashrate, and the energy follows the price.
The economists have a name for the mistake in the popular version. A cost-of-production theory of value says something is worth what it took to make, and Carl Menger and the marginalists took it apart in the 1870s: a hole that cost a week to dig isn't worth a week's wages if nobody wants a hole. Burning energy doesn't make anything valuable by itself. If nobody valued bitcoin, the energy would stop, and nothing about the energy already spent would bring the price back.
So here's the claim I'm actually prepared to defend. Two things in Bitcoin are tied to energy, and neither of them is the price.
The first is the cost of issuance. New bitcoin can only come into existence through the coinbase of a block that carries valid proof of work. There's no other door. Whatever the market thinks a coin is worth, producing a new one costs roughly that much in energy, because competition between miners pushes the cost of winning a block up towards the value of what the block pays.
The second is the cost of rewriting history. To change a line in the ledger, you have to redo the work behind it and everything after it, faster than the rest of the world combined. The security of every past transaction is measured in energy that would have to be spent to undo it.
Neither of those costs can be waived. There's no window to close. No government, central bank, foundation or developer can issue a coin without the work, or reverse a payment without redoing it, because there's no keeper whose word could stand in for the energy. That's the property Nick Szabo had in mind when he wrote about "unforgeable costliness" years before Bitcoin existed: an asset whose production cost can't be faked. Gold had it, imperfectly, through the cost of mining. Fiat currency abandoned it. Bitcoin is the first monetary system to rebuild it from scratch, and to tie it to the one commodity every human activity depends on.
So bitcoin's price is a proxy for energy, in a specific and more interesting sense than the slogan. The network continuously converts its own market value into energy expenditure, and that expenditure into security. The higher the market values the ledger, the more energy defends it. The dollar's anchor depended on someone's willingness to keep a promise. Bitcoin's anchor is a feedback loop between price and physics that nobody is in a position to suspend.
In The Dollar as Token I argued that taxation anchors demand for the dollar: you need the token because the state requires it. Why anyone should want bitcoin in the first place is a different and harder question. It's a question about utility, and it's where the next few posts on this blog are heading. What this post can say is that whatever value the market does assign to it, that value is defended by work that has actually been done.
How much Energy
A rough figure, so the scale is concrete. At around
That's comparable to the annual electricity consumption of a mid-sized European country. Treat that as a back-of-envelope estimate; the fleet efficiency figure is the softest number in it.
All of that energy ends up as heat, and none of it produces anything except the security of the ledger. Some miners put the heat to use, warming greenhouses or homes, and some run on energy that would otherwise be wasted, flared gas at oil wells or renewable output curtailed because the grid can't absorb it. Those are real, and they don't change the basic fact that the computation itself is deliberately useless. Its only output is proof that it was done.
A Proof of Concept
Which brings me to the limits, because an argument that only lists strengths is an advert. Bitcoin has been running for seventeen years and carries well over a trillion dollars, and it's still a first attempt with first-attempt flaws, every one of which came up in the sections above.
The energy link weakens on schedule. Every halving cuts the subsidy, so unless fees grow to replace it or the price keeps doubling, the energy defending the chain will eventually fall. The security of the ledger in 2040 depends on a fee market nobody can yet show will be deep enough.
The security is welded to one hash function. An industry worth billions of dollars exists to compute SHA-256 and nothing else, which is formidable while the function holds and a crisis if it ever has to change.
The ownership layer has an expiry date of unknown length. A third of all bitcoin sits behind public keys a future machine could break, and the network will have to decide by agreement what happens to coins whose owners can't or won't move them, a decision the system was designed so nobody would ever have to make.
Block production concentrates in a handful of pools, and the energy it consumes produces nothing but heat and proof.
None of that undoes what it showed. Before 2009, nobody had built a ledger that could run without a keeper. Now there's one that has done it for seventeen years, through crashes, bans, bugs and at least one attempt to print 184 billion coins, and every block in it can be checked by anyone with a laptop. Prototypes are judged on whether the principle works. This one does, and its flaws are the specification for whatever comes next.
Every ledger before this one asked you to trust the keeper. This one asks you to check the cost. A keeper can be bribed, and a promise can be suspended on a Sunday evening. Heat, once it has left the building, doesn't come back.