BIP: 42 Layer: Consensus (soft fork) Title: Fix Platform Dependent Block Reward Issue Author: Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: Unanimously Recommended for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0042 Status: Final Type: Standards Track Created: 2014-04-01 License: PD
This BIP fixes a platform bug in the specification of the subsidy curve for Bitcoin.
The code below:
int64_t nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210,000 blocks
// which will occur approximately every 4 years.
nSubsidy >>= (nHeight / 210000);
contains undefined behaviour in the C++ specification.
The block number is divided by 210000 (the "apparent" subsidy halving interval in blocks), and the result is used as input for a binary shift, applied to the original payout (50 BTC), expressed in base units. After 64 such halvings, the result of this expression is undefined as per the C++ specification.
In any case, if the value of the right operand is negative or is greater or
equal to the number of bits in the promoted left operand, the behavior is
undefined.
This BIP fixes this undefined behavior to be well defined and in line with the intended subsidy curve.
Note that several other programming languages do not exhibit this behaviour, making alternative implementations likely to already be enforcing this rule. For example, Python returns 0 when shifting an integer beyond its size.
A softfork (see BIP16, BIP34, BIP62) will take place when `nHeight/210000 == 64`, permanently setting the subsidy to zero. The result of this will be that the total currency supply will be limited to 21 Million Bitcoin, as originally intended.
An implementation for the reference client can be found on bitcoin/bitcoin#3842 .
Given the long time frame over which this change is to be activated, we expect all miners to use a client compatible with this before such a nHeight is reached.
If they don't, and a minority remains on the old code base, the minority may mine invalid blocks but will not form the most work chain (as claiming the block reward is optional). If the majority of miners do not enforce this rule, then a fork (or many, depending on the contemporary hardware and software interpretations of undefined behavior) would occur.
Thanks to Gregory Maxwell for proposing this solution. Thanks to "ditto-b" on github for discovering this issue.
This document is placed in the public domain.