RFC 57: Safecoin Revised

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 parts field represents a multiple of ā€œ250 pico-safecoinsā€, i.e. the number of 250 * 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 :open_mouth:)

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 :slight_smile:

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 :wink: )

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 :slight_smile:

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. :heart:

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 :thinking:

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! :slight_smile:

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