Already done, just a specific part of it and no updates since this
4 Likes
Exactly. For example Bitcoin nodes code only deals with satoshis, and bitcoins only appear in front end programs.
To plan for futur possible usage, nanos is clearly better than micros.
Edit: My previous calculations were wrong. It is micro that would be similar to satoshi: one satoshi represents 10E-8 bitcoins, so 100 times smaller than one micro. But Bitcoin max issuance is 200 times smaller than Safecoin, so in fact micros would be very similar to satoshis.
So, I change my mind because I donāt see a clear winner anymore between nanos and micros. For me Bitcoin is the reference and if Satoshi is good enough as base unit, so would be micro.
Edit 2: but then LN developers invented milli satoshis, so maybe nanos would be useful?
14 Likes
If the back end stores 1 micro as 1000 nano, but doesnāt expose this information, then it could be possible to provide as interface later on. However, nano and micro could be exposed via the api from day one.
My opinion is nano has more headroom and it should take advantage of. If itis absolutely necessary to provide only micro numbers for some clients, I donāt think it would be bad to expose this via the API. Simpler is better, up to the point where you sacrifice capability.
5 Likes
How do you guys feel about, start micro for initial test-safecoin. As it is a u64 we can go deeper later with not so much trouble at all (we have the space in that u64). This allows us to march quickly to test-safecoin and app devs to play around and so on. If we start with very hard ot make mistakes in apps then look at complexification later?
11 Likes
If you do what @Traktion suggested and just expose micro, but store as nano and build the API such that nano is a natural expansion of the interface then there is no reason to worry. But Iād like to think this is a pre-launch phase with clear intentions for nano to be used by the apps after release.
Otherwise it is like a number of things, this simple upgrade to nano will be pushed back further and further because of the weight of produced APPs and desired functionality will be essentially lost and adoption of safecoin delayed because micro $ transactions is lost and people see nano is the base safecoin value and see that APPs just are not providing said functionality.
19 Likes
Test safecoin is a test ā¦ so go for it! 
9 Likes
Thatās a fair point ā¦ I think the intention needs to be made clear in any case ASAP. So any who do start developing can plan for and around it.
14 Likes
Agreed. Also after launch all network upgrades will require node operator consent, which going by Bitcoin and Ethereums experience opens the system up to all manner of social attacks, disinformation campaigns, fear mongering. Messing around with the default base unit would be a good issue for social manipulators to attempt to rally node owners around to refuse the change using all manner of deceptive arguments.
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!?
16 Likes
Hmm - actually true - issues can only happen when trying to transfer/calculate with > maxCoin/1e6 which is still a ālargeā number of coin 
and starting earlier gives devs more time to come up with an elegant solution for each programming language
8 Likes
Good points really. .
2 Likes
Why not poll now we have the info we wish, AFAIK. Seems like a reasonable time to take the temperature?
9 Likes
Not sure if poll is the best over reasoned discussions here. But what were you thinking of polling? āGoing to nano now vs going to nano near launch vs going to nano after launchā?
10 Likes
Yes indeed.
To add some more info, not for a particular purpose just so we can better understand a similar situation of bitcoin/lightning, the division to 8dp in bitcoin is not considered enough for lightning network use cases.
Lightning network uses millisatoshi is the base unit (type uint64). But this adds edge cases when closing a channel on the blockchain.
Firstly, thereās a limit on the smallest transaction amount in bitcoin which is known as ābitcoin dustā. It means a very low-value channel may not be relayed or mined and thus canāt be used to open or close a lightning network channel. So a 1 satoshi channel isnāt possible in the current design of bitcoin.
Secondly, when closing a channel, the balance may contain some millisatoshis which cannot be settled on the blockchain. These are all rounded down to the nearest satoshi when closing channels.
So thatās 21*(10^6)(10^8)(10^3) total millisatoshis, or 2^60.86, well within a u64 but outside the safe range for double precision floating point numbers.
Key takeaways from this
- Very fine resolution is anticipated to be necessary, hence millisatoshis as the base unit of the lightning network and not satoshis
- Fitting the total units into a double precision float (the only number type offered for many systems such as javascript) is violated in lightning network but it hasnāt blown up because of it
- There may be 10^9 subunits of safecoin (nanosafecoin) but it may be convention (set by vaults) to only accept transactions that are in multiples of 1000, effectively setting the number of transactable units to 10^6 (millisafecoin). If needed later this can be relaxed. Itās primarily meant as an antispam measure but it does have other benefits too.
Another thing to state (which I donāt find very convincing but letās see what it provokes) is lightning channels will mostly be dealing with relatively small amounts. So the amount of millisatoshis in a channel would almost certainly always safely fit within a double precision value. Arithemtic on channels shouldnāt have problems with overflows etc. But the calculations that do have problems are unfortunately also the most valuable ones.
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.
2^53 nanosafecoins is about 9,007,200 safecoins. Doing calculations with quantities more than that could become unsafe if the user isnāt aware of the details of their language / floating point safety.
19 Likes
During some of the debate it has not been clear to me when people were talking about underlying representation and when about developer API. Again here!
So when we say āgoing to nanoā letās be clear about each of API, and underlying representation (backend).
If I have understood, it is feasible /sensible to use 64 bit values on the network (internal representation), and for backend implementation to operate in nano, and for the developer API based on that to either provide nano or provide micro.
So Iām assuming going to nano or micro refers to just the developer API (on top of a 64 bit representation with nano operations). But as I say, Iām not clear that this is what is being discussed.
6 Likes
That is what i understood from Davidās post. He said previously āu64ā. Not sure if that is set in stone yet or a suggestion that it should by David. But I understood the poll should be about the API
5 Likes
Iāll wait to do the poll till I get some confirmation on what was actually being asked to be polled.
Using nano safecoin we only need 62 bits so I thought that it might help to make it signed allowing both addition and subtraction without the need for exceptions of that operation overflowing. And being signed it may allow some benefits elsewhere in the backend when working with coinBalances and/or sectionās coin balances. I donāt know yet where but the possibilities are now there. @anon86652309
9 Likes
Another idea: one of the 2 unused bits could also be used in the future for versioning (to have more precision than nano).
value of this bit = 0: safecoin is completely in this u64
value of this bit = 1: this u64 is followed with for example a āVersion: u32ā.
This is not a priority now, I think, and if it becomes necessary in the future, then it means the Safe Network is very successful and a lot of smart people to come up with a solution then.
As long that at the backend nano (very handy that this sounds as nine) level a possibility is, certainly long term and for possible micro transactions, like you already mentioned, it seems ok to me (as someone with no fintech background).
1 Like
not a reason to use bad practices, the compiler would just use the compiler-rt (thereās even a rust impl) (this applies for eg u128 on pretty much all systems)
looks like premature/micro optimization to me. also you would need to handle the overflow/carry of parts by hand, i do not think that this would be faster than optimized compiler primitives.
5 Likes
I wonder if trying to utilise one of the bits that way may cause more work than just having a version byte up front. I would say though that if you did it that way then it would be expanding the u63 to a u127 and the 2nd u64 space + the first is a u128 variable and represents 10^-27 of a coin. Personally my opinion is that 10^-9 (nano) is enough while the safecoin is less than say 1 million dollars.
I was thinking that having s64 allows a subtraction result to be negative and either fail it or add a 3rd balance to bring it back positive. I can imaging that this might come in handy some where. But I know of no instance but the devs working on it might know of one.
3 Likes
Masking bits and manipulating raw byte data is super easy with python but might be problematic with other languages (like js 
) not sureā¦ might be over engineering hereā¦
(Knowing which version 64 vs 128 should be fairly easy simply because of the length if it ever becomes an issue)
2 Likes