Update August 5th, 2021

[Mendrit]

Sad to see him leave this forum with all posts and PM.

You will miss me @Antifragile

[Nigel]

@JimCollinson

Can can you imagine the frustration of returning to the upload process moments/hours/weeks later only to find our I’m a few fractions of a token short! It’s tear your hair out and never bother again time.

This is barely even getting started to being worked out of the general crypto space as is so this would be a massive leap in usability!

[tfa]

@JimCollinson

we cannot really adequately define “about to expire”, “data so large” nor “expected to upload in time” again because of what I listed above. And this is not even taking into account the elephant in the room of introducing time .

No need to define these terms with my proposal. Nor do we need to introduce time.

@oetyng

the argument that rejecting chunks when network is full is very bad for the network, that people will be turned off en masse… I think it applies more to the “your payment is not enough” a millisecond after you “paid” (committed) - which is something that would happen all the time .

This would never happen with my proposal (I mean never after milliseconds)

@JimCollinson

Can can you imagine the frustration of returning to the upload process moments/hours/weeks later only to find our I’m a few fractions of a token short! It’s tear your hair out and never bother again time.

This wouldn’t happen after moments/hours with my proposal.
For weeks, that will depend on the network stability.

[oetyng]

@nevel

Getting a quote is a service provided by the network and therefore should cost some small amount of SNT I think.

An Elder could refuse to provide a quote unless DBC(s) are sent to it, with a value of at least - for example - 1/10th of the quote amount.

It would hinder quotes being asked for in excess.

As it is DBCs in plural, it means you could always top up if you sent in too low amount.

The first downside of this is that it’s an extra round of DBC kerfuffle.

Other downside is that it could become quite annoying as well, if the Elders for some reason don’t have the same view, so that you can’t aggregate sigs over the same value. Shouldn’t be a common problem for individuals, but generally could be quite common. You could send in those sigs as to show that you paid but didn’t get a supermajority over the same value, but then how many times can you send in those sigs? Should an Elder keep a count of the times you sent it in, and only allow a certain count, or should it allow you to repeatedly ask for fresh quotes with that one case of a glitch? Or should it just ignore it and say “sorry, that’s part of the costs, try again”. Bad options all the way through.

@nevel

Also, a quote is some kind of option, as mentioned before. It gives the right to execute some upload for a certain amount of SNT. This makes the quote itself valuable. So it makes perfectly sense to me to charge some SNT for getting a quote.

The quote is only for specific data.
Sometimes there would be some publicly known data that you really want to upload. Maybe because of rep or earning PTP? But then it can’t be that important, because if it was, you’d just upload it directly instead of wasting time looking around if anyone has a quote for a few pennies cheaper.
Out of the total, can’t be a large share that someone get a quote for and later find someone who wants to buy it…?

It doesn’t seem like quotes in general would be valuable to someone else than the data uploader.

---

@oetyng

@tfa

To clarify things say that x is set to 10%. In addition to the data you plan to store in the quote you would also store a limit price equal to current cost plus 10%.

The quote would be perpetually valid at the condition that at time of payment new cost is less than this price limit.

This hits the same issues that I described in the reply to @VaCrunch (linked above).

I can try explain in more detail, but see in that post if you get what I mean?

No?

You’ve mentioned your proposal now a couple of times. Maybe you can go into more detail of it? I have tried to walk the path of it here below.

@tfa

To clarify things say that x is set to 10%. In addition to the data you plan to store in the quote you would also store a limit price equal to current cost plus 10%.

The quote would be perpetually valid at the condition that at time of payment new cost is less than this price limit.

At time of payment, would mean at time of reissuing. Because that commits the amount.
So reissuing section would either need to get knowledge of the quoting section, or you must be asking for the quotes at the section where you will be reissuing.

One section getting the value from another section, in this case doesn’t seem like a motivated faff.
So, I’ll bring up this example again, where quote responsibility is moved to DBC section:

