Thanks to ALL involved in this and every other update.
Amazing to see it all coming together. Keep it up guys, we are almost there and dont waste too much time over the nitpickers and naysayers,
15 Likes
Wow - fantastic progress on many fronts!
Canāt wait to hear @JimCollinsonās ideas for MVP and economic incentives. I think Jimās doing a great job. He has clearly been thinking things through logically, and is open to discussion of various options, so seems like itās in safe hands to me.
Lots of teasers for things to look forward to in the near future, with UTXO details, launch marketing focus & MVP details, and of course seeing how all of the new additions (UTXO, streaming, tweaked payments for storage etc) work on the next test nets!
The pace of progress here is not slow 
18 Likes
Great work once more 
13 Likes
Thx 4 the update Maidsafe devs
Really amazing progress itās all happening @ blackhole speed now.
Kudos to all who participated in RewardNet 
Roadmap: Farming 
Really nice blog post from David
Keep hacking super ants 
13 Likes
Looking forward to Thursdays even more now 
12 Likes
As always, David, your patience (and ability to trim back that patience when appropriate 
) is measured and humble. It is wonderful to see the project getting what seems to be epic traction, technically, and rolling forward inexorably. Itās really something to not only observe but participate in at whatever level.
Cheers!
19 Likes
This is all super positive news and development! What is there to be critical about at this juncture?
Love the whole team but when it comes to market/messaging/presentation specifically, no one is more qualified than Jim, and that includes us lot.
Sit back and watch Maidsafe take the world by storm. 
19 Likes
Could this be explained more? Surely the client would overpay by default, then the node (not the client) would refund (repay) the difference?
3 Likes
After 6 years break 
ā¦ What a pleasure to read! Really insightful, had to re-read to extract everything from this. Thanks, David.
16 Likes
Is economics, everything is possible, from the greedy to the altruistic. We are testing, I see what you are saying, though.
I need to do much more, and hopefully it makes sense.
8 Likes
Does this mean that if clients overpay, nodes could potentially escape the obligation of refunding?
I canāt figure out how a client repaying would work. If the price goes up again, then the number of repay attempts would be unpredictable. This seems like a legitimate concern for a network that is meant to be time-neutral. If the client overpays by default though, then there are only 2 options: the node accepting and giving change, or the node declining.
2 Likes
Yes the current idea is if the price rises then the client pays the increase on top of original. This can repeat till the node accepts. Yes it is technically possible this could be a never ending cycle of increases.
Practically, and even in these tiny test nets, the price does not increase so fast the client cannot successfully pay. As the network gets larger the rate of increasing will be very much slower and when considering these payments are occurring within seconds there should never be a case of needing to pay 2 extra payments. IE practically there will be the occasional case where a client will encounter a price rise between obtaining the quote for the record and the price rises. A rare case where there is 2 price rises between original quote and final payment will only strengthen that 1 extra is the most ever expected.
Key here is the word network which the network of nodes/protocols are not working in time and while the client is part of the network it does have the luxury of having a type of temporal knowledge. It can know how long between asking for the price and when it tries to upload. If it is like days in-between then realistically it should get a new price quote for each record.
These quotes (badly used word in my opinion) here are not the quoting system proposed a long time ago where the quote last forever, it is simply a price check of what the node is charging at the time of request. In essence the client now has to consider that the price it calculates for multiple records may change and I expect if the user requested a price first before actually uploading then the user has to either allow for the potential of some price increase or accept the file may not fully upload. Maybe a price is given with a +/- of 10% stipulation.
This reminds me of the early days of mainframe computing. If we wanted to run jobs then our account had to have money in it and when a job ran we had no knowledge of final costs. How many seconds of CPU time (1960ās/70ās $1/second), how many pages printed, how much tape/drum/disk storage used and all that was not precise and no āquoteā could be had. Basically a guesstimate was all we could hope for.
I guess the safe network will end up being a better than guesstimate and closer to known price with a margin for potential minor increases based on when the upload is done
12 Likes
Yes 100% agree with you here
7 Likes
This would be a great fudge-factor to accommodate the price shift sensitivity. It would ensure flexibility for completing transactions with the price shifting either direction, over the short time needed to execute the storage.
4 Likes
I doubt that this is feasible, or at least doubt itās worth the complexity and overhead in checking that nodes donāt just pocket the whole payment, but do a refund.
I think it will be better for the client to choose a payment based on the price and send that.
If itās accepted, thatās it. If itās rejected the client either stops there or offers more until it is accepted. To reduce the chances of a payment being rejected you can offer a premium, say 5% or 10%, maybe adaptive based on recent attempts.
The higher the premium offered, the more chance that the process completes immediately.
This is simple, no need to check a node does a refund of excess etc, and has a similar effect to the way the fee paid for a bitcoin transaction affects the speed of the transaction.
4 Likes
Iām thinking along the line of, when a node states a price, it is understood that it will accept a payment that is 10% above or below the price it considers appropriate at the moment the payment is received. That way, it simply stores within that range, even if it āquotedā a different price to that client before. If the quotes are soft-edged it allows for grace under fire, so to speak. Sometimes the node will get slightly less than its current price, sometimes more, but either way, itās within acceptable parameters for both parties.
Seems that that would cut down on the instances of needing to have transactions fail and be reattempted on the client side, and allow the node to just do the storage in most cases without producing extra traffic, which is good for everybody. The small percent gain or loss should be rather inconsequential to either side of the transaction, but generate less traffic that a āhard priceā.
Added: This would also act as a governor mechanism to discourage nodes from changing prices a lot suddenly, thus causing more failed stores and additional traffic.
3 Likes
If this is required it has to be checked and enforced which adds complexity and computation.
My point is that it isnāt worth it. Much simpler and just as good for nodes to suggest a price and accept it, or whatever payment comes through if itās likely their group majority will also accept it. Minimal complexity, minimal overhead, and will work just as well.
If I understand correctly, nodes are already incentivised to charge fairly. If they charge too much, they risk not being paid at all and still have to store the data because the enforcement is based on them storing the data of their close group.
If it is the group majority that matters here, nodes are incentivised to accept a payment and not reject it out of hand unless they see the price shift more than they are willing to tolerate, because they expect the rest of their group will do the same.
4 Likes
Agreed, refunds will last all of how long it takes to mod the code to stop it.
My opinion is that the client gets price, pays it along with record and if price increased then pay it if reasonable. As long as the total upload is within reason then the user will just have to accept it. Thats where the client tells the user (if asked) the expected price with the potential variance acceptable. One user might tell the client 10% is fine another user might be willing to lose sometimes and say 0% variance accepted.
My thought (See above) is the client does this using the mechanism current being used and the client is willing to pay more upto some limit. Failed transactions should not be many in even a small live network (prob 100,000 nodes or more) and it should be less than a second to resolve for that record and with parallel uploading this wouldnāt even be noticed for a multi record upload.
EDIT: if node does it then its more work for the node and it will be doing it for multiple clients. Shift as much work as possible to the client for network efficiency.
That would be an advantage, but I wonder how often it would discourage since price rises are typically due to space issues. Also wouldnāt a favourite mod to the client be to pay 10% less always and retry if node rejects it.
3 Likes
I gather this forcing will only happen when another node with the record relocates or when a node in the group dies and the other nodes populate close nodes to hold the records for that group
1 Like
That seems too easy to game. I would suggest nodes only accept exact price or above.
Client can pay exact, and on price change retry with new amount (or ask user what to do). Only risk is a delay.
Client also can overpay to be more likely successful on first try.
3 Likes