RFC 57: Safecoin Revised

Yes, mostly, but arm cortex / m etc.

Rust is doing good things on embedded which will help a lot. I am not certain of the “c” code that currently is in use in terms of integers they provide, I imagine at least 32 bit is handled though.

Yes, I am thinking more of headless nodes, vaults and possibly clients (sensors etc.)

I do not think we will have issues handling integers and 64 bit integers through various means though. It just may be a good bit slower, but in saying that, internally there are a few 64bit representations in the code, so no need to focus on that for safecoin alone. It would be something that would need to be handled in any case.

2 Likes

Maybe just a custom library for dealing with safecoin in js?

I guess that a browser wallet could be a plugin (as opposed to an extension) and plugin can be written in many languages - even rust.

Seems like many possibilities here.

1 Like

And yes a library - either programmer makes one or uses one that will be available sometime soon after release. Its not an issue here.

If just for safecoin then slowness is minimal as I’d expect the embedded device isn’t doing too many of them a second

2 Likes

And how about spreadsheets? And … and … and on it goes. Just saying… this is a general problem and even though it can (and will) be resolved, it would be nice to do it with minimum screwing around and maximum foresight rather than hindsight.

Although Excel can display 30 decimal places, its precision for a specified number is confined to 15 significant figures, and calculations may have an accuracy that is even less due to three issues: round off, truncation, and binary storage.

4 Likes

What about integers? I seem to remember using very large integers in libre-office calc and not having any issues EDIT: just tried libre-office calc and no integers

And any financials apart from simple $/Cents without mult/div is a pain in the backside and needing the use of the rounding frunctions to get any control over its crap maths.

I would hope noone uses excel for anything safecoin other than recording facts and not trying maths.

1 Like

Google has their cloud sheets … probably all js? Maybe some young entrepreneurial type will make Safe sheets! Coded in Rust! :wink:

Edit: if safecoin does well … I will fund that! :wink:

2 Likes

Cell A1 =POWER(2,32)*POWER(10,9)
Cell B1 =A1-50
Cell C1 =IF(A1=B1,“broken”,“works”)

Says “broken” for me

6 Likes

Perhaps one thing to say in favour of the ‘libraries’ concept is it provides a strong rally-point for sub-communities to form and is some easy low-hanging fruit for getting developers involved if not in core at least in the ecosystem.

3 Likes

About feeling hurt by having your ideas and creations confronted with scrutiny, reason, arguments and being asked to explain the rationale… I don’t normally expect developer professionals to do that. Not because it wouldn’t be human to do so - it is! (And not because there aren’t very good reasons to be considerate, diplomatic as well as kind in many situations.) But because a major part of our profession is about NOT feeling hurt by that. Just like it’s human to run from a fire, a fireman’s profession is to NOT do that.
One of the biggest skill as intellectual, is not knowing most or best, it is to devour the knowledge of - as well as convey to - others, and to speedily and accurately (without distracting irrelevancies) exchange arguments in order for one or the other, or both, to be able to devour available knowledge.

So I simply expect professionals to be professional, and don’t worry about that.
To me a conflict of views in these relatively simple matters (we’re not talking philosophy here) is always a win-win. Either you’re showing me that I’m wrong, and I can be very grateful for not having to be wrong anymore about one more thing (leveling up in life!), or I show that I am right and obviously that is a win (because we can continue doing important stuff based on that, and I was able to contribute by being the source).
The case when there actually is a distinguishable preferred way, and we don’t reach this mentioned outcome, is a failure, a malfunction in our communication.
I consider that a malfunction because we should all strive to be as trained as possible to communicate in this way, it is a prerequisite for effective collaboration. Humanity after all is nothing without collaboration, so it indeed is a virtue to get skilled in it.

I’m actually quite surprised @neo has had to repeat himself several times, almost as he is begging for this communication to take place, and still his arguments are not refuted, and no (substantial) arguments for him to refute are presented. That to me is a failure of what we are trying to do here.

I didn’t think I would need to say anything in this regard because I think @neo, @JoeSmithJr, @Traktion and others have been laying things out perfectly logically to either accept it as is - or if we don’t quite trust their judgement, verify the statements and numbers ourselves. +Not that discussion isn’t needed or good, I just think the discussion has been lacking at best.)

But, I’ll add to that (fwiw), that as having worked in fintech as well, I have no differing view on this than the above guys.

