Bitcoin's monetary policy is not a promise; it is a theorem of the system's constants. A handful of integers embedded in every node's validation code—an initial subsidy of 50 BTC, a halving interval of 210,000 blocks, a target block time of 600 seconds—determine the currency's famous properties by elementary arithmetic: the 21 million cap (Theorem 15.1), the end of new issuance around 2140 (Theorem 15.2), and an inflation rate that falls toward zero (Theorem 15.3). This chapter derives these monetary theorems first, then surveys the remaining consensus constants.
Some parameters were carefully calculated; others were pragmatic choices that became fixed through network effects. Together they form the constitution of Bitcoin: Section 15.7 examines why changing any of them amounts to founding a different network.
15.1 The 21 Million Cap
Bitcoin's most famous parameter is its fixed supply limit.
Definition 15.1 (Maximum Supply)
The maximum supply of bitcoin is:
20,999,999.9769 BTC ≈ 21,000,000 BTC
This limit emerges from the halving schedule rather than being directly enforced.
Theorem 15.1 (Supply Derivation)
With initial subsidy S₀ = 50 BTC and halving every H = 210,000 blocks:
Total = H × Σᵢ₌₀^∞ (S₀ / 2ⁱ) = H × S₀ × 2 = 210,000 × 50 × 2 = 21,000,000
Proof.
The geometric series Σᵢ₌₀^∞ (1/2)ⁱ = 2. Each halving era produces 210,000 × (50/2ⁱ) coins. Summing all eras: 210,000 × 50 × (1 + 1/2 + 1/4 + ...) = 210,000 × 50 × 2. □
Remark 15.1 (Why Not Exactly 21 Million?)
The protocol maximum falls short of 21 million solely because of integer truncation in the subsidy calculation (subsidies are whole satoshis, halved by integer division). The spendable supply is lower still due to:
- Lost genesis block reward (50 BTC unspendable)
- Miners occasionally claiming less than full subsidy
- Provably burned coins
15.2 The Block Subsidy Schedule
New bitcoins are created exclusively through block subsidies, which halve approximately every four years.
Definition 15.2 (Block Subsidy)
The block subsidy at height h is:
subsidy(h) = ⌊50 × 10⁸ / 2^⌊h/210000⌋⌋ satoshis
where ⌊·⌋ denotes floor (integer truncation).
| Era | Block Heights | Subsidy (BTC) | Approx. Years | Coins Created |
|---|---|---|---|---|
| 1 | 0 – 209,999 | 50 | 2009–2012 | 10,500,000 |
| 2 | 210,000 – 419,999 | 25 | 2012–2016 | 5,250,000 |
| 3 | 420,000 – 629,999 | 12.5 | 2016–2020 | 2,625,000 |
| 4 | 630,000 – 839,999 | 6.25 | 2020–2024 | 1,312,500 |
| 5 | 840,000 – 1,049,999 | 3.125 | 2024–2028 | 656,250 |
| ... | ... | ... | ... | ... |
| 33 | ~6.7M – ~6.9M | 1 satoshi | ~2136 | 210,000 sats |
| 34+ | ~6.9M+ | 0 | ~2140+ | 0 |
Theorem 15.2 (Final Subsidy)
The last non-zero subsidy will be 1 satoshi, occurring in era 33 (approximately year 2136–2140). After era 33, all subsidy calculations truncate to 0.
Proof.
In era n the subsidy is ⌊5 × 10⁹ / 2ⁿ⁻¹⌋ satoshis. For n = 33 this is ⌊5 × 10⁹ / 2³²⌋ = ⌊1.164...⌋ = 1, while for n = 34 it is ⌊5 × 10⁹ / 2³³⌋ = 0, since 2³³ ≈ 8.59 × 10⁹ > 5 × 10⁹; the subsidy remains 0 in every later era. □
15.3 The Inflation Schedule
The supply schedule of Section 15.2 fixes not only the eventual total but the rate of issuance at every height.
Remark 15.2 (Digital Scarcity)
The 21 million cap creates absolute digital scarcity. Unlike gold (where more can be mined) or fiat (where more can be printed), Bitcoin's supply is mathematically fixed and verifiable by any node.
Theorem 15.3 (Inflation Rate)
At block height h, the annual inflation rate is approximately:
inflation ≈ (52,560 × subsidy(h)) / supply(h)
This decreases with each halving, approaching zero.
Proof.
At the 600-second target interval the network produces 6 × 24 × 365 = 52,560 blocks per year, each adding subsidy(h) to the supply. The relative annual increase is therefore 52,560 × subsidy(h) / supply(h), exact up to the variation of subsidy and supply within the year and the deviation of realized block times from the target. Since subsidy(h) halves every era while supply(h) increases, the ratio decreases toward zero. □
| Era | Supply (approx) | Annual Inflation |
|---|---|---|
| 1 (2009-2012) | ~5M | ~50% |
| 2 (2012-2016) | ~12M | ~10% |
| 3 (2016-2020) | ~17M | ~4% |
| 4 (2020-2024) | ~19M | ~1.8% |
| 5 (2024-2028) | ~20M | ~0.9% |
Remark 15.3 (Fee Transition)
As subsidy decreases, network security must increasingly rely on transaction fees. This transition is gradual (100+ years), giving the ecosystem time to develop a sustainable fee market.
Remark 15.4 (A Fair Launch)
The theorems above concern the schedule; one further property concerns its history. Every bitcoin in existence was issued through the coinbase subsidy of Definition 15.2, under rules public from the first block: there was no allocation before the chain began, no founder or investor tranche outside the consensus rules, and no sale. The openness of the rules did not produce equality of outcome—participation in early mining was sparse, and early participants, the protocol's designer among them, accumulated large holdings at negligible cost (estimates attribute roughly one million never-spent BTC to mining in 2009–2010). The property is narrower and stronger: the terms were identical for everyone who chose to participate, because the issuance function contains no privileged branch (Remark 14.3). Most later cryptocurrencies launched otherwise, with premined allocations, founder rewards, or token sales preceding public availability; Chapter 27 records examples among Bitcoin's own forks. The distinction is structural: an asset whose initial supply is allocated has, by construction, an allocator. Definition 15.2 contains no such position.
15.4 Block Timing Parameters
Definition 15.3 (Target Block Time)
The target block interval is:
T_block = 600 seconds = 10 minutes
The target is maintained by the difficulty adjustment: every 2016 blocks (about two weeks) each node recomputes the proof-of-work target from the time the previous window took. The algorithm, its clamping to a factor of 4, and its off-by-one quirk are treated in Section 14.4 (Definition 14.4); here we record only that the 600-second constant is the value the adjustment steers toward.
Remark 15.5 (Why 10 Minutes?)
Satoshi chose 10 minutes as a balance between:
- Faster: Better user experience, but more orphan blocks, wasted work, and centralization pressure
- Slower: Fewer orphans, but worse user experience and slower finality
Ten minutes allows global propagation before the next block, minimizing the disadvantage to honest miners.
Example 15.1 (Timing Calculations)
Blocks per hour: 6
Blocks per day: 144
Blocks per week: 1,008
Blocks per year: ~52,560
Time between halvings: 210,000 × 10 min = 2,100,000 min
= 35,000 hours
≈ 1,458 days
≈ 4 years
15.5 Block, Timestamp, and Script Limits
Several consensus limits constrain block contents rather than money. Each is defined in the chapter that introduces the underlying structure; we collect the cross-references here, together with the one limit not stated elsewhere.
Block size. The block weight limit of 4,000,000 weight units (Definition 13.9), equivalent to the original 1 MB size limit for witness-free blocks (Definition 13.8), is discussed with block structure in Section 13.4.
Timestamps. A block's timestamp must exceed its median time past and may run at most 2 hours ahead of network-adjusted time (Definition 13.5, Section 13.2.4); Appendix D states both rules in catalog form.
Script limits. The 10,000-byte script size, 1,000-element stack, 520-byte element, and 201-opcode bounds guarantee that script validation terminates in bounded time and space (Section 11.12, Theorem 11.1). Later script versions add limits of their own: at most 20 public keys in a CHECKMULTISIG, a 520-byte P2SH redeem script (BIP-16), and at most 100 witness stack items with 10,000-byte witness scripts under SegWit; Tapscript replaces most per-script limits with policy-only ones. Policy limits in general (for example, the 400,000-weight-unit standardness cap on transactions) are not consensus rules; Appendix D.6 catalogs them.
Definition 15.4 (Sigop Limits)
Blocks are also limited by signature operations:
- Legacy: 20,000 sigops per block
- SegWit: 80,000 sigops (weighted)
15.6 Coinbase Maturity
Definition 15.5 (Coinbase Maturity)
Coinbase outputs cannot be spent until the block has received:
100 confirmations
This is approximately 16.7 hours at average block times.
Remark 15.6 (Why 100 Blocks?)
Coinbase maturity prevents issues if a block is later orphaned:
- The coinbase reward would disappear
- Any transactions spending those coins would become invalid
- This could cascade through many dependent transactions
One hundred blocks makes deep reorganizations (which would orphan a mature coinbase) extremely unlikely.
15.7 Parameter Immutability
Consensus parameters are not merely difficult to change—altering them would create a new, incompatible network.
Remark 15.7 (Protocol Rule: Consensus Incompatibility)
A change that expands the set of valid blocks (for example, raising the block weight limit or altering the supply schedule) is a hard fork in the sense of Definition 26.5:
- Nodes running old software reject the new blocks
- The network can split into incompatible chains
The result is potentially a new currency. By contrast, tightening a parameter is a soft fork: old nodes still accept the new, stricter blocks (Chapter 16).
Example 15.2 (Parameter Change Consequences)
Changing the 21M cap would:
- Require modifying the subsidy calculation
- Be rejected by all existing nodes
- Create a new chain that existing users do not recognize
- Be economically equivalent to creating an altcoin
The resulting currency would not be "Bitcoin" in any meaningful sense.
15.8 Summary of Key Constants
| Parameter | Value | Significance |
|---|---|---|
| Maximum supply | ~21,000,000 BTC | Absolute scarcity |
| Satoshis per BTC | 100,000,000 | 8 decimal places |
| Initial subsidy | 50 BTC | Starting issuance |
| Halving interval | 210,000 blocks | ~4 years |
| Target block time | 600 seconds | 10 minutes |
| Difficulty adjustment | 2016 blocks | ~2 weeks |
| Max block weight | 4,000,000 WU | ~1.5-2 MB typical (up to ~2.3 MB) |
| Coinbase maturity | 100 blocks | ~16.7 hours |
Exercises
Exercise 15.1
Calculate the total BTC issued in the first 10 halving eras (eras 1–10). What percentage of the total supply does this represent?
Exercise 15.2
At block height 850,000, what is the block subsidy in satoshis? Show your calculation using the subsidy formula.
Exercise 15.3
If the network hash rate doubled instantly, how long would it take for difficulty to fully adjust? What would average block times be during this period?
Exercise 15.4
Why is 100 million satoshis per bitcoin (1 BTC = 10⁸ satoshis) a good choice for divisibility? What problems might arise with fewer or more decimal places?
Exercise 15.5
Estimate the year when block subsidies will fall below average transaction fees, assuming fees of 0.5 BTC per block. What assumptions does this require?