I don’t think so … the costs are the costs and so the price will reflect those costs no matter what methods are employed. If the ratio paid is smaller, then the price for each will be higher - assuming full replication ultimately happens.
It feels like that might be simpler in the end.
Once we have hole punching 
Of course if signing was to be done then rather than time it would simply be the previous 1 or 2 or 3 prices remembered and if correctly signed with one of those prices then accept it assuming space isn’t too critical.
I think that as long as we advertise the pricing to be price checks in a system that can see price increases sometimes, rather than time framed quoting system then we should be fine.
I expect though that in a medium to large network with sufficient nodes then the price will change in terms of weeks/months rather than minutes/hours like in the tiny system. Maybe for the first 6 months we’ll see it go from hours to days to perhaps weeks between price changes. It all depends on adoption rates.
But in any case even the tiny test networks shows promise in that the price is not changing every second and more like many minutes to hours between client getting prices and finally uploading those later records hours later.
Thats a fundamental flaw in your logic. It takes time to upload a large file and this is not seconds but minutes to hours when price checking a large file.
Also if the node has accepted the record with the payment then it does not ask for more. Its only when the client sends the record with insufficient payment that it rejects it and the record is not sent if the price changed. There is no bait and switch in a honest/properly operating Node.
Even the tiny test networks showed that the price changes affect large files where there is a large time frame. In seconds it’d be rare for the price to change, just like petrol pricing its rare for change when looking at second by second timeframes but regular when looking at days.
Again this is the problem with analogies for this, the analogies have more problems than just looking at the actual operation.
You want prices set for long timeframes, like hours for a many GB file, but the network is always in flux and there will be times the node has to charge more and price setting is not good and introduces unnecessary complexity and consensus.
Without specifying a measure for when this expires can cause many headaches for the network in practical terms and also a way to game the system and undercutting the nodes in the future.
EG If I had a movie library some 10TB or maybe 100TB. I’d get price check for the whole lot before starting to upload. Then hold the nodes to the old price while uploading all the movies over the next year or two.
The above is just one problem with quotes.
I did suggest the node just remembering its previous couple of prices and if the signed “quote” matched one of those prices then it accepts that. That way the node cannot be undercut in a gaming type of way like the example above and also allows the node reasonable control over its pricing and not needing to remember all the quotes it gave out.
But as @joshuef points out even that idea relies on the nodes behaving 100% and for a node to deny the quote is not enforceable by anything since there is no way of knowing how often each node changes its price.
Yes the node is responsible for records that have a XOR address around its ID XOR address. This creates a natural balancing effect since the XOR address of a chunk is based on its content being encrypted. And de duplication means that a particular chunk being uploaded many times is only stored once to the network and not a new copy each time.
Maybe when talking of pricing and price changes, its not time thats important but the movement of prices. So rather than time the count of price changes could be the measure since thats the important metric.
Keep it simple and only needed if needed.
Yes that was an original concept before it was realised that people who could not supply storage also need to store and the idea of a token was introduced.
Once the token was introduced then the idea of storage credits as you said was changed to you get paid for your supplied storage and thus that becomes the credit for you to store your data.
EDIT: Oh David showed it was the 2nd iteration. But still the fact that most people using the network to store data will not be running nodes, the token as the way to “credit” you for supplying storage is far simpler and allows easy access to store data for those without nodes.
I think you also need to consider those running light weight machines/bandwidth/quotas (eg phones/IOT) don’t want the additional code for one, but also they need to be able to run without the additional bandwidth/quota reduction the node s/w would cause to happen. If they are combined then there needs to be an option to exclude the node portion of the s/w or operation.
Hi David.
That strategy is to assume everyone is (or at least many are) a bad actor; one must prove they are a good actor by strict compliance. The trustless network.
This is kind of amusing since AI is based entirely on something that is not “exact engineering and provable,” yet it is the current rage.
What is the mechanism for detecting and dealing with bad actors in the current system? The ant analogy is fine, but ants aren’t known to be malicious toward their own (members of the network). This seems to be a universal concern. Since the network is supposed to be run by known code, deviations from code imposed processes are not minor infractions (evidence of code modifications). The transactions are not human, just human initiated, so there should not be any deviations. However, problems like lost packets and network delays could be either malicious or outside a member’s control.
Is there a document that discusses the current process(es) regarding bad actors?
Thanks.
I was thinking the time from the price quote (not check) until payment is tendered so the upload can begin. I presumed that the procurement for the storage space did not need to be concurrent with its usage. Once it is paid for, it is not available for sale, whether it gets used or not. That is what a price agreement is about, that amount of storage is sold, done deal. You are presenting real-time pricing for the current system, based on access/usage, which is not what I was discussing in the binding quote alternative, that is your process not mine. I did ignored the issue of how the node determines the uploaded chunk(s) are those that have been paid for (payment/usage tracking). All chunks have an address, which would be provided with payment by the elder, so when the chunk arrived for that address the node could establish it was paid for and not used since there is no data for that address. Also, a node could go down before its part of the upload is completed. It was paid but did not perform. Is this not just a corner case of any storage node going down?
I never brought up any bait and switch scenario.
You are combining an analogy for the current system with a binding quote strategy as an alternative.
In the current system, for large files, or blocks of files, that could take days to upload, the price check becomes meaningless. The chance of a price change increases and a successful upload becomes a difficult project for the client. Who keeps track of which chunks were uploaded successfully and which ones need to be attempted again? I assume the client’s app. It’s kind of like driving a nail; how many hits will it take?
A quote would include a validity duration set by the node providing the storage in the binding quote alternative. That duration is for acceptance and payment by the client, not the upload of the data. Again, the analogy was about the current system (whether it was a good one or a bad one). The alternate idea for binding agreements was not part of the analogy.
The binding quote idea presented has already been addressed as too complex and expensive (CPU time) to re-consider.
As I stated in a reply to HappyBeing: It does not have to be one or the other exclusively. Both could be available. That does add more complexity; two tokens, a payment token and a storage credit token. It also would create problems for for-profit storage providers, since a storage credit token has no payment value (profit).
It was decided that both are not worth the effort a while back.
My concern was for clients that have space to offer, but not the cash and having to go through the additional overhead to convert that cash to tokens to purchase storage. That process may not be so easy. Use an exchange, set up an account, transfer funds, pay fees, yada yada yada. I guess this was determined to be too small a group to justify both.
Thanks for the reply.
I’d be interested to hear more about why refunds are unreliable. Under a overpayment-refund-based payment system, failing to refund would surely be just another type of malicious behaviour that the section would punish, unless I’m missing something.
One unrelated concern is that if different sections charge different amounts, then a program to split files into cheap chunks could become prevalent. The program would split each file into network-sized chunks, make copies with a few random bits on the end, then find the cheapest variation of those chunks. If this somehow led to further price disparities, then it could turn into a serious issue.
That’s true, except there’s currently no way to punish this kind of behaviour and doing so would introduce a lot of complexity and inefficiency which is not needed because the existing mechanism should be good enough to ensure the network achieves its goals.
What is the current process/strategy to deal with bad actors, either implemented or planned to be implemented?
It depends what you mean by bad, so many ways a node can fail. So lets say specific attacks like Sybil, recently we learned of the work in libp2p for that (v cool) https://arxiv.org/pdf/2307.12212.pdf
So other ways to be bad or fail may include:
They cannot include
So when nodes are seen to be faulty they are ignored. That means they disappear from nodes routing tables and then they are isolated.
We have not put in many mitigations and fault detection yet, but it will be this simple.
Sorry, not specific. Failure of a node to perform a client service request for which the node receives a payment (outside of Proof of Resource)?
It appears that price for node service agreements (binding price quotes) are not enforcable and dishonors (failure to perform) are not punishable for any such case, so these types of agreements cannot occur, there is no such process in the network for it, right?
I read the current Primer (Feb. 2023). Are all sections up to date?
It still presents DBCs, which were replaced, right?
There is still some consensus and signature acts; mainly for elder’s section maintenance.
Node age is used to punish for Proof of Resource failures. PoR is fundamental to the network. Unlike upload price checks.
Punishing price quote dishonors (not in the current implementation) could indeed become a very expensive task if any consensus is required. It appears that more than one elder may handle a single client initiated upload transaction, so it would get complicated quickly. Even if the processing of a client initiated upload transaction was completed by only one selected elder (if the elder establishes a quote dishonor, age punishment could occur without the need for consensus, since elders are trustworthy), how would the section determined which elder gets to process any particular request? It is like whack a mole, you solve one problem and another pops up.
Am I starting to understand now?
Not at all.
There was a complete re-design last spring.
That explains a lot. Is there any ETA for an updated Primer?
It is impossible to try to understand the SAFE Network without one, especially when I’ve been trying to track this project for years now. Even with all the changes, unfortunate, but apparently very beneficial, this still looks like a great project.
I’m afraid there’s not.
But there might be some very beneficial Dev-Updates from around last April.
… but …
Therefore it seems to me that there is a way! I’m optimistic here 
But at the same time it is said, that cheating by re-starting with empty node will not be feasible. I would say, that when starting new, it’s impossible to tell whether the old one is still running, or not…
On the first point there is no way to punish that behaviour because there is no way to detect it. But we don’t need to punish that behaviour.
To detect it is unnecessary, adds complexity and inefficiency. The existing simpler mechanism will do the job. Nodes are punished for not storing the data they are responsible for etc as David explained.
On the second point it’s irrelevant whether the old node is still running. If you restart (or start a new node) you end up at a random location and must store all the data that location is responsible for without payment and wait for new data for which you will be paid.
You gain nothing and waste time and resources.
If assume such behaviour on a large scale in a tiny to very small network is going to cause the network to fail (potential for large scale data loss) we can then assume this behaviour is occurring at a small enough scale in relation to the size of the network and ignore the edge case of too many doing it.
Now in a small to large network we have a reasonable number of nodes running and each node has been receiving enough income for the operator to continue running nodes. Other cases are not worth examining since the network dies anyhow. This also means that each node will have a reasonable amount of records for it to be worth running nodes.
If we look at the case of a single node “filling up” then turning off we have to ask ourselves what is happening.
Now when a node starts up it will as @happybeing said have to store all the records that are in the closest groups to its new XOR ID. This will be approximately the same number of records it held before stopping and restarting as a new node at a new XOR address.
What is the consequence of this.
In the end there maybe some minor increase in earnings for some cases and delayed earnings in other cases. That all depends on the randomness of records stored and newly uploaded after starting again.
Now what happens if it is done on a large scale by the operator but not large scale on the whole network since that would cause data loss eventually.
Now if the node could cause all clients to use it till it filled up then you’d be on a winner there
Thats a very big IF, IIUC.
What mechanism could cause that to happen?
Its impossible for any of the current methodology and would require some sort of “god” like routines in nodes to control all the clients. IE the clients around the world have to connect to that one node and be told to send their records to it.
The current methodology is to use the XOR address generated by the hashing of the encrypted data. And that is done by the client (to reduce network load) and then the client finds the nodes to store the record to. The nodes are found by being the closest nodes to the XOR address of the record.