Use a bignum for account balance

[duh102]

Currently we use longs to store and calculate the balance for each user. This works fine as long as users do not attempt to gain the most money possible, in which case they can achieve the maximum value within about a week of work on and off (as I discovered). This also leads to overflows, which are no good.

We should instead use some bignum package to divorce the balance from the data type and allow storing arbitrarily large balances. We could perhaps cap it at a certain value to prevent people from getting infinitely rich (or bias the gambling so that after a certain user balance it becomes much harder to make money).

We would have to switch the data storage type in sqlite to a blob or text to store them properly, as long is the largest integer value that sqlite can handle.

[duh102]

Easiest way would probably to store in text and do a combination lexical/length sort. Lexical sorting falls over (for numerical purposes) when two numbers share similar digits but are different lengths, ex 12 and 111. 111 would be sorted less than 12 since 11 is less than 12 (even though the 111 has an additional order of magnitude).

For integers, fixing it is as simple as using the length of the same-base number as the primary sort and then lexical sorting as the secondary sort. Something like

ORDER BY length(field), field

For floating points you'd have to break across the floating point, sort by the integral part as above, then format the floating point part to the same precision and sort that as above. Thankfully we're only dealing with integers so we don't need to worry about that.

[duh102]

This will require migrating both accounts as well as all the items that refer to wagers, transfer amounts, or mining results, and also a database migration path.