What if people lie about the space available?? If there’s a settings for my Vault and I can specify the numbers of MB’s I have available, why no say I offer 2TB when in reality I only have 1TB available? If enough people do this, maybe the price of Safecoin could be tricked??
Proof of Resource is about sacrificial chunks you have stored, the network can and does ask proof of that (on GETs). Actual empty space doesn’t count for the network, so lie all you want! 
4 Likes
Ah, this is what I hoped indeed.
1 Like
1st I never attempted to imply that it would be anywhere close to 9 times, just that it will be higher and that offsets some effect of the scarcity. As per the whitepaper
2nd Farming Rate follows the spare space percentage and is not affected by any market value. Increase in farmers is not guaranteed and certainly not at the same rate of coin issuance rate changes
3rd The market WILL react to scarcity. Remember that safecoin has real utility and scarce to get and a need to use will be a driving force on $$$ value.
Issuance is not affect by market value, and more so if you were correct that market sets the value. Issuance is affected by both scarcity of coin and scarcity of spare space. But scarcity of coin issuance is not a measure of farming rate (FR) (spare space percentage.)
No because spare space percentage cannot be measured by coin issuance rate, unless you factor in scarcity then why not just use FR (farming rate).
The rise in farming value per hour is not proportional to the coin issuance rate. You said it yourself 9 times issuance rate does not equate to a 9 times less value of coin. Put cost must react faster to farming rate (FR) than relying on market forces to adjust price to attract more farmers. Especially when there is an outage. The Put cost must have a direct factor in it that affects put cost when spare space drops. In other words you have to raise put costs to reduce the influx of uploads. coin issuance is not close to being accurate and thus not a direct indicator of space problems.
EDIT to be clear I am not disagreeing with changing the formula along the lines/principles you outlined. Just concerned that ONE factor has to be the FR (spare space percentage), and have other factors to adjust according to issuance/absorption rate
The current price is just like Bitcoin and Ethereum. Speculation. There’s no one here who can predict how the network will look in the coming months. We go live without any farming, so if it takes 10 weeks for the next sprints to get Safecoin implemented, the network is already live. If there’s a virtual S:// drive available, and Safecoin becomes active, there will be more PUT’s than when we’re still on the level where you can only upload your safe:website. So no one has a clue.
And even if there’s a number attached to Safecoin which says: you can store 100MB. per Safecoin when farming becomes active, this will soon balance out in these next days. So again, no one has a clue IMO.
It seems his statements related to this kind of contradict his claims that he’d always understood how the Safecoin farming and issuance (should) work…
If the farming rate changes from hour to hour, shouldn’t it also be impossible to guess how much in Safecoin one needs to put online a 1GB video?
Edit: Removed all further debate, since a solution is probably more fruitful:
Okay, I guess it’s possible to do that without breaking any of the current principles, in which case I’m neutral towards that. I guess we could multiply MB_per_SC by FR to arrive at a new, actual MB_per_SC. We just need to rename “old” MB_per_SC to something new then. Something like base_cost? Anyway, perhaps like this:
base_cost = I don't know a meaningful description :D
MB_per_SC = Megabytes bought per SafeCoin
FR = farming rate (0.0 - 1.0)
if (I > A) { //fewer SafeCoins have been absorbed than we want
base_cost--; //So increase the PUT price to start absorbing more of them
} else if (I < A) { //More SafeCoins have been absorbed than we want
base_cost++; //So decrease the PUT price to start absorbing less of them
}
MB_per_SC = base_cost * FR
Thoughts?
Edit: I made a silly mistake here, it should’ve been division by FR not multiplication.
I never said that! I said I always knew the algorithms weren’t finished, and that I always believed we will find a solution together before launch of real SafeCoin. You’re resorting to personal attacks now?
Proof:
Besides, I didn’t even contradict myself:
I didn’t use the word “equate”. I said that reducing issuance by 9 times doesn’t lead to 9 times more value for a coin. What I did say is that a 9 times more valuable coin likely leads to 9 times less issuance. The causal relationship is inversed here!
Looks to me @janitor didn’t even check if I actually contradicted myself, just used the comment as an excuse to attempt to baselessly defame me.
1 Like
Haha I had written a reply to your previous post.
I’d say you need a “competing” factor in which the spare space percentage can override while spare space is low, but when plentiful it has minor effect.
I realised from my deleted reply that your equations from previous were affected by download patterns. Rate of downloads will directly affect the coin issuance to farmers, but you assumed they were related to space issues. In effect a large sporting event over a period of a month or more could cause your previous equations to react incorrectly for the amount of spare space.
Also what is the modeling when coin is scarce. How will that drive the put cost?
No, I’m just enjoying the process of untangling this problem.
And you confused (forgot?) that farmers get paid for GETs, not PUTs, but Neo just pointed that out.
I would need to see some reasoning. That does not seems logical or reasonable. The results will be an unknown amount very much controlled by a few factors. But it is not linear in any case.
During heavy download usage (think large event happening worldwide - Olympics) coin issuance may dramatically rise even though economic factors are causing the price to drop. Say people selling off their coin because he next big shiny crypto appears
It is certainly not a short term fact nor a long term.
I hope your equations assumptions do not rely on specific market movements of price leading to rates of issuance. Its a two way street. Greater issuance will tend to push downwards on price, increased cost of puts will lead to both a down & up wards push at different times. greater price will push more people to farm, but issuance increases when downloads increase, and downloads are not concerned by markets
Ah, so just trolling then, okay. 
I didn’t confuse nor forgot:
If downloads increase, the strain on the network becomes larger, so the maintainance cost of data also increases. It’s only appropriate that upload costs then rise, which my proposed algorithm does: More downloads → accelerating I → decreasing MB_per_SC. In addition, the extra bandwidth costs from many downloads may lead to some farmers leaving who start making losses because of that, leading to space shortage, leading also to accelerating I.
Yeah sure, the rise may be temporary. Then the effect will reverse afterwards. We’ll never get a “perfect” price for any point in time, if such a thing even exists. The goal is that on the long term the network is stable.
What do you mean with scarce? High market value? It leads to an increase in farming (just like mining capacity expands when BTC rises significantly), which leads to overcapacity, which leads to decelerating I, which increases MB_per_SC. Which is appropriate too.
Increased downloads lead to higher PUT cost, which is appropriate (see above). People dumping their coin on the market causing price drops should lead to farmers leaving, because the value of their rewards is falling. This causes scarcity, thus accelerating I as well, thus increasing PUT costs.
I don’t see any contradiction here, both events should lead to higher PUT cost (in terms of SafeCoin). Even if there were a contradiction, say a huge spike in SafeCoin value during that “large event” which would lead to a decelerating I, the net change in I is what the PUT cost reacts to. So the events (partially) cancel each other, the one having the stronger effect “winning” proportionally in it’s effect on PUT cost.
The effect of inflation/deflation of money supply is a second order effect, acting on the existing market value, with delay. I don’t see any danger to “over-compensate” with inflation in this algorithm, where it’d become the lead cause for market movements (spirals). On the contrary, this algorithm is the first that actively constrains inflation by describing the dynamic between the network’s SafeCoin input and output.
As for downloads not being concerned by markets, any malign effects of that on SAFE are unrelated to this algorithm, since it’s caused by the established choice of the ‘Pay on PUT’ and ‘Free GETs’ model.
The scarcity you mention is a scarcity of space, not of Safecoins. Why should that increase the float I?
According to the original pre-IPO white paper from 18 months ago they expected as much as 2 billion coins to be issued in the first five years and I would take that to mean 500 million in the first year. Add that to say 100 million from the IPO and together that becomes 600 million coins. The network capacity would have to keep up with that growing number of coins. If it couldn’t, the price of the coin would have to drop.
I don’t agree with the premise that farmers (the 500 million coins) would just hang onto their coins. They’d sell most of them right away (and that’s what most people expect, otherwise new users couldn’t acquire Safecoins to use the network).
Another possibility is that estimate is completely wrong, which means any other could is just as likely to be incorrect as well.
I am still struggling to find a way to pinpoint the main problem with the coin design, but it won’t take me forever.
Even if we assume everything is going to work great, it simply doesn’t make sense that the moment new coins can’t be printed (i.e. I=4.3 billion), the system can’t work. It reminds me too much of central banks. Something’s wrong.
Edit: I just thought to add this - if the scavenging of unused disk space will dominate supply of new space, then “Best mining hardware” might be “anything but a dedicated farming rig”.
Are you refering to this?:
Yes, in Summary:
The total cap of safecoin is set to be 4.3 billion. With the proposed mining procedure (and assumptions) it is estimated that half the total volume will issued during the first 5 years, with 95% issued after 10 years.
Your first example says it’s “A projection of coin distribution can be illustrated as”. So I didn’t see that as good proof of your statement. Your last quote also has the word assumptions in it, so I’m also not to sure if you can use that one as proof.
The network doesn’t know time and as far as I know it was never said that it would know about time, so Maidsafe’s issuance scheme has always been a guess.
I’m not using it a proof, I always say I base my assumptions on official docs.
They may be wrong by now, but there’s nothing else.
If no assumptions are ever made, then no discussion will happen until after release. I said it above - I now fully expect that the algo will be tweaked even after v1.0.release.
I am sorry for labouring this point and I realise you are willing to consider it. I feel that it is so important that it gets fleshed out because free space percentage control is critical to the health of the network and any network economics (NOT Market) must ensure that users uploading are influenced to slow down immediately when free space %age is low or critical. Also not as important there is lower barrier to uploading when free space is plentiful.
During times when free space is not critical then controlling put cost by the greater economics is a great idea. As long as the control system developed is not so dampened to create a driving force to a particular % of coin issued. Perhaps the Sigmoid curve might be a good model to use for the desired coin issuance factor and have the upper bound at the level that allows a buffer (maybe 90%) and lower at the pre-issued (~15%) So when total coin issued is low the equation results in a higher downward force and when coin issuance is high the equation resists downward force. Hard to explain but basically under the same conditions if coin issued is 20% Put cost is much lower than if coin issued is 85% And follow the curve to factor for this.
Effectively any equations on PUT cost can be modeled into Control Theory and having studied that, it can be seen that certain patterns of dampening/control will result in certain types of outcomes. You just need to ensure that the only resulting effect on total coin issued is that (1) it resists allowing issued coin to rise above a certain amount to allow a buffer and (2) allows/encourages the coin issued to rise at a reasonable rate till and reducing when approaching max desired
The scarcity was in the available coin scarcity in the network. At NO time can we rely on market forces to Directly determine PUT/GET/Farmers activities. The market will only influence their behavior, not deterministically control their behaviour. The market is only one of many factors that affect behaviour.
The basic issuse I am exploring in your equations has always been the free space percentage issue. You suggested that a factor be introduced and that is good. I hope you understand that input factors around the free space percentage cannot be economic, it must be a network measure of the free space. And that must have a driving force upwards on the PUT cost proportional to the lack of free space. Only when free space percentage drops below a certain percentage must the space factor be a major contributor to the put price
But I sense, by your comments, that your equations somewhat rely on the market to be a direct control on GET/coin issuance rather than an influence. For any particular month or two, the actions of farmers, uploaders & downloaders can cause your previous equations to do the opposite to what you want in relation to free space percentage.
Am I correct in this analysis?
If all other factors are the same (coin issued, market value at that time, etc) and the following changes using your previous equation without any FR factor (in order to understand the factor needed for free space %age control)
Case to illustrate the effect of GET rate when free space is not Directly factored in
- get rate low to average
- put rate average
- coin issued 50%
- free space 10% (emergency case)
only Increase d/l ==> Get rate incr ==> Put cost driven up because of increase in coin issuance
only decrease d/l ==> Get rate decr ==> Put cost driven down because of decrease in coin issuance
Coin in/out approx equal ==> markets little influence
So the conclusion is that If downloads are decreased then put costs are decreased which encourages more uploading thus endangering the network more. Thus the need for the direct free space %age factor.
EDIT: Another consideration is the well backed financial malicious entity who wants to bring down SAFE by filling up its storage. Under the current RFC the price would rocket up when the knee point is well past and before critical point. So effectively bankrupting any entity/group wishing to fill up the network. But without spare space control over PUT price the quick massive uploading would mean that the pressure on put price is downwards because of the coins being absorbed, and thus giving a free & easy ride for that malicious entity/group to fill up the network. (There is not increase in GETs/issuance of coin, markets do not change since coin bought prior to attack)
2 Likes
I think the core difference in our views is that I see a very distinct role for the farming rate algorithm on one hand, and for the store cost algorithm on the other.
In my view the responsibility of the farming rate algorithm is ensuring a sufficient supply of storage capacity, and the responsibility of the store cost algorithm is ensuring a sufficient supply of SafeCoin (i.e. staying solvent) so that the farming rate algorithm can keep doing it’s job.
In your view the store cost algorithm also has the responsibility to manage the supply of storage capacity. What I fear is that if you design the algorithm to have two responsibilities, that at some point they will conflict with each other.
Modifying the store cost directly by FR in times of crisis has the risk of reducing SafeCoin income (because at extreme prices, price elasticity of demand falls below -1, i.e. further increases in price reduce total income) to the point that the supply of SafeCoin starts filling up. If that happens on a long term, the SafeCoin cap will eventually be reached and then the store cost algorithm fails in it’s primary responsibility to keep the network solvent (a nasty side effect would be that during this process it’d also cause a huge burst of inflation).
So I reach two conclusions:
- The farming rate algorithm must in the end be able to ensure a sufficient supply of storage capacity on it’s own by manipulating farming rewards. If our conclusion is that it can’t, SAFE is doomed.
- If we incorporate FR (supply of storage) somewhere in the store cost algorithm to temporarily support the farming algorithm in times of crisis, it must never endanger the primary responsibility (ensuring solvency) of the store cost algorithm. The primary responsibility of ensuring solvency takes precedence over the secondary responsibility of supporting the farming rate algorithm.
If we can do the latter, great, then problem solved (so let’s try this). If however we can’t find an algorithm that qualifies, I firmly believe it is better to scrap FR from the store cost algorithm so that it’s sole responsibility is ensuring solvency.
I could triple this post in size by arguing why, including remarks on your described scenarios above, but that’s a waste of time if we can simply find an algorithm we’re all happy with.
1 Like
Actually that is an essential point. But only when it needs to discourage uploading (when free space is low). If free space is quite low then farming rewards are not working fast enough and more is needed, which can happen when uploads are high.
As I explained it cannot do it on its own. The ONLY thing that farming rate algorithm can do is HALF the story, it can only encourage more farmers, which will take time for it to become known and maybe markets help.
We NEED to be able to discourage uploading as well. It is a two sided coin.
Yes, discourage excessive uploads when free space is low.
If it happened long term then NOT doing it would result in zero free space long before then. If the FR is causing Put cost high then free space is very low and if long term then free space is low for a long time.
Farming rewards as you say should increase free space and so PUT cost should only be affected short term.
Disagree, and that is why the framing rewards relies on PUT costs being able to ALSO discourage uploading
The rewards and PUT cost can only encourage people to follow certain behaviours. If it was able to directly and quickly control behaviour then farming rewards would be sufficient. But world events are just another thing that can control people’s behaviour, for instance World sporting events can cause a 4 week flood of uploads.
Sounds a little contradictory. If it is to temporary support then it has to take precedence temporary.
I do agree that it can certainly be a temporary measure (buried in my posts is that suggestion 
).
Really it needs to. And is a simple matter.
The effect will be temporary because if it is not temporary then free space will be critical or gone.
The only way to solve a flood of uploads (malicious or otherwise) is to make it uneconomical to keep it up, and wait for farming rewards to bring in enough farmers.
Rather than a direct multiplying factor we could use a function (maybe just square or cube the FR)
Off the top of my head have
MB_per_SC = base_cost * ( 1 - fn(FR) )
where fn(FR) is a function that is extremely small and only becomes significant when free space drops to a point where we need to do something about it and rises in a way that reflects the required adjustment.
EG
40% free ==> FR = 0.60 ==> fn(FR) = 0.00 ==> MB_per_SC = base_rate * 1.00
30% free ==> FR = 0.70 ==> fn(FR) = 0.10 ==> MB_per_SC = base_rate * 0.90
20% free ==> FR = 0.80 ==> fn(FR) = 0.25 ==> MB_per_SC = base_rate * 0.75
15% free ==> FR = 0.85 ==> fn(FR) = 0.50 ==> MB_per_SC = base_rate * 0.50
10% free ==> FR = 0.90 ==> fn(FR) = 0.80 ==> MB_per_SC = base_rate * 0.20
<9% free ==> FR = 0.9x ==> fn(FR) = 0.99 ==> MB_per_SC = base_rate * 0.01
That is a simple illustration of what could be done to use FR (1-TS/TP) to only control PUT cost during very low spare space. Obviously the ‘fn’ could be tailored to produce results that only affect the PUT cost when it is absolutely needed to discourage over supply of uploads when spare space is low
1 Like