That is a weird way to look at it. No computer network will ever get to tell me how much is my storage or bandwidth worth. In other words, there’s a real world outside. It’s not the network but the person who gets to decide how much is a fair price. Without a way to express that as a number (practically, computed by algorithm running on the vault but freely chosen by the user), they are left with a binary choice: stay or leave.
4 Likes
you dont understand that you will not get more money if there is a freemarket on the put and get side of things.
a person with the best bandwidth and fastest storage in the lowest cost will shatter a common user with his normal bandwidth and slow storage/pc so end result, you will not make ANY money if the puts and gets are in the way you propose.
does that sound logical?
edit: also lets make the assumption that 8 users got a chunk of a data and we use your method of bidding the get rewards. do you think that the network or the user that wants to PUT some data will choose your bigger price or will it choose the cheaper bid of the 8 users that have the chunk?
again the only one that knows the demand in storage or the price it should have is the network so its profitable for all vaults and its incentive enough for people and for organisations to load data by paying the PUTs.
1 Like
This discussed a lot and its not quite right. Where in the world will have a lot to say in who is fastest.
1 Like
I’m a bit confused by that sentence but I do want the vaults with the lowest price to win.
Vaults that are getting full will demand a higher price because they know other vaults will and they wouldn’t want to miss out selling their remaining storage for a higher price by selling it cheaply now. On the other hand, if somebody is more interested in short term profits or they are new and their vault is just getting filled up, they can instruct it to offer below the market price.
As you can see, the network itself doesn’t need to know anything about how much resources are available since the market would take care of that way more efficiently even the best hand-crafted algorithm ever could.
4 Likes
from the point that the user needs to keep up with the correct price I think its counter intuitive
but if you want there to be this bidding as an option, then I think I would consider it.
but shouldn’t we make the network work as simple as possible? human factor may lead to playing the network and people with high IQ and insight may manage to get more rewards from the network directly leading to loss to people that will just use the default network rewards.
1 Like
Two things:
- work: we want an absolutely fool-proof and un-gamable method and, fortunately, a free market is where “gaming it” is the game, making it a perfect solution to avoid… gaming it?
- simple: if there is a free market, there’s no need for the network (that is, the core software) to care about setting the price
Let’s face it: the human factor is just there. The question is, are we happy with users just leaving if they are unhappy with the current price, probably never to return, or are we willing to give them more choices?
A few things about this:
- what’s wrong with that? (ignoring the fact that IQ is bullshit pseudoscience)
- people would play the network anyway, so turning that into the very mechanism by which it would set the price makes sense (and it has already worked in real life)
- the better the players, the higher the liquidity, and the better the price would approximate the “real price”
It isn’t a loss if you get what you’re asking for. Moreover, different people have different priorities. As I already mentioned, some may want some quick and steady money, some may hold out and wait for the times when scarcity would push up the price higher some more. Both group would leave if they couldn’t achieve their goals only some generalized “ideal” solution somebody clever put together disregarding such thing does not exist.
3 Likes
10 posts were split to a new topic: Debate about central planning vs. free market for negotiating the PUT price
Those are good points and I’m becoming rather clueless about the economics at this point.
On the one side, and this is why I came up with the free market idea in the first place, I don’t believe in hand-crafted control of supply and demand. Get it wrong just a little and everything will fall apart with extreme prejudice. Or not. The point is, it’s impossible to tell and that’s scary.
On the other side, you’re correct in that the forever aspect of storage introduce a serious flaw with regards to bidding for the first upload and the first upload alone.
Effectively, it either doesn’t make sense or it should be carried forward to relocations as well, but then things become complicated for joining/leaving sections. Should we demand or force refunds for the chunks that are no longer stored by the vault before we pay them for the new ones in its new section? Should we just not pay them more until they reached the same number of chunks they were already paid for? Or, … but I think I’ll just give up at this point and hope for the best.
1 Like
You offer a get you get reward, so people are incetivised to provide stable and 24/7 access. If you leave for an hour all those chunks you got will not produce you any reward!
1 Like
What will cause less damage?
Not perfect algorithm or not perfect free market ?
1 Like
What will not work is trying to control the market with network algorithm
5 Likes
Many good points, but we also must realise that the network will evolve, as optimizations are made and obstacles are avoided.
In the spirit of agile development, you talk with stake holders regularly and iterate through changes to suit their needs. We cannot know everything from the start - we can just make a good stab at it and then see how it goes. As long as the team is nimble, where there is a problem, a solution can be found.
You can easily end up with paralysis through analysis, which results in a never launching network. There has been a great deal of analysis already and it is time to see how that works out. There is little point worrying about unknowns, when we simply can’t guess how they may materialise - start simple, then tailor to suit.
13 Likes
Thanks @neo, you’ve hit the nail on the head. All through these discussions my intuition has been warning me away from what felt like the temptation (of various bells and whistles) to see them as better than something imperfect but much cleaner and understandable. I think you’ve encapsulated what that nagging was trying to say to me.
EDIT: I’m also reminded of the temptation to over engineers things. I wonder if that is driven by the pursuit of perfection ending up hiding flaws rather than arriving at a solution with less flaws.
7 Likes
This is key, everything must evolve and nothing is born perfect. Nothing ever gets to perfect anyway, but as long as it survives and does it’s job we are all good. Key for me these days is release with all required features with the minimum code (and here I mean take time to remove old complex code, that cost to me is 100% worth it) and complexity possible.
21 Likes
Interestingly enough - I still think the old (maybe original) RFC for safecoin had a perfect supply/demand mechanism (not to mention its other problems).
I think it was something like: You have a big array 2^32 representing each coin, and when a farmer has done a unit of work the network picks a random address from that array to reward the farmer. If the address picked is empty, it is assigned to the farmer. If it is full, the farmer gets nothing. Regardless of the other aspects, I think the supply/demand mechanism for this was perfect. This is why I bought into MAID in the first place.
The main problem I saw with it was it didn’t allow decimal values of SAFE coin. All other proposed supply/demand mechanisms seem overly complex and frankly I’m losing confidence that they’ll be solved in a sensible manner.
5 Likes
is this not solved? I thought the safecoin is already implemented and agreed on
1 Like
The farming algorithm is not implemented. As it will be initially the code is simple, the thought not so much, that is why we made it phase 3, to allow some thought/discussion on the simplest initial solution.
11 Likes
The farming algorithm may turn out to be the hardest part to get right. I think taking as much time as needed to think, discuss, and test various approaches/rules is very wise. Even very simple rules can drive complex and unexpected emergent behaviors in large systems.
10 Likes
regarding u64 vs u128:
Why not implement as u128 but have a convention/rule that for now clients should/must truncate values to 9 decimal places for display purposes? ( or 8 places like bitcoin? )
This provides a path to future increased divisibility/units without changing core APIs, but keeps amounts looking “normal” for now.
Perhaps the poll results would have been different if people were presented with this option…
4 Likes
I’ve read Primer a couple of times recently, so I’m not familiar with the Safe Network.
And I read RFC 57 today.
I have been curious about whether the Safe Token has complete anonymity. Because the elders of each section need to know the current states, i.e. the number of tokens, of all clients in the section to avoid double spending. To do this, the elders or nodes need to know the account states of all clients. Without knowing this, I can’t figure out how to prevent client’s double spending. The other issue in this case is that when a new elder is included in a section, the correct states of all clients in the section must have newly downloaded. Also, how do I make sure the download is correct?
Therefore, it seems that the Safe Token will be known through anonymity. So I guessed that you can’t transfer safe tokens using DSC. Is this right?