Show Posts
1
Stakeholder Proposals / Proposition to Change a Parameter for the Maximum Share Supply
« on: August 12, 2017, 02:51:38 pm »
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.
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.
