6 Likes
Eheh, could resist and installed client 0.80.49. Good to see the 30s limbo gone, lol. Much faster connecting to the network.
Obviously the testnet nodes (not updated) are still missing some required implementation:
Not enough store cost quotes returned from the network to ensure a valid fee is paid.
6 Likes
yep - confirmed – now get told about errors MUCH faster 
willie@gagarin:~/projects/maidsafe/safe_network/target$ SN_LOG=all time /usr/local/bin/safe --log-output-dest data-dir files upload /fgfs/Aircraft/A320-family/
Logging to directory: "/home/willie/.local/share/safe/client/logs"
Using SN_LOG=all
Built with git version: 2110694 / main / 2110694
Instantiating a SAFE client...
🔗 Connected to the Network Loaded wallet from "/home/willie/.local/share/safe/client/wallet" with balance Token(99999948658)
Preparing (chunking) files at '/fgfs/Aircraft/A320-family/'...
Making payment for 4608 Chunks that belong to 976 file/s.
Error: Failed to send tokens due to Network Error Not enough store cost quotes returned from the network to ensure a valid fee is paid.
Location:
sn_cli/src/subcommands/wallet.rs:305:26
Command exited with non-zero status 1
56.93user 4.09system 0:30.91elapsed 197%CPU (0avgtext+0avgdata 1422224maxresident)k
2043552inputs+3008outputs (0major+400843minor)pagefaults 0swaps
4 Likes
It’s going to look like this:
- each chunk will get a store cost from those holders (not like atm, where it’s a bad guestimate)
- From the 8 returns, it will pay the cheapest 5 (if CLOSE_GROUP is 8; and this is the absolute mininum, it may be wise to pay 6 eg, could be user configurable)
- So you may get lucky and hit a fresh node for a price, and one of your CLOSE_GROUP payments is cheaper (for one Record).
- But, with replication etc ongoing, they’ll fill up fast. Probably making the quote actually out of date prettty fast.
11 Likes
Muchas Gracias Señor
4 Likes
Is finer staging of increments planned, or is doubling somehow not a problem for pricing data storage? It seems drastic and impossible for a market to function if price can only half or double!
I expect I’m missing something in my understanding of this comment.
5 Likes
Refining it all is planned. This is only the beginning. 100 steps are arbitrary. It may be 100 / YourCustomNodeSize eg, in which case you’ll get different increments. Or it could be finer. More steps makes it more difficult for clients to hit the right price, perhaps.
Plus, it’s an average over all the close group, so the final price could be somewhere in between (as things stand).
We’ve options. We’re getting in a floor and will be improving things from there 
9 Likes
Going to bring this down now. We’ve got a good deal under out belt from this. Thanks everyone!
11 Likes
So that was ThePriceIsRightNet. When can we expect BullseyeNet? Or BlanketyBlankNet?
Sorry.
6 Likes
Strictly come vaulting
6 Likes
Looking forward to NatNoProblemNet 
6 Likes
LOL at 62 steps you are charging the whole 2^32 SNT (well a tad more)
Yea doubling each time will not work long term me thinks LOL
Just as refresher that from my understanding of the original concept of charging more as node fills was to have very slow rises till it reaches a certain point and increasing rises as it fills because of a inverse factor in the equation, basically rises faster and faster as the free space dwindles. Along the lines of 100/%free and this means you are only charging double at 1/2 full, 3 times at 1/3 free, 10 times at 10% free, 100 times at 1% free.
if you wanted faster increase then 10000/(%free^2), 4 times at 1/2 full, 100 times at 10%.
This way only when the free space is less than around 20% is the price starting to rise dramatically and also means that for normal operation the nodes will have similar pricing. When space is getting low then the brakes are put on by quickly increasing price.
I have assumed that free space refers to the situation where full means a certain amount of allocated storage. Full currently is 1/2 of allocated storage.
1 Like
Really depends on how we step it in this approach. As you note, we want price to go up as space decreases. The first impl certainly does that 
We could have larger steps or vary when we step but keep the doubling so as we have less space, we have more steps and a higher price eg. (Basically what you outline).
I think aiming to ask for all the money for a last record isn’t a bad aim. We do not want full nodes. (full of relevant data), so we want to have encouraged folk to join well before that)
8 Likes
The use of an inverse function seems to fairer for all since the increase increases faster than doubling when free space is approaching critical, and inverse function give the near infinite price for last record.
Perhaps more importantly while the network is running between 0 and 66% full the pricing only varies by a very small amount between nodes. Much happier “customer” base and more predictable with less sudden rises where the node increases prices on the client during upload. Only as space gets less available (eg 30% and less) does the price dramatically start to increase.
It also encourages quick running up of new nodes.
Whomever did the initial function for the pricing seems to have hit on the money and just tweaking is needed. Although I know the project is in good hands and a even better function will be devised.
6 Likes
Yeh, that’s just in. We’ve a base level in, and with you and others looking at this I think we’ll get to something sound relatively quickly
11 Likes