Early demand, and effect on storage costs, after launch

[dyamanaka]

@Seneca

Since we start with 30%(?) of SafeCoins already in existence, I should be initialized at 0.3 * 2^32, and A should probably be initialized so that TA == A where S = 0.3.

@Seneca can you create a simulation model to show how this works?
I ran some numbers and it didn’t turn out the way I expected.

---

Initialized Starting Point

IF

S = 0.3
I = 1,288,490,189

THEN

TA = 1,288,490,189 * (0.3 - 0.1) = 257,698,038

Am I correct in saying, the Network is trying to absorb 20% of the total SC in circulation from the start? Therefore, it will keep increasing PUT costs until it absorbs 257 million SC.

As we approach the SC cap of 2^32, the percentage increases to 90%, which means PUT costs increase until it absorbs 3,865,470,566.

---

I don’t think this will work. In fact, I think it will hinder the Network. Here’s why…

Early Demand
I think it’s likely only 10% of SC from the 430 million crowd sale will be used in the beginning. That means 43 million SC spent on PUTS. According to your formulas, the Network it is “already” looking to collect 257 million SC from the start. Let me know if this is not right.

SC Usage Limitation
If the Network ends up trying to absorb 90% of SC after cap. That means a higher percentage of SC earnings (farming, APP, PtP, etc) will be required to use the Network. It also means SC has less freedom to be used for other things, beyond Network PUTS.

Fiat Market Reaction
If the Network keeps increasing PUT prices, the market will likely drive down the fiat value of SC. Why? Because it costs more SC to buy less storage. The counter argument is that farmers will keep adding storage, therefore pushing the fiat value back up. We like to think fiat value doesn’t matter to the Network. But it does matter to consumers and farmers.

I have great respect for what you’re trying to do and really hope it works. Please don’t take this as a negative. I’m just adding a my point of view based on my experience. I’d love to be proven wrong because it means success for my investment and the project.

[Seneca]

@dyamanaka

Am I correct in saying, the Network is trying to absorb 20% of the total SC in circulation from the start?

You might have missed it because dirvine didn’t quote this last part of my post, but I took that into account with the value initilializations:

@Seneca

Since we start with 30%(?) of SafeCoins already in existence, I should be initialized at 0.3 * 2^32, and A should probably be initialized so that TA == A where S = 0.3.

MB/SC can be initialized at a guesstimate number, the algorithm would quickly correct it to the right value.

A should probably be initialized so that TA == A where S = 0.3.
I guess I could’ve written this more explicitly: If we initialize I with 0.3 * 2^32, TA is indeed as you calculated 257,698,038, and thus A should be initialized at that value so the network starts with the formula in balance. I.e. we initialize the formula with values as if the network had reached 30% of the coins supply naturally, with A and I in proper balance for the initial S.

@dyamanaka

If the Network ends up trying to absorb 90% of SC after cap.

it doesn’t try to absorb 90% of SC after the cap, it means that when 90% of the coins are in circulation, the network will try not to issue more coins than it absorbs. The values A and I are cumulative values, representing the history of the network, not the current state.

Edit: See my post below janitor’s, I did make a silly mistake which might have been the cause of this misunderstanding.

@dyamanaka

Please don’t take this as a negative. I’m just adding a my point of view based on my experience. I’d love to be proven wrong because it means success for my investment and the project.

No problem! I hope I convinced you!

[janitor]

@polpolrene

We would see websites that track the network and display real-time that we’ve gone from 0.1% to 0.2% of the coins in circulation.

If the formula is known, there will be no need to visit sites for this. SAFE clients/extensions will show the rate (“price”) and perform PUTs according to client-side settings (compared against the situation on the network).
Of course there may be more sophisticated analytics sites on the Web.

[Seneca]

I now see I did make a mistake though, maybe that caused confusion as well:

@Seneca

TA = I * (S - 0.1)

This is wrong and should be:

TA = I * (S + 0.1)

Because TA should be equal to I when S == 0.9, or at least in my example of a prefered reserve of 10%.

Edit:

@dyamanaka

@Seneca can you create a simulation model to show how this works?

