Introduction⌗

Mining is the process used to confirm valid transactions on the network without a trusted third party. Miners recieve compensation for this service through the block reward which is composed of two parts: i) transaction fees & ii) block subsidy:

\$tt"transaction fees + block subsidy = block reward"\$

Neither fees or subsidy are fixed. The fees respond to market conditions depending on current demand for transactions. The subsidy is hard coded into the protocol — it started at 50 Bitcoins per block and every 210,000 blocks (approx 4 years) this is cut in half.

Tip
 h/t @Murch: The % of the total bitcoin supply being mined in a particular epoch is equal to the block subsidy for that epoch. i.e. in the epoch with block subsidy of 50 bitcoins, 50% of the total supply was mined. In the epoch with subsidy of 6.25 bitcoins 6.25% of the total supply will be mined.

Based on this formula of issuance, bitcoin mining rewards decrease exponentially until approximately the year 2140, when all bitcoin (20.99999998 million) will have been issued. After 2140, no new bitcoin will be issued.

Bitcoin economics⌗

From a starting block subsidy of 50 bitcoins in 2009, Bitcoin will experience 32 halvings. The code determining the subsidy for tag v0.21.1 can be found at src/validation.cpp#L1236-L1247:

CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval; # (1)
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64) # (2)
        return 0;

    CAmount nSubsidy = 50 * COIN; # (3)
    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings; # (4)
    return nSubsidy;
}

  1. Calculate the number of halvings we’ve had based on the nHeight of the block and a consensus parameter nSubsidyHalvingInterval.

  2. This is block subsidy code which was added in PR 3842 in 2014! This PR identified that, after 64 halvings — at block height 13,440,000, roughly 256 years after bitcoin’s genesis and 32 halvings after the block susbsidy has become 0 bitcoin — the right shift operation becomes undefined in C++ and halvings >>= 65 would become equal to halvings >>= 1, which would fundamentally and radically alter the total supply of bitcoins.

  3. Set nSubsidy to the initial and maximum value of 50 * COIN, where COIN is defined in src/amount.h to be 100_000_000 ("satoshis") in Line 14:

  4. Binary right-shift nSubsidy by halvings to get the nSubsidy for the block

static const CAmount COIN = 100000000;

…​followed by a right shift of this value by the number of halvings to determine the current nSubsidy. Because each halving is equivalent to dividing the previous epoch’s subsidy by 2, we can use a base 2 (binary) right shift to perform the division in the most processor-efficient way.

Mastering Bitcoin includes a short python script to calculate the maximum monetary supply of bitcoin:

# Original block reward for miners was 50 BTC
start_block_reward = 50
# 210000 is around every 4 years with a 10 minute block interval
reward_interval = 210000


def max_money():
    # 50 BTC = 50 0000 0000 Satoshis
    current_reward = 50 * 10**8
    total = 0
    while current_reward > 0:
        total += reward_interval * current_reward
        current_reward /= 2
    return total


print("Total BTC to ever be created:", max_money(), "Satoshis")

This means that, after 6.93 million blocks, in approximately 2140, almost 2,099,999,997,690,000 satoshis, or almost 21 million bitcoin, will be issued. This finite supply is of ultimate importance to many bitcoin holders as a monetary system that can resist third party inflation.

Decentralised consensus⌗

Bitcoin’s decentralized consensus emerges from the interplay of four processes that occur independently on nodes across the network:

  1. Independent Transaction verification by every full node, based on a comprehensive list of criteria

  2. Independent Transaction aggregation into new blocks by mining nodes, coupled with demonstrated computation through a Proof-of-Work algorithm

  3. Independent Block verification by every node and assembly into a chain

  4. Independent Chain selection by every node, of the chain with the most cumulative computation demonstrated through Proof-of-Work

Transaction verification⌗

When a node recieves a transaction over the p2p network or it’s own wallet, it will perform a number of checks using the functions AcceptToMemoryPool, CheckTransaction and CheckInputScripts:

  1. The transaction’s syntax and data structure must be correct.

  2. Neither lists of inputs or outputs are empty.

  3. The transaction size in bytes is less than MAX_BLOCK_SIZE.

  4. Each output value, as well as the total, must be within the allowed range of values (less than 21m coins, more than the dust threshold).

  5. None of the inputs have hash = 0, N = –1 (coinbase transactions should not be relayed).

  6. nLocktime is equal to INT_MAX, or nLocktime and nSequence values are satisfied according to MedianTimePast.

  7. The transaction size in bytes is greater than or equal to 82.

  8. The number of signature operations (SIGOPS) contained in the transaction is less than the signature operation limit.

  9. The unlocking script (scriptSig) can only push numbers on the stack, and the locking script (scriptPubkey) must match IsStandard forms (this rejects "nonstandard" transactions).

  10. A matching transaction in the pool, or in a block in the main branch, must exist.

  11. For each input, if the referenced output exists in any other transaction in the pool, the transaction must be rejected.

  12. For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions pool, if a matching transaction is not already in the pool.

  13. For each input, if the referenced output transaction is a coinbase output, it must have at least COINBASE_MATURITY (100) confirmations.

  14. For each input, the referenced output must exist and cannot already be spent.

  15. Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in the allowed range of values (less than 21m coins, more than 0).

  16. Reject if the sum of input values is less than sum of output values.

  17. Reject if transaction fee would be too low (minRelayTxFee) to get into an empty block.

  18. The unlocking scripts for each input must validate against the corresponding output locking scripts.

By independently verifying each transaction as it is received and before propagating it, every node builds a pool of valid (but unconfirmed) transactions known as the transaction pool, memory pool, or mempool.

source Mastering Bitcoin Chapter 10.

Note
 Not all full nodes need to participate in transaction relay on the network. For nodes running Bitcoin Core this means running the software with config flag blocksonly enabled. Back when this was introduced in v0.12.0 this was estimated to result in bandwidth savings of 88%!

More information on blocksonly mode can be found in reduce-traffic.md.

Transaction aggregation⌗

Transactions are aggregated into blocks by Mining nodes, effectively performing the transaction settlement function for the users of the network.

Mining nodes perform the same Transaction verification and Block verification that all full nodes on the network are doing. However, they are also performing an additional function — creating new blocks full of valid transactions and trying to find a proof-of-work solution for their block.

To create a block, the mining node will check its mempool of already-validated transactions and see which it would like to include in its (candidate) block. We expect the transaction fee market to generally reflect the transactions the miners are likely to select, but certain miners may have other preferences they consider too. In some cases, miners might want to include a transaction with a high fee/vByte

Block verification⌗

While a few full nodes will run in blocksonly mode, most will have a mempool of transactions which they use to validate blocks (see Block verification).

Tip
 Whilst we think of the blockchain being shared state amongst every node on the network, there are no such guarantees for the Mempool. Everyone’s mempool may look different at any point in time, depending on e.g. what node parameters they are running, their connectivity to the p2p network, whether they are a miner who accepts transactions via some other means than the public p2p network etc.

Chain selection⌗

asdf