theoretical code limit on handling values

[bumbacoin]

ignoring the obvious 21mill projected coin supply,

what is the theoretical max value that the code base can handle ?

is it int64 ?
or
9223372036854775807

divided by satoshi ofc, so just over 92 billion coins ?


edit.
i see dogecoin has over 100 billion coins :p


edit.
i've just been looking further and i see int64 max is 2^63, as 1 bit is used for +/-

[bumbacoin]

curiously enough,
21 million is allegedly close to a 64 bit floating point number ?
2^52 = 2251799813685248 satoshis



https://en.bitcoin.it/wiki/Controlled_supply#Currency_with_Finite_Supply
"Speculated justifications for the unintuitive value "21 million" are that it matches a 4-year reward halving schedule; or the ultimate total number of Satoshis that will be mined is close to the maximum capacity of a 64-bit floating point number. Satoshi has never really justified or explained many of these constants."



obviously there are some programming limitations on what a 64 bit integer can usefully represent,
this has confused me no end. lol

[Foxpup]

The main limitation is that JSON, being JavaScript-based, interprets numbers as double-precision floating point. The largest value that can be thus represented correct to 8 decimal places is 67,108,863.99999999. But even if nothing in Bitcoin Core used floating points, it's highly likely that other Bitcoin software still would (eg, web wallets using JavaScript), so it's not a simple matter to use larger number formats.

[achow101]

The main limitation is that JSON, being JavaScript-based

What does JSON have to do with any of this? The Bitcoin protocol does not use JSON anywhere.


The field for the value of an output is an int64 so its max value is 2^(64-1). That is how many satoshis you can specify in one output.

[bumbacoin]

i notice doge has over 100 billion coins,
and 2 ^63 is around 92 billion coins (9.22337203685478E18 satoshi),
so seemingly as long as they're not all in one tx, it's possible because any individual case will not exceed int64 limits.

i wonder how PoS coins with their moneysupply rpc would handle that.

seems like that 'd be the first thing to break.

[achow101]

i notice doge has over 100 billion coins,
and 2 ^63 is around 92 billion,

No it isn't. 2^63 is 9.223372e+18, which is several orders of magnitude than the billions. Where did you get the billion number?

[bumbacoin]

and 2 ^63 is around 92 billion,

wat?

sorry, 9.22337203685478E18 satoshis (or dogetoshis, or bumbatoshis lol),

which is ~92 billion coins,


fixed above also

[Foxpup]

The main limitation is that JSON, being JavaScript-based

What does JSON have to do with any of this? The Bitcoin protocol does not use JSON anywhere.

No, but the RPC interface does, and enough programs are still treating bitcoin amounts as floats that floating-point precision is the limit of what numbers are "safe".

In fact, I predict that within a year of fractional satoshis being introduced (by a protocol extension or second layer or whatever), someone will lose a significant amount of money due to a floating-point rounding error in third-party software.

[bumbacoin]

The main limitation is that JSON, being JavaScript-based

What does JSON have to do with any of this? The Bitcoin protocol does not use JSON anywhere.

No, but the RPC interface does, and enough programs are still treating bitcoin amounts as floats that floating-point precision is the limit of what numbers are "safe".

In fact, I predict that within a year of fractional satoshis being introduced (by a protocol extension or second layer or whatever), someone will lose a significant amount of money due to a floating-point rounding error in third-party software.

i've been looking at Stronghands (PPC clone) because it can't handle a transaction value close to MAX_MONEY,
it appears to pass a pre-check, then is entered into wallet db, then fails a post-check breaking the wallet.dat

i'm not sure what's going on, but at some point tx out value is handled by JSON.
i'm wondering if this is causing the problem through slight variations in value.

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 .00000011 over that value so there is some obvious looseness around these values. (edited, too many zeroes)
https://github.com/bumbacoin/stronghands/commit/8bc58843f43012e142beff29a8fcbb7a37c8ed5b

on a cursory glance the code is the same as PPC, BTC has changed a lot since then.

[Foxpup]

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:

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:

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).