At this point it is not clear if in the future another version (more than nano) will be needed, so you would already introduce an extra byte (the version byte) that maybe will never be used. Or is the version byte optional/not required, because the size of the Struct coin is defined somewhere in meta data?
Or maybe the wasted storage/network usage etc. of this extra, possible never used, byte is not really an issue.
In my proposal you don’t have to do anything at this moment except making sure 0 is written to these 2 bits, what is normally the default behavior. So, no over engineering, on the contrary. So, do nothing until the 2 bits both are used for something else. At that time you should have an idea if something bigger than nano could still be necessary and if yes, how to solve it in another way. And if the version bit would be introduced Safe will be that popular (you need more than nano precision…) the work part is less of an issue.
The coin balance is stored in disk data, so the program has to know what it is looking at. Until a coin balance is updated on disk only the u64 is valid and after update it is then bigger by 8 bytes
If a version byte doesn’t need to be introduced right away it is indeed probably the better solution.
No it would be needed now unless you use that one bit to indicate the need for one, but makes the direct use of the variable a tad more complex.
In my opinion it probably will be good to have a version variable anyhow in case of future enhancements. The version though could be in the account information and when any of the balances in the account data is updated they all are.
For contacting the c api the data type needs to be reconstructed on the other side precisely the same (bit length) - it’s not like the api could suddenly hand over a u128 instead of a u64 - enabling an upgrade for data types will always require changes in the APIs everywhere… So it’s not really something that could go unnoticed (from v0 to a potential v1) and a version information only has a value (in the sense of carries information) from v1 on and I would claim doesn’t make sense for the safecoin discussed here (only forces all users of the api to divide the returned information again/mask bits if included in the 64 bits…) so as of now more an anti feature than a feature…
On the whole, I don’t quite understand why it would make sense to save for tomorrow something that could be easily done today. Is nano significantly harder to implement right now than micro, or is this more of a stylistic debate? That’s a point that hasn’t come through clearly (to me) in this thread.
To that end, if there’s going to be a poll that’s open to everyone for voting, I think it might be a good idea to discretely state the pros/cons of nano now vs. nano later (assuming that’s what the poll would be about). That way people could make an informed choice.
I don’t think an “informed choice” is possible without quite a bit of background knowledge. The pros and cons seem to be in this thread already. I try to read, but I understand so little that I don’t even dare to give “likes”, although I do appreciate the input of all these knowledgeable people very much. Thank you all. I’m not a great believer in democracy, but rather meritocracy when it comes to this stuff.
+1 to this from me - nano now, but with a dust limit if necessary
I’m also pro nano.
However, I don’t think a spendable amount restriction is necessary.
Regarding transaction spam protection (in regard of frequency) it’s a little bit funny because Safecoin itself is some kind of spam protection. But yeah, if the min. spendable amount gets too cheap that might become an issue. Especially if there is no transaction fee. For bitcoin it had become an issue as well when the network got spammed and congested with microtransactions. In the rfc I couldn’t find anything about it. Would it be imaginable / useful to enforce some transaction rate limit per client on Elder/Section level?
So is it not possible to make Safecoin divisibility to be truly scalable? So that today we have 100 subunits and after ten years 100 000, later even more? You have to decide a magic number, that is enough for every imaginable and unimaginable scenario?
I’m running low on time, so I haven’t read through the whole thread yet. I did see my previous suggestion in the old Safecoin thread mentioned a few times here, and am curious what the argument against it is. Neo is pretty adamant about not mixing binary and decimal, and I agree. He suggested a 64 bit - 128bit data size depending on the amount of desired divisibility. I still wonder why create divisibility at all. If you are going to make a large balance data structure, just make it non-divisible and multiply the number of coins by whatever level of divisibility is desired.
Meaning, instead of 4B coins, simply make 4 Quadrillion coins. Or, if you want some divisibility, limit it to two decimals like most monetary systems available already today. Why make the problem more difficult by having so many decimals? This system is for every day people, and the every man doesn’t normally work in decimals 10 deep. So why are we creating a system that will be confusing to people?
Crypto is a new paradigm, so things that weren’t really possible before like micro-transactions for tipping or protocol/API/content monitization will enable new sorts of services and capabilities.
The ideas are similar to having more coins, but by inserting a decimal place you can maintain the original target number of safecoins.
128 bit would surely provide more than ever needed, but 64 seems more than adequate for the foreseeable future.
well - i guess if i want to send you 1 dollar (represented by e.g. 1 million coins) that would result then in 1 million ownership transfer requests + 1 million network interactions 
that’s probably the reason why divisibility doesn’t look this bad
except for that i for my part would agree with you 100% 
I mean, I realize that, but that doesn’t really address my question. Why micro tip people in .00000005 coins instead of 500?
Except that isn’t necessary in a balance data structure presented here. If each coin was an independent piece of data, you would be correct.
Think about it from a psychological perspective. There isn’t even a single coin for every person in the world. Distributed evenly, there’s only about .55 coins per person. That means pretty much everyone will always be functioning in decimals. That makes people feel like they have very little, even if the monetary value still ends up being high. Alternatively, everyone could have 550,000 coins, which makes people feel better.
Not to mention it is just easier for the maths.
ok - sorry then i misunderstood your suggestion - well - then you are just talking about the representation layer 
tbh i don’t care about that one … 
… whatever anybody comes up with is okay for me
Yes a dust limit is probably the sensible way to approach this. I had not even got to considering the spamming aspect yet. Maybe for early tests the dust is even as high as 1 milli safecoin, but you can specify an exact value down to the nano and the value though has to be at or over the dust limit
I’d be possible but setting the lowest division now makes sense since it determines the data structures used and to get lower means expanding the structures and that requires upgrading every coin balance existing in the network by some method. But they are encrypted so this process has to be done as the coin balance is used
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
Reminds me of one of my all-time favourite bits of design, UTF-8. Really clever use of the eighth unused ASCII bit
Exactly. Bitcoin wallets for example usually let you choose if you want to see your balance in BTC, bits (oyyy how I hate that name), or satoshis. I think the lightning wallets are all defaulting to satoshis now.
as a crypto trader I really don’t mind fractions, or see any personal advantage to turning decimals into whole numbers. I guess for nocoiners it could make things more friendly to not have to think in fractions directly. @Antifragile 's point is valid though that if you make a unit that is not even worth 1 sat its gonna be even more confusing when trying to trade. I would say keep safecoin as it is and then on the front end let people toggle views between whole coins or nano-coins but that is just a representation of the actual amount of safecoin under the hood. Maybe they like to see 1 smiley face for each coin. You could represent in a myriad of ways. I am all for letting people look at it in different ways if it helps them out being comfortable transacting. I am against actually making smaller units for real.
Where I could accept it is when the network gets so big we are transacting on the last decimal place. I would not call it some new smaller unit though. I would just make safecoin go to an additional decimal place. I mean I guess there already ARE smaller units. The last decimal place is the final indivisible unit. If we need more decimal places OK then I guess we are making smaller units.