It would seem like you are missing something from the actual update text. (unless the text is misleading/incorrect)
get quote at any time
at any time pay for it
at any time upload it.
So from the update it is clearly quote, then anytime after pay for it.
But cannot be. There is no 3rd party or other exchange/trading/method to pay for it.
Arbitrage is playing off one supplier against another supplier. Here there is only one supplier and asking for better quote from them.
What it is, is that you can get a quote now, later get another quote and choose the better one. (or do more quotes).
So more of a wait till get the best price before paying / uploading
This is the confusion. With one-time keys the âproof you will payâ locks the payment. So you cannot reuse the input key to do anything else but actually make this payment. So payment there means finalise the payment i.e. give the recipient the DBC, But you have already said (And locked) you will make this payment and locked the input key to only this payment. Itâs a bit confusing, but quite powerful.
i.e. A locked intent to pay means the payment completes or the money is gone.
Well you could not do the payment.
then later on get another quote (new set of keys)
Maybe more if not happy
When the day comes that you need to do uploads then use the keys from the best quote
EDIT: another attack surface is to request quotes for PBs of data, again and again. No cost to the attacker but uses resources in the network to provide quote.
Attacker gets best quote for PBs of data upload. Then wait for scarce spare space and pay/upload to do their attack. This attack has thus been amplified because they were able to delay payment till the attack is easiest and best time. If they had to pay when quote then they used their SNT up front. Or if quote is short lived then no amplification will happen.
EDIT2: Most quotes in the real world have a expiry date. The network does not know time, but could have a count of events as the expiry (or similar system). This I feel is essential for any quoting system and will reduce the manipulation any normal person would do to get the best price if they can wait hours/days/weeks.
Then a quote is not a quote if you cannot reject the quote
Also clearly from the update there is any time between quote and paying.
The idea is if you accept the quote then you pay (anytime after). If you do not use the keys there after then the money is gone.
So there is an issue either with names or explanation. If get quote and have to pay immediately if quote accepted then thats good in my opinion and by immediate I mean see quote and either accept(&pay) or reject within seconds/minute. IE like an answer to the quote while network keeps it open for very short time.
This is correct, itâs a guarantee of store based on a guarantee of payment. If you donât store you donât pay but your money is gone. Itâs to allows you to get quotes/guarantees then upload later (when you are off the plane etc).
I agree itâs like the deal is done and agreed, you cannot back out of it, either party.
To me if I donât pay then I have my tokens. If I donât have my tokens then I have paid, whether the data is uploaded or not.
If a quote takes my tokens whether I accept the quote or not then its not a quote, but payment in my opinion as a man in the street so to speak.
I understand that once the batch has been paid then I cannot be charged differently whether I upload straight away of in a year that specific data in the batch.
Then really its only 2 steps and neither is a quote. Request to get keys to upload a batch which requires payment of tokens at that time, then upload that data anytime after. Thats if I understand what you are getting at.
Maybe a more precise step by step is needed here (user/client & network side) since even this is not precise as the process could be a couple of things.
I will wait till the process/protocol is more precisely laid out. In any case I have given a few thoughts on the matter even if barking up the wrong tree.
Something like âpayment to storage commitmentâ âdata dealâ âupload contractâ feel a bit more accurate description than âquoteâ. I actually like quote but it clearly is unintentionally misleading.
Still just as powerful
Getting a storage guarantee from the network when you currently have no connection, seemingly allows you to perform an action like sharing/editing/uploading and have it be reflected locally, and then once a online connection is reestablished, be uploaded to and reflected on the network.
Yes, part of the problem is thinking of accounts, with DBC you can commit to a payment and not have completed it. You have no choice but to complete it or lose the cash. Unlike accounts where a payment is made in 1 atomic withdrawal and deposit.
Best to think of register and then multimap as git like indexes, where you can have forks etc. and âmergeâ back. The merging though is a client issue and the network makes no attempt to do that for us. So apps need to provide the ability.
So we can say here is a website and there may be more than 1 version at the address (which is current is app dependent). From the version shown we can go back a parent at a time.
We have not put a sequence type API there yet, but you can in the registered go back to the parent or forward to child. That will be exposed in the multimap as well. It feels wrong but likely it is right, if there are concurrent updates that conflict then the app needs to allow the human to merge that otherwise, s/he will confuse their customer.
@dirvine I know this is in someway an impossible question to ask, but how long do you think it will be until we have a basic network running. I know based on all the past attempts it is a question hard to answer. But we have come a long way. I feel a momentum amongst the team. If you think you canât answer this at this time I totally accept this. As Iâve said before I believe in you and the team. You guys are charging into known territory. For this alone Iâm grateful. Time is limited. Please do your best, which I know your are, to get something out of the gates. Time is short. We believe in you.
Yip, all we can promise is we are pushing as hard as we can every day. We have come a long way and it feels very close, but until that release button is pushed and folk use it with no bugs then itâs impossible to tell. The proposition is much simpler now though and the confidence in it all working well quickly is much higher.
It seems to me that there is still at least one mental piece missing from the puzzle for many commentators (myself included).
To me a quote is âthis is the price you would pay if you commit nowâ. And surely your client has to see such a quote, or how would you know how much to lock via the DBC mechanism? Then once the DBC is committed, the quote is perpetually valid⌠that part makes sense. But is there not some mechanism whereby you can ask the network âwhat would it cost to store this?â and either say yep/no?
Anyone can get a quote for any data. If they pay using the quote, then they pay, if not, then they donât. But there is no way to prevent people from uploading data.
Well, this is made out as a relatively simple thing to do. Iâd say itâs enough trouble for it to be prohibitive. There are plenty of costs associated with the above steps. And as with so many other things, costs are what prohibits.
All start when the price (SNT) of upload is extremely low
When is this? They have to be ready and commit to waiting for an indefite time. That costs.
Get quote for PBs worth of data to upload.
What data is this? If they are just generating random data, then they must store what you expect a network to not be able to store, for an indefinite time. Because the quote is only valid for that exact data you inquired for (with provided hashes).
If it is data that they think is valuable, then they probably rather try to get it cheaply stored ASAP. If itâs just publicly available data, that they intend to upload at some point in the future, then they need to have massive infrastructure available at just the right time, to be able to fetch it and pipe it into the network.
The smaller the network, the smaller the reason for anyone to care enough about it as to invest enough resources in a bet that they might be able to do something to it in the future.
Another way to say it is: If the conditions occur when the network is very small, then the negative impact could be achieved.
And that goes for many of the possible attacks. The small network is inherently weak and susceptible to all sorts of things. It simply needs to grow before it can work well.
Wait till they see price skyrocket because of network spare space is low
When is this? The price can fluctuate, but if the network grows it wonât rise. And grows it needsâŚ
The price skyrocketing would be like a very small network, and some fluctuation. Otherwise it is a network shrinking and in deep trouble. Already the âdo not merge sectionsâ thing assume there will be no shrinking.
I donât think it is much of an issue actually.
Itâs neither a pre-quote nor a payment. Itâs just a quote.
Yes, this is how it works.
In other words:
You ask "Given this data [bunch of hashes], how much will I pay?", and you get an answer "To upload the data corresponding to those hashes ([bunch of hashes]), you'll need to pay X" - plus, of course, the so necessary section signature over it.
And thatâs it. Thatâs the quote, itâs perpetually valid.
Doing the payment is a separate step, which you may or may not do. If you donât like the price then you donât pay. If you think the price will go up, then you might keep the quote, and pay for it in the future.
After you have made the payment, you have a receipt. That is also perpetually valid, and of course only valid for the data you said you wanted to upload.
Naturally, youâll want to use the service you paid for, so itâs likely youâll eventually do so.
Yes, this is the thing.
If you find the price to not be attractive, (for whatever reason; you are not in that big need of the distinct properties of the service, or you do not have a higher alternative cost for keeping the data somewhere else, etc.), then you of course wait.
âNo costâ is not quite true. Itâll take resources from a spammer to spam. Currently there are many ways you could spam the network, such as [excessively] querying for data, sending tokens to yourself, or asking for quotes. Any free request will have that property, untill there is some msg prioritization, granular back pressure and the like in place.
Currently though any msg sent in the network will cause more work on the network than on the client, so amplification is already there. For writes, there is costs to that prohibits, but for queries thereâs not.
Yes. And a GuaranteedQuote, as the type/concept is currently called in the system, is a perpetually valid quote.
I hope the confusion is cleared up with the above description.
Should this not be called CommitedPaymentReceipt or similar as the DBCs can only now be minted for this payment, i.e. they are not necessarily yet minted but the transaction hash is committed to and the revocation packet for the key is uploaded?
No because itâs neither committed, nor a payment nor a receipt.
The DBCs are not involved at that step. Itâs just the answer to âhow much would this costâ, and we say that weâll perpetually allow that data to be uploaded for that cost, if paid.
Not perpetually valid and identifies the nodes who will be paid what amount
Then send back to the same Elders (SAP) - or start again if Ae kicks in â Here is my DBC Transaction and the revocation key written (client writes this)
Then whether the DBCs are minted or not the Elders give back a PaidStore / receipt (perpetually valid)
Then on the actual store, the client must have the output DBCs (so has re-issued as per his revocation packet) and the PaidStore/receipt
The nodes are given the DBCs to spend as they wish now.
If the store is made too late though the nodes to be paid may have gone, unless they know a DBC is en-route I presume (or we did pay each Elder in section and Adults close to XX but that can be messy) ? Worst case we pay the current section though and that means section wallets which would be nice to avoid?