@oetyng

You could move the quote responsibility to the section where you will be reissuing your DBCs, but that gives a strange recursive logic to it;

• To know which DBC you will pick to pay with, you need to know how much you will pay so you need to have a first estimate which you base your DBC pick from, then you ask the section responsible for that DBC, and if your DBC will cover the amount, then you can take that, otherwise you need to start from zero again.
• OTOH you’d probably build up a map over sections and the last known value you had, so it’s not a big problem.
• But then again, you will not be able to pay a quote with multiple DBCs, because then you will most likely need to talk to multiple sections, of which you now need some sort of agreement on the price and the quote… That breaks it right there I think? Because being able to pay - more or less equally swiftly - for network services with any combination of DBCs seems like quite an essential property… Otherwise we’d need to introduce an additional step where you have to merge your various dust / change DBCs into a single one, which size you don’t know for sure until you have queried the section which will be responsible for it… That path seems convoluted.

Thoughts?

[riddim]

Seriously people - this topic has sucked so much time and energy out of development… (and the community)… I want to see a live and running safe network and I seriously don’t give a f**k about limited or unlimited quotes at this point… We’re discussing and changing stuff since 2015… Now would be a good time to just have/focus on a running and browsable network that can survive for 1 month without breaking… (just to clarify: this is no criticism about decisions of the past … Those changes made a lot of sense to me - but this discussion here doesn’t imho)

… Why can’t we just start with unconditional unlimited quotes and when we know the basics of the network do indeed work we can revisit this topic and discuss ‘is this the best way to run the network or might conditional quotes of some kind make more sense for the network to survive?’
… I think its obvious this is an issue (if it really is an issue) that doesn’t need to be solved on day one - day 1 a browser (/rather sooner than later) on the other hand would make a lot of sense…

[tfa]

@oetyng

@tfa

To clarify things say that x is set to 10%. In addition to the data you plan to store in the quote you would also store a limit price equal to current cost plus 10%.

The quote would be perpetually valid at the condition that at time of payment new cost is less than this price limit.

At time of payment, would mean at time of reissuing.

I don’t know, I just meant step 2 of the OP (With that quote - again, at any time of choice - pay and retrieve a receipt)

@oetyng

So reissuing section would either need to get knowledge of the quoting section, or you must be asking for the quotes at the section where you will be reissuing.

I was considering something simpler: If in step 2 of the OP current store cost is greater than store cost at the time the quote was issued plus 10% then payment is refused. To allow this comparison you just need to add the initial store cost in the quote data structure in addition to the data you already planned in it (list of xor names of the chunks in the batch, quote price, …)

[feinberg]

@dask

From where I sit, this would be one argument to add an options-like pricing to the perpetual quote. As volatility decreases, the option value will trend to zero, but in high volatility times (e.g. a price pump), the volatility will cause the option premium to raise quite quickly, preventing much volatility based exploit. I.e. if the network price was calculated as (however you do it) + Blacks-Scholes on the volatiliaty of (however you do it), that would take care of a ton of the attack surface. And as the network grew, volatility would decrease, option value would trend lower (and volatility in the option value would trend lower) until it was a so-called scalar factor.

This person gets it.

[neo]

@feinberg

This person gets it.

Wondering if there could be a premium for quotes in terms of raising store cost of chunks with a low store cost compared to the others. For instance if the average of the highest cost chunks (say top 1/2) becomes the minimum store cost in the quote.

EG 10 chunks and the store cost of the chunks are (from lowest to highest)
0.25, 0.25, 0.27, 0.30, 0.30, 0.30, 0.30, 0.35, 0.35, 0.35
The average of the top 1/2 is 0.33
Thus the quote would have the prices as 7 chunks at 0.33 and 3 chunks at 0.35

This maybe exaggerated in the range of prices but its to illustrate the idea. This then smooths out the most market shifts in the near to medium range and reduces any loner term issues.

Maybe even the top 1/3 average.

