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.
2 Likes
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
3 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 
6 Likes
Are you here all week?
2 Likes
linking a reply of mine in a relative post!
Let’s ask Bill Gates
5 Likes
Ah the 64 dollar K question. 
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.
7 Likes
How would dust level be set? Is is variable for the value of SC? Is this an easy fix to spam? Even with dust level, SC could be bounced from accounts owned by same entity.
Perhaps a dust level plus a proof system? e,g, like how Nano prevents spamming - you have to do a proof of work to send - but you can do them in advance, so there is no delay.
DON’T FORGET TO VOTE IN NEO’S POLL ABOVE – CLOSING SOON!!
It is a limiting factor, and of course people can still bounce amounts between coin accounts and nothing in the system can prevent that. But it does reduce a lot the potential to d this. Instead of being able to send 1 safecoin to 10^9 accounts/transactions it is limited by the lust amount (or minimum transfer amount). For the normal person this simply means that any transaction has to be above the minimum but can be accurate to the full 9 places.
For simple ping-pong bounce between 2 coins accounts the network itself will effectively limit the rate since there is a finite time for a transaction to occur and cannot double up. The spamming would require sending to multiple coin accounts so that some parallelism can occur and make the spamming more effective and by having a minimum transaction amount then effective spamming requires each spammer to have significantly more amounts of safecoin and it helps limit the spamming.
Dust or minimum transaction amount is not a fix-all for spamming but it does make it more costly and more difficult. The finite time to do a transaction also limits the reuse rate for sending coin.
Testing will help determine what the real world rates can be for a spammer. AFAIK dust/minimum amount is not being implemented at this time.
Proof of work is good in theory but not so much for a real world spammer. The proof has to be easy to run on a lower end phone and the spammer uses a 12 core CPU and looks like 1000 to 10000 low end phones for processing power.
Yes please ensure your vote is in and if you wish to change your choice then also do so.
1 Like
I guess we don’t know how much of a problem this sort of attack will be. What about putting a simple rate limit on SC transactions? But with no network time is that even possible? so no transactions per second rate, but transactions per ?? get ??.
I suppose it will be worked out in the end. My lack of brilliance is wasted here
1 Like
I guess we have to see how long a transaction takes for safecoin since there is likely communications between sections in order to process the request and thus lag times could mean its in terms of a second. I’d guess 0.5 seconds to 5 seconds for one transactions depending on lag times and delays through the internet. Yea 5 seconds would be hugely delayed I’m guessing
4 Likes