RFC 57: Safecoin Revised

[dirvine]

Or just penny where 10^6 (or similar) of them is a safecoin perhaps?

[neo]

Maybe we could hold a competition (no prizes though) for a name that people think it should be.

I dunno penny seems too overloaded now-a-days and we did away with them in 66 over here.

[happybeing]

Technical points aside, I think we should reflect as a community on how our passion can be received. We see it in this topic IMO and in others, when people tread on our toes or bump up against views we hold strongly.

I love that we have that passion, and I’m prone to doing exactly what I’m cautioning about here. I could easily have been at the centre or caught up in it too, and I have done so many times on this forum when I spent more time in discussions. I think it’s generally OK, but when it’s lots of us against one, I get concerned, particularly when it’s someone who we all know is very committed to the same vision and working hard to implement it.

Personally, if I was getting told one of my SAFE Drive coding decisions was rubbish and must be changed - I would feel hurt and demoralised - regardless of the technical validity (and for goodess sake don’t look, much of my code is not pretty).

I realise this is much more important than anything in SAFE Drive - but that would not change my experience.

One of the things David, Nick, Viv and all at Maidsafe have helped me with, by their example is taking that passion and directing it. I want to comment on this because I know one reason I can let that impact on others without realising it, is because if I’m on the receiving end it hurts. And I’m concerned that may happen here.

I don’t know Fraser, but I know most humans are sensitive to this stuff - including some who who don’t realise it (points to past self). I don’t think it matters if Fraser is completely fine with this, which he may be (and good for him if so), but I don’t think we knew that he would be.

Maybe I’m being over sensitive here. I can accept that, but it won’t do any harm to reflect on the possibility I’m not.

[JoeSmithJr]

@mav

Just to be sure (even though I’m confident everyone in the thread already knows) I want to explicity state that IEEE doubles are not and never have been and never will be proposed or used for safecoin.

I bought them up only in the context of “core-based handling of sub-coin units when values are represented as a single u64” to argue it’s a bad idea because the only meaningful non-u64 number that we could hand over to the core is the f64 and that doesn’t have the necessary precision.

[JoeSmithJr]

@dirvine

Or just penny where 10^6 (or similar) of them is a safecoin perhaps?

@neo

I dunno penny seems too overloaded now-a-days and we did away with them in 66 over here.

Even a dollar cent coin is called a “penny” so I feel it is not as much overloaded as it is a well-established generic name for “smallest indivisible unit.”

[JoeSmithJr]

@happybeing

Technical points aside, I think we should reflect as a community on how our passion can be received. We see it in this topic IMO and in others, when people tread on our toes or bump up against views we hold strongly.

@happybeing

Personally, if I was getting told one of my SAFE Drive coding decisions was rubbish and must be changed - I would feel hurt and demoralised - regardless of the technical validity (and for goodess sake don’t look, much of my code is not pretty).

I know I’m definitely one who’s personally at fault here and I do apologize. I came back from a funeral on Thursday and my filters were way off for the rest of the day. Not cool.

[dirvine]

@JoeSmithJr

I know I’m definitely one who’s personally at fault here and I do apologize.

No worries, we all know each other enough at least to debate. Everyone, me included are allowed to react like humans and not robots. Anyhow, I know @anon86652309 pretty well, he is hard to shake, so I doubt he was shaken Anyhoo, all cool,

[drehb]

@neo

Yea, we could be generic and call them nanos, or safenanos, or Daves, or safties, or just nanosafe

There was a thread with a poll about this before:

What is your favorite name for a SafeCoin analogy to BTC’s Satoshi? (reboot) divs = irvines, troons, and ayrs?

What is your favorite name for a SafeCoin analogy to BTC’s Satoshi? Bitcoin has 10E8 satoshi = 1 BTC. What would be a good moniker for SafeCoin assuming 2^32 divisibility as in the original proposal? Apologies to anyone who voted prior to the reboot. poll

[Anders]

I only looked briefly at the RFC, but this looks interesting: “As in RFC 0051, this proposal is that safecoin doesn’t exist as units of data representing individual coins (or parts of coins), but rather only balances of safecoin exist on the network.”

It seems to mean that Safecoin transactions are done directly with those balances, and therefore will be very efficient regardless of the amount in the transactions.