Only code needed is averaging and bringing up the low prices to that average. Its a compromise and something for further down the track if the devs like the idea. If people want the cheapest then they can get quotes for smaller batches.

[tobbetj]

Yes but does it have to be that complicated? Why not buy what you get on what might be called a spot market? I only took one course on Options\exotics and other derivatives, after that I’am just glad if I never have to deal with options.

I just hope we can find the most simple, best and optimal solution.

[treslumen]

@maidsafe

elements such as XorName being moved out of a slimmed-down sn_routing and into qp2p

Hi, I wonder if someone could offer more insights regarding the reasons behind this change? Naively I thought things like XorName are semantically routing stuff, rather than connection stuff? Was it a pragmatic decision? Just curious:)

[dirvine]

XorName is just a representation of an XOR address. So all data clients and nodes are in that space.

[Southside]

Is it time to dust off the Project Glossary and make it a sticky?

I know it gets a mention in every update but perhaps it should be more front and centre for n00bs and forgetful buggers like me.

I have updated a couple of the terms in the Glossary. Please add missing terms and/or give a more correct/fuller definition of whats there if you can.

[treslumen]

thanks, but i thought qp2p was general for any kind of p2p network, while xor is only for kademlia based networks. so does that mean qp2p is for xor based routing only?

[dirvine]

Right now we are getting it all working and they can be generic later on. Speed to launch beats use by everyone right now. Later it will be generic again, but qp2p is about to be ripped to bits and most of it removed.

[jlpell]

Just finished scanning the last 200 comments… wheww.

I think the perpetual quote concept is rather elegant and kiss. I see a variety of hurdles to making a successful attack on it. A few things to note.

@oetyng

And the only thing you cause is disruption of service, because all users have to fight with you for the bandwidth and their requests will be delayed

Having a quote priority may alleviate this. Older quotes get stored at a lower priority than newer quotes. So the only client that might see a denial of service is the one that sat on their quote for 5 years.

@oetyng

Oh yes it does. What happens when the network is so slow that no-one can upload? Farmers don’t get paid

Not being able to upload is not as big of an issue as not being able to retreive the data.

@dask

The network will eat these ‘losses’.

Another reason why a healthy network buffer of snt that can absorb price volatility is so important imo. The network always needs to have the ability to pay farmers, even if there are no uploads.

@oetyng

The quote is only for specific data

This is a primary mechanism that makes it a very expensive attack imo.

[happybeing]

@jlpell

The network always needs to have the ability to pay farmers, even if there are no uploads.

Farmers are only paid for storing data so a pool doesn’t help this (they are no longer paid on GET, but penalised if they don’t supply what they have been paid to store).

[jlpell]

@happybeing

(they are no longer paid on GET

news to me. That was only supposed to be for a simple testnet. Nothing finalized.

[neo]

@jlpell

news to me. That was only supposed to be for a simple testnet. Nothing finalized.

Yep, that is the current, Yes it was for the testnets, but the other topic showed it is for ongoing and the way forth if testnets shows it works. The new step is whether all the tokens are issued to MAID holder and whats reserved for those wonderful investors who put millions into the project/company or use the original distribution.

[jlpell]

@neo

other topic showed it is for ongoing and the way forth if testnets shows it works

Seems backwards imo. Pay on Get has some wonderful properties. What does it matter if you penalize after they get paid and then leave?

[dirvine]

@jlpell

Pay on Get has some wonderful properties.

It does but also has some complexity and network state. So pay on put works also, but we monitor nodes are responding to Get requests and kill those that are not. So you are really still being paid on usefulness overall.

Nothing set in stone, but pay on put is very similar to pay on Get as long as we check nodes are responding to Get requests and penalise those who don’t.

So pay to Put is nice as it balances with pay to store. Whereas pay on get could be seen as an attack where nodes know the data in a section (they got an Adult in there, so quite easy) and ask for all data on their pals node and so on.