I will do this, because I feel there’s another effect that I missed, one that would make MB/SC implode at higher S levels, so that would require tweaking of the algorithm.

[janitor]

@Seneca

tweaking of the algorithm.

So the current algorithm is “suboptimal” which has gone relatively undetected for 18 months.
Also, as it turns out that many (myself included) have had no clue how this actually works (which didn’t prevent us from buying MAID). Everyone seems to have thought that someone else did the math.
And along various queries (not to Maidsafe, but to the community here on this forum) about economics of the network have been ignored.

At this point I can only say there is no way to untangle this. I’ll probably post why after I digest this in coming days, but my initial reaction is that there’s no way to model this.

First and foremost, there’s the Day 1 Problem, which makes any analysis for time after that period highly speculative.
Second, even if we assume Day 1 will come and go, what happens later is also impossible to predict with any reasonable accuracy. For example, if one assumes HDD capacity will grow between 20 and 30% a year, that farmers will sell between 50 and 90% of their earnings, that the number of coins spent in Year 1 will be between 100 and 500 million, etc. the solution space becomes enormous.
Third, because of that, I now fully expect that the algo will be tweaked even after Safenet enters production, which to me used to be unfathomable. What would that mean for the value of Safecoin (including MAID right now)?

If the algo works as it’s supposed to, no one should profit because there should be no discrepancy between the dollar value of MAID and the dollar value of HDD space “rented” by the farmers and MAID. Other possibilities (relatively too cheap, or too expensive compared to a similar app on the Internet or a SAFE fork) won’t work or will require constant tweaking of the algo (a la the ECB). [I mention "similar app on the Internet; except for a fork, there’s no similar network, but in some cases depending on the use case, similar apps do exist.]

In some ways it’s going to be like with Skynet, where Safenet has to be switched on even though most people don’t know how it’s going to work simply because further delays aren’t possible.

[Seneca]

I did some testing and some thinking, and there is indeed an issue, which I think is what you were on to with your second point, but in different words:

Essentially, we start with a discount that sets the PUT cost at 40% (0.3 + 0.1) of the “real” price (price being the SafeCoins farmed). As we go towards S == 0.9, the current proposal tries to take back all the discounts it has previously given, because it tries to match I and A. It shouldn’t try to do this, as MB/SC would indeed keep collapsing (i.e. ever rising PUT costs).

So here is a redo of the proposal in an attempt to fix that:

---

I = total SafeCoins issued
A = weighted total SafeCoins absorbed (poor description, but please bear with me)
S = supply of SafeCoin (0.0-1.0)

On every SafeCoin that is bing absorbed, A is not simply incremented by 1, but instead:

A += (1 / (S + 0.1));

This means that at launch when S == 0.3 absorption of a SafeCoin increases A by 2.5 instead of 1. In other words, A now tracks the amount of SafeCoins that would have been absorbed if there had not been a discount.

Now we don’t need TA (target total SafeCoins absorbed) anymore, since the goal becomes keeping I and A exactly equal at all times, i.e:

MB_per_SC = Megabytes bought per SafeCoin

if (I > A) {            //fewer SafeCoins have been absorbed than we want
    MB_per_SC--;             //So increase the PUT price to start absorbing more of them
} else if (I < A) {     //More SafeCoins have been absorbed than we want
    MB_per_SC++;             //So decrease the PUT price to start absorbing less of them
}

Now we can also simply initialize I and A at 0 at the start of the network. Since the network will be empty, A will take the lead after the first few PUTs come in, which increases MB_per_SC until the network is filling up to the point that the farming algorithm kicks in. Then I will start climbing faster and faster until it surpasses the value of A. Then the balancing game truly starts, MB_per_SC will start decreasing, A will go faster than I again until it overtakes it, and so on. With every cycle (I or A surpassing the other) volatility of MB_per_SC will decrease.

[Seneca]

@janitor

So the current algorithm is “suboptimal” which has gone relatively undetected for 18 months. Also, as it turns out that many (myself included) have had no clue how this actually works (which didn’t prevent us from buying MAID). Everyone seems to have thought that someone else did the math.

I don’t know about the others, but I personally have been aware of these algorithms not being finished for a very long time already. Yes, I’ve been buying MAID regardless, because I have confidence that MaidSafe together with this community will find all the required answers. I’ve always considered this challenge doable.

[neo]

@Seneca, I was wondering how this will compensate for free space percentage.

I can see the case where free space is dropping because vaults are off line. Plus also the put cost is dropping because of the amount of issued coin. Which then encourages people who have been waiting for a more favorable (ie cheaper) time to upload to start their large uploads. Which then makes the free space situation worse.

Raising farming rewards when that happens will have a delayed effect in increasing storage and just not be fast enough to recover from the cheaper storage cost.

[Seneca]

@neo

Plus also the put cost is dropping because of the amount of issued coin.

PUT cost doesn’t drop because of the supply being low, it only drops when less coins are being farmed than absorbed. This will only happen when there is plenty of free space.

If vaults go offline leading to scarcity, the farming rewards will quickly go up, I will accelerate and overtake A, which causes MB_per_SC to drop (i.e. higher PUT cost).

@neo

It seems that your method will result in a system that attempts to keep the total issued coin as a %age of total coin supply.

No, my method doesn’t try to manage the total issued coin, that is part of the farming algorithm (which I think is fine already). The farming algorithm will issue as many or as few coins as it needs to keep the network healthy. My algorithm attempts to adjust the PUT cost accordingly, taking into account how close the supply of SafeCoins is to the SafeCoin cap of 2^32. The goal is to provide the lowest PUT cost possible while tapering off inflation lineary* until the SafeCoin supply is at 90% (that figure is debatable of course).

*lineary as a function of coin issuance, not lineary as a function of time. Inflation is higher in times of scarcity (high I), lower in times of abundance.

[neo]

@Seneca

PUT cost doesn’t drop because of the supply being low, it only drops when less coins are being farmed than absorbed. This will only happen when there is plenty of free space.

I do not see where coins issued by farming rate is in your formulas. Only the total issued coin, so coin issuance rate has little effect.

The coins issued from farming has a 2 factor control over it.

• the farming rate determines the number of successful farming attempts
• the coin scarcity determines the number of successful farming attempts that are successful in a coin issuance

In effect there can be less coins being issued from farming, but a lot of farming activity and plenty of “successful farming attempts” but little coin issuance. And no relation to the actual free space percentage. That is one reason the RFC has FR in the put cost calcs, because FR is the only reliable measure of free space percentage (that is what it is). Coin issuance from GETS does not give that at all

[neo]

@Seneca

No, my method doesn’t try to manage the total issued coin,

It may not be desired, but will be a result of the formulas.

[Seneca]

@neo

Only the total issued coin, so coin issuance rate has little effect.

It does have a lot of effect, because we look at the difference between total issued I and A. So even if I is at 500,000,000 already, ‘A’ will be at a similar number, for example 500,000,020. So ‘I’ only has to increase a little faster to overtake A, causing PUT price to increase.

@neo

The coins issued from farming has a 2 factor control over it.

the farming rate determines the number of successful farming attempts
the coin scarcity determines the number of successful farming attempts that are successful in a coin issuance

In effect there can be less coins being issued from farming, but a lot of farming activity and plenty of “successful farming attempts” but little coin issuance. And no relation to the actual free space percentage

I must apologize here, where I mentioned successful farming attempts I always meant successful coin issuance. I increments by 1 for every coin issued, not for every farming attempt. I hope that clears things up a bit.

[neo]

@Seneca

I must apologize here, where I mentioned successful farming attempts I always meant successful coin issuance. I increments by 1 for every coin issued, not for every farming attempt. I hope that clears things up a bit.

But as I said coin issuance does not show spare space percentage reliability and can be way off.

[Seneca]

@neo

But as I said coin issuance does not show spare space percentage

The rate of coin issuance is directly affected by spare space percentage because of the farming algorithm.

Edit:

@neo

reliability and can be way off.

I don’t see how it can be “way off”. Could you explain that?

[digipl]

@Seneca

Looks like it is! I didn’t base this proposal on that one, at least not consciously (looks like I did read it back then when you posted it, and looking at my comment I didn’t fully get it then hehe). I’m happy to give you all credits though if you want, I’m just glad if together we succeed in making SAFE as stable as possible.

Don’t apologize. We reach similar conclusion by different paths.

@Seneca

Since we start with 30%(?) of SafeCoins already in existence, I should be initialized at 0.3 * 2^32, and A should probably be initialized so that TA == A where S = 0.3.

Always the same doubts but for me the network start with only 15% of safecoin in existence. The 15% of Core developers and Apps developers will be created over time by farming attempt.

[neo]

@Seneca

The rate of coin issuance is directly affected by spare space percentage because of the farming algorithm

I have to disagree there, because you said that it accounted for free space correctly BUT

When there is 10% coin issued. coin issuance rate = FR * 0.9 (over the whole network)

When there is 90% coin issued. coin issuance rate = FR * 0.1 (over the whole network)

So with both cases the free space percentage can be the same but coin issuance says there is a 9 TIMES difference

[Seneca]

Ah, I see what you mean.

My counter to that is that farmers only care about actual coin issuance (their actual income). So if the supply percentage reduces the odds of a successful coin issuance, FR will have to proportionally rise to compensate that supposed loss in income (assuming for simplicity that the SafeCoin value is equal in both cases).

So…

@neo

When there is 10% coin issued. coin issuance rate = FR * 0.9 (over the whole network)

If FR is 0.1 here, and the average farmer earns on average 10 SafeCoins per hour…

@neo

When there is 90% coin issued. coin issuance rate = FR * 0.1 (over the whole network)

Then FR must be 0.9 here to still let that farmer earn 10 SafeCoins per hour.

So I think fluctuations in the coin issuance rate is a far better metric of changes in the supply/demand balance than FR. These fluctuations also contain the actual SafeCoin value changes.

[janitor]

@Seneca

I’ve always considered this challenge doable

If the challenge be solved properly, the price of coin will be merely “realistic” (.e.g. how much it costs to acquire capacity on Day 10, as the first few days will be volatile). Up to that point the exchange rate of MAID (and Safecoin, after that) will not have any relationship to the cost of disk capacity on the network.

Which is why I ask: what does the current dollar price of MAID represent now and how does it relate to the purchasing power of Safecoin after first ten days of the network going live?

[neo]

@Seneca

My counter to that is that farmers only care about actual coin issuance

I counter that with the white paper which shows that as coin is more scarce the price will naturally rise as per anything desirable that becomes scarce to obtain. Farmers are motivated by both issuance rate and price.

BUT it is still an extremely poor judge of spare space percentage and your formulas could cause a rush on uploading at a time when the network is very low on spare space. Such is the problem of not using FR directly (or ratio of TS:TP)

[Seneca]

@janitor

If the challenge be solved properly, the price of coin will be merely “realistic”

I think it’ll be the other way around. These algorithms indirectly adjust to the actual market value of SafeCoin, so the price of PUT and farming rewards will be “realistic” to market value.

@neo

I counter that with the white paper which shows that as coin is more scarce the price will naturally rise as per anything desirable that becomes scarce to obtain.

You can’t assume that because only 10% of successful farm attempts results in actual issuance instead of 90%, that that makes the SafeCoin value 9 times higher in the former than in the latter situation. Farming rate and coin issuance follows the market value, it doesn’t set it. Sure, here’s a feedback loop to some degree, but inflation and such is a modifier of existing value, not the main factor of initial value. Just like BTC value doesn’t come even close to following it’s issuance rate.

@neo

Farmers are motivated by both issuance rate and price.

My point is that the issuance rate already incorporates fiat price (or rather, market value). If the market value suddenly multiplies by a factor of 10, then the issuance rate will likely divide by a factor of 10 as well (because the real operating costs of farming don’t change so we’ll get a shitload of farming competition and an abundance of space), and the PUT cost needs to be adjusted accordingly too.

So by adjusting PUT cost to issuance rate, we adjust it to both supply/demand of storage and thus indirectly also to any changes in SafeCoin market value. That’s perfect, because uploaders care about market value as well.