I have started this topic to try and gather from the community, reasoning, opinion, ideas and input to some aspects of the coin itself for the benefit of the Dev team and planning purposes. Since the coin is to be in a u64 variable in the back end and represented as a 9 decimal place Fixed Point there are a few options available for consideration.
The next post in this topic will lay some of the relevant posts from the main RFC topic for the revised safecoin RFC. And the third Post will be some polls to help gauge people’s opinions and desires for safecoin
I am doing this now because these should be easy to implement now compared to what is to be implemented as it relates to the u64/u128 and exposing micro now and nano later or nano now.
And finally this topic is purely for the discussions of the number of decimal places 9 (u64) or 28 (u128) and whether its considered necessary to expose nano safecoin now (or 28 places if u128) as well as micro and milli. Please consider your uses and future IoT needs.
Now the APPs will control how you view your safecoin balance/transaction amount and is not dependent on the API or backend, except if only micro exposed then the APP is limited to micro (0.000001)
Please vote as it was requested to gauge community position on whether the nano safecoin should be exposed in the API now or not.
Here are the relevant posts from the main RFC topic and ones that I considered best representative of the subject at hand. You can add more to the discussions by replying
The first poll is about whether we keep to 2^32 SAFEcoins or expand the number to fill the 2^64 while keeping 9 decimal places (or 28 places if we got with u128). This would mean that the exchange from MAID to safecoin would be 1 MAID = 4,294,967,296 nano (Approx 4.3 coins/MAID). If u128 is used then it would be similar except 28 decimal places.
There is no fear of inflation as each MAID keeps its value. All MAID is still the approx 10% of total supply of safecoin when exchanged. Only perception is affected.
@anon86652309 , you might find this helps to use all bits
Keep to 2^32 coins for SAFE coin 1 MAID => 1 Safecoin
Use max allowed variable for safecoin 1MAID => 4.294967296 safecoin (~4.3 safecoin/MAID)
Give me Candy - ( No Opinion either way )
0voters
Second poll is for consideration of IoT and if anyone feels it is necessary for IoT to be able to transact smaller amounts than 1 nano safecoin. when price of safecoin goes high, for instance over 100$ or maybe 1000$
OR do you feel that nano is not small enough for such a innovative coin such as safecoin and the SAFE network.
EDIT: Please Note that the 28 decimal places option (u128) does not mean that the network (back end) needs to work down to the 28th place. It could work with say 12 places on launch and change its lower limit later on to say 15 or 18 places with an upgrade changing the one lower limit value. Good Front end APPs would work with the whole 28 places anyhow so they don’t need changing and the Front end APPs only show what you want to see.
Use current proposal of u64 giving 9 decimal places (nano)
Use a u128 variable that provides for 28 decimal places (this represents more atoms in the universe and is practical infinite division)
Give me Candy - ( No Opinion either way )
0voters
Third Poll is for whether you would want the exposure of nano safecoin immediately or wait for the eventual exposure of nano and only have micro safecoin allowed till its upgraded sometime later which maybe during beat but more likely after release.
Expose nano now so it can be used and tested
Expose only down to micro now and wait for nano to be exposed.
My opinion based on experience is that if nano exposed at the API is delayed now there is a reasonable chance that other priorities will see the nano exposure and testing pushed back past release
Not really. The Api would have to only go down to a certain amount to keep it sensible. Say 12 places until the SAFEcoin $$ value increases by doing a update on the code.
Depends on number of vaults and amount of storage. approx 2^128 if it were possible to store that amount. Quite impossible since there are not enough atoms let alone bytes
I haven’t been following these threads closely enough to understand the arguments either way so I haven’t voted as it would really just be a dart throw. Could someone layout the tradeoffs inherent in the various options? A simple list of pros and cons of each would be helpful to a lot of us here I’m sure.
That is why I gave the “Give me Candy” option so you can tell us that you don’t know or don’t have a preference either way. Its important for gauging how the community feel. For instance if more people don’t care then the other options have less significance.
So with u64 and proposal to pad it out ~4.3x maid token. what is the total proposed nano-safecoins?
my number is: 1945975371600000000
but that seems too small … I was only counting the maid tokens which are ten percent of the total safecoin that were to exist in the original design.
so: 452552412Ă—4.3 = 1945975371.6
then: 1945975371.6Ă—10^9 = 1945975371600000000
One advantage I see is that this gives us 4 times the max coins allowed and utilises the whole u64 word which @anon86652309 was desirous of. It means also that nano is slightly smaller in value than if 1:1 exchange
I must admit I am also one who likes to see no bit lost. Every bit is precious (sung to Monty Python’s famous tune from the movie). In saying that though I am also aware that sometimes for practicality wasting a bit or two is the better option saving on either program space or following best practices or making it clear to the next programmer. I once put a timeshare tasking scheduler and ran tasks in a D2 6800 kit that had 256 bytes of memory. That is squeezing a lot out of little memory
@JPL Yea, I know but please conflate the two so you can be counted. I am not assuming the “give me candy” means any more than you are not choosing at this time.
I should have put “Up to” because its not necessary to use every place and be up to the front end APPs to display the value to your liking. Thus the back end could use down to the 12th place and the front end shows you the truncated 6 places. (ie micro)
And an upgrade in 5 years could allow the back end to use 15 places without any other change to the API. Just change the lower limit that can be used by the backend and no other change needed to the backend since then 15 places become used. And front end APPs written correctly would be able to work with all 28 places and they would just work and the user only needs to request the display of the full 15 places.
I put a note on the poll for 9 decimal places (u64) verses 28 decimal places (u128) to point out that the back end could implement the u128 option but have a lower limit value that it uses to limit it to say 12 places now and 15 later on. And that the front end can accept all 28 places but only display what you want.
Please change your vote if this information changes your preference…