Thanks @dyamanaka. As David Irvine promised my head is hurting (not just from this, I’m fighting with actual computers too :-)) but this is confusing.
I still haven’t fully grasped your alternative. But first I want to be clear about the system I though was in place so I’ll summarise that, and see if I can find the fault or make it work! This:
- we have users who create demand and pay with Safecoin, or with storage if they also farm
- we have farmers who supply storage, and receive Safecoin in return
- we have exchanges that allow Safecoin/fiat exchange
Each sees the world from their perspective, but all are part of a closed feedback loop. I think I can see the issue you are trying to solve, but let’s see if I have that first. Then I might be able to understand your alternative. I’m going to work through to understand why you think someone needs to set the fiat price. Here’s a description of the original scheme as I understand it (please correct me!):
Network Utilisation Controls Farming Rate
Let’s start in balance. Users are paying UR (user rate) Safecoin per GB and farmers are being rewarded at FR (farming rate). Fiat price of Safecoin is $X, but let’s ignore X to start with.
If demand for storage rises, network utilisation rises, and the network increases FR. This increases supply and network utilisation at some point falls back. And vice versa. Ignoring X the system self regulates fine, I believe.
When X rises, users see the price of storage rise, and farmers are rewarded more highly (as both see the value in fiat terms). A user who farms is insulated from this provided their farming is sufficient to balance their use - this encourages users to farm, which helps the network grow and stay in balance. However, not all users are farmers, so when X rises, some users find it expensive and demand falls. Equally some farmers find it attractive and supply rises. As a result network utilisation falls. The network reduces FR, provision of storage pays less well. This is dangerous because if left unchecked, users might be lost in large numbers very quickly, and would be reluctant to return because of the pain they suffered in having to find another home for their data. We could lose people forever over this.
I notice that the more users who are farming to pay for their use, the impact of this change will be reduced, but that as X * UR (the SAFE fiat price of storage) gets more and more out of step with the real price/cost of storage, this begins to reduce the number of users who are also farmers (as users leave for cheaper storage and farmers join to earn more - and vice versa if X falls). Which is bad - we want to encourage users to also be farmers because it is more efficient use of resources (hardware and energy) as well as being more decentralised.
The Storage Pricing Problem (X * UR)
As described, we have a feedback mechanism between fiat prices and network utilisation, but I can see that a problem arises because we end up with an overpriced network if the price of Safecoin rises compared to the actual storage costs. And this I think is what you are trying to fix?
So we need a way for X * UR and X * FR to be kept in balance with $R per GB (the real cost of storage) yes?
A Solution?
Is this something the network can do? Well I’ve described how I think X affects the network. The real world cost of storage R reduces slowly over time, but with very occasional spikes and troughs (e.g. due to supply to demand imbalances in the market).
So we need the network to cope with: a) finding a level according to a steady R, b) tracking R as if falls gradually over time, c) tracking R through spikes (famine) and possibly troughs (gluts). And coping with potentially wild fluctuations in the fiat price of Safecoin, X.
The parameters that need adjusting are UR (the user rate for storage) and FR, adjusted proportionately up or down to cope with rapid changes in X and R, while more slowly tending towards values that ensure a healthy level of network utilisation. I think if we knew X (Safecoin fiat price) we could build this in, but we’d need to take care not to create instabilities - not my area so I could be talking total bollocks about the algorithms here. Ignoring that possibility :-)…
I can see us obtaining X by polling exchanges and feeding this quickly into adjustments in UR and FR.
I also think that could be done without human intervention, once there are enough exchanges to base it on. It creates a centralisation risk in that the exchanges could collude, or people with sufficient Safecoin could collude, but I’m not sure this represents significant risk to the network itself, because as soon as the fiat price corrects (manipulation can’t be sustained) the network also reverts quickly so I don’t immediately see a benefit to such an attack.
As I said, I’m not confident that this would be a stable system, but at first sight it seems to work and may be achievable.
How To Calculate Safecoin FIAT Price: X
Nodes will need a role which polls exchanges. Exchanges would be nominated by - not sure how to keep humans out here - to appear in a distributed database (on SAFE). The database would provide a decentralised ranking of exchange price accuracy (based on agreement across a trustable subset of the database). The trustable Safecoin price would be obtained periodically using the prices provided by the top ranked exchanges, having pruned not just low ranked exchanges, but any exchange with a prices in the top or bottom P percent of the total price range (or other methods which limit scope for price manipulation). I guess we start with USD or a weighting based on USD, EUR, YUAN. Others will know how to do this part best.
Exchange Price Interface
An exchange entered in the database will deliver pricing information by writing to the database using a SAFE API in exchange for Safecoin. Exchange reward would be based on relative rank, achieved based on least deviation from X over time.
I’m not sure how we stop people spamming the database with exchanges that just copy prices from an exchange API. Perhaps this is where human intervention will be needed! Or where we get to try out voting :-). A lot easier than maintaining the price itself though :-). A problem to solve, but otherwise, how’s that?
Now I need to have another read of your explanation @dyamanaka and see if I get it yet! I need a break first though 
