We're not doing any math with the block reward code, other than the initial * COIN, so one might argue, the issue of block halving would become an issue far sooner than the block reward, since there could be feasibly some precision loss and desynchronization accross different platforms once the formula moves from * COIN to /2 * COIN;
there are probably safeguards in place to prevent this anyway, probably thought of by the original creator of bitcoin. Also, remember bitcoin units are only required to be precise to 8 decimal places, leaving a rather large margin of error.
there are probably safeguards in place to prevent this anyway, probably thought of by the original creator of bitcoin. Also, remember bitcoin units are only required to be precise to 8 decimal places, leaving a rather large margin of error.
No, you're misunderstanding how the code actually works. In the code, there is no nothing but satoshis. "1" in the native unit of bitcoin, is a satoshi. COIN is defined as 10*8. All units in bitcoin are stored and conveyed using a 64bit integer, not a floating point number. There is a reason for this, and there is a reason that no protocol critical code uses floating point numbers. Programmers have heard of things like 0.1+0.1 = 0.19999999901 and such related horrors, well imagine that for the block reward, but it's also not consistent. So, the wallet on your raspberry pi thinks that the block reward should be 0.1999172. and the wallet on your x86 PC, thinks it should be 0.199999999998. and the wallet on your Android device using ARM thinks it should be 0.19998.
