That is the key. That’s what I’m not sure about.
If the node decides not to accept the agreed price, what happens?
Is a new price negotiated? How many nodes are involved?
And the big question, is a timestamp really needed when the node can refuse without being punished?
Maybe the timestamp isn’t necessary, testing will help establish that along with the other uncertainties.
I suspect the timestamp is a speedup optimization. If it can simply see that the quote was recent, then it can simply accept it. If not then it may need to do some other factoring to see if the quote is still reasonable.
perhaps a solution: When the node replies to client’s store-request (which includes the quote), the reply include’s the node’s signature over the store-request.
The client can then request a copy of the stored data from node. If the data is not present, the client can send the node’s address, store-request, and node’s signature to other node(s) who can also request the data from node (if quote-timestamp is greater than their own now() ). When they find node does not have the data within time window, they can de-list the node, or whatever the punishment mechanism is.
Wouldn’t giving clients the power to ‘initiate proceedings’ 
be a DDoS vector?
Perhaps, but there are ways to mitigate. For example, when a node accepts a client report, it doesn’t have to act on it. Instead it could process say up to 10 reports per minute and discard the rest.
So a bad node that is discarding data might get away with it a few times, but will eventually get caught, so why take the risk?
How will they know if the node deletes the data long after the initial time window?
Rhetorical question. The time window on safe is an indefinite infinity.
Wow. This is what I was suggesting on the Sept 14 update. It appears that I wasn’t the first either. I was criticized for the suggestion: Signatures take too much CPU. Pricing must be real time to reduce complexity. Price changes are not going to occur that quickly. There is no efficient way to coordinate/synchronize clocks. Unnecessary complexity.
I would like to suggest here that the timestamp should be the expiration date-time for the quote and should be UTC. This allows more flexibility. Each node gets to choose how long their quote lasts. The client gets to choose if a quote does not allow sufficient time.
Does this proposed strategy occur on a block by block basis from the client (that would help keep it simple)?
While this could result in multiple chunks going to the same storage provider node, the redundancy strategy should protect the data.
Is a storage confirmation notice from the node to be expected? A reasonable confirmation would include the entire original quote, a timestamp for the received time of payment, accepted/rejected, and a signature.
Note that it is in everyone’s best interest to keep their clock reasonably synchronized to an Internet standard, which typically occurs anyway. While this is not mandatory, it is foolish not to for both nodes and clients.
There’s an important difference between this proposal and those criticised earlier for complexity, and that is these are not binding quotes. I think it is misleading to call them quotes for that reason.
There’s no contract, no enforcement. It’s a means for a node to operate more efficiently but entirely at it’s discretion. It could ignore the time or offer any length it chooses.
None of the earlier proposals were like that, but calling these quotes makes this seem similar when it is fundamentally different.
It is no different than what I was proposing. An enforcement mechanism may have been a proposed option. The suggestion was based on a price, timestamp and signature. No suggestion should be seen as an all or nothing proposal. Using this process, a price “quote” cannot be faked and contains an expiration time; about as simple as it gets. While it does not force a node to do anything, it at least shows good faith. The signature is indeed a type of contract, while any enforcement may or may not be possible. It is both a contract by the node with itself (the node can verify it generated it), and with the client, who has at least some proof that the offer was presented with the node’s signature. Even if there is no formal enforcement process, it provides a trail of evidence of possible bad action. The confirmation I just proposed adds to this, by creating more good faith in the transaction.
Performance is almost impossible to enforce is any contract even through a court of law. The best you can get is some compensation awarded for the lack of performance and payments accepted. If no payment is accepted, often nothing can be done, except bad ratings, if a rating system exists. So, this network is not all that far from reality.
I find this post/reply process can become quickly judgmental and dismiss proposals without really considering its possible contributions, which may be only one or a few components. It can discourage suggestions, possibly shutting down creativity the team may be looking for. I find it discouraging sometimes. I do Find David’s comments thoughtful and explanatory.
That sounds like a decent idea. Maybe already part of the plan? IDK. Of course clocks have to be in sync to get it perfect, but if they are out by a smidge, maybe still useful info for the client and even saves time for the node if time runs out.
Exactly! Time synchrony does not have to be exact. Perfection is not realistic anyway. The node’s clock rules the offer, if they don’t outright ignore it (bad actor). If the duration is something like 10 minutes, what is a few seconds? These transactions should not be cutting it that close anyway. The expiration should allow for reasonable network traffic delays too. Nodes are free to offer any duration they choose. The expiration creates the duration where clients can choose the most attractive, screening out offers that are too short, for whatever reason.
If each block is handled separately by the client, the client need only have some expectation for the price for one block. They can determine how many blocks are required for the file to determine an expected approximate total price. Pricing is per block on the network anyway. No volume discounts anticipated or allowed (AFAIK). This allows the client to get an idea for the total price right from the first block quote.
It seem to me that the good faith aspect (though the “quote” could be fraudulent) is also very beneficial. The process at least provides some evidence to justify a complaint, whatever good that may or may not be. Trying to think ahead here. A bad actor mechanism may be found that is feasibile in the future.
Then it would have been easy to point out that the criticism, that enforcement was impractical, didn’t apply because there was no enforcement. 
Thanks for the claification of optional. 
Thank you for the heavy work team MaidSafe! I add the translations in the first post 
Privacy. Security. Freedom