Proposition to Change a Parameter for the Maximum Share Supply

[pc]

I'm against going above the 2^53 limit. We don't know which/how many (possibly private) applications are affected because they rely on double precision.
I wouldn't mind a careful increase to 2.5*10^15, for example.

[abit]

For example, https://cryptofresh.com/a/COMPUCEEDS

Code: [Select]

Supply 99,999,999,999 COMPUCEEDS
Issued by compumatrix1
Details
Internal ID 1.3.822
Max supply 99,999,999,999 COMPUCEEDS

Updating the allowed max supply to 9x the original value will let the issuer of this asset be able to issue 8x more tokens, thus may not be liked by holders.

Although I think most of "normal" assets won't be affected.

[alt]

this is a hard fork request,
I would like to see what response will get from the share holders, vote proxy, business man, users

[xeroc]

Python doesnt have the limits javascript has and the javascript library could probably be extended to use a bignum library instead of builtin integer math ...
then we could go for full 64bit representation, no?

[pc]

Found the reference: https://github.com/bitshares/bitshares1-core/blob/master/libraries/blockchain/include/bts/blockchain/config.hpp#L31-L39

[Taconator]

Here is my current opinion of the proposition

Pros

• It could satisfy the requirements for this new UIA without affecting any other assets nor operations (if the current technical understanding is correct)
• Easy to implement

Cons

• Existing unit tests might need to be updated
• Additional unit tests should be created to confirm proper behavior
• Additional testing on private or public testnets would be recommended to further testing
• Require a fork to integrate into the MainNet (unsure whether hard or soft)

[Taconator]

Background

While recently discussing the feasibility of introducing "Fast Bitcoin" as a UIA to BitShares, a technical constraint within BitShares arose which might limit the introduction of this coin with the full quantity of units in Bitcoin (21,000,000) and with the fractional precision of 8 decimal digits.

Two constraints in the code were first investigated and appeared to be adequate for the requirement:

(a) asset object uses int64_t for the quantity of to "raw"/"highest precision" units (see asset.hpp amount)

(b) the decimal precision of a fractional unit can handle 12 decimal digits (see asset_ops.hpp asset_create_operation)

However, @abit highlighted a third constraint that is not compatible with the requirements.

(c) #define GRAPHENE_MAX_SHARE_SUPPLY int64_t(1000000000000000ll) in config.hpp

With a fractional precision of 8 decimal digits and this existing constant, only 10,000,000 BTC could be handled.

When asked about the origin of this numerical value, @pc noted, that as best as he could recall, it is set to 15 digits because IEEE doubles have 53 bits of precision. 2^53 ~= 9 * 10^15. Therefore, 10^16 could not be represented by an IEEE. In addition, @pc noted that "Languages like JavaScript use IEEE double for all numeric types."


Proposition

@pc suggested that one method of satisfying the requirements would be to change this constant to 9*10^15 without violating the IEEE representation of doubles.


Considerations

@alt suggested that pros and cons of this proposition be discussed publicly hence this post.