Early demand, and effect on storage costs, after launch

[dirvine]

@happybeing

What I don’t understand is how the PUT cost is calculated and how this would be affected by shifts in fiat price, since demand for PUTs will vary due to factors other than fiat price (whereas farming provision should be closely tied to it). I guess this is not finalised, but can you explain a little?

https://github.com/maidsafe/rfcs/blob/master/proposed/0012-safecoin-implementation/0012-safecoin-implementation.md#establishing-farming-rate

This explains the process in a bit more detail. Let me know if this answers the questions please Mark and I will add in more info to help out.

[dallyshalla]

Indeed it’s all there, and that’s pretty much how its been since the get-go. The space that a safecoin buys is always determined at the time when you want to store something;

[Seneca]

I appreciate the difficulty that comes with designing these aspects of the network, but I think the NC variable (the total number of client accounts) is a bad one in this formula:

StoreCost = FR * NC / GROUP_SIZE

Compare a scenario where X amount of clients each consume on average Y amount of resources per day, with a scenaro where 5*X amount of clients each consume on average Y/5 amount of resources per day. The resource usage is the same in both scenario’s, but the StoreCost is 5 times higher in the latter than in the former.

---

What about this alternative:

1. Close groups must track the total amount of SafeCoin issued as rewards, and must track the total amount of SafeCoins absorbed from PUTs
2. Based on the amount of issued SafeCoins and the total amount of SafeCoins in circulation, a target figure of total amount of SafeCoins absorbed can be computed
3. On every PUT, if the actual amount of SafeCoins absorbed is lower than the target figure, the PUT cost is increased, else if the actual amount of SafeCoins absorbed is higher than the target figure, PUT price is decreased.

Let’s put it in a formula. Step 1 and 2:

I = total SafeCoins issued
A = total SafeCoins absorbed
TA = target total SafeCoins absorbed
S = supply of SafeCoin (0.0-1.0)

TA = I * S

S makes sure that the rate of increase in SafeCoin supply (i.e. inflation) tapers off as we approach the cap. At the cap, S == 1.0, so then the target total SafeCoins absorbed is exactly equal to total SafeCoins issued. Since there may be times when the farming rate algorithm suddenly has to increase rewards, we probably want to keep a buffer of reserve SafeCoins for such times. If we want to keep 10% of SafeCoins in reserve, the formula becomes:

TA = I * (S + 0.1)

Step 3:

MB/SC = Megabytes bought per SafeCoin

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

A great benefit of this approach is that we actually have control over inflation now. Unlike in BTC where the inflation rate is a function of time (block count), with this algorithm the inflation rate is a function of usage of network resources. More usage (growth of the network) increases the inflation rate, less usage decreases the inflation rate.

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.

[happybeing]

I’m trying to understand the Safecoin RFC linked above. Can anyone give definitions for:

• primary chunk
• sacrificial chunk
• GROUP_SIZE

Thanks.

[dirvine]

@happybeing

primary chunk

Chunks are now stored as 3 groups of 2 chunks. So 1st group is primary, 2nd group is backup (in case of failure) and third group is sacrificial. The sacrificial basically has farmers holding data we don’t need. The amount of this held in relation to the number of primary chunks tell us the network storage health (balance). So basically we have 50% more data copies than needed. We can lose all of that but then it’s dangerous, so the resource balance kicks in when we see this is vanishing.

Nodes will delete sacrificial data to make room for the other types. This deletion starts to increase farming rates and as we lose more we increase the rate more (farming rate == amount of reward)

Group size is the size of the group in which data can be stored, so with a group size of 32, data can be stored on the closest node to the data and, as the group changes, it stays there (the node may no longer be closest; in probability, it will not be). If that nodes leaves or goes out of the group then the members of the group (NaeManagers) will relocate the copy to (again) the closest node. This is continuous.

I hope that helps.

[happybeing]

@dirvine

Group size is the size of the group in which data can be stored, so with 32 data can be stored on closest node to the data and as the group changes stay there (may no longer be closest, in probability will not be). If that nodes leaves or goes out of the group then the members of the group (NaManagers) will relocate the copy to again the closest node. This is continuous.

Thanks David, I’m getting there slowly . I’m not sure what GROUP_SIZE is yet though. Is it the total number of vaults?

[dirvine]

@happybeing

I’m not sure what GROUP_SIZE

It is only the sizeof the group around any address. So 32 in our case, the closest 32 nodes to an address.

[happybeing]

OK thanks, last question for tonight

I don’t understand this from the RFC:

StoreCost = FR * NC / GROUP_SIZE

Therefore a safecoin will purchase an amount of storage equivalent to the amount of data stored (and active) and the current number of vaults and users on the network.

I see that farming rate FR varies from 0 (sacrificial = primary) to 1 (sacrificial = zero)

The number of active clients that have PUT data, NC is a rapidly growing unlimited number.

If GROUP_SIZE is a constant I don’t understand its purpose, and I don’t see how the formula incorporates the total number of vaults, as indicated by the text.

[Seneca]

Consider NC / GROUP_SIZE as a client/close group ratio. It doesn’t incorporate the total number of vaults, everything is “local” to close groups. So a close group simply counts it’s own clients to get it’s NC value.

[smacz]

@dirvine

The sacrificial basically has farmers holding data we don’t need. The amount of this held in relation to the number of primary chunks tell us the network storage health (balance). So basically we have 50% more data copies than needed. We can lose all of that but then it’s dangerous, so the resource balance kicks in when we see this is vanishing.

