RFC 57: Safecoin Revised - Specific Question concerning Safecoin size and Number + Polls

[neo]

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.

The other two polls are related.

[neo]

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

@anon86652309

With regards to the underlying representation being a u64 , I guess it’ll save a lot of further time if I agree that we should adopt this approach. So I’ll agree to that now

@anon86652309

With regards to the underlying representation being a u64 , I guess it’ll save a lot of further time if I agree that we should adopt this approach. So I’ll agree to that now

@krnelson

I am not understanding why starting with micro is considered simpler, quicker or easier for test-safecoin? Short term programming effort wise it is the same effort to go nano (Longer term nano from day one clearly wins on programming effort). Testing wise you actually want to test the limits - not delay them to roll out on a live network where there is a lot more at stake and you have to deal with “consensus”. If anything you would want to use nano safecoin for testing and maybe downgrade to micro. Also something I used to harp on about back in 2015 when I had more time for these divisibility discussions - What about IoT use cases which are raring to go from day one of launch which require nano safecoin!?

@dirvine

Why not poll now we have the info we wish, AFAIK. Seems like a reasonable time to take the temperature?

@mav

Thinking in a similar way, vaults and sections and traders and end-users will be unlikely to be dealing with the total nanosafecoin amount, only with smaller amounts that would fit within the safe range of a double precision float. So I think in probably 99.9%+ of cases using nanosafecoin won’t result in issues.

@neo

There is nothing stopping a wallet from presenting your balance as a whole number of tiny bits of safecoin and working with them. So then the wallet could show you for example 500 nano instead of 0.0000005 coin

@neo

@lubinew

then, there are some interesting ways how to get practically infinite divisibility by building apps above SAFE Network.

I’d prefer IoT to not require its own tokens since that introduces another element of uncertainty in what value the IoT can place on the payment used.

u128 certainly provides practically unlimited division for safecoin with 28 decimal places.

it is believed that between 120 to 300 sextillion (that’s 1.2 x 10²³ to 3.0 x 10²³) stars exist within our observable universe. How Many Atoms Are There in the Universe? - Universe Today

I’d say that is for all practical payment purposed unlimited division.

@neo

EDIT: and I agree there is no need for the notion of the previous implementation. Maybe we could go to the max of u64 and have 18,446,744,073,709,551,616 nanos == just over 18,446,744,073 coins and then issue 4,294,967,296 nanos (approx 4.3 coins) per MAID. No inflation and no loss for anyone. But increases total supply for the future and allows @anon86652309 to realise full use of all bits. Only downside is people’s perception of imaginary inflation.

[neo]

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 )

---

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 )

---

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.
• Give me Candy - ( No Opinion either way )

[neo]

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

[neo]

@Antifragile

But on the other hand, this will be complete mess on exchanges.

Good point.

But all it would mean is that they close the MAID market and open the SAFE market with your converted coin.

Or if the exchange does not do the conversion then they will have 2 markets. And likely close the MAID market at a certain date.

They can do this easy enough since MAID is on the omni protocol and SAFE is on the SAFE network.

[drehb]

Are there any downsides to 128 bit? Would performance suffer much on low power devices? Are the plenty of languages or libraries that support 128 bit?

[neo]

@drehb

Are there any downsides to 128 bit? Would performance suffer much on low power devices? Are the plenty of languages or libraries that support 128 bit

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.

Also Dust transactions may also be a problem too

[Zoki]

I’m in for infinite divisibility.

How many user accounts are possible on the safenet?

[neo]

@Zoki

How many user accounts are possible on the safenet?

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

[JPL]

More than one account for every atom in the universe. Can’t get much more democratic than that .

[JPL]

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.

[neo]

@JPL

enough to understand the arguments either way so I haven’t voted as it would really just be a dart thro

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.

[TylerAbeoJordan]

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

but is that right?

[neo]

@TylerAbeoJordan

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.

Its 18,446,744,073,709,551,616 nanos - 2^32 * 2^32. If you notice the 4.294967296 is 2^32 nanos

4,294,967,296 MAID * 4.294967296 = 18,446,744,073.709551616

So a wee bit over 18,446,744,073 coins

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]

@neo

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.

“Don’t care” and “Don’t know” are very different things though.

[neo]

@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.

[Bogard]

Considering changing my vote. Since the PUT layer is being removed, more granularity in Safecoin could be needed.

Still, 28 decimal places is a bit much. So the 4x option (i.e., full use of u64) may be an okay compromise.

[dirvine]

@Bogard

Since the PUT layer is being removed

For now, not necessarily forever though. We need to test it.

[neo]

@Bogard

Still, 28 decimal places is a bit much. So the 4x option (i.e., full use of u64) may be an okay compromise

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.

[neo]

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…