RFC 57: Safecoin Revised

[bridge]

I think that the core thing is “limited” total number, not “total number”.

People still buy BTC even it is over 8,000 per coin. Because it has “limited” 21M total number. No one have something wrong about total number or BTC is 21M.

People really like if someone give them 0.5 or 0.05BTC because BTC has high market price. But 0.5 or 0.05 ripple doesnt make them happy. Maybe 10,000 ripple make them happy (0.5 BTC = 10,000 ripple).

So I think the total number is not important so personally too high total number is bad for ecosystem. The order book trouble…

[neo]

@Toivo

Can we in practice do without any magic numbers, or does there have to be some?

There will be some since we are humans, have a similar financial currency to each other, and IoT devices are created by humans so yes there are some inherent ways humans think and act. Like using 3 billion coins to pay for one bottle of milk does not go down well. But 3 coins does, so leaving safecoin as 1 MAID and having decimal places is one such magic number. And then to determine the value of that magic number (number decimals) comes down foreseeable value of 1 safecoin in the future and what we can see it being used for and accounting for the unforeseen. At this time 9 places fits a u64 and seems to fit IoT for a while to come (at least 10 years)

Now because it is feasible to increase to u128 and virtually unlimited decimal places (up to 28 places and unlimited since each atom in the galaxy or universe is less than the count).

The increase would be done with some effort, but if needed in 10 or 20 or 30 years then that is fine since much will change by then anyhow. The effort is in changing the API to include a version parameter and

• for apps not yet converted they don’t supply a version and thus treated as pre-conversion values
• any coin balance accessed without a version stored in the account data will have its data structure upgraded automatically to use the u128 and a version for that coin balance stored with the account data.
• Updated apps will supply a version parameter and be able to specify values all the way to 10^-28.
• Again there has to be a “dust” value that again maybe a number with “magic limits” that the system can vary depending on space/size of network etc. But this “dust” limit prevents spamming and again is a human created idea and thus the dust limit will have its value partially determined by human nature/experience.

@draw

But I’m not so sure that feeling will remain if you’re effectively going to use the coin to buy stuff. Think on some poor countries where you could need a wheelbarrow of money to buy a bread… That sounds like a very expensive bread to me.

Definitely and actually mention above. safecoin is a network coin and a human coin.

My personal opinion is that the safecoin is kept as a coin with say 9 decimal places and there is a name given to nanosafecoin and machine usage of safecoin uses this nanosafecoin as its basis because IoT does not have the “wheelbarrow of money” issue and its just similar to use nanosafecoin than trying to frame it as safecoin. safecoin is just nanosafecoin with a decimal point added at the 9 place mainly for us humans.

@lubinew

I am getting thoughts maybe even 10^-9 will not be enough.

Yes that occurs to me at times to, But I have no justification to back up going further than 9 places (nano)

If 1/2 the coins exist and the nano safecoin is 1 micro $ then safecoin is 1000$ and total supply is 2 trillion dollars. This is not the world’s financial turnover so you may have a point. My thoughts are that we want to be able to specify 1 micro dollar for all those who wanted to do micro $ tipping/transactions. But for IoT this may very well be the case that the sensor wants to earn something for every reading it supplies to whomever asks. Or to allow payment per GET rather than waiting for payment after an certain amount of GETS

But are we going to see 1000$ in the next 10 years. 1/2 supply of safecoin is 100 times the maximum btc supply and so is safecoin at 10$ somewhere near equivalent to btc at 1000$ ?

@lubinew

then, there are some interesting ways how to get practically infinite divisibility by building apps above SAFE Network.

I’d prefer IoT to not require its own tokens since that introduces another element of uncertainty in what value the IoT can place on the payment used.

u128 certainly provides practically unlimited division for safecoin with 28 decimal places.

it is believed that between 120 to 300 sextillion (that’s 1.2 x 10²³ to 3.0 x 10²³) stars exist within our observable universe. How Many Atoms Are There in the Universe? - Universe Today

I’d say that is for all practical payment purposed unlimited division.

[TylerAbeoJordan]

I’m not understanding the concerns regarding exchanges using nano-safecoin. As it’s ‘nano’, then certainly the exchange can just insert a decimal point and trade safecoin, mili-safecoin, micro-safecoin, and nano-safecoin … all as required by the needs of the traders due to the trading value of safecoin.

Am I missing something here? Why is this an issue for apps and/or exchanges?

Assuming there isn’t any significant issue here … what are the issues with going nano and beyond for the network?

1. Presuming the network only exposes what’s needed, then would need to be managed by maidsafe foundation or some such – as an oracle would be required.

2. How does the network deal with transaction spam generally - assuming no transaction fees … does smaller size really make any difference here? If so why?

3. How low could we go technically? atto? zepto? yocto? Could be an interesting marketing angle - having the smallest divisibility of ANY coin.
   a. what are the problems with going THIS low?

4. … ?? other??

[TylerAbeoJordan]

The Safe Network … beyond blockchain … beyond crypto … beyond smart contracts … beyond the Internet … A new world order for information and currency management.

lol

[draw]

@TylerAbeoJordan