50% buffer? Nice.

if sacrificial_chunks < (.5 * primary_chunks):
    increase(farmers_rewards)
else:
    decrease(farmers_rewards)

Now I begin to see how Proof-of-Resource works. There is data there, but it’s sacrificial. So the resource must always be there, otherwise the data would be gone.

EDIT: Upon further reflection, that should be 33% buffer, and the first line should be:

if sacrificial_chunks < primary_chunks

[neo]

@happybeing

The number of active clients that have PUT data, NC is a rapidly growing unlimited number.

I would think you will find that is the total Number of clients that the group (32 nodes) has connected to it.

The client’s Group cannot know the stats on the whole network so the calculations has to be an estimate for the whole network.

So NC/GROUP_SIZE (NC/32) is the estimation for the whole network Total_network_clients_active/Total_network_nodes

FR in the equation takes into account the free space available

Personally I think that the equation will result in too low a PUT cost when spare space is plentiful, and escalate the PUT cost too fast/high when the knee point in the equation is hit. Maybe cost needs to rise quicker towards the knee point and the rise after the knee point be a tad slower. ie a flatter rise as this equation has the potential to see large changes in cost for little change in spare space near the knee point and after. But testing will hopefully show what will really happen in a larger system

[dirvine]

@Seneca

What about this alternative:

Close groups must track the total amount of SafeCoin issued as rewards, and must track the total amount of SafeCoins absorbed from PUTs
Based on the amount of issued SafeCoins and the total amount of SafeCoins in circulation, a target figure of total amount of SafeCoins absorbed can be computed
On every PUT, if the actual amount of SafeCoins absorbed is lower than the target figure, the PUT cost is increased, else if the actual amount of SafeCoins absorbed is higher than the target figure, PUT price is decreased.

Let’s put it in a formula. Step 1 and 2:

I = total SafeCoins issued
A = total SafeCoins absorbed
TA = target total SafeCoins absorbed
S = supply of SafeCoin (0.0-1.0)

TA = I * S

S makes sure that the rate of increase in SafeCoin supply (i.e. inflation) tapers off as we approach the cap. At the cap, S == 1.0, so then the target total SafeCoins absorbed is exactly equal to total SafeCoins issued. Since there may be times when the farming rate algorithm suddenly has to increase rewards, we probably want to keep a buffer of reserve SafeCoins for such times. If we want to keep 10% of SafeCoins in reserve, the formula becomes:

TA = I * (S - 0.1)

Step 3:

MB/SC = Megabytes bought per SafeCoin

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

A great benefit of this approach is that we actually have control over inflation now. Unlike in BTC where the inflation rate is a function of time (block count), with this algorithm the inflation rate is a function of usage of network resources. More usage (growth of the network) increases the inflation rate, less usage decreases the inflation rate.

This seems like a very good approach, if you can raise an issue against the RFC then it can get the devs debating it as well from an implementation perspective. Looks good though

[digipl]

This is not similar to my proposition of using the notion of velocity of money?

Safecoin VS SAFE Storage

I am thinking the possibility of using the notion of velocity of money to achieve the desired economic stability of the network. In the general theory the velocity of money is set as: [image] when [image] is the velocity of money for all transactions in a given time frame; [image] is the aggregate real value of transactions in a given time frame; [image] is the price level; and [image] is the total nominal amount of money in circulation on average in the economy (see “Money supply” for d…

Your S==1 is the same of is constant.

And my = your MB/SC

And

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

is

If T (quantity of PUTs) increase P should decrease for that we increase M (total safecoin).

If T (quantity of PUTs) decrease P must increase, so we diminish M (total safecoin).

The M is controlled via the rate reward.

[Seneca]

@digipl

This is not similar to my proposition of using the notion of velocity of money?

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.

[anon40790172]

@Seneca

Consider NC / GROUP_SIZE as a client/close group ratio. It doesn’t incorporate the total number of vaults, everything is “local” to close groups. So a close group simply counts it’s own clients to get it’s NC value.

People are free to surf SAFE (like using a plugin for Firefox) so than they’re client’s. So they’re in a group of max. 32 nodes and the nodes know they’re clients. But in the same group (address range) there can be Vaults than? Or are vaults in group with vaults and client’s in groups with clients? A bit confusing to me.

[anon40790172]

How would we know the total amount of Safecoin in circulation? Groups need to scan the address-range than, and share the numbers with each other?

[Seneca]

@anon40790172

How would we know the total amount of Safecoin in circulation?

Close groups handle farming attempts, so you can simply track the success rate of the last 100 attempts for example.

[neo]

@anon40790172

So they’re in a group of max. 32 nodes and the nodes know they’re clients

The current RFC uses NC as “active” clients that are storing data

[MrAnderson]

I love to see this kind of collaboration where everyone wins and all creative are easily included.

SafeCoin is the reason SAFE will survive and grow. Not only because of the value of currency feature and ability fund its own progression, but IMHO it will also give valuble real-time quantifiable feedback on the health of the entire network.

[anon40790172]

@Seneca

Close groups handle farming attempts, so you can simply track the success rate of the last 100 attempts for example.

That’s a great idea. If 10% of the coins is already around we would see 10% less successful farm attempts and know quite sure how many coins are out there. Although 1000 would even be better 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.