Rational numbers are the superset of the fixed point approach we’re suggesting. They would be a great and clean solution, even more so if we had to deal with exchange between currencies. They would be a significant differentiator in the crowded crypto space.
I just don’t think they would provide enough extra value compared to how much trouble coding them would be, which would still be incomparably easier than getting outside devs learn and use them.
This conversation feels like familiar territory, even down to the BTC dodging cryptographic bullet links 
Ok,
But if I’m not missing something:
Or 1 safecoin = 1,000,000,000 nanocoin
Or 1 safecoin = 1,000,000 microcoin
I’m ok with penny 
I didn’t check the maths, tbh! 
the point is that we can name in whatever way is required, to keep the same number of safecoin.
The difference between then and now is that the chatty transaction issue has gone - we are just moving balances about, rather than individual coins. This makes the argument against having lots of small denominations moot - with no overhead, why not have them?
tl;dr
Just to be clear we would expect no less. Also for the API Just have the ONE type of coin and that is nanosafecoin and leave it up to the front end to work with it and keep it simple in the front/back ends and the API
It is the core code that we are talking of here and that is why the RFC is put out there so we can discuss the core code too and so world wide experience can be brought to bear on the code base.
Well, not really. To paraphrase Bill Clinton “it depends what the meaning of ‘has’ is”
https://tc39.github.io/ecma262/#sec-ecmascript-language-types-number-type
There’s only the “Number” type in javascript which is a “double-precision 64-bit binary format IEEE 754-2008 values as specified in the IEEE Standard for Floating-Point Arithmetic”
but yes you can represent integers
“Note that all the positive and negative integers whose magnitude is no greater than 2^53 are representable in the Number”
So there’s an unfortunately practical incentive to keeping total units less than 2^53 because greater than that will introduce issues in basically all javascripts (should we even care about those heathens?!).
Useful disambiguation from this stackoverflow comment - “Yes there are integer values, but there is no integer Type, only Number. Implementation details, such as how they are stored, is not part of the language specification”
I think Fraser will particularly enjoy the last sentence there about ‘implementation details’.
I only rave on these tiny specifics because they do matter. Addition with computers is weird.
Do we want to be in the 700K+ library downloads per week category?!
I’m sure that Coin type will work totally fine in the end. But at the same time, the careful thinking of this whole topic is very worthwhile.
The question of the smallest value being micro or nano is pretty much a mute point since we might as well use the maximum decimal that reasonably fits (250 pico is not decimal and so is out of the question since its financial not sensors/protocol/etc) Remember that Bitcoin never expected to be over 10K USD
@JoeSmithJr FYI we for instance never refer to our 1 cent as a penny even though I grew up with pound/shillings/pence . Australia is not the only country to never refer to any coin as penny.
So if we look at some potential values
Safecoin Price Micro Value Nano Value
-------------- ----------- ----------
$1.00 USD 0.0001 Pennies 0.0000001 Pennies
$10.00 USD 0.001 Pennies 0.000001 Pennies
$100.00 USD 0.01 Pennies 0.00001 Pennies
$1000.00 USD 0.1 Pennies 0.0001 Pennies
$10000.00 USD 1.0 Pennies 0.001 Pennies
Now there has been a bit of talk in the past when talking of tipping that “micro tipping” capability is essential for an economy without advertising revenue. This is not micro as in micro coin but micro $$$ and micro safecoin loses that capability once the coin gets higher than one dollar. And nano safecoin loses that capability once it hits 1000 dollars.
Pretty obvious we need nano safecoin. Its more of a question if anyone ever thinks we need less than one nano safecoin
Point taken but the point is still a front end issue and java-script is still not limited to 2^53
And there are more languages than java-script that can be used for wallets.
@mav, @anon86652309 To design the back end based on one (non-essential) front end language is not good. And java-script has many workarounds anyhow. (Bash script could implement a wallet real easy using 64 bit integers too utilising the CLI)
Yes this should work, except it should be 4,294,967,295,000,000,000
See above for just a couple of many reasons for having nano and not micro. RFC 57: Safecoin Revised - #155 by neo
should we even care about those heathens?!
Oi!
Indeed, and @neo, Fraser’s point seems valid. If we are trying to design the API to minimise the chances of devs messing up financial calculations, I wouldn’t dismiss a very popular language even if it is only used by heathens (like myself 
).
I understand Fraser not wanting to waste bits (the reason he gave for picos ‘under the hood’) and he’s managed to avoid this without making users of the API susceptible to committing programming errors. I haven’t understood the reason for using a split value and at the same time I don’t think it is necessarily an issue (again because I it is under the hood),.
The 52 bit point seems much more relevant to me.
Given @neo’s point about helping devs write reliable code, what this says to me is that it would be wise to do a quick survey of popular and up and coming languages, and see if there are any other bit lengths and issues we should factor into this decision.
At the same time I’m not convinced that we should see the ‘how many pennies needed to represent all of the world’s wealth’ calculation as more than a guide to the upper limit needed for divisibility. I just think that we can deal with extra divisibility later if we need to.
What’s clear though [cough] is that getting this community involved and is all tugging on these issues the way we have is valuable, and it’s a great strength of this project - both the quality and passion of this community, and MaidSafe’s ability and willingness to encourage and make use of it. This is such a great project! 
Yes but it wastes more bits in all the code to do the operations to handle under/overflow and adding/subtracting 2 parts and error checking than all the 2 bits of all the coin balances. Each node only has a certain number of coin balances. Say 10,000 balances for the Node is only 4.5Kbytes
BUT the code is now 3+Kbytes longerwith error checking and extra code to handle two sets of operations and conceptualising it for the API. This is stored on disk and takes up memory in the main memory while the Node is running. Thus 6Kbytes is used up.
So all this saving bits results in a net increase in the needed bits used.
False economy
When using 250 pico makes SAFEcoin the laughing stock of the financial and crypto world then what benefit is it?
As you said this is only the API and seems to be passing strings anyhow. So where is the issue?
My big issue is the use of 2 1/2 words to store a conceptually single value which can be stored as a single value saving a significant of code and conversions for the API whichever form it takes.
Since the API is string then java script can do as it pleases. To limit the capability because a java-script programmer is incapable of handling it is the tail wagging the dog. We are creating something to change the world. Not conform to the lowest common factor.
Also as I showed above, if safecoin exceeds 1$ then micro tipping/transactions are not possible. The lowest value will be greater than 1 micro $
I gave a few reasons above why it is
The big point people miss about front end code is that if a mistake is made then it affects only that APP. If you cripple the back end with 52 bits only then nothing can expand it or if you make a mistake emulating the ALU to handle 2 1/2 words and the exceptions. If you introduce storage in the back end that leads to extra code/nett size larger and has many times the avenues for bugs to be introduced then is it wise?
Let the front ends use nano and deal with it.
Now for your 52/53 bit, front ends that do any maths like multiplication/division using float then they will get the wrong answers in an absolute sense many times. Whereas handling fixed point would not without bad programming.
This doesn’t make sense to me when considering the importance of avoiding programming errors. I think we can be pragmatic while changing the world. Let’s at least look at the likely impact of programmers - in various languages - trying to manipulate Safecoin based on the API we provide.
Edit: I now understand your point that your main concern is the back end. I’ll have to think about that - seems both matter, but you are right that the back end is more important.
Also as I showed above, if safecoin exceeds 1$ then micro tipping/transactions are not possible. The lowest value will be greater than 1 micro $
I might have missed this. Are you saying tipping won’t work in units of a millionth of a dollar? 
To cripple the capability in an attempt to make bad programmers good programmers when they are converting to display a value has no end to what you can do. Where do you draw the line? Should the core code do all the maths so that we don’t have a bad programmer make a mistake in the front end?
My opinion on this is give the front end programmer something workable. Nano safecoin is more than workable. They are likely using packages & libraries anyhow and I’m sure google has a maths package that handles 64bit numbers. Otherwise someone can create a safecoin library for java-script to solve all the problems. 53/52 bit float is only really good if you add/subtract within well defined limits. Mult/divs can easily result in inaccurate values where integer will be exact in the financial sense. Any fiat multicurrency is not affecting safecoin since the conversion to safecoin occurs after all the multi-currency conversion happens.
We cannot tailor the back end to solve all the potential front end errors. Just provide workable values and let the front-end programmers use their skills and/or libraries. A poor programmer will stuff up even any API result.
Yes both matter but we cannot fix bad front end programmers. Just supply them useful reasonable values and they can work from there and use libraries if needed. But a poorly designed back end affects everybody and the bug avenues means that any update could “silently” stuff everything up and trying to be an ALU with the single value balance is a sure fire way to allow bugs to be introduced in a safecoin update.
Tipping would work, but the desired (some say required) micro $ tipping would not then be possible, it would be bigger than a micro $ and if the coin reached 1000 dollar then it is milli $ tipping.
If we are using overall 62 bits for safecoin then why not use all the available decimal places it can provide for 2^32 coins worth. And that is conveniently nano safecoin. Nano provides micro amounts even when 1 safecoin is 1000. 2^32 safecoins at 1000$ if all existing, is only 429 trillion dollars. What is the US economy today? how many trillion dollars? So yes its sounds crazy to have all safecoin worth 429 Trillion, but we would never have all 2^32 anyhow.
At 1000$ also we would need less than 1 micro safecoin for farming rewards, unless your want Farming to be a minimum of $100/TB and storage costs are higher (2 or 3 times) and to have an absolute minimum of $200-300 USD per TB upload does seem a tad too high
Didn’t you want to offer different units through the api anyway @anon86652309 ? So if JS would use milli (which internally gets multiplied and then ends up in the same functions as nano requests) and not nano as smallest denomination it would just be them who are limited for starters and not all the real programming languages just because of JS…
Cutting down possibilities for all just because of the inability of few doesn’t seem right to me. …
Edit/ps:
While I understand this very well and am just the same it doesn’t mean that one must enforce the solution one favours if there are no serious arguments against the solution a coworker with experience in a similar area suggests
I’m not sure I understand the worry over Javascript. It seems that JS CAN handle the task, the coder just needs to use strings to manipulate instead of a number … correct? Using strings is extra steps, but for any coder who isn’t just starting out, this shouldn’t be a problem. Am I missing something here?
I like the nano safecoin idea … have argued in years past that we need a lot of subdivisions for future scaling and this seems as though we’d be completely SAFE with nano divisions.
Javascript is the second most used language by MaidSafe. What happens when a javascripter does MAX_SAFECOIN_NANO - 50 === MAX_SAFECOIN_NANO and sees that it’s true?
To be slightly less provocative, what is the plan for MaidSafe using javascript and integers more than 2^53?
Strings for all numbers?
BigInt?
Custom types in a library?
I’m not actually worried about it that much. People will manage. @neo is right that you can’t ask to build a robust backend from the basis of a shonky frontend language.
These examples are real. They will happen in real life to real people spending real money.
I still prefer u64 and nanosafecoin as the smallest unit. But let’s not pretend edge cases are trivial or stupid or undeserving.
Application testing would pick this up.
I understand and agree somewhat with what you are saying here, but these are bad programmers problems and quickly fixed for reasonable programmers who do some testing.
The back end is of utmost and essential use use best practices for it.
I do too, but not called any technical name like nano though 
. I think it has to try and be easy to be accurate in every language by default if possible.
something not mentioned in this conversation could be embedded systems, many of which may not have 64bit addressable memory. I am not all that comfortable with 2 x 32 bit integer or even a single 64 bit integer. However maybe thinking embedded does favour the (internal) 2 x 32 bit integers, or even 4 x 16 bit or 3 x16 bit or … In any case I am not posing a solution here, just poking around, like many of us.
It is easily if the official JS bindings just contact milli as smallest unit 
Actually a large part of my day job is plc programming - and those systems move(d - depending on the brand ofc) to 64 too lately 
so even though arduinos are 32 bits for now they probably won’t (be able to use safe APIs directly anyway atm) and they most certainly will not handle insanely large numbers of little denominations but just choose the appropriate base unit… (and it’s probably a matter of time until we will see 64 bit there too)
embedded is easy enough. If the device is capable of running a SAFE client then its capable of a simple library that converts a internally used value for “safecoin” into the required API.
This would be a simple library that the programmer writes.
This is what i was trying to say that we cannot cater for every device now. There are simply too many. ARM, MicroChip, AMD, etc etc and they can use different base codes. But they do usually do “c” code so any library is fairly portable between embedded devices.
If they are capable of running a Node then by default have 64 bit integer maths. I do not know of a 32 bit cpu that does not do double length integer
And I gather there will be “c” bindings anyhow.
But again this should not dictate the back-end and using non-standard storage units.