I’m not understanding the concerns regarding exchanges using nano-safecoin. As it’s ‘nano’, then certainly the exchange can just insert a decimal point and trade safecoin, mili-safecoin, micro-safecoin, and nano-safecoin … all as required by the needs of the traders due to the trading value of safecoin.

Last time I went to an exchange office after a holiday in a no Euro(€) country I could exchange, but not the smaller coins and notes (~= “dust”?)… I also hope and think something similar should be possible on crypto exchanges, but it’s good to check/think about it.

[david-beinn]

Just skim read this so apologies if I’m repeating anything but a couple of points came to mind so I’ll just throw them out there quickly:

• The workflow of the network in having (basically) one account and being logged in all the time lends itself well to micro-payments, so small units wouldn’t go amiss.

• Whatever the technical arguments, on the front end side, expecting people to be counting the decimal places isn’t going to work. Therefore a good, comprehensive naming system is crucial. A Satoshi is the only unit of Bitcoin (or any other crypto currency) I’ve ever heard of, and I haven’t the faintest idea which zero after the dot it represents. For that reason alone Bitcoin is not easy to use, and should be regarded as a failure rather than a model to base Safecoin on.

• People have slipped into using the words Micro Safe and Nano Safe. I like this because it’s happened naturally and is not asking people to learn a whole new naming system, it’s clearly related to the main unit Safe, it reflects the maths, and adapts well if in the early days Safe is fluctuating (rising!) wildly against fiat.

[mav]

What do you think is a good model / analog to help reason about the design of the safecoin reward algorithm?

Here’s some ideas I’ve considered so far

Spring Mass Damper

The network has some built-in stable steady state but is constantly being pushed or pulled by the forces of uploaders and farmers. There must be some friction or control to reduce oscillations and some elasticity to absorb the varying magnitudes of uploaders. This can be modelled using the standard linear solid model.

Predator Prey

The farmer and uploader relationship is a bit like a predator and prey relationship where both populations fluctuate but are interdependent. This can be modelled using the Lotka-Volterra equations.

Population Growth

The scarce resources of safecoin are produced, consumed and reused by a population of uploaders and farmers. The population is expected to grow exponentially even though the resources are fixed.

Government Taxes and Subsidies

The network incentivises certain behaviours and discourages others at various times by governing the flow of economic resources. This can be modelled as a tax and subsidy depending on over- or under-production and the efficiency of participants.

Tides

There are big and small waves in the ocean that vary depending on wind strength etc, which is like the highly variable intensity of upload activity. But this is underpinned by a longer tidal movement which is the general flow of the network toward increasing or decreasing supply of coins.

Any others that come to mind? Any of these seem more or less useful?

[Nigel]

I personally like predator-prey because it seems accurate and fits into the bio-mimicry of natural systems that is often in Maidsafe’s engineering.

[JoeSmithJr]

Predator-prey can lead to this:

More specifically: Chaos in Low-Dimensional Lotka-Volterra Models of Competition

I would prefer something less prone to chaotic behavior.

[Nigel]

They’re looking at competing species though so not so sure that fits as farmers aren’t really a competing species but one that follows the same rules for the limited resource of (Safecoin). I guess you could even think of farmers as a pack in a way. It seems as though to me it’s a more pure predator-prey model simply because there are only one species each of both farmer and uploader.

I’m not qualified on the maths so my assessment is purely high level, just my take on it.

[TylerAbeoJordan]

How about:

consumer/worker → shopkeeper → consumer/worker

Maybe not abstract enough?

Otherwise I prefer either the tides or the spring-mass-damper model you listed. The others have negative connotations for me.

[neo]

@mav

Here’s some ideas I’ve considered so far

I still feel the original idea in the safecoin algorithm was a reasonable way to address the issue.

• Somewhat based on the free space
• Had a scarcity component where the more coins existing the less coins that would be created based on the results of the algorithm.

My thoughts were to add some parameters to that

• lower limit. The 2^-63 lower limit was not going to be good since a reasonable amount of free space meant near zero cost to PUT and near zero farming rewards
• upper limit of 1 safecoin per PUT was also somewhat high, maybe not as bad as the lower limit of 2^-63. Maybe min price should be around 1000 nano safecoin and max could be 1 safecoin still but only if the free space is virtually nothing (which hopefully never happen).
• Rather than an inverse law for determining safecoin price, something between linear and inverse function so that the price rose from the lower limit faster but was slower at rising when space was becoming less plentiful rather than the inverse function where the price only really rose when space was very short on supply
• The original idea put the difference between (near) min and (near) max price as very small in terms of the % free space so saying the previous point differently the range of the % free space needs to be much larger for min->max price of PUT

[JoeSmithJr]

@mav

Any others that come to mind? Any of these seem more or less useful?

I think best would be starting out with the most basic criteria:

• the network should never run out of coins
• the network should never fill up

NOTE: As @neo has noted, I messed up the order of these points but you’ll figure it out

The first point could be guaranteed if the PUT price approached infinity when running out of space, so we’d want “free space” (or a suitable proxy) in the denominator for the price function.

