Proposal to scrap expanding to 4.3bn Safecoins and just 10x everyone's holdings instead (i.e. moving the decimal point)

The vaults/nodes have a lot of work to do behind the scenes, routing messages, ensuring communications, encryption, maintaining data integrity and sufficient redundancy, archiving cold data, bringing new storage resources online, protecting against spam, and other attacks by adversaries. All of this takes time. Time is money… err safecoin. :wink:

I think you need to think of it in terms of cash flow. How would your own finances work if you had to spend everything you earned immediately and had no monthly or yearly buffer and no access to loans or a credit card. Typically we all have a buffer of some sort, whether that be savings or debt. Some individuals are born with a large trust fund, others are born into debt. The network will be born with an analogous sort of safecoin “trust fund” given to it by design and implementation from it’s creators/supporters (dirvine, MaidSafe, the devs, the investors, the community) for the benefit of Everyone.

(Cash_in - Cash_out = Net_income + initial_funds). Theoretically, the network’s initial funds will eventually go close to zero and it will operate more “hand to mouth” to borrow neo’s term. But you need those initial funds to financially (in terms of safecoin) “bootstrap” the network.

1 Like

Indeed. This is what farming rewards are for, which can function very well without being out of balance with the income the network is generating.

The network’s demand for farmers’ resources is equal to users demand for network resources.

In terms of cash flow, I don’t understand why cash in to the network would need to be different to cash out from the network for any significant period of time, given the the role the network is playing is to balance supply & demand of resources.

I’m not an autonomous network with a specific role of balancing supply and demand for my resources.

To flip this question around, for what reason would the network need for a buffer / credit card / trust fund?

The SAFE network certainly needs a buffer, but I think this can be the spare space on the network - not a stash of SAFE coin.

Any spike in demand for network resources (drop in spare resources) should trigger a proportionate;

  1. increase in cost per PUT to ration available space on the network
  2. increase in farming rewards to encourage new resource provision

…and vice versa.

If instead, the network increases payments to farmers & pays from its trust fund & leaves the cost per PUT unchanged, then it is subsidising the network, which is now out of balance and in negative cash flow.

To some degree this will lead to;

  1. Farmers making investments that they wouldn’t based on an unsubsidised price, which would have increased to a smaller degree
  2. Users uploading more data than they would based on an unsubsidised market price that had been allowed to increase

A return to equilibrium would result in farmers getting paid less, as demand from users at the equilibrium price would be lower than it would have been at the subsidised price.

Why is it desirable to have the network being used in a way that doesn’t reflect the true supply and demand of those contributing and using resources?

I know that I’m not seeing this in the same way as others here & we’re crossing wires a bit, but I am being honest and enjoying exploring the concept, so please be patient, and hopefully we’ll all learn something :smiley:

I see your counter-points, and will refer back to one thing. Volatility. You will have things the way you want/describe when the network approaches a steady state with not much left in the trust fund when it is mature and large enough to balance volatility due to it’s physical size. The transient response from genesis to steady state is where a lot of uncertainty lies. So giving the initial buffer allows the network to minimize volatility. I see low or no volatility as a very positive feature. You also get no fiat value dilution for initial investors by having a smooth transition to steady state. Like @neo said, “control theory”. One generally prefers a critically damped system.

Volatility in this case is a double edged sword.

If the network seeks to balance demand & supply through adjusting PUT price & farming rewards, it can only reduce the volatility of one of these at the expense of an increase in the volatility of the other.

I guess you could say farmers won’t care about volatility & users will, so hold PUT price relatively constant & let farming rewards increase / decrease to a greater degree?

However, I don’t think volatility would likely be a significant issue once the daily volume of uploads to the network is a small fraction of total data on the network. The speed of fluctuation of the spare capacity level of the network will change at an ever slower rate as the network grows, giving more & more time for farmers & users to respond to small price signals before they become significant.

Yes. True. And how do you do that without a buffer? You can’t. Maybe you can argue the size of the buffer, but then the network will optimize this for us. So now we’re arguing the size of the buffer at launch, which I would say needs to be as large as possible and cannot be less than 51%. Investors wouldn’t have understood an initial pre-sale of less then 10% so I think MaidSafe made the best choice.

