Bitcoin's behavior is determined by a set of fixed parameters embedded in every node's software. These consensus parameters define the supply schedule, timing, and constraints that make Bitcoin what it is. Understanding these constants—and why they were chosen—illuminates both the technical and economic design of the system.
Some parameters were carefully calculated; others were pragmatic choices that became fixed through network effects. Together, they form the constitution of Bitcoin.
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 actual maximum is slightly less due to:
- Integer truncation in subsidy calculation (satoshis, not fractional)
- 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.
15.3 Block Timing Parameters
Definition 15.3 (Target Block Time)
The target block interval is:
T_block = 600 seconds = 10 minutes
Definition 15.4 (Difficulty Adjustment Period)
Difficulty adjusts every:
2016 blocks ≈ 2016 × 10 minutes ≈ 2 weeks
Remark 15.2 (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
10 minutes allows global propagation before the next block, minimizing honest miner disadvantage.
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.4 Block Size and Weight Limits
Definition 15.5 (Block Weight Limit)
The maximum block weight is:
W_max = 4,000,000 weight units (4 MWU)
For legacy transactions (no witness discount), this equals the original 1 MB limit.
Definition 15.6 (Sigop Limits)
Blocks are also limited by signature operations:
- Legacy: 20,000 sigops per block
- SegWit: 80,000 sigops (weighted)
| Parameter | Value | Purpose |
|---|---|---|
| Max block weight | 4,000,000 WU | Limit resource usage |
| Max block size (legacy) | 1,000,000 bytes | Backward compatibility |
| Max transaction size | ~400,000 bytes | Prevent abuse |
| Min transaction size | 82 bytes | Prevent CVE-2017-12842 |
15.5 Coinbase Maturity
Definition 15.7 (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.3 (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
100 blocks makes deep reorganizations (that would orphan mature coinbase) extremely unlikely.
15.6 Timestamp Rules
Definition 15.8 (Median Time Past)
The Median Time Past (MTP) of a block is the median timestamp of the previous 11 blocks. Block timestamps must be strictly greater than MTP.
Definition 15.9 (Future Limit)
Block timestamps must not exceed:
network\_adjusted\_time + 2 hours
where network-adjusted time is derived from peer clocks.
15.7 Script and Transaction Limits
| Parameter | Value | Introduced |
|---|---|---|
| Max script size | 10,000 bytes | Original |
| Max stack size | 1,000 elements | Original |
| Max element size | 520 bytes | Original |
| Max ops per script | 201 | Original |
| Max pubkeys in multisig | 20 | Original |
| Max P2SH redeem script | 520 bytes | BIP-16 |
| Max witness stack items | 100 | SegWit |
| Max witness script size | 10,000 bytes | SegWit |
| Max Tapscript size | None (policy only) | Taproot |
15.8 Network Protocol Constants
Definition 15.10 (Protocol Version)
Protocol versions indicate feature support. As of 2024, common versions are 70015-70016.
| Parameter | Value |
|---|---|
| Default port (mainnet) | 8333 |
| Default port (testnet) | 18333 |
| Default port (signet) | 38333 |
| Magic bytes (mainnet) | 0xF9BEB4D9 |
| Max message size | 32 MB |
| Max headers per message | 2000 |
| Max inv per message | 50,000 |
15.9 Economic Design Rationale
The parameters were chosen to create specific economic properties.
15.9.1 Scarcity
Remark 15.4 (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.
15.9.2 Diminishing Inflation
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.
| 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% |
15.9.3 Security Budget Transition
Remark 15.5 (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.
15.10 Parameter Immutability
Consensus parameters are not merely difficult to change—changing them would create a new, incompatible network.
Theorem 15.4 (Consensus Incompatibility)
If any consensus parameter changes:
- Nodes running old software reject new blocks
- Nodes running new software may reject old blocks
- The network splits into incompatible chains
This is a hard fork, creating a new currency.
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 don't recognize
- Be economically equivalent to creating an altcoin
The resulting currency would not be "Bitcoin" in any meaningful sense.
15.11 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 | ~2-2.3 MB effective |
| 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 satoshi million (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?