Fantastic way to view it 
1 bn tonnes of SAFE.
Oh, btw
We haven’t discussed this recently in the team. The community poll back in the days resulted in this, i.e. majority wanted u64 at the time.
I was then, and am still, in favor of u128, but I haven’t made any attempts (yet) to push for that.
If I voted u64 I would change it to u128. You all know much better and with all of the recent postings maybe people’s opinions have changed? Perhaps the @mods could run an updated poll after providing links to relevant discussions?
I would like to see that and honestly think u96 is plenty for a way over the top future.
Also that article ignored a lot of practical usage. Its an interesting idea to go rational numbers for currency, but would be a huge negative when considering public uptake. Its hard enough for general public to take up crypto and even harder when you go against practical usage of currency. There is always the human element to consider and computer science has factored that in for the last 70 years of financial programming
safe-money addresses the “people are not comfortable with fractions” argument by performing all calcs as rational numbers and then (if desired) developer may convert to a discrete type using smallest unit of currency, and a choice must then be made to floor, ceil, trunc, or round according to biz-logic, but also the remainder is kept around if needed. See also reddit discussion linked below:
As a math purist I like the rational number approach. I have also been a big proponant of “infinite” divisibility of safe coins. (See forum thread out there on "quasi infinite divisibility) However, the challenge I see is following KISS. When it comes to the accounting code it needs to be simple. Auditing the haskel library and conversation to rust may be easy, might not be. The math and the code must be proven to be absolute perfection.
Rational fractions offer ultimate flexibility but most complexity. U64 is the easiest to implement. U128 and U256 are middle of the road. On the way to rational fractions there are other bignum libraries to make for greater than 256 bit divisibility.
The same arguments could be made for network xor addresses. I view getting a hash collision at a certain xor bit depth as analogous to not having enough coin divisibility or a fatal rounding error. It’s a state when users become frustrated and angry. So why not use rational fractions to represent XOR addresses? The reasons not to are performance, cost, and complexity. The conclusion so far by Maidsafe that was posted to the forum was to reduce Xor addressing from 512 to 256 bit depth for simplicity, with a plan to increase if necessary. My view there has been 512 bit minimum to follow NIST recommendations. So going beyond 512 bit divisibility for safe coins seems excessive. A level of divisibility offered by u128 is the min required to gives us IEEE infinity.
yes indeed. There doesn’t seem to presently exist a safe-money for rust, though there are rational number crates, which maybe get us 90% there.
This point cuts both ways. yes, using integers there is no need for code review of the integer type itself, eg u64. otoh, if doing complex calcs in the app that require intermediate results, it can be challenging to audit such code and ensure that precision is not lost during the calcs. Whereas with rational numbers you get this for free.
And that extends to not only the SAFE core logic, but also to 3rd party apps that will ever interact with SafeCoin API, which will tend to have a lot more business logic.
Although we can imagine two different scenarios:
SAFE libs perform all ops with rational numbers internally, but convert from/to integer at the 3rd party API level.
SAFE libs perfom all ops with rational numbers, and use these in the 3rd party API also.
Seems a little difficult to have no limit on the size of numerator or denominator. Seems like a good angle for a malicious operator to attack. Especially given the potential for exponential growth in size of the denominator.
yes, indeed it seems that could be an issue, good point. In practice there might need to be some type of size limit put in place, which then begs the question of how to handle when the limit is hit. It would be interesting to ask the safe-money author if the library offers any protections/mitigations for such an attack.
Intuition tells me that if you want 128 bit divisibility then you would need a 256 bit numerator and a 256 bit denominator to store the parts of the rational fraction. The simple reason for this is that you need to cross multiply the fractions to form a common denominator in order to perform addition and subtraction.
The original method we discussed before of using a single u128 can be viewed as a special case of this rational fraction representation where the denominator is locked to (2^32)/(2^128-1) or a convenient base 10 number like 10^30 if we don’t care to use all available binary precision. This common denominator is implicitly understood for all transactions and we only do common add subtract operations with the numerator which is represented by the aforementioned u128.