Yes “for any significant period of time” this is true after steady state things will be in balance. In the beginning the network doesn’t have a significant period of time to work with and needs plenty of resources to deal with uncertain situations or crafty adversaries. Not really sure how else to explain it, feels like we’re going in circles or circles now.

Yes, this is exactly what neo and I have been saying. Until that point in time, we want the network to have as many safecoin resources available to it as possible so that it can easily grow and flex some muscle if needed.

You don’t do that without a buffer - my comment is exploring the affect a Safecoin buffer could have on volatility in the context of a Safecoin buffer existing - it’s not a suggestion that it is a desired feature.

I feel the market would work best with clear and efficient market signals to all actors, not dampened signals that lead only one party to make a response toward a desired goal where two parties could have.

After 6 weeks the daily volume of uploads is likely to be a small fraction of the total data on the network. I can’t imagine the intended purpose for the 90% of the safecoin that the network holds is to try to decrease the volatility of resource prices during the first weeks of the network’s existence.

Perhaps for the first few weeks the spare space requirement of the network can be higher, and this can reduce in time as the fluctuations between the target spare capacity, and actual spare capacity decrease.

What reason could the network have for needing to ‘flex some muscle’ to grow ahead of demand?

I agree though, we’re not making much progress here, so I’ll leave it for now and come back if I have an epiphany :smiley:

And this is very much in error.

I can upload stuff and the demand could be a minute later or a month or even a year later.

There is only a indirect correlation between the two.

No it cannot if uploads slow down for some reason. Say a fearful global event that has everyone researching the (SAFE) network but reluctant to upload. As I show in the previous post this then becomes self defeating for SAFE. The network spirals downwards unable to pay farmers and the higher upload costs makes reward payments scarce.

Simple the network is in control, not the uploaders or the farmers. The network makes the decisions on what to charge and what to pay for people to supply it data and for retrieving the data.

The uploaders don’t pay the farmers.

Until the network is large it is essential for the network to be able to regulate the prices contrary to to one or the other (upload vs farming)

Essentially the functionality of farming is not related to uploading. Only the data for storing is related and loosely related. In other words the data being retrieved is not necessarily the data just uploaded. Some uploads cause massive downloads in a short time and some uploads rarely get downloaded (if ever more than once).

Again there is no subsidy in the current model. Nowhere is there that. The network works out the value of its safecoin. The uploader is charged at the current price the network determines and the farmers are paid at the price determined by the network. The network does not apply any subsidy. No where and never does it. The price is determined by market conditions. If there is glut of resources the farmers are paid less, if there is a shortage the farmers are paid more. NO subsidy in sight anywhere.

While you work with the concept of subsidy then you can never see how the network is actually going to work its “economics”

For instance while the network is a 100 thousand node strong, the uploading might be “X” per month one month and “X/100” for the next two months. Or we might have that for 12 months. Who knows. Living hand to mouth then the network under your scheme would have run out of coins say after 4 weeks then farmers are not paid for one or more months. I do not see safe surviving since the diehards might only number 10000 nodes of that 100000 nodes.

That is just one simple example to show that your model cannot survive some situations.

Your model can only survive the model where uploading costs are greater than farming. As soon as uploading drops that forever increasing curve then it is at grave risk of failing

To expand that if after a year or two you have had increasing rates of uploads then the network is fine. But as soon as the rate drops below a sweet point of increasing then the “GETs” of all that bulk you have stored previously will overwhelm the upload receipts and the network runs out of coin very quickly. Also you must remember that since the coin was fully issued there is no reason for its price to increase beyond a fairly static price. So farmers getting less coin does not cause the price to rise since it represents only a tiny portion of available coin. And when farmers collectively are getting zero coin then what?

The network has to be able to regulate its charges and payments. And it cannot effectively do that without the stabilising mass of coins available to issue.

