interactive tool
Difficulty & Halvings
Bitcoin's difficulty retargets every 2,016 blocks to keep block time near ten minutes. Halvings cut the issuance subsidy every 210,000 blocks. Both are on rails — neither requires a vote, and every full node enforces them.
Next retarget in ~14d 0h 0m (block #949,536).
Estimate assumes a perfect 10-minute block. Real arrival can be weeks early or late.
Each step is one retarget — every 2,016 blocks (~two weeks). Hashrate has grown roughly 1014× since 2009; difficulty tracks it.
| Era | Block | Date | Subsidy | Status |
|---|---|---|---|---|
| 0 | 0 | 2009-01-03 | 50 BTC | Genesis |
| 1 | 210,000 | Dec 10, 2012 | 25 BTC | Past |
| 2 | 420,000 | Jul 18, 2016 | 12.5 BTC | Past |
| 3 | 630,000 | May 20, 2020 | 6.25 BTC | Past |
| 4 | 840,000 | Apr 24, 2024 | 3.125 BTC | Past |
| 5 | 1,050,000 | — | 1.5625 BTC | Future |
| 6 | 1,260,000 | — | 0.78125 BTC | Future |
Why both at once
Difficulty and halvings are the two clock-springs that make Bitcoin a closed-form monetary system. Difficulty keeps the cadence constant — blocks every ten minutes — regardless of how many miners show up. The halving forces the issuance curve to converge: 50 + 25 + 12.5 + ... BTC per block, multiplied by 210,000 blocks per era, sums to exactly 21,000,000.
Together they decouple the schedule from any one party's will. Nobody chooses to adjust difficulty — every full node computes the same retarget from the same chain history. Nobody can vote in a higher subsidy — every node already knows what the next subsidy should be at every height for the next century.
Difficulty epochs bundled with the site (refreshed via npm run refresh-difficulty). Current tip via mempool.space, cached server-side for ~30 s.