[Sotros25]

@neo

Maybe we could hold a competition (no prizes though) for a name that people think it should be.

Well, we did have a topic devoted to this question: What is your favorite name for a SafeCoin analogy to BTC’s Satoshi? (reboot) divs = irvines, troons, and ayrs?

Perhaps, we start there?

Just noticed @drehb noted this too

[Mindphreaker]

@dirvine

Or just penny

I always liked the name “Troons” in regard of tiny parts. Send me some Troons!

[Audity]

Aye, gimme some Ayrs.

[tfa]

My remarks on this RFC:

• Each CoinBalance has an associated queue named credits, but it isn’t stored in struct CoinBalance. So, where is it stored?

• credits is a queue but no POP operations are described in the RFC. The Drawbacks section suggests that there is a size limit, but its value isn’t mentioned anywhere.

• Relocating chunks seems risky because a fundamental invariant is not maintained anymore: the 8 nodes nearest to its address store a chunk (8 or whatever duplication factor is). I propose that elders kill a node that cannot a store a chunk, at least in a first version and improve it later.

• Also remove the concept of good node and, instead, find a way to truly measure the space dedicated by a vault. There was a very good topic created by @mav on the subject (Proof Of Storage prototype).

[anon86652309]

Thanks for the concern folks, but no need to worry/apologise I’m as frustrated at my own obvious inability to make myself clear as I am at anyone in this thread!

@Bogard

I think someone mentioned overengineering in another thread (@opacey?). If this split structure or not debate isn’t emblematic of it, I don’t know what is. One is simple and practical, and many people with real life experience of pain have now chimed in with several examples. Yet, you refuse the feedback. Why?

I’m not refusing the feedback, I’m disagreeing with it. Possibly because I’m not understanding it, or I’m not being understood. @neo made a point in response to the previous safecoin RFC about the fractional part representing a decimal fraction rather than my proposed binary fraction, and I understood and agreed with his point pretty readily.

What concerns me here (and this is how I deal with code reviews too, both as reviewer and as author) is that I don’t understand where the breakdown in understanding is. What I’m proposing seems to me to be ticking all the requested points by @neo and others in terms of safety and historical lessons learned. I’m not going to just roll over and agree to something because lots of people are in agreement if I think it doesn’t make sense.

On that note… I rewrote the example code getting rid of the two u32s in favour of a single u64. In my opinion, it’s slightly inferior to the previous version in terms of clarity, but as promised, the library’s API has remained the same (well… almost).

One change I made was to rename the types as plurals, since I’m wondering if that could be the root cause of the resistance to my proposed example? Some notion that these types aren’t all roughly equivalent ways of expressing an amount of safecoin up to approximately the limit of 2^32 safecoin?

Another thought I had was that there might be a notion that the two inner u32 fields would be directly exposed. They won’t.

Just to be clear, with my proposed API, it will be exactly as safe to get the sum of two NanoCoins as it will be to get the sum of two Coins with the same respective values - there’s absolutely no loss of information/rounding errors/floating point calculations happening under the hood when using the Coins.

@mav

Some relevant bitcoin history with uncanny similarity to the conversation here about divisibility (bitcoin has always been integer math)

What I’m proposing is also integer maths, just abstracted in some cases via the Coins struct.

Your links are interesting though - thanks for posting them! It led me to this article which states:

Why do we care about floating point values if we have integers? Because many higher-level programming languages (eg. Javascript) do not expose the low-level “floating point” and “integer representations”, instead providing the programmer with only the concept of “number” - represented in floating point form, of course. If Satoshi had chosen 210 million instead of 21 million, Bitcoin programming in many languages would be considerably harder than it is today.

If we want to follow Bitcoin’s lead, we could use 52 bits to represent safecoins including their fractional parts, and that quote in @mav’s post indicates that gives enough divisibility. Their points seems fairly convincing - I find them more convincing than the arguments to not use 250 pico-safecoin as the base units under the hood.

So that could be presented as something like 4,294,967,295 safecoins as the limit (as per original proposal) with divisibility up to single micro-safecoin (10^-6, i.e. 0.000001) and that would fit in a 52 bit integer. Similar to Bitcoin, but not identical. ~4.3 billion coins vs 21 million and divisibility down to a mico-coin vs a hundredth of a micro-coin.

