Discussion topic for RFC 57
25 Likes
Iām trying to catch up with this but Iāve hit an acronym I feel I should know
Ctrl-F on the superceded RFCs didnāt help so Iāll ask hereā¦
What is BLS?
2 Likes
The
partsfield represents a multiple of ā250 pico-safecoinsā, i.e. the number of250 * 10^-12-th parts of a single safecoin
Can we get rid of mixed binary - decimal units here.
Most people on the planet use Decimal and only some on the planet understand binary
Financial is now decimal. This is important
By having 250 pico, (0.000000000250) there is now a binary/decimal usage. It is confusing to the general public. They will immediately say what happened to 0.000000000001 As soon as you have 12 decimal places but apply a binary limit to the last 3 places you will create problems for anyone used to financial markets. Be it the school kid saving for that item, or the home budget person, or the banker, or anyone who is not fluent with different bases and understand the reasons why binary represented as decimal works a certain way.
I can tell you after 40 years of very technical programming, protocol creation, financial programming, and general exposure to the public criticising binary/decimal crossovers that you will have problems and general anger as to why they cannot use the last 3 decimal places.
If you think we need more than 9 decimal places then go to 64 bit for decimals.
Better yet go to 64 or 96 or 128 bit and represent the balance as one variable and have fixed point interger variable. This will save computation too. EG
- 64 bit
- 1 safe coin = 1000000000
- 0.0001 safe coin = 100000
- move decimal point 9 places
- 96 bit
- 1 safecoin = 1000000000000000000
- 0.0001 safe coin = 100000000000000
- move decimal point 18 places
- 128 bit
- 1safecoin = 100000000000000000000000000
- 0.0001 safecoin = 100000000000000000000000
- move decimal point 27 places
I will fight this till it is fixed up.
And yes this is a special pet peeve since it causes so much problems for people that i personally have had to either fix in my code for people or if in other peopleās code had to try and explain time and time again why the program operates in such stupid and idiotic way
20 Likes
Imho itās pretty stupid āto waste spaceā but since our world works decimal and there is plenty of space going decimal seems like a smart moveā¦ (I will probably sent 0.1 or 0.01 safecoin somewhereā¦ But not a strange in between valueā¦)
@Southside BLS digital signature - Wikipedia (I had the same look on my face when I saw it at the Roadmap not long ago - it suddenly seemed to be something one should know for ages 
)
8 Likes
I know. For the ones interested in a previous discussion about the topic: Fraser's Safecoin Alternative Design (Postponed State) - #2 by neo.
6 Likes
There is a reason that since the 60ās banking and financial programming has used fixed point notation (fixed point integer). Initially COBOL and later some use other languages, but the common factor is the use of fixed point integer and simply place the decimal point in a fixed place. Its nothing new and whenever anyone goes against that it causes problems. Financial programming uses way more than 2 places for their internal storage of amounts. Only your bank balances have 2 places. Interest was from memory 8 places early on and rounded when applied to your account balance
9 Likes
The point @neo is making has been brought up every time now when it came to safecoin discussions - has anybody ever had a contra argument?
(why is it not in the rfc anyway? Oo I really donāt understand thisā¦ )
5 Likes
Not about the decimal only part: I get that. But about the possible issues with an exagerrated level of precision: see the topic I referenced in my previous post.
Though for me not a high priority: just a remark if you say that binary can be confusing, then also a good idea to look if other things, like too much precision, could give confusion.
3 Likes
Thus this
struct Coin {
units: u32,
parts: u32,
}
Would become
struct Coin {
value: u64,
}
The āu64ā can be āu128ā if its thought we want more than 9 decimal places.
Now a modification could include a version number with the Coin structure to allow for expansion later on if we feel that 9 places is fine for now but may want expansion later.
Thus the structure would be
struct Coin {
value: u64,
Version: u32,
}
So Version allows us to upgrade the coin to more decimal places, or heaven forbid increasing the number of whole coin by a factor and so the new version coin == 2^x the old coin.
This would simply work after an upgrade that expands the range of safecoin (decimal places or #coins) by the code dealing with safecoin using the version to know how to process the coin and converting the balance to the later version in the process.
6 Likes
I cannot stress high enough that we want to present this to the WHOLE world and to have a technical only understood binary/decimal figure is a mistake that will slow down safecoin adoption
And the benefit to 250 pico is what? Extremely minimal compared to 1 nano safecoin
6 Likes
And encoding again base32z?.. I wonāt argue anymore because I just want to finally see it live - but imo opinion if you want do something in a strange way you donāt need very good arguments against it you need a at least medium good argument for wanting to do it ā¦ And just claiming better readability doesnāt make it easier to readā¦
4 Likes
THanks @riddim Reading up on that now 
2 Likes
Not sure what you are saying and to whom
To me a single integer representing the units and decimal portions is better since there is less work to be done to both implement it and process it.
5 Likes
You had me already convinced in the previous discussion that the pico part is probably a bad idea and it is better to not use these spare bits.
With not a high priority Iām more thinking about how much bytes/bits (precision) for the Safecoin āpartsā to start with. Edit: I also find something with a Version number a good idea (you could even use the spare bits for it 
)
2 Likes
To maidsafe because the suggested encoding for safecoin addresses is base32z
it was designed to be easier for human use permuting the alphabet so that the easier characters are the ones that occur more frequently.
ā¦ We are talking about encrypted data on safeā¦ So more or less random dataā¦ There is no such thing as more often occurring bytes ā¦
ā¦ I was arguing against it in the xor address rfc but seem to have failedā¦ (Edit: and imo itās a stupid choiceā¦ Sorry for being rude but saying it nicely didnāt make anybody hear and thatās just how I see itā¦ If you donāt have arguments and just want to do it because you claim it would be better and want to be differentā¦ Thatās not very smart imoā¦)
Edit2/Ps: if anybody can present something that proves that base32z is better readable than base32 I would appreciate it and maybe change my mind (depending on the proof really be proof or just an opinion/claim and relevant in the context of safe)
Pps: okay I obviously failed in not commenting too much on it again - sorry
8 Likes
Thoroughly agree for all the points mentioned. This is absolutely necessary, imo.
8 Likes
I saw this on the Dev forum first so responded there. We should probably just keep one topic, so Iāll link here: The Dev forum topic is being deleted, so hereās what I posted there:
Nice to see you @anon86652309! Hope allās well
Iām jotting notes here while readingā¦
First thought is - do we have a way to show that nobody has created more than the max issued Safecoin? As this was guaranteed while coins were data, but not with balances. Iām not looking for an answer right now, but I think it will be near the top of a FAQā¦ Ah, OK, if I understand it the Farming description covers this, by ensuring the total for all sections remains within that limit, or very close to it?
Iām concerned about another lost feature: coin balances are much more visible. I see that visibility is only to the vault holding a balance, but vaults could pool or even publish balances, both with true information or false information, for various purposes (FUD, tracking and no doubt things that Iāll never think of). Iād like to see this area discussed because it seems like a big change!
as the recipient will likely not be aware of the actual CoinBalance used by the sender to credit its own; only the transaction_id is visible
Does ālikelyā need to be in this sentence? If so please elaborate.
Creating balances seems very neat. Am I right in thinking this is a bit like creating a bitcoin wallet - as in that you can do it entirely off network and then somebody can send Safecoin to it. And when you wish, you can use your private key to claim it by creating an account? And import to an exist thing account? Plus you get the bonus that it is very hard for anyone else to be able to discover the balance on an address you give them - because it is only visible to a few random vaults. 
Related, from Unresolved questions: āwe currently require payment for the creation of a new CoinBalance instanceā. I think it would be great if a vault can be started without Safecoin cost, vital really! How could this be achieved - I guess it is tricky because otherwise youād be proposing it 
Account creation costs one PUT, correct? But messing with aspects of data (eg keys) stored in an account is free to mutate? Why - might this encourage spam?
If no initial CoinBalance::owner is provided, that vault will never earn farmed coin (its proportion will never be sent and will remain unfarmed at the source).
Does this mean that the maximum issuance of Safecoin is permanently reduced, or that the coin remains unissued but still farmable?
Farming - Iām sure weāll have a big discussion about the farming aspect, but Iām just going to note here: itās a big change, where instead of payments being decoupled from farming, with Safecoin recycled and used to pay for GET, everything happens on PUT: payment is received and immediately allocated (buffered before distribution), along with an equal amount of newly issued Safecoin (until the section reaches its max issuance). Itās a very interesting change!
Spam seems a big area to think about. This RFC seems to create opportunities for spam - eg in the coin transfer area - that werenāt there before because Safecoin was just data, albeit data that it was free to mutate.
First impression: really nice RFC, well explained and solves many issues. Might be worth doing a comparison chart to help people think about the change and see the pros and cons.
9 Likes
I really appreciate that youāre now considering switching to a balanced based storage system. I think this will be much more performant.
Additionally Iām a fan of divisability in general. However I also found the solution with units and āpartsā somehow confusing. On the other hand I donāt even know if it would be necessary to have divisability once we are nearing the 2^32 coins in circulationā¦ If Iām not mistaken IOTA has half this value for instance?
I fully agree with Neo that we should look for the most simple, most easy to understand solution which hopefully also is least error prone. My feeling here is that one value field is better in this regard, maybe if it means sacrificing storage resources.
5 Likes
Iām fairly ambivalent on the degree of divisibilty of a safecoin personally. The main argument I found compelling from the previous discussion was that the parts field should represent a decimal fraction of a safecoin. Other than that, I have a mild preference to make maximum use of the given space, which is why I stuck with parts representing the number of 250 pico-safecoins. If we donāt need that level of divisibility (which Iād guess we donāt) then Iād be happy to change that to represent the number of nano safecoins.
I donāt see this at all as mixing of binary and decimal parts though. The units part is a decimal value too if you view it that way. Certainly by default thatās how Iād view it.
A further point on this is that Iād not expect humans to be interacting with inner pieces of this data type directly, or having to work out how e.g. 12.3 safecoin would be represented. I can try adding a bit more detail to the RFC to show examples of possible constructors which could e.g. take a string or an f64 and output a Coin. So, given that, (and as mentioned last time) the inner elements being a single u64 or two u32s is an implementation detail. And in that case Iād favour using two fields for clarity.
(Edit: I didnāt mean to specifically reply to your comment @happybeing Having done so now, I donāt see a way to undo that!)
9 Likes
The most compelling point o using nano safecoin is the normality and understandably for people who are not technically and binary literate. Keep to what 99% of the financial world and other people in the world understand and use. We want adoption of safecoin, not people saying why cannot I use the full range of 1 pico safecoin. You show it but make it unable to use.
That is expected and understood. But when they can only āmicroā tip 250 pico safecoin and not 1 pico safecoin they will be āWTF there must be something wrongā and assume that it is broken and not trust it. And yes once you specify a lower limit people will want to use it for āmicroā tipping
Also why use two variables for units & parts instead of one integer (fixed point) that requires only one operation rather than 2 separate ones for units&parts
6 Likes