I’ll reply to try to explain what I’m saying, but I think it might be helpful to set out some assumptions I have to try to figure out where we’re not understanding each other. It may also be good to clarify the assumptions to help us and others explore the economics of the network. I’ll try to set out some of my assumptions, and ask for feedback in another post following this reply.

To clarify, I’m talking about the network’s pricing mechanism, which cannot take into account future demand & supply only present.

The fact I’m pointing out there was that the network’s resource requirements, and demand from users is one and the same thing: current demand for Safe network resources by users = current requirement for supply of resources from the Safe network.

The network will only ever need to increase its resource supply if those resources are demanded by users of the network.

Given this, there should never be a time where the network doesn’t see an increase in its ‘income’ at the same time as it’s required to up its ‘expenditure’, and vice versa.

This, if true, makes balancing the internal market tightly possible without any large pool of Safecoin held by the network.

In a functioning market;

  1. a slowing in the pace of uploads without a corresponding reduction in resource supply leads to;
  2. a reduction in the cost of uploading data to the network, which leads to;
  3. people uploading more

This price mechanism prevents there ever being a massive dip in uploads, because the price drops to incentivise uploads if they’re too low.

A significant dip in the cost of uploading would likely trigger immediate action from any software optimised to upload queued backups etc during dips to minimise its costs (e.g. backup software that uploads within a certain band of upload cost - a spike in price reduces low priority uploads, and a dip in price triggers low priority uploads to continue etc).

This was the example you gave previously, which I find hard to understand given the nature of the network and market dynamics:

  1. I can’t imagine any time or event that causes people to stop emailing, posting blogs, sending photos, using forums, updating news sites, video calling, releasing music, backing up data, on a large scale.
  2. The network would not see farmers pay disappearing - it would see a reduction in the amount they’re paid until the resources they are contributing are equal to the demand for those resources from users
  3. Some farmers that don’t consider their compensation sufficient may leave until supply = demand. This is fine - it’s a functional market.

The base assumption of there being a catastrophic drop in demand for uploading to the Safe network would signal the death of the network however it’s played: if nobody wants to use the network’s resources enough to pay for them with Safecoin, nobody will be willing to offer the network resources in exchange for Safecoin that have no demand.

I agree that this should be the case, but don’t understand how your examples could happen if there is a functional market balancing supply and demand, e.g:

How could a functioning market for Safe network resources see X demand one month and X/100 the next?

Has Google / Amazon / OneDrive / DropBox etc ever faced such an incredible fluctuation in demand for their services that they’ve even had to drop their prices by even 30% from one month to the next?

This isn’t the case due the the network’s ability to drop the price for uploads. As soon as there’s a drop in demand for uploads, the price starts to drop until the demand is suitable for the resources available on the network.

The network does make the decisions on what to charge and what to pay the farmers, and I have thought that it does this based on the demand and supply of resources available.

While the network pays farmers based on demand for downloads, and charges users per upload, the farmers don’t really care what triggers the payments - they only care that they’re getting paid enough to make their contribution worthwhile.

My current thinking (right or wrong) is that the network will adjust the farming rate depending on the amount of storage space available, so while the timing of a farming reward payment is triggered by a download event, the amount of the payment will determined by the level of payment needed to incentivise farmers to provide sufficient resource.

I’m at, or beyond, my knowledge of the network here, so I’ll ask for clarity in my next post to help develop my understanding.

How??? They definitely NOT the same thing, because users have dual demands and the network only needs to regulate its spare storage. But the user demands are opposing forces when it comes to coins created and destroyed.

Network requirements is if there is more/less storage space needed/desired

2 Demand from users is

  • I want to download files and see forums etc
  • I want to upload my pictures, files, comment, etc

Wrong.

Users downloading their cat videos is a drain on the coin supply and living hand to mouth on a network anything less than a very mature network requires people uploading at a faster rate each period. As the network ages this is not so pronounced, but under your model the first major downturn of a ever increasing rate of uploads and the network is at grave risk of dying due to farmers leaving on mass due to not being paid.

Lets say you have uploaders uploading 100TB per month and downloaders telling their firends of all the cool material on SAFE are watching all the cat videos as they are uploaded and also catching up on old favourites that were uploaded previously. Typical youtube audience spending hours watching all the new stuff and the ones they really like

