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

18 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 https://en.wikipedia.org/wiki/Boneh–Lynn–Shacham (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).

5 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

8 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… )

4 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 @Fraser! 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

As far as I know, IOTA has cca 2 779 530 283 000 000 IOTA in circulation, thus way more than 2^32. MIOTA stands for 1M of IOTA.

2 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