The problem isn’t not rolling over when you think it doesn’t make sense (I don’t do that either, fiercely so when I think it’s important). What you need to do is show why it doesn’t make sense to you (produce counter arguments to be refuted), and preferably show why your idea makes sense.

(Now I know you said early on that you actually were not supposed to spend much time in this topic, argumenting back and forth, so that there is perfectly understandable - but I would have expected that to be used for reason then, like “I’m sorry guys, I do have some good arguments here, I just don’t have time to do this right now.” )

I don’t see any other way forward for productive argumentation:
Either refute their arguments, or produce arguments they can’t refute, or as a last resort bring in someone that you know can do either of those. If not, roll over. That’s what seems sane to me at least, and so that’s how I do it.
(Again, ultimately ending up in failure in communication I consider to be a fundamental lack of prerequisites for collaboration, so I don’t include that.)

There’s beginning to show some arguments in later posts now (more or less refuted IMO), so I’m happy about that :smiling_face:

My 2 cents.

22 Likes

Great summary on the way forward @oetyng. There is some great work going on in the rust community on restructuring the RFC process to emphasise locating the best solution, rather than winning the argument. A lot of the communication problems displayed in this thread they are attempting to address through better RFC process here: AiC: Adventures in consensus. Also the Forum and the collaborative summary document.
Could help structure future Safe Network RFCs so they are less chatty and with more meat - although may still be too bleeding edge.

8 Likes

Thanks for the measured reply, @anon86652309. I’m very encouraged to see that you have not taken any of this personally (as they were not meant to be!) Your success is our success, and we’re all rooting for you and only trying to help (maybe by now and then drying your sweat while you lift all the loads).

Disagreeing with the feedback but not acting upon it is the same as refusing it.

Disagree AND commit. This means that you may personally still not fully agree with how the rest of the team wants to proceed, but if they offer very good reasoning/evidence that you cannot refute, then you owe it to yourself, to them, and to the desired goal to commit to their approach. This is because we all have blind spots. Oftentimes, something that appears straightforward to us may not be so to others, especially when we haven’t had the experience they had.

To be more specific, the only valid argument you would have to not take the course of action above would be for you to state that you are very aware of the pains that @Neo and several others have described, that you’ve encountered such difficulties, and here is how you have successfully overcome them in the past using such and such. Alternatively, you can offer a recent innovation that has obviated their concerns and which they’re not aware of.

But if you don’t have that evidence, the rest of the group cannot afford to go through avoidable pain just so you can finally be convinced. If you agree that all these well-intentioned folks are not making ups their experience with fintech programming, then you can’t reasonably insist (it’s implied) that the fintech world change to fit your approach when you aren’t fully familiar with the concerns they must make allowance for.

Barring these, again, disagree and commit. It isn’t about rolling over. It is the only way to successfully move fast. I’m rooting for you.

10 Likes

Thanks for the further comments folks. With regards to the underlying representation being a u64, I guess it’ll save a lot of further time if I agree that we should adopt this approach. So I’ll agree to that now :slight_smile:

Well, I believe my argument that it makes the code clearer still stands, but I understand that’s a personal opinion. His arguments didn’t (don’t) make a more compelling case to me, but I don’t want to draw out the discussion on what I consider to be an implementation detail.

I really hope this isn’t seen as me wanting to win an argument btw! I kept the discussion going before because I couldn’t understand how my point of view was so controvertial… I wanted to understand. I’m reasonably convinced now that there’s no lack of understanding on either side - it’s just a difference of opinions.

Agreed. I expect once we reach a conclusion on the various points in this forum topic, the RFC will be updated to relect the consensus. So for this particular one, I expect the Coin struct to be updated to hold a single u64 as my current example code does :slight_smile:

I feel the bigger issue needing a conclusion is the level of divisibility, and after reading the Bitcoin discussion linked by @mav, I’m now favouring divisibility down to micro-coin. Again, this is just my own personal opinion. I do try to be careful to say “I” when it’s my own opinion and “we” when I’m talking on behalf of the company or backend team, etc. I’m sure I slip up now and then, but I try to remember :slight_smile:

Thanks again for the constructive feedback and support, all!

41 Likes

I actually agree with you on this :slightly_smiling_face:, I think it’s immediately evident what is what when looking at part and fraction, and with single u64 it is a little bit less so. But I don’t think it is worth the downsides.

