Hey all. Reading the source, in main.cpp...
int64 nSubsidy = 100 * COIN;
[...]
nSubsidy >>= (nHeight / 288400); // Approx 1 million blocks per year
At current block height, 2161131 / 288400 = 7.4935
That division result gets rounded and converted into an integer, so 2161131 / 288400 = 7 bits to shift the reward by.
I was thinking that C++ rounded either up or down to the nearest integer, which means we'd be very close to a block reward halving (once the result is a tiny bit over 7.5) but after some research it seems it actually truncates the result by ignoring the decimals, so 7.999 becomes 7. In that case, it's not until the result hits 8.000, at block 2307200, that the reward halving will happen.
At some point in the future due to block halving the reward calculation will fall below the minimum accepted input of 0.0001, which is likely going to cause problems. At block 5768000, the reward will change to 0.00009500, which is lower than the minimum accepted input of 0.00010000. Not sure if the client will reject PoW blocks at the moment they're mined (I've seen this happen with another coin where the coinbase transaction could not be created because the reward was too low), or it will just ignore the inputs from mined blocks when trying to send. Either way, the increase in (usable) money supply will probably effectively halt at that point... assuming people are still mining with such a low reward! If it does keep working, by block 9517200 the reward will be 0.00000001, and at block 9805600 you will need more than 8 decimal places to express a non-zero amount.
Okay, got a bit carried away with calculations, so...
tl;dr next reward halving is at block 2307200, and in another 3 or 4 years there's going to be some serious issues with PoW mining when the reward is effectively dust.
So all that remains is to go to the POS. And maybe even change the algorithm on the X11. Currently, the popularity of the coins using anonymous transactions continues to grow.