In this scenario new farmers come online at a rate that keeps spare storage sufficient to make uploaders combined pay 1000 coins per 100TB and Farmers paid at constant rate of say 1000 coins per 1000TB (ie farming rate remains constant)

Month 1

  • network gets 1000 coins
  • Uploaders pay at rate of 1 coin per 100GB “PUT”
  • 1000TB “GOT” so network gives out 1000 coins
  • Farmers paid at the rate of 1 coin per 1TB “GOT”

Month 2

  • network gets 1000 coins
  • Uploaders pay at rate of 1 coin per 100GB “PUT”
  • 1000TB of new data “GOT”
  • 500TB of previous one month “GOT”
  • Total 1500TB “GOT”
  • Farmers paid 1000 coins when first 1000TB “GOT”
  • Farmers paid nothing for last 500TB “GOT”

Month 3

  • network gets 1000 coins
  • Uploaders pay at rate of 1 coin per 100GB “PUT”
  • 1000TB of new data “GOT”
  • 500TB of previous one month “GOT”
  • 400TB of first month “GOT”
  • Total 1800TB “GOT”
  • Farmers paid 1000 coins when first 1000TB “GOT”
  • Farmers paid nothing for last 800TB “GOT”

You need increased rate of uploads each month so farmers can be paid fully

If any month the uploads decrease then the farmers are paid for even less

You need to be forever increasing upload rates otherwise the payments to farmers dies very quickly and the network suffers.

I would imagine month 2 would look like:

network gets 1000 coins
Uploaders pay at rate of 1 coin per 100GB “PUT”
1000TB of new data “GOT”
500TB of previous one month “GOT”
Total 1500TB “GOT”
Farmers paid 1000 coins for 1500TB “GOT”

Wouldn’t that work?

It might result in farmers deciding to contribute new resources at a slower rate, and increase the PUT price if available resource levels drop, but that’s part of finding a market price as it should.

The cost of uploading should reflect the cost of contributing the resources required for that uploaded data to be stored and transmitted as required.

Only if new farmers didn’t come online fast enough to keep the farming rate very close to what it was on month 1

To do what you suggest would require the network to do artificial price fixing (subsidy) and not in accordance with spare storage.

But to do as you suggest then month 3 the upload price has to be be like 1 coin per 15 GB then month 4 like one coin per 3 GB then month 5 is like one coin per 500MB. The stablising point would not be reached till a few hundred months and likely to be 1 coin per 20 MB while farmers are still only paid 1 coin per TB

I only need to show one very plausible scenario that causes your model to fail to show that its not a good idea.


In order to have the network “honest” in its pricing then it needs to not artificially set prices And be according to needs not because you are living hand to mouth.

Part of the reason for the buffer is to allow long term balancing of the two opposing forces (recycling and creating of coin). Its only when the rate of new data viewing vs rate of old data viewing stablises (maybe 5-15 years) will the income really be able to match the payments in a one for one (hand to mouth) way.

One human trait is rewarded at a fair rate will attract farmers and being charged a fair rate for uploads will attract uploaders. Thus having the 90% (even 80% or 70%) reserve at the start allows the network to do this by charging actual costs.

But as you showed with your response you cannot have fair prices (set by spare resource) until the network has matured beyond the point of that data viewing balance.

That only works if downloaders (viewers) only downloaded the the data stored at the time of uploading and not later. As soon as downloaders/viewers can download previous data then your model fails or has to constantly increase the cost of uploading till that balanced mature point.

tl;dr

Your model only works for the uploaded data to be consumed in a set time period then discarded.

Can we detail this more? It seems we need it to be 100% certain this is how it turns out - can we be that?