Or, if the marketing folks think it’s viable and the majority on here prefer, rather than having safecoins being divisible at all, just change the limit of safecoin from 4,294,967,295 to 4,294,967,295,000,000.

[anon86652309]

@tfa

• Each CoinBalance has an associated queue named credits , but it isn’t stored in struct CoinBalance . So, where is it stored?

I was thinking just as an in-memory queue by the vaults managing that CoinBalance.

@tfa

• credits is a queue but no POP operations are described in the RFC. The Drawbacks section suggests that there is a size limit, but its value isn’t mentioned anywhere.

All I had in mind was that as a new transaction is added, if the size of the queue is above the limit, we pop the oldest. The size limit isn’t mentioned because I just don’t know what a reasonable value would be right now.

Also, I’d hope that this whole mechanism of holding size-limited queues could be replaced by messaging from vaults to clients eventually. I see this as a stop-gap solution until then and would be happy if we could find a better way to let paying and receiving clients know that a given transaction succeeded without a need for them to be connected for the duration of the transaction.

@tfa

• Relocating chunks seems risky because a fundamental invariant is not maintained anymore: the 8 nodes nearest to its address store a chunk (8 or whatever duplication factor is). I propose that elders kill a node that cannot a store a chunk, at least in a first version and improve it later.

• Also remove the concept of good node and, instead, find a way to truly measure the space dedicated by a vault. There was a very good topic created by @mav on the subject (Proof Of Storage prototype).

These are both thorny issues, and I do feel they’re worth discussing further. I know they’re both mentioned in the RFC, but I wonder if the actual rationale behind them should be discussed in separate threads? Just to try and keep this one focussed on the actual safecoin details?

[Mindphreaker]

@anon86652309

Or, if the marketing folks think it’s viable and the majority on here prefer, rather than having safecoins being divisible at all, just change the limit of safecoin from 4,294,967,295 to 4,294,967,295,000,000.

I think this would not be an option as it would effectively mean a dilution for existing coin holders.

As others here I’m also in favor of introducing a sub unit compared to “Satoshis” and just store this amount. Wallets then of course can give users then the choice in which units they want to operate in the frontend.

[anon86652309]

@Mindphreaker

I think this would not be an option as it would effectively mean a dilution for existing coin holders.

I meant without the dilution though. So, 1 maidsafecoin would be equivalent to 1,000,000 safecoins.

[happybeing]

For folk who are interested in a broader treatment of the issues around programming money, not just representation, this article just popped up in my twitter about… wait for it : safe-money (a Haskell library)!

Although it is about a Haskell library, it covers all the issues I can imagine to do with how you might write a program to do stuff with money and explains the different techniques, when and why to use them.

https://ren.zone/articles/safe-money

[JoeSmithJr]

@anon86652309

So that could be presented as something like 4,294,967,295 safecoins as the limit (as per original proposal) with divisibility up to single micro-safecoin ( 10^-6 , i.e. 0.000001) and that would fit in a 52 bit integer. Similar to Bitcoin, but not identical. ~4.3 billion coins vs 21 million and divisibility down to a mico-coin vs a hundredth of a micro-coin.

Or, if the marketing folks think it’s viable and the majority on here prefer, rather than having safecoins being divisible at all, just change the limit of safecoin from 4,294,967,295 to 4,294,967,295,000,000.

I don’t quite understand what the problem is. MaidSafe can say:

The total market cap is 4,294,967,295 safecoins (as we already stated years ago) and each can be divided down to a million “pennies”, as we call them.

By the way, as a side note for the devs in the audience, as you may have already guessed, the network works with pennies expressed as 64-bit integers under the hood so there’s no need to worry about rounding errors.

It’s all a question of definition. Just because we stored safecoins as pennies in a single u64, they would not become any less “safecoiny” than if we stored them as two u32s, one for the whole coins and one for the decimals.

[Traktion]

@anon86652309

I meant without the dilution though. So, 1 maidsafecoin would be equivalent to 1,000,000 safecoins

There is a better way - you give the smallest unit a different name (nano-safecoin) and you call 1,000,000 of them 1 safecoin.

The same as representing £1 as 100 (penny) units.