Similarly, the second point needs that rewards approach zero when running out of coins, so we’d want “free market cap” (or a suitable proxy) in the numerator and/or “coins in circulation” (plus constant) in the denominator for the reward function.

We’ll just need to shoehorn in whatever desired behavior is not achieved by the above, though they already do most of what we need, I think.

Then, some parameters, e.g. what should the theoretical maximum reward be (when there are no coins in circulation) or how flat the price / reward rise should be when we’re not near the extremes (very empty or very full network, very few or almost all coins used).

Then, some technical details: smoothing out changes (averaging over time, Kalman filtering, etc), including some headroom for the storage space (just in case), and so on.

---

The big question is, do we need to connect the storage cost and the farming rewards at all, or could they work as two independent sides? Could it lead to chaotic oscillations and, if so, can it be stopped? (For example, one side could be dampened using a much longer period than the other.)

[neo]

@JoeSmithJr

Similarly, the second point needs that rewards approach zero when running out of coins, so we’d want “free market cap” (or a suitable proxy) in the numerator and/or “coins in circulation” (plus constant) in the denominator for the reward function.

Actually that is your first point.

The original algorithm used a method to ensure this virtually never happened.

It did this by doing the calculation if a coin should be issued, then after that used the coin address and if the coin existed then the coin would not be issued.

Thus on an average basis the coin creation would occur in (coins existing)/(max possible coins) cases

Thus when 90% of coins issued only 10% of the time would a coin creation attempt happen.

@JoeSmithJr

The big question is, do we need to connect the storage cost and the farming rewards at all, or could they work as two independent sides?

In a sense they need to have common driving forces and that is spare space.

But maybe some sort of moving average could be used by both (but separate) so that massive swings do not occur, but the price/reward calculations are much more smooth arriving at the instantaneous price calculations more slowly and really only the average or mean of the instantaneous prices.

[JoeSmithJr]

@neo

The original algorithm sued a method to ensure this virtually never happened.

That’s true. But we can’t use that method anymore, can we? So, a new method is necessary.

@neo

In a sense they need to have common driving forces and that is spare space.

Maybe the farming reward needs to include something about free space too, just less aggressively than the PUT price.

Should the PUT price also include something about the amount of coins in (or not in) circulation though?

@neo

But maybe some sort of moving average could be used

Kalman filtering may help here. We (well, a section) would make a number of imprecise observations over time and use them to calculate a good estimate of the actual value. Something like that.

[Toivo]

How about getting rid of the term “coin”?

I think it is bad in bitcoin too, especially nowadays, when the value is far beyond the “coin range”. Also it sounds very un-digital, and can create confusion now that we have this common coin -algorithm as a part of PARSEC.

I don’t have time right now to give better alternatives, though.

[neo]

@JoeSmithJr

That’s true. But we can’t use that method anymore, can we? So, a new method is necessary.

EDIT: this was a progression of of ideas and the first part was musings
Maybe we can, since the section is responsible for a portion of the 2^32 coins, it could do a bitmap of issued/spent coins. So if 1 section the bitmap is 2^32 bits in the section. If 1024 section then bitmap is 2^22 bits etc.

Now this would allow the section to say issue milli coins and have a bitmap that is 1000 times the coins it is responsible for.

But really a bit map is not needed for implementing a scarcity function. Just knowing the number of “coins” existing in the section could allow this.

Say the section is responsible for 2^24 “coins” and there are 2^23 coins issued (50% of the coins) then every 2nd farming payment that was to be done results in a payment occurring. Or another way is to multiply the payment determined by 50% every time. Of course you could extend this to smaller units like say nano or micro or milli

[TylerAbeoJordan]

@neo

Say the section is responsible for 2^24 “coins” and there are 2^23 coins issued (50% of the coins) then every 2nd farming payment that was to be done results in a payment occurring. Or another way is to multiply the payment determined by 50% every time.

Just trying to get my head around this.

So each section would be paying out slightly different amounts over time?

How do sections get a balance … do sections divide over time and hence have their safecoin balance divided as well?

[JoeSmithJr]

@neo

Maybe we can,

Not as much as denying it as a possibility, what would the point be? Suddenly, there would be a need to store a bitmap for no other reasons than something that could be done much easier in another way, just as you described later on. Coins as network objects was a great idea, I love it, but there’s no point to retrofit its remnants into a fundamentally different concept.

@neo

then every 2nd farming payment that was to be done results in a payment occurring

If we had nanos, there may be no need for probabilistic rewards even. They would be a useful fallback for when safecoins are expensive though.

@TylerAbeoJordan

How do sections get a balance

They get half of the original section’s when there’s a split. Other than that, they are the ones who maintain the balance, so they know exactly how much is free and how much is used.

@TylerAbeoJordan

So each section would be paying out slightly different amounts over time?

That’s unavoidable, yes.

[neo]

@TylerAbeoJordan

How do sections get a balance … do sections divide over time and hence have their safecoin balance divided as well?

Each section divides in 2 and takes responsibility for 1/2 the XOR address space the original section had. The same applies to the 2^32 possible safecoin (or could say 2^32*10^9 nanos)

So if the section is the result of 8 divides it then is responsible for 1/256th of the XOR space and 1/256 of the coins