I doubt it. There is a number of reasons EG

  • Dedup. In the past people would upload into their dropbox or elsewhere their copy of some file they found on the web and want to keep it. Often files disappear on the web at the moment and people copy the data to keep it for later. So this means that some old data is new again. We do not how much this will be. Will it be 0.1% or 5% or ??
  • Some studies show that new data is accessed mostly in the first 3 months then reducing after that. But how much of that is because that data disappeared (website cleanup, DCMA takedown, dropbox subscription not continued, etc) and how much is that people like to view things new and not view old things,
  • A lot of data (proportion ??%) on SAFE will be web pages, and database. How the pattern of use pans out is anyones guess.
  • There will be great use of backup data uploaded and accessed once for verification. How much backup data will be for web sites and users request restoring of data they deleted by “accident”
  • and so on.

So I doubt that we can know unless someone comes up with a way to monitor usage. But with privacy, anonymity and security in SAFE I doubt this is even feasible. Even for public data this cannot be done since downloads cannot be monitored externally.

But from the studies we do know that typically (not all) old files that people upload or consume from public sites are accessed/viewed/download less and less as time goes on. So for a large portion of public files (movies, pictures, documents, etc) this data will be accessed less and less as time goes on.

This of course does not relate very well to how valuable the data is to be kept. For instance some of the most valuable data will only be accessed way into the future. (eg last will & testament, list of insured items etc)

Not how to work out this balance except by monitoring the rate of coin creation from “GETS” and compare that with the storage used over time. This can of course only be done on a per-section basis and taken as a rough average for the network.

Or did you want details on what I mean by this balancing.

The balancing is basically taking (on average) new data stored and watching the accesses over time. At some point the network will see (if it could monitor it that is) for an average piece of data stored the access rate decline over time. I suspect that on average it will have a point which it approaches.

For some data the “GETS” will slow down gradually over time.
For some movies the “GETS” will die of rapidly
For some classical movies (eg back to the future) will see “GETS” die off then rise then die off then rise and so on. But most likely still reducing over the decades.

So some data might see 10x the initial week’s “GETS” and some data might see 2x the initial week’s GET.

This is where tuning of the “PUT” cost will need to be done. So while it is still based on spare resources the multiplying factor will need to be tweaked I’d say. But there will be a sweet spot around which we will get the optimal pricing.

2 Likes

Just a few more things other than what neo pointed out… Also, I don’t have time to soften the tone or add a lot of emoji’s so this is all said in good fun. If something comes across harsh, don’t read into it. I think this is turning into a useful topic for people. :sweat_smile:


Yes, your data and everyone else’s. The past needs to be considered too. All network data must be stored safe and secure forever, not just yours. While one can’t predict the future, we can calculate what it will take to presently maintain the past and present. At least for myself, I see that when it comes time that I pay for a PUT, there is an implicit understanding that part of the PUT cost goes towards securing my data immediately, while another part of it helps maintain and secure ALL the data that came before it. And to pre-empt a possible criticism : NO, this is NOT a ponzi scheme, nor is it even analogous to a pension fund, so those analogies/metaphors don’t even remotely apply. It’s simply this, “In order for you to add data to the network, at this time based on current network conditions, this is how much the single one-time fee for data immortalization will cost you, right now.”

Yes, and it will only happen this way in your imagination, or neo’s, or mine. There is no way for us to predict the rate at which things happen. The end result might eventually be predictable under long term average steady state conditions, as in a large percentage of, or all the world’s annual data production will be stored to SAFE in some form, but the rate at which this happens is unknowable at this time. It becomes an argumentum ad ignorantiam.

If I was rich enough (I am not) I figure I alone could easily put 1TB per day to the network on launch day… When the computation module arrives I could put easily 100TB after one HPC simulation. I think the SAFE network will grow in size faster than any one of us can predict, or not. The supply of data is infinite, so the network needs to continuously grow as long as people can afford it. In times when they can’t afford it, the network buffer will be there to help people out and handle excessive GETs.

There are a variety of ways to tweak the basic internal economic systems within SAFE. Or one might be able to propose a new alternative altogether. As long as they support and promote the flourishing of The Network equal to or better than the current plan I think people will be all for them if they can also maintain the spirit of the ICO. However, siphoning away the network’s emergency fuel supply on day 1 will NOT do that. Safecoin is not an Alt-coin.

1 Like