New Bitcoin is generated when a miner produces a valid block whose coinbase transaction claims no more than the permitted subsidy. The successful miner or mining pool proposes that block, but independent full nodes verify its proof of work, transactions, and reward amount before accepting it. Miners therefore perform the issuance event without having authority to choose an arbitrary supply. The protocol’s height-based subsidy schedule determines how much new Bitcoin a valid block can create, while transaction fees form a separate part of miner revenue.
A miner builds a candidate block
A miner selects transactions, constructs a coinbase transaction, calculates a merkle root, and builds a block header. Mining hardware repeatedly changes permissible header-related data and hashes the header, searching for a result below the network target.
The coinbase transaction is special because it does not spend ordinary previous outputs. It creates the block’s permitted reward claim and can direct outputs to the miner, a pool, or another configured destination. “Coinbase” in this technical sense is a transaction type, not the cryptocurrency company.
Bit.Fan’s explanation of who creates new Bitcoin through mining provides a beginner view of the roles. The precise distinction is that miners propose newly issued value inside a candidate block and nodes decide whether that proposal follows consensus rules.
The subsidy comes from a public height rule
The Bitcoin developer block-chain reference states that the subsidy began at 50 BTC and halves every 210,000 blocks. Transaction fees and subsidy together form the block reward, and a coinbase transaction is invalid if it claims more than that available amount.
The subsidy was 50 BTC before block 210000, then 25, 12.5, 6.25, and 3.125 BTC across later completed eras. A miner cannot use more computing power to restore an earlier subsidy. Hash rate affects competition for finding valid proof of work, not the permitted issuance at a given height.
The familiar supply limit results from repeatedly halving a finite, satoshi-denominated subsidy until the calculation reaches zero. It is enforced transaction by transaction and block by block rather than maintained as a counter controlled by a company.
Proof of work selects a proposer, not a rule maker
Finding a qualifying header lets a miner broadcast its candidate. Other nodes validate it. They check the proof of work, previous-block reference, transaction rules, absence of invalid spends, merkle commitment, block constraints, and coinbase claim.
If a miner creates extra units beyond the allowed reward, conforming nodes reject the block even if its proof of work is otherwise valid. The miner then loses the chance to earn the valid subsidy and fees for that effort. Economic competition does not grant permission to rewrite local validation rules.
The current Bitcoin Core mining code visibly combines fees with the calculated subsidy. Its documented block-assembly source forms a block reward from transaction fees plus GetBlockSubsidy for the candidate height. Code is only one implementation, but it makes the two components easy to inspect.
A pool separates block creation from worker payouts
Most individual mining machines do not find blocks at predictable intervals. A pool coordinates many workers and commonly pays them according to submitted shares under its own payout method. Those shares demonstrate contributed work at a lower difficulty; they are not Bitcoin blocks and do not generate protocol subsidy themselves.
When a pool finds a valid block, the coinbase transaction may pay an address controlled by the pool or follow another disclosed arrangement. The pool later allocates payouts according to its contract. An explorer label naming a pool therefore identifies an attributed block producer, not necessarily every machine or the final economic owner of each reward unit.
Pool fees, payout thresholds, and methods such as pay-per-share concern private accounting between the pool and miners. They do not change how much subsidy the network permits in the block.
New issuance and transaction fees must remain separate
Suppose a hypothetical valid block at a 3.125 BTC subsidy height includes 0.40 BTC in transaction fees. The maximum combined reward claim is 3.525 BTC, subject to the actual valid fees. Only 3.125 BTC is newly issued; the 0.40 BTC came from transaction inputs exceeding transaction outputs.
Calling all 3.525 BTC “new Bitcoin” would overstate issuance. Calling the miner’s income only 3.125 BTC would omit fees. Financial analysis should label subsidy, transaction fees, pool deductions, and miner payout separately.
A halving reduces the subsidy component at a boundary height. It does not promise to halve fees, total revenue, hash rate, or market price. Those outcomes respond to other conditions.
Nodes verify, but no single node issues coins
Each full node applies its chosen consensus-compatible software to received blocks. A single node does not create new Bitcoin merely by validating. Its role is to refuse blocks that violate the rules and to select among valid chains according to accumulated proof of work.
Likewise, developers do not press an issuance button. They publish software that users may choose to run. Changing the supply rule in one program does not compel miners, businesses, or nodes to accept blocks produced under it.
The accurate answer to “who generates bitcoin” combines roles: a successful miner includes the allowed subsidy in a valid coinbase transaction; proof of work earns the chance to propose; and distributed validation enforces the limit. No one participant can award itself extra Bitcoin and have conforming nodes recognize it.