Yeh, I don’t think these are quotes now. It’s just a node saying how much they want at that point in time. No obligation, YMMV
Yeh, it will depend on the price curve too. If we’re in slow territory, it wont be a big difference, a full network could well have large differences per record. It should all eventually be transparent to the user, and they can choose to overpay (no refund, I agree, that just gets complicated), or not. The only thing they lose is time.
Ah, but there you have group complexity. will they accept it. Right now it’s just down to the individual node. That’s it.
That’s what we’ve had in the last testnet, it was pointed out it was gameable. We shall see. Seems pretty clean/easy to just give the client control here. With repayment it should just be that you end up paying a price they’ll accept. Nothing lost. The tolerance will just be about how fast you want something done (ie, lower repayment cycling).
What if the client runs out of funds as node raises price? Can they obtain funds later and continue the process or will they have to pay full price all over again?
Can the client set a spending limit on total funds to be used for any or all particular requests? And Can the client refuse a higher asked payment partway through and query another node for a better price? Or wait for a time and try again for a better price?
I’m unclear on how the client obtains the price in the first place - does the client query a single node, or multiple nodes and pick the best price?
Couldn’t this response from the storing node include a flag if an imminent price rise is expected due to being close to a storage capacity threshold, and then suggest the current and post-threshold price as an option?
Then the uploading node can pay the post-threshold price ensure no delay, or lower price if they want to try to get the lower price.
Yup. For every relevant record they’re currently holding. (Relevant meaning they are responsible for it).
In theory it could be way lower than 50%. IT also depends on the curve. Right now we start at 10 nanos instead of 2… But it increases much slower… We’ll see how things pan out in the current testnet and tweak accordingly.
This whole storage payment process seems ridiculous, like trying to catch a falling knife (even if not common). There should be no guessing on overpayment, etc. It would seem that a network storage rate should be a true quote, valid for a specified/fixed time period. This quote would need to be unalterable by the client (signed by the source), for a limited amount of data (could use less, not more). The space required is known at the time of the request, right? All nodes are required to accept payments with a valid signed quote for the price quoted, or they get downgraded. It was the valid rate at the time of the quote and submitted within the time window. If the rate goes down, the nodes get to keep the overage. So, on average, if rates are fluctuating, it should even out. This is how most businesses work. The amounts one node would need to provide per quote is in terms of chunks, not gigabytes and storage is cheap, as was previously stated, so why allow for real time price changes. Is this strategy more complex or straight forward to implement?
Obviously not what I expected. It is what it is.
Is the network determining the current storage price based on network storage availability, or do the nodes set their own rate? The latter would definitely make quotes very difficult and relieves the network from tracking storage availability. Any estimate would seem to be vague since the network would not have established for certain where the chunks are going to be stored.
Thanks.
yes. When storage get’s short the price rises AND nodes set their own rates based on how much space they have. If the network set the price then a consensus mechanism would have to be put into place - that’s complicated.
The price is going to determine that I expect. When a node is full, then it’s price will go to infinity … so you’ll just store somewhere else.
This is all my speculation, but I think that’s how it’s currently working.
Well, this definitely appears to be a system that operates in the best interest of the storage providers. Providers make no commitments regarding availability or price for a specific storage request, right? So, any estimate would seem to be based on using specific nodes or some local average, but those nodes’ prices could change, possibly dramatically if they are running out of storage, or could become unavailable. Also, the chunks need to be distributed across the network for security and redundancy, so one would assume the estimate’s node choices would be used for the actual storage, or the estimate basis is dynamic and may not reflect actual pricing. Changes could even occur during the storage process, right? So, the process requires a certain amount of price and availability stability. I believe it was stated that nodes above a certain fullness threshold are avoided so as not to hit their storage limit during the storage process, making availability reasonably likely. So, the solution appears to be throw enough payment at the network to try to make sure the storage occurs. This is like going to a grocery store and putting down enough money for payment for all items (chunks, here) before check-out and hope that you actually will get the items, otherwise, try again during a new check-out run. Is this an reasonable analogy? If storage cost stability is relatively high, then this should easily succeed. Is there any restriction on how often a node can change its price or how that price is determined?
Thanks.
Nodes who are to pricey won’t get data. It’s a balance economy, the price rises, more nodes join and the price falls or if not less data gets stored and is kept elsewhere instead.
yep … but clients don’t have to accept the price - they can choose another node.
They do and so uploads can fail if not quick enough and have to be renegotiated at new price.
I think this will all be determined by price. The fuller the node the price goes exponential. Meaning the client just won’t choose to use that node. So should be self-balancing.
Somewhat, but if some of your chunks fail, you renegotiate only those chunks. So you don’t have to repay for what you paid for (and successfully stored) nor start from scratch.
I believe the node recalculates as it’s load increases and the price is determined by an algo that’s currently being tested. Of course rogue node can do whatever it likes, but may not get any data or payment.
Do I understand well, that for every chunk/record we have a fixed set of nodes (redundancy) responsible for storing this chunk, and there is no choice, client just has to pay whatever price these nodes ask?
So, if I modify node’s code to, say, ask 10x more than the standard node, clients just have to pay anyway? That would be confirmed by testnets, where some nodes experienced significant income, even without being intentionally evil?
But the intention is to open that up and let the client decide on their own payment / redundancy desires. (to avoid what you’re suggesting).
Right now we’re testing to nodes get payments, and are uploads working there / repaying. Once that’s nailed down we can start avoiding outliers once more (as we had this in prev testnets, mind)
Each record is dealt with separately and would typically go to different nodes if the network is large enough. For a tiny network some of your records from a file will end up going to the same node.
So say your file generates 10 records. Then there are 10 groups to deal with and that means up to 80 nodes. In a large network this will mostly be different groups for each record. For a tiny network it may see a couple of records go to the same group.
Now to use shopping/grocery stores and the 10 record file, it’d be like going to 10 different malls and each mall has 8 shops selling that item (different item for each mall). So initially you may visit all the stores and get a price check from each store for those up to 80 stores. Remember each record goes to a particular mall so its not 80 stores give a price on the whole 10, but the 8 stores in one mall gives a price check on a particular record.
Now the major difference is that its like you go and get price checks from each store going outside before deciding to buy anything, then you go to each store. And in real life it is possible for a store to change its price within that relatively short time. Petrol stations are great at this when its time to update the price. You see the price and drive in and by the time you buy the petrol the price has changed.
Remember in real life it happens sometimes that you get a price check from a store and by the time you get to (or return to) the store conditions changed and the price has changed.
One of the remaining consumer protections in UK means if a price is displayed it has to be honoured. More than once I’ve filled a trolley with underpriced wine and at the checkout they’ve charged the correct higher price. But they had to refund and charge the lower price because that’s what it says on the shelf. Same with petrol stations, but I’ve never experienced then getting that wrong.
