Introduction
This page is L1 #5 — Monetary design in the design-document series. It covers Bitcoin’s monetary layer: the rules that govern coin creation, the economic mechanisms that compensate miners, and the incentive structure that makes honest participation more profitable than attack.
The transaction design page explains how value is represented and transferred. The consensus design page explains how nodes agree on a single chain. This page sits at the intersection: how much new value enters the system per block, who receives it, and why rational miners choose to follow the rules. Forensicxs’s 2024 code walkthrough confirms the 50 BTC initial reward and 210,000-block halving interval were hardcoded from the v0.1 release.
New to these concepts? What miners are actually racing to do introduces the mining lottery and the halving schedule with no prior knowledge assumed; this page is the design-document treatment of the same issuance mechanics.
Four questions organize the material:
- How many bitcoins will ever exist? Exactly 20,999,999.9769 BTC — the result of a geometric series with 33 halvings and integer-satoshi truncation.
- What does a miner earn per block? A block reward composed of the subsidy (new coins) plus the sum of transaction fees.
- How do fees work? A decentralized auction where transactions compete for limited block space based on fee rate.
- Why mine honestly? Because the expected return from following the protocol exceeds the expected return from any known attack, given the capital cost of hash rate.
Where behavior differs between the Satoshi-era implementation (v0.1, January 2009) and modern Bitcoin Core (v27+ baseline), both are noted.
1. The 21 million cap
Bitcoin’s total supply is bounded by a geometric series. The block subsidy starts at 50 BTC and halves every 210,000 blocks (approximately every four years at the 10-minute target rate). Because the subsidy is denominated in satoshis (integer arithmetic, 1 BTC = 100,000,000 satoshis) and integer division truncates remainders, the subsidy reaches zero after 33 halvings.
The total supply is:
210,000 × (50 + 25 + 12.5 + 6.25 + … ) = 210,000 × 99.99999989 ≈ 20,999,999.9769 BTC
The last satoshi of new issuance enters circulation around block 6,929,999 (approximately year 2140). After that block, the subsidy is zero and miners earn only transaction fees.
Satoshi stated the cap publicly in the v0.1 release announcement and kept reconfirming it whenever asked directly — including a February 12, 2009 reply to Martien van Steenbergen on the P2P Research mailing list: “There is a limited supply of money. Circulation will be 21,000,000 coins. Transactions only transfer ownership.” Why 21 million and not 42, he explained to Mike Hearn in January 2011 by how people count: “The brain is better able to work with numbers from 0.01 to 1000.” Satoshi counted in cents follows that range through the code.
Halving timeline
Halving epochs
| Era | Block range | Approx. dates | Subsidy per block | New BTC in era | Cumulative supply (BTC) | % of final supply |
|---|---|---|---|---|---|---|
| 0 | 0 – 209,999 | Jan 2009 – Nov 2012 | 50 BTC | 10,500,000 | 10,500,000 | 50.00% |
| 1 | 210,000 – 419,999 | Nov 2012 – Jul 2016 | 25 BTC | 5,250,000 | 15,750,000 | 75.00% |
| 2 | 420,000 – 629,999 | Jul 2016 – May 2020 | 12.5 BTC | 2,625,000 | 18,375,000 | 87.50% |
| 3 | 630,000 – 839,999 | May 2020 – Apr 2024 | 6.25 BTC | 1,312,500 | 19,687,500 | 93.75% |
| 4 | 840,000 – 1,049,999 | Apr 2024 – ~2028 | 3.125 BTC | 656,250 | 20,343,750 | 96.88% |
| 5 | 1,050,000 – 1,259,999 | ~2028 – ~2032 | 1.5625 BTC | 328,125 | 20,671,875 | 98.44% |
| … | … | … | … halves each era | … | … | … |
| 32 | 6,720,000 – 6,929,999 | ~2136 – ~2140 | 1 sat (0.00000001) | 0.0021 BTC | ~20,999,999.9769 | ~100% |
| 33+ | 6,930,000+ | ~2140+ | 0 | 0 | 20,999,999.9769 | 100% |
The front-loading is extreme: 75% of all bitcoins were issued by mid-2016, within the first seven years. By October 2026, around block 970,000 in era 4, about 95.7% of all supply had been mined.
Satoshi-era arithmetic
The GetBlockValue function in v0.1 computes the subsidy using a right bit-shift:
nSubsidy = 50 * COIN → nSubsidy >>= (nHeight / 210000)
This is integer division by powers of two. The same logic persists in modern Bitcoin Core’s GetBlockSubsidy (in validation.cpp), with one guard added: if the shift count exceeds 63, the subsidy is explicitly set to zero. The arithmetic has been a consensus-frozen constant since genesis.
2. Coinbase reward structure
Every block contains exactly one coinbase transaction — the first transaction in the block, which has no inputs. Its outputs distribute the block reward: the sum of the subsidy (newly minted coins) and all transaction fees collected from the block’s other transactions.
Reward composition
In consensus terms: ConnectBlock() sums both sources into blockReward = nFees + GetBlockSubsidy(...) and rejects the block only if the coinbase’s actual output value exceeds that combined total — it never checks the subsidy and fee components as separate line items.
Coinbase constraints
| Constraint | Rule | Notes |
|---|---|---|
| Exactly one per block | The first transaction must be coinbase; no other transaction may be coinbase | v0.1 onward |
| No inputs | Coinbase has no previous output references; the “input” is a freeform data field | The data field is used for extra nonce, pool identification, and BIP 34 height encoding |
| Output cap | Total coinbase output value ≤ subsidy + sum of transaction fees | A miner who claims more than the allowed reward produces an invalid block |
| Maturity | Coinbase outputs cannot be spent until 100 confirmations have passed | Prevents chain reorganizations from invalidating already-spent newly minted coins |
| Height in coinbase (BIP 34) | The coinbase scriptSig must start with the serialized block height | Activated 2013; ensures every coinbase transaction is unique, preventing txid collisions |
A miner may claim less than the full reward. Any unclaimed fees are permanently destroyed — they reduce the effective supply.
Some blocks have coinbase outputs below the maximum, either by accident or by design. The mechanism was opaque enough to puzzle early users: an unexplained 50.44 BTC reward prompted a February 2010 BitcoinTalk forum post that became one of the earliest public explanations of how fees are appended to the subsidy.
3. Fee market design
When block space demand exceeds supply, transactions compete for inclusion by offering fees. The fee market is a decentralized, continuous auction with no auctioneer — each miner independently selects which transactions to include, typically prioritizing by fee rate (satoshis per virtual byte).
Fee-based transaction prioritization
In practice: the block template fills top-down by fee rate until the 4 MWU weight limit is reached, so which bucket a transaction lands in depends entirely on how many higher-fee-rate transactions are also waiting at that moment — there is no fixed fee-rate threshold for “next block” versus “waits.”
Fee mechanisms
| Mechanism | Description | Introduced | How it works |
|---|---|---|---|
| Fee rate | Satoshis per virtual byte (sat/vB) | Implicit from v0.1 | Higher fee rate = higher priority in the block template. Virtual bytes account for SegWit’s witness discount. |
| Replace-by-Fee (RBF) | Sender replaces an unconfirmed transaction with a higher-fee version | BIP 125 (opt-in, v0.12); -mempoolfullrbf option v24.0; full RBF default since v28.0 | The replacement must pay a strictly higher fee rate and cover the relay cost of the original. |
| Child-Pays-for-Parent (CPFP) | A child transaction spends a low-fee parent’s output with a high enough fee to make the package attractive | Mempool ancestor tracking (2016+) | Miners evaluate packages: including the child requires including the parent, so the combined fee rate determines priority. |
| Fee estimation | Node-side algorithm predicts the fee rate needed for confirmation within a target number of blocks | estimatesmartfee (v0.15+) | Tracks historical confirmation times in fee-rate buckets. Returns a conservative estimate for a given confirmation target. |
| Package relay | Relay low-fee parent transactions alongside their high-fee children as a single unit | Under deployment (v28+) | Ensures CPFP works across the relay network, not just at the mining node. |
Satoshi-era fee behavior
In v0.1, most transactions paid no fee at all. The client included a priority metric based on coin age (coin value × number of confirmations since the coin was created) that gave free relay and inclusion to “high-priority” transactions. As block space remained abundant through 2012, fees were economically irrelevant. The fee market only became meaningful after blocks began filling consistently (2015–2017).
4. Miner incentive model
Bitcoin’s security rests on the assumption that mining honestly — extending the most-work chain with valid blocks — is more profitable than any alternative strategy. Section 6 of the whitepaper presents this as a game-theoretic argument: a rational miner with significant hash power earns more by collecting block rewards than by attempting to defraud the network.
Incentive analysis
| Strategy | Required hash rate | Expected revenue | Risk / cost | Outcome |
|---|---|---|---|---|
| Honest mining | Any share | Block reward × (share of total hash rate) — stable, predictable income | Hardware + energy cost | Sustainable; positive expected value if operational cost < revenue |
| Selfish mining | ~25–33% (Eyal-Sirer 2014; depends on network connectivity) | Temporarily higher share of blocks by withholding and releasing at strategic moments | Withheld blocks that lose the race are wasted; needs a sizable, sustained share and good connectivity | Above the threshold, a larger share of block rewards than the attacker’s share of hash rate |
| Double-spend attack | >50% for reliable success | Reverse a confirmed payment after receiving goods/services | Enormous capital cost; risk of detection and market collapse (BTC price drop destroys attacker’s own holdings) | Economically irrational for large miners whose assets are denominated in BTC |
| Transaction censorship | >50% sustained | Exclude specific transactions from all future blocks | Same capital cost as double-spend; censored transactions simply wait for honest blocks | Ineffective unless attacker holds permanent majority; honest minority still includes censored transactions |
The self-reinforcing loop
The incentive model creates a positive feedback cycle:
This is a feedback loop, not a one-time proof: each stage depends on the one before it, and it can be entered or reinforced at any point, but it can also be weakened at any point — which is exactly the concern examined in § 6 as the subsidy link in the loop shrinks toward zero.
As Satoshi wrote in the whitepaper: “If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules.”
This argument is strongest when the block subsidy dominates the reward. As the subsidy diminishes through halvings, the incentive model increasingly depends on transaction fees — a transition examined in § 6 and in the dedicated mining reward exhaustion analysis.
5. Halving events and economic transitions
Each halving is a discrete monetary-policy event: the rate of new supply issuance drops by 50% overnight. The table below records the four halvings that have occurred, with market and network context at the time.
| Halving | Date | Block height | Subsidy before → after | Subsidy per block, post (USD ~) | BTC price (approx.) | Network hash rate (approx.) | Notable context |
|---|---|---|---|---|---|---|---|
| 1st | Nov 28, 2012 | 210,000 | 50 → 25 BTC | ~$300 | ~$12 | ~25 TH/s | First ASIC miners arriving; GPU era ending |
| 2nd | Jul 9, 2016 | 420,000 | 25 → 12.5 BTC | ~$8,100 | ~$650 | ~1.5 EH/s | SegWit debate underway; Ethereum launched one year prior |
| 3rd | May 11, 2020 | 630,000 | 12.5 → 6.25 BTC | ~$54,000 | ~$8,600 | ~120 EH/s | Institutional adoption accelerating |
| 4th | Apr 20, 2024 | 840,000 | 6.25 → 3.125 BTC | ~$200,000 | ~$64,000 | ~600 EH/s | Spot Bitcoin ETFs approved in US (Jan 2024); Ordinals/inscriptions driving fee spikes |
Each halving forces a structural adjustment in the mining industry. Miners whose operational costs exceed revenue at the new subsidy level must either find cheaper energy, upgrade to more efficient hardware, or shut down. Historically, hash rate has dipped briefly after each halving before resuming growth — evidence that the surviving mining fleet is more cost-efficient than its predecessor.
Subsidy dominance erosion
In eras 0–3, the subsidy constituted over 95% of the average block reward. Fee share has grown measurably since 2017 as blocks fill consistently, and at peaks of demand it has outrun the subsidy: block 840,000, the fourth halving block, paid 37.63 BTC in fees against a 3.125 BTC subsidy. The long-term trend is toward fee dominance as the subsidy approaches zero.
6. The fee-only future
Around the year 2140, the block subsidy reaches zero. From that point forward, miners’ sole revenue source is transaction fees. Whether fees alone can sustain sufficient proof-of-work security is the subject of ongoing debate — a central open question in Bitcoin’s long-term monetary design.
The security-budget question
The concern: if block rewards drop too low, the cost of attacking the network (acquiring >50% hash rate) falls proportionally. A fee-only regime must generate enough total fee revenue per block to keep the cost of a 51% attack prohibitively expensive.
Satoshi’s original position, expressed in Section 6 of the whitepaper and in subsequent forum posts, was that transaction fees would replace the subsidy smoothly:
Satoshi Nakamoto (BitcoinTalk post, February 14, 2010, 3:52:23 PM UTC)In a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes.
Arguments on both sides
| Position | Argument | Key reference |
|---|---|---|
| Fees will suffice | As Bitcoin adoption grows, demand for block space grows. Even small per-transaction fees, multiplied across thousands of transactions per block, can match or exceed current subsidy-era revenue. Layer-2 systems (Lightning) reduce on-chain volume but drive periodic settlement transactions with high fees. | Satoshi’s whitepaper §6; market evidence from 2017 and 2023–2024 fee spikes |
| Fees may not suffice | Fee revenue is volatile — it depends on demand cycles, not on a predictable schedule. Without a guaranteed minimum reward, miners face uncertain income, and the network faces uncertain security. Game-theoretic models suggest that fee-only mining introduces new instabilities (selfish mining becomes more attractive when rewards are variable). | Carlsten et al., “On the Instability of Bitcoin Without the Block Reward” (ACM CCS 2016) |
This question is explored in depth in the mining reward exhaustion analysis, which examines the documented debate and the game-theoretic models. The separate fixed supply vs adjustable money analysis places the 21 million cap in the broader context of monetary-design alternatives, including Wei Dai’s elastic-supply proposal in b-money and the fiat baseline of central-bank discretion. The digital-gold structural analysis reads the same cap from the opposite end: not how it is enforced but why it endures. It argues that the property making Bitcoin ‘digital gold’ is the cap’s political survival, which rests on the network’s decentralization rather than on the halving arithmetic alone.
7. Two-era comparison
| Feature | Satoshi era (v0.1, Jan 2009) | Modern Bitcoin Core, v27+ baseline |
|---|---|---|
| Total supply cap | 20,999,999.9769 BTC (geometric series, integer truncation) | Same — consensus-frozen constant |
| Subsidy calculation | nSubsidy = 50 * COIN; nSubsidy >>= (nHeight / 210000) | Same arithmetic; explicit zero-guard for shift ≥ 64 added |
| Halving interval | 210,000 blocks | Same |
| Coinbase maturity | 100-block maturity rule | Same |
| Coinbase height | Not required | Required (BIP 34, activated 2013) — block height serialized in coinbase scriptSig |
| Fee behavior | Most transactions free; priority based on coin age | Fee-rate auction (sat/vB); coin-age priority removed |
| Fee estimation | None — fees were negligible | estimatesmartfee — bucket-based mempool fee estimation |
| Replace-by-Fee | v0.1 let an unconfirmed transaction be replaced via nSequence (not a fee mechanism); Satoshi disabled it in an August 2010 commit released in v0.3.12, “just to reduce surface area”; first-seen policy afterward | Opt-in RBF (BIP 125, v0.12); full RBF default since v28.0 |
| CPFP | Not implemented | Ancestor-aware mempool; package evaluation for mining |
| Package relay | Not applicable | Under deployment (v28+) — relay parent+child as unit |
| Block template | Internal miner; trivial ordering | getblocktemplate (BIP 22/23); fee-rate-sorted mempool; SegWit weight accounting |
| Witness discount | Does not exist | Witness bytes at 1/4 weight (BIP 141) — incentivizes efficient use of block space |
8. Limits of this page
This page covers the monetary and incentive layer in isolation. The following topics are out of scope and addressed in their respective domain pages within the design-document series:
- Proof-of-work mechanics — the SHA-256d hash puzzle, difficulty adjustment algorithm, and block validation rules are covered in the consensus design page.
- Transaction structure — UTXO model, Script evaluation, and signature verification are covered in the transaction design page.
- Block template construction — how miners assemble candidate blocks from the mempool, including transaction ordering and weight optimization.
- Mining pool protocols — Stratum v1/v2, share accounting, and pool payout models. Covered in the ecosystem design page §5.
- Layer-2 fee dynamics — how Lightning Network channel opens/closes and submarine swaps interact with on-chain fee markets. Covered in the ecosystem design page §2.
- Security model — 51% attack economics, selfish mining game theory, and the full threat model are deferred to the security-model deep dive, which shares the same Eyal-Sirer selfish-mining threshold and fee-only security-budget transition this page introduces in §4 and §6.
The mining-reward-exhaustion analysis takes the same framework past the point where issuance ends.
