Title: theoretical code limit on handling values Post by: bumbacoin on February 13, 2017, 02:58:26 AM 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 +/- Title: Re: theoretical code limit on handling values Post by: bumbacoin on February 13, 2017, 03:08:39 AM 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 Title: Re: theoretical code limit on handling values Post by: Foxpup on February 13, 2017, 03:33:56 AM 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.
Title: Re: theoretical code limit on handling values Post by: achow101 on February 13, 2017, 04:02:40 AM 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. Title: Re: theoretical code limit on handling values Post by: bumbacoin on February 13, 2017, 04:57:14 AM 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. Title: Re: theoretical code limit on handling values Post by: achow101 on February 13, 2017, 05:09:31 AM i notice doge has over 100 billion coins, and 2 ^63 is around 92 billion, Title: Re: theoretical code limit on handling values Post by: bumbacoin on February 13, 2017, 05:10:54 AM sorry, 9.22337203685478E18 satoshis (or dogetoshis, or bumbatoshis lol), which is ~92 billion coins, :) fixed above also Title: Re: theoretical code limit on handling values Post by: Foxpup on February 13, 2017, 05:33:58 AM 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.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. Title: Re: theoretical code limit on handling values Post by: bumbacoin on February 14, 2017, 01:12:37 AM 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.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. Title: Re: theoretical code limit on handling values Post by: Foxpup on February 14, 2017, 04:29:51 AM there are a bunch of checks arounds MAX_MONEY (including MoneyRange). 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 Code: >>> 1999999999.00000011 |