A ledger with no clock built in
Every few pages of this book refer to Bitcoin's schedule as if it runs on a calendar: a halving "every four years," a cap reached "around 2140." Those are useful shorthand, but they're approximations of something more precise underneath. The actual schedule — the one enforced by the software, not the one summarized in headlines — doesn't count years, months, or days at all. It counts blocks.
A block is simply a batch of transactions bundled together and added to the chain. Miners compete to produce the next one, and Bitcoin's issuance rule is stated entirely in terms of that count: the reward halves every 210,000 blocks, full stop. No calendar appears anywhere in the rule. The problem is that a decentralized network of computers scattered across every time zone has no shared clock to consult, and can't fully trust any single participant's clock even if it did. So the question this chapter answers is: how do you build a reliable schedule out of a process that has no clock to run on?
The ten-minute target, and why it's a target, not a guarantee
Bitcoin's mining process is deliberately hard: producing a valid block requires finding a number (a "nonce") that makes the block's hash fall under a target value, and the only way to find it is brute-force guessing, billions upon billions of guesses a second across the whole network. This is called proof of work. The network aims for one successful guess, on average, every 10 minutes.
The word "average" is doing real work in that sentence. Proof-of-work mining is a random process — closer to rolling dice repeatedly than to a metronome. Some blocks are found in under a minute; occasionally the network goes an hour or more without one. Over any single block, the 10-minute figure tells you almost nothing about when the next one will land. It only becomes meaningful once you average over many blocks, the same way a casino can't predict one dice roll but can predict its take over ten thousand of them.
The correction: difficulty adjustment
A target that's only true on average would drift badly if nothing kept it honest. The total computing power pointed at Bitcoin (its "hash rate") isn't constant — it rises as more miners join and falls when electricity gets expensive or miners switch off. If block production stayed at a fixed difficulty while hash rate doubled, blocks would start arriving roughly every 5 minutes instead of 10, and the entire schedule — halvings included — would quietly speed up.
Bitcoin corrects for this every 2,016 blocks, using a rule usually called the difficulty adjustment. At that checkpoint, the network looks at how long the last 2,016 blocks actually took and compares it to how long they were supposed to take, then scales the mining difficulty up or down proportionally.
If the last 2,016 blocks took less than 14 days — meaning hash rate had risen and blocks were arriving too fast — difficulty increases, making each individual block harder to find. If they took longer than 14 days, difficulty decreases. Either way, the adjustment is proportional: it's a ratio of expected time to actual time, applied directly to the difficulty value.
That 16.7% harder target pushes the next period's average block time back toward 10 minutes. The correction isn't unlimited, though — Bitcoin Core has always capped any single adjustment to a factor of 4, in either direction, specifically so one wildly unusual two-week period can't send difficulty to an extreme in one jump. The largest adjustment in Bitcoin's history so far happened in July 2021, when a government crackdown on mining in China took a large fraction of the network's hash rate offline almost overnight; difficulty dropped by about 28% at the next retarget to compensate. It was a sharp move, but nowhere near the 4x cap, and the network kept producing blocks and enforcing the schedule throughout — just more slowly for a few weeks until difficulty caught up.
Bitcoin doesn't check a calendar. It checks its own pulse every two weeks, and corrects itself if that pulse has drifted.
From blocks back to years
This is what makes the "every four years" language in Chapter 1 an estimate rather than a rule. The actual rule is 210,000 blocks per halving; the four-year figure is just that block count translated through the 10-minute target.
Three-point-nine-nine years rounds cleanly to "about four years," which is why that phrase shows up everywhere Bitcoin is discussed. But it's a derived number, not the actual rule — and it only holds exactly if blocks average out to precisely 10 minutes over the whole epoch, every epoch, for the next century-plus. In practice, average block time drifts slightly above and slightly below 10 minutes across different periods (hash rate isn't perfectly smooth even with the two-week correction), so real halvings land a little early or a little late relative to a naive four-year calendar countdown. This is also why any halving countdown that shows a specific calendar date — including the one on this site's homepage — is a projection built from the recent average block time, not a fact fixed in stone. The one number that is fixed in stone is 210,000 blocks; the calendar date is just today's best guess at when the network will get there. Chapter 5 lays out the full block-by-block halving table this arithmetic produces.
Timestamps: bounded, not exact
Blocks do carry a timestamp, set by whichever miner produces them — but it isn't a trusted, verified clock reading, since no single miner's clock is authoritative for the whole network. Instead, Bitcoin uses a rule called median-time-past: a new block's timestamp must be greater than the median of the previous 11 blocks' timestamps, and nodes will also reject a block whose timestamp is too far ahead of their own local clock (more than two hours, in Bitcoin Core). That leaves miners some genuine latitude — a timestamp can be a little off in either direction — but not enough room to meaningfully fake the passage of time. It's a bounded, consensus-checked estimate, not a promise, which fits the rest of this chapter: Bitcoin doesn't need an authoritative clock to run its schedule, because the schedule was never built to depend on one.
This isn't just a theoretical guardrail — a weaker version of it has been exploited for real. In April and May 2018, the Verge (XVG) cryptocurrency, a Bitcoin-derived coin that mines across five separate algorithms with independent per-algorithm difficulty adjustment, suffered two attacks in which someone submitted blocks carrying falsified timestamps to trick one algorithm's difficulty calculation into thinking far more time had passed than actually had. That kept the difficulty on that algorithm artificially low, letting the attacker mine a disproportionate share of blocks in rapid succession; estimates of the two attacks' combined losses run from roughly $1.7 million to several million dollars' worth of XVG, depending on the source and exchange rate used at the time. Bitcoin's own design closes the specific hole Verge's did not: a single difficulty across the whole network rather than five independently gameable ones, and the median-time-past rule means an attacker would have to convincingly forge the timestamps of several consecutive blocks in a row, not just one, to move the median at all. The mechanism in this chapter isn't decorative — it's the reason the same category of attack doesn't work here.
What actually keeps the clock honest
Put the pieces together and the schedule looks less like a single clock and more like a self-correcting one: a probabilistic 10-minute target that no individual block obeys exactly, a difficulty adjustment every 2,016 blocks that continuously drags the average back toward that target regardless of how much hash rate joins or leaves, and a hard rule — 210,000 blocks per halving — that only ever counts in the one unit the network can actually agree on without a central timekeeper. The four-year halving cycle isn't the rule; it's what the rule looks like once you do the division. The blocks are the rule.