Well, yes. There’s not much choice there if we want to be able to divide the notional single coin?
So are you suggesting app devs and users should do this too?
Can you maybe give an idea of what actual bugs could happen with my proposed example vs having say just the NanoCoin type and no other types?
With the data length in the api to represent multiple safecoin if needed?
Yes, up to the max possible number of safecoin. I’m still meaning as per the NanoCoin example, but without all the other types.
…
@anon86652309 reflecting back to see if I understand your suggestion…
Developers using the Safecoin API will deal in nano coin* units passed as a single 64 bit integer, with a ceiling on the maximum number of nano coin it can represent, in units of one nano coin.
So for most API related calculations, apps will be doing 64 bit integer math with overflow detection (with errors thrown by the API where the max value is exceeded, or a value cannot be represented exactly - eg on parsing a value).
The underlying storage, not usually accessed by apps uses a representation that has a precision of a quarter of a nano coin (ie 250 pico coins). So that precision could be used in theory, but typically not, and would require access to a lower level API and would use the split value representation rather than a 64 bit integer.
* one nano coin is 10^-9 or one (US) billionth of a Safecoin.
How’s that?
I don’t actually believe any of the points I criticized were meant to be set in concrete. I just responded to Request for Comments with a snarky comment. I’m sure the final version will be great, and the general idea is already more flexible than the one from the previous safecoin RFC, though I liked the more unusual approach of discrete coins.
Is there reasoning behind it? Like to force bigger vaults to be split into multiple smaller ones? (which would decrease the avg vault size; resulting in even smaller vaults?)
Because you don’t want to accidentally mix multiple sizes in calculations. You don’t want to add a variable storing an amount in nanos to a variable storing an amount in micros then just assume the sum is a nano or micro amount.
The primary cause of this discrepancy was that one piece of ground software supplied by Lockheed Martin produced results in a United States customary unit, contrary to its Software Interface Specification (SIS), while a second system, supplied by NASA, expected those results to be in SI units, in accordance with the SIS. Specifically, software that calculated the total impulse produced by thruster firings produced results in pound-force seconds. The trajectory calculation software then used these results – expected to be in newton seconds – to update the predicted position of the spacecraft.
solution: use multiple types for each size that handle the size conversion implicitly
let sum = NanoCoin::from(1_000) + MicroCoin::from(20);
assert_eq!(sum, NanoCoin::from(21_000));
https://research.mozilla.org/2014/06/23/static-checking-of-units-in-servo
Which is only possible if you have different sizes 
Edit: Oh yes I see your point - you were targeting the ‘different structs’ - yes makes sense if they are incompatible for calculations for example 
… But I’m pretty positive the python api will simply use nanos then since it is possible 
No Divisibility is the reason to go from 2^32 data objects to a singular u64 value that can provide division all in one.
This is muddled thinking really. Its back to front. These first two sentences read we need split balance values because we need split values. It is rather circular.
And that is why you proposed a balance value. Then your split it up. Its like you want the one data structure for each coin then have a decimal fraction of the coin separate. This is basically bad reasoning. You created a balance system that got rid of the one data object per coin, so have a balance system and not a weird hybrid system that will cause troubles when the next (or the next or…) person updating the code makes a mistake. Also the hybrid introduces unneeded operations and avenue for bugs
Then don’t do it, it is not good. And I gave you a number of reasons above.
That goes in the memorable quotes for this project when people find out all about it and it causes issues as I explained above.
Please
You will be wasting operations in program, and the number of bytes will likely far exceed the 2 bits in each coin balance. It’ll be at least 256 to 512 bits wasted per node just for the additional operations needed to handle the under/overflow when doing the operations of the parts then the coin. It could even be >1024 bits with the error conditions.
So false economy
I apologise for my tone of voice and seeming hostility towards you @anon86652309, it is not intentional and no issues with you. The issue is with this one line of reasoning where you seem to have a bee in your bonnet and just cannot free yourself of thinking you need to split for dogmatic “reasons”
Well he has said he still wants it, so I take back that.
i think there’s no way around if we want to hide the actual implementation details, we need to have one (or more; especially if we want to add more granularity in the future, and also to improve UX if i only want to work with whole coins there’s no need to write $n * 1_000_000_000 (or whatever) and risk a typo) publicly visible type.
I meant it for keeping the full coins as u32 and adding another part for the change, not for how the change is represented.
Why not just have 4,294,967,296,000,000,000 nanos and define safecoin as a billion of nanos? It can be stored on one u64 (though a little over 2.1 bits are wasted) and it’s much simpler.
Anyway, most of these are already brought up, so I’ll add just one: 250 picos sounds really bad for marketing.
Absolutely - but I don’t think this needs to be done ‘inside the core’ - that’s something that can easily be handled by apps - nobody would want to type in large numbers… Just choosing the right unit that reflects the factor and handing the multiplied value to the one entry point in the api…
Ps: For starters it probably even makes sense to enable the user to put in dollars or euros and just showing the amount of safecoin that this will reflect (using for example current coinmarketcap data)
Exactly as I said before too.
The extra 2.1 bits allow for adding two vales together without overflow and check if the result is over 4,294,967,296,000,000,000. No need to worry about operation overflow then and will save even more program words trying to catch an arithmetical error and handling it.
Not to mention 6 decades of financial programming. Yea I know Excel broke it and introduce roundup/down functions to try and correct the issue.
It’s not exactly radical either, just continuing a practice that started with bitcoin itself.
I went to get a cup of water and was just going to add this when I was back. You were faster.
Why not? 1. we will have coin calculations in the core 2. typos can occur in the core too. The core would do the convertion to eg nanos at the FFI level.
As long as I can just go with nanos that’s all fine with me
Edit: And ofc I won’t hesitate to implement the other variants too in python for users that really want to use it =) it’s just that I personally would have seen it as unnecessary for my world because I don’t think I will ever use it myself oO
Any programmer worth anything in the financial realm knows how to work with fixed point and more than likely the front end language will have fixed point as a type and so any ascii to/from integer conversion will handle all the human interface. So the issue is only to have the most efficient and bug resistant structures in the core. And a split value system is not normal and more prone to errors/bugs being introduced when someone other than @anon86652309 does the updating around the coin balances and may even be unsure what is the point of the split value and make mistakes. Just have industry standard way of storing the value in the core and we potentially save a lot of heartache and potentially a failed safecoin system when a bug introduced 5 years down the track causes issues with people’s coin balances.