there are a bunch of checks arounds MAX_MONEY (including MoneyRange).
i changed one of the error checks to (MAX_MONEY - 1),
and it still allows .000000011 over that value so there is some obvious looseness around these values.
https://github.com/bumbacoin/stronghands/commit/8bc58843f43012e142beff29a8fcbb7a37c8ed5b
You seem to have snuck in an extra decimal place there:i changed one of the error checks to (MAX_MONEY - 1),
and it still allows .000000011 over that value so there is some obvious looseness around these values.
https://github.com/bumbacoin/stronghands/commit/8bc58843f43012e142beff29a8fcbb7a37c8ed5b
Code:
>>> 1999999999.00000011 > 1999999999
False
But there's no inherent "looseness" here; remember that floating points are simply integers multiplied by an integer power of two, eg, the decimal fraction 0.5 is represented as 1x2-1. Binary scientific notation, in other words. Double-precision floats (which is what you're dealing with) use 11 bits to store the exponent, which leaves only 53 bits bits for the mantissa (including the sign bit). That's just not enough for a number like 1999999999.00000011, so the least significant bits are lost:False
Code:
>>> 1999999999.00000011
1999999999.0
This isn't really a problem with floating points per se; you're fundamentally trying to squeeze a too big number into too few bits, which will naturally give erroneous results no matter what method you use. Nothing you can do except use 64-bit integers everywhere (and convince everyone else writing software for your coin to do the same; good luck). 1999999999.0
fixed above also 
