A chain of decisions · Rules and machinery

From CPUs to ASICs: How Bitcoin's Mining Rules Changed

In January 2009, an ordinary computer was enough to mine bitcoin. Today specialized machines perform the same work, but computing power still grants the right to propose a block—not the right to set the network's laws alone.

EDITORIAL OVERVIEW · Prepared by the project editors from the sources listed below.

2009: one computer, one miner

In the first Bitcoin software, the CPU maintained the wallet, verified blocks, and searched for the next valid header. The subsidy was 50 BTC, while fees were almost irrelevant.

Difficulty already adjusted every 2,016 blocks. More computing power could not accelerate issuance for long because the network answered with a harder target.

2010: graphics cards and the first pools

GPU mining software appeared in 2010. Graphics cards performed the repetitive calculations much faster than CPUs, but this was not a protocol change: a block does not record which machine found it.

The first pools also appeared. Participants combined hashrate and divided income according to contributed work. To Bitcoin, a single participant still produced the block; distribution happened inside the pool.

2011–2012: miners assemble their own blocks

The early getwork mechanism handed hardware an almost finished task. BIP 22 described getblocktemplate, giving a miner the future block structure and the ability to select or remove non-required transactions.

At height 210,000 in November 2012, the first subsidy halving changed 50 BTC into 25 BTC. It executed the original schedule rather than introducing a new developer decision.

2013: block height enters the reward transaction

BIP 34 required miners to place the block height in the coinbase transaction—the first transaction in a block, which creates the subsidy and collects fees. After a defined threshold, old block versions were no longer accepted.

ASICs began displacing GPUs during the same period. The protocol did not require an ASIC; it accepted the first valid proof of work regardless of the hardware used.

2015: signaling support is not validation

BIP 66 required strict DER encoding for signatures. Some miners signaled support while continuing to build without full validation, producing invalid chain branches in the summer of 2015.

The episode showed that announcing readiness to follow a rule is not the same as actually checking it. BIP 65 later added CHECKLOCKTIMEVERIFY, requiring miners to enforce conditions that prevent an output from being spent before a specified time or height.

2016: the second halving and readiness bits

At block 420,000, the subsidy fell from 25 to 12.5 BTC. BIP 9 introduced separate block-version bits for coordinating backward-compatible upgrades.

A miner's signal indicated software readiness; it did not grant the miner authority to rewrite the protocol. After activation, nodes applying the new rules determined whether blocks were valid.

2017: SegWit changes block structure

Segregated Witness moved signatures into a separate witness structure. The former size-only limit was replaced by block weight, capped at 4,000,000 units.

A miner including SegWit transactions had to add a special commitment to the coinbase transaction, binding witness data to the block. Upgraded nodes rejected an incorrectly assembled block.

2020–2021: fees and Taproot

At height 630,000, the subsidy fell from 12.5 to 6.25 BTC. Fees became a more visible part of mining income, while operators retained discretion over which valid transactions to include.

In 2021, at least 1,815 of 2,016 blocks had to signal readiness for Taproot. After lock-in, the new rules activated at height 709,632, adding Schnorr signatures and more flexible spending conditions.

2024: a 3.125 BTC subsidy

At height 840,000, the fourth halving reduced the subsidy from 6.25 to 3.125 BTC. More powerful hardware did not change the issuance schedule; the next difficulty adjustment adapted the network to the competition.

Until the next halving, a miner may add transaction fees to 3.125 BTC, but attempting to claim extra newly created bitcoin makes the block invalid.

What a miner can actually decide

A miner chooses valid transactions, their order, hardware, energy source, pool, and which upgrades to signal readiness for.

Without acceptance by the validating network, a miner cannot increase the subsidy, cancel a halving, spend somebody else's coins, or force full nodes to accept an invalid block. Computing power earns the opportunity to propose the next block—not unilateral control over the rules.

The machinery changed rapidly. The fundamental rules of issuance and block validation proved far more durable.

Sources and verification

  1. Bitcoin Developer Guide: mining
  2. Bitcoin Developer Reference: difficulty and subsidy
  3. BIP 22: getblocktemplate
  4. BIP 34: block height in coinbase
  5. BIP 66: strict DER signatures
  6. BIP 65: CHECKLOCKTIMEVERIFY
  7. BIP 9: version-bit signaling
  8. BIP 141: Segregated Witness
  9. BIP 341: Taproot

Historical educational material. It distinguishes consensus rules, upgrade coordination, and the technological evolution of mining hardware.

Unless stated otherwise, the text, conclusions, structure and editorial arrangement were created by the project editors. Facts, quotations and source materials remain attributable to their authors and rights holders.

Back to the rubric