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

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

2 Likes

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.

5 Likes

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…

3 Likes

One aspect that makes me puzzled with these wasted bits, is these are coin balances. So unless we expect one account to hold all the SafeCoins (or at least a significant part), we will always have many wasted bits. So it is not clear why we would want to fix the max value when no balance will be anywhere near it anyway.

5 Likes

Yep. Exactly. All coinbalances could be 1/1000th the full coin supply and it would still work fine. If any one had more than 1/1000th of all coins then shame they had to keep two coinbalances. My heart bleds for that person

3 Likes

You mean with the discussion of the wasting bits we were focusing on the minimum (max division), but on the maximum there is also something to gain? That’s a good point: for example a maximum balance of 1/256 of all 4,3 billion Safecoins gives us an extra 8 bits. The check to prevent rollover (like in level or score of some games, like NES Tetris) is not an issue? Edit: probably not -> You need to sent a lot of SafeCoins to an address (of someone else you want to go broke) to let it rollover.

1 Like

My comment was related to the first poll:

Not clear what real disadvantage there are of keeping 2^32 safe coins, we can still get nano coins with 64 bits. No roll over issues I can see.

1 Like

That poll question is judging if people would be happy or not to have approx 4.3 times the coins. It makes no change to what MAID is worth or anything like that. The differences I can see is

  • the perception you have more coins than with 2^32
  • There is enough whole coins for each person on the earth to have one each (perception effect)
  • It means that the question about u64 or u128 is a little less important. It makes u64 4 times more effective and delays any need to go beyond 9 decimal places
2 Likes

Yes, if a balance doesn’t have to be able to contain all safe coins at once, a conversion of 4,3 safecoin/MAID instead of 1 safecoin/MAID has less value. You could go for example to pico precision (10^-12) and use the ‘rest’ of the 64 bits for a max of 2^64 / 10^12 = 18,4 million SafeCoin on 1 balance.
Ps: is there a balance somewhere of all Safecoins in a section?

3 Likes

Make sense, in particular the first 2 items.
The last one as you mentioned has a more effective solution of holding PicoCoins instead of NanoCoin, and not allowing a single balance to keep all the coins. But with the first 2 points, it is a nice bonus.

1 Like

Good point, I may have forgotten that part, we may need to keep all the remaining coin somewhere. Not clear if it would be able to use exactly the same mechanism, but it might be a good reason to allow all coin in one balance.

2 Likes

I was tongue-in-cheek saying having less than allowing all coins in one coin balance.

It would make unnecessary complexity to have otherwise

1 Like

I am following this topic (and the original one) for a long time. It is interesting debate, but I am missing one fundamental question:

Is it really important to save every bit posible? I know there are implementation differencies between u32, u64 a u128, and some problems connected with using u64 a even more with u128.

But do we need to care about unused bits in u64 or u128? Nowadays even tiny devices like RaspberryPi have somewhat huge memory and paid dataplans are in GB. Is it worth the work saving 2 bits here and 5 bits there considering the added amout of work and complexity?

5 Likes

It matters a bit :rofl:

6 Likes

Maybe partly professional deformation of developers.

1 Like

Are you here all week?

2 Likes

Nope. I just realized that our discussion about safecoin divisibility is discussion about every kind of toke on Safenetwork. We care about few bits for safecoin but we expect that there will be thousands or even millions of various tokens using same technology. Also are we sure other tokens will not need more than 64bits? We can’t imagine what will others do with their tokens. So I think this discussion should include tokens too. Will other tokens use same technology? Will they have more bits than Safecoin? So many new questions, lol.

4 Likes

linking a reply of mine in a relative post!

Let’s ask Bill Gates

4 Likes

Ah the 64 dollar K question. :wink: Or IBM’s 5 computers globally

Needs tend to be larger than we first estimate. Just like the 10,000 special types to which I said make it 2^40 special types leaving 2^64-2^40 for everyone else. 10,000 seems too small when the available space is so large.

I certainly can see advantages to 128 bit and its certainly possible to use only 96 bits of it.

2^128 is more than the atoms in the known universe and as such is practically impossible to ever use it all. 2^96 is practically infinite too.

The issue for 128/96/64 bits is that the dust level has to be set to an amount that prevents spam attacks that the network cannot handle. Imagine sending 10^-18 or 10^-27 safecoin over and over again by a bot net or group of attackers. It’d generate more work for the network than those computers doing gets ever could. A dust level of course limits the smallest size that can be sent.

5 Likes