Honestly, to me it looked like someone very intelligent being very sure of his own idea (it’s nothing strange), and for some or other reason not countering the counter arguments, maybe because of a tad of stubbornness :slightly_smiling_face:. But of course fully aware that’s just what it looked like to me, so not what I considered a fact.
Anyhow, so I for one did not see it as you wanting to win an argument :slightly_smiling_face:

For the divisibility, I am not of the same opinion right now, but if I’m going to weigh in I will need to read and think a bit more.

9 Likes

Hmm - where would be the down side of exposing micro and nano as the two units? (one that works for all languages and one that can be used by the mightier ones)

3 Likes

It’s a question of browser compatibility at this point. Micros would work with JavaScript, nanos would be problematic though BigInt could be utilized for that. WebAssembly may also be some sort of an answer.

It’s messy and it’s complicated. Two ways to do the same thing will lead to confusion too often. It’s better to dealing with the same kind of representation both under the hood and the API should follow that. A single number that represents “nanos” or “micros” (whihcever will be the chosen basic unit) would be the simplest for that, and safecoins would only ever show up in the GUI or on exchanges. It’s how all coins do it, by the way.

2 Likes

We don’t want opinion but reasoned discussions as the the best way to do things. I backed what I considered to be correct using 6 decades of industry practice and so was not expressing my personal opinion here but standards/practice for storing financial data.

It worries me when RFCs are decided on opinion and worries me that it is framed as your opinion opposed to others opinion. RFCs are better than that surely?

And that is where you missed the considered arguments. It was considered a front end issue when the argumentation was directed at a specific back end issue.

We are all prone to cherry picking and here I feel you have done this. SAFE is better than Bitcoin and SAFE has so much more utility than an experiment, so we should be open to reasons and argumentation why we should have nano over micro. Not the least is that we cannot be short sighted. Nano is important since once once SAFEcoin is over 1$ micro no longer is able to provide micro $ transactions or tipping. Some (big discussions on this) feel this is absolutely important for the economy of SAFE since advertising revenue is not available and so tipping and micro $ transactions is essential.

@anon86652309 please don’t handwave all of this as mere opinion, but I have mostly shown reasons and tried to stay away from opinion to show why nano is important for SAFE. Maybe those reasons are not important enough but they are not opinions.

And BTW you cherry picked @mav reference and ignored the reasoned discussions and even @mav’s reasoned considerations and @mav is experienced in bitcoin workings so I regard his reasoned considerations as important as the referred to documents because SAFE is not bitcoin (wallet) but it is so much more in utility and safecoin hopes to have more utility than bitcoin, so lets not limit it to bitcoin’s ability when we have the ability to have nano just by using all the decimal places available in u64

@anon86652309, if we have nano on the backend and only expose micro safecoin then that is a different matter. Then the algorithms can work in 1000 nanos and in an update as safecoin approaches 1$ we could expose the full amount. Of course it is simpler to just expose nano up front and then the front end APPs can work with nanos from the start. Java-script can use nano and someone will write a java-script “library” that others can include to handle nanos if the programmer feels the need

12 Likes

If the backend only has micro … how difficult would it be down the track to switch to nano?

Unless it is very simple to later add nano, then why not add it now? As pointed out js can use micro for now anyway (everyone can and likely would) and perhaps by the time there is need to use nano either js will have advanced it’s technical abilities or a library will be coded to allow for this.

Edit: I guess I don’t understand this “micro should be good enough” viewpoint … is it that much harder to code into the backend? Can I beg for some explanation on that?

2 Likes

The issue is that if the coinBalance variable has 1000 in it then its 1000 micosafecoin (1 milli)

Now if you goto nano then a value of 1000 is 1 micro safecoin. So then all the coinbalances have to be converted by multiplying them by 1000. This can be done by version specific code and adding a “version” variable to the coin balance structure.

Now considering the issue arises when SAFEcoin is 1 dollar then we have to question is if its worth implementing micro now and then upgrade. And considering MAID went over 1$ already then is it worth doing the upgrade or is it better to just have nano now.

4 Likes

I can easily believe that when the network goes live the price will move well over USD$10 … Looking at market cap info and knowing how many people will flood into the network when it goes live I can’t see any other serious possibility for it remaining under that level.

6 Likes

Hope it’s okay that I share this.

Bullish.

7 Likes