Increased complexity leads to increased amounts of bugs.
That’s why it is better to compare testnets with similar amounts of features.
If I remember correctly, previous iteration with similar functionality was crashing after several hours. So this one is definitely better.
7 Likes
Update from a home behind a NAT in Helsinki:
Node is running fine, getting and delivering chunks. Getting rewards as well.
Vdash is reporting a bit more errors now than yesterday. It looks like they all are similar to these two examples:
[2023-09-06T05:59:17.861481Z DEBUG sn_networking::event] ConnectionClosed: outgoing (/ip4/104.131.66.218/tcp/38727/p2p/12D3KooWBDcCE6jMS9swnKoqeUraZvR5gnKURnofvnBgGPrUt7Y6) peer_id=12D3KooWBDcCE6jMS9swnKoqeUraZvR5gnKURnofvnBgGPrUt7Y6 connection_id=ConnectionId(216919) cause=Some(IO(Custom { kind: Other, error: Error(Closed) })) num_established=1
[2023-09-06T05:59:17.878306Z DEBUG sn_networking::event] ConnectionClosed: outgoing (/ip4/104.131.67.44/tcp/41157/p2p/12D3KooWJkcN8ywG22YMqPij3tTBX2MrgNNUGbHfwQ6Q8QnNGm7X) peer_id=12D3KooWJkcN8ywG22YMqPij3tTBX2MrgNNUGbHfwQ6Q8QnNGm7X connection_id=ConnectionId(216918) cause=Some(IO(Custom { kind: Other, error: Error(Closed) })) num_established=1
@Josh’s script reports:
Timestamp: ke syys 06 01:57:56 EDT 2023
Number: 0
Node: 12D3KooWCXJYagGXfHcv3jcxZmq8k8CLUDZ6qaQyreV5JkuQnAvC
PID: 7036
Memory used: 61.4492MB
CPU usage: 3.5%
File descriptors: 1683
Records: 85
Disk usage: 36MB
Rewards balance: 0.000000080
9 Likes
Im seeing a lot more errors on my home internet connection compared to the cloud vps’s im playing with
Cloud node
home node
2 Likes
just been through all my nodes and can confirm all 110 are still running and all have received some rewards for providing resources 
7 Likes
I am wondering that one way to relieve some of the rejects due to price rise happening between getting the quote price and then actually uploading it is to have a system where nodes will accept the quoted price if the current price change is not too much higher.
Basically when the price quote is given the node signs that quote and when the client sends the record to be stored it not only sends the DBC but also sends the quote so that the node can decide if it will honour the quoted price it gave.
In a mature system we don’t expect the price to change over short periods very often. But in a small system or test network the price is almost guaranteed to change often. So this idea is more suited for a more mature network since any price change would typically be very small over short time periods (days to weeks to months)
It would work like this
- client asks price from each node for each chunk.
- client remembers the signed quotes and not just prices asked
- client sends the record to a node with the DBC payment and the signed quote from that node
- node instead of rejecting record simply because its price rose in the mean time, it will evaluate if it will accept the previously quote price or reject it.
- one reason to accept the previous price might be because it is only a small difference
- another is that it is a previous price and accepts it to prevent too many rejections over longer uploading times for the client.
- one reason it might reject is the price difference to too great due to quickly filling up and needs to reject it due to critical space shortage.
- another reason to reject might be its simply been too long even though the price difference is not much (eg too many price changes since quote was given)
I expect that the “official” node code would have a couple of parameters like how many price rises, what price difference is acceptable (maybe a percentage like if quote is 90% of current then OK). Expect that it would require both to accept for the old price to be acceptable. Even these two parameters allow for nodes to allow 1, 2 or more prices rises to occur without rejecting while also having a safety net for the node to not undercut itself if large price hikes had to occur.
6 Likes
That’s in already, see below. But I wonder can’t the quote node gave be seen as a binding contract? Once a node gives the price, it has to store the said file / chunk with that price.
6 Likes
My thing really relies on both working together. So the tolerance is part of the way.
If the node is coded to accept a price quote from a previous price and that previous price could not only be the immediately previous but could also include 2 price rises ago or even 3.
Once that is used then the “tolerance” factor could be increased a lot since the node had to have quoted that price previously (immediate or 2nd or 3rd previously) and not just a client trying to undercut nodes by always sending less than the quote.
IE the tolerance factor allows clients to undercut nodes by the “tolerance amount” and skimp. Eventually this would become a Mod that many install to “cheat the system”. If too many install it then tolerance factor really becomes ineffectual and a joke.
But by using both factors then clients cannot just reduce the amount paid by a tolerance amount but has to have a signed quote showing the node did in fact offer the client that reduced amount and it had to be within 1 (or 2 or 3) price hikes. And the tolerance becomes a safety net for the node in case previous price hike was a lot. (Prob due to available space dropping fast)
1 Like
Yeh, that’s basically what we had in place, and I added an earlier check, but forgot to have this tolerance. There’s a fix in for that now (fix(node): accept fees _near_ our current store cost. by joshuef · Pull Request #710 · maidsafe/safe_network · GitHub).
(The tolerance is currently pretty wide. 50% of whatever we’re asking)
Sending back their own signed quote with the upload feels more robust. I’m not sure it’ll be necesary in the end. This is one of the things we’ll be playing with in coming testnets I suspect.
7 Likes
Experience says it will be very necessary. Just the scenario I outlined will happen, even if I am the only one who does it. Who doesn’t like discounted prices. No need for testnet to find that out and unlikely to happen in a testnet anyhow
4 Likes
I’m talking about the signing here. I’m not convinced that part will be necessary.
Clients are welcome to undercut if that’s accepted… but if the tolerance is set per node eg that will be harder and just be making your uploads slower…
Or nodes can keep their sent costs on a peerid basis in cache… and so the signing might not be necessary.
4 Likes
Thats not so bad. But once people know the prices that would occur then get quote price and pay only an amount that would be lower and on the standard price amount. So really signing is the only real way of knowing if the client is trying to cheat or not.
I feel it would be bad for the ongoing economics if clients can be dishonestly undercutting nodes. And node operators would rightly be upset if this undercutting is done and so easy to do. I’d expect that the node only needs to keep a max of the 2 previous prices, and with the client proving it was offered that previous price then its the fairest for client operator and the node operator while help relieve the record store rejection issue.
2 Likes
Having signed quotes would allow sections to punish nodes that don’t keep their promises. Good thing, no?
Yes, iiuc the quotes need to be time limited to keep the node operators happy, but can’t change too fast to keep clients happy. For example, if a quote could only be valid until a section splits, this may offer a reasonable balance without needing tolerances or fuzzy factors.
The pace of testing is unbelievable! And I remember back in the spring when someone attacked @dirvine that it was another promise that the project would finally start working and there had been so many false starts, etc…
But even then I felt that this was the moment when all the pieces of the puzzle were on the table and it was only a matter of time before the real testing started. 
Great job gentlemen. 
7 Likes
Cooould be. I’m not sure it’s needed over just comparing / tracking what nodes are storing in general though?
And you get into how many quotes to keep track of, or how long something might be considered valid… what happens with churn and responsibility? Feels like it could be can-o-wormsy. But I’m not ruling anything out!
We will be testing out everything we can while keeping it all as simple as possible.
2 Likes
Puzzle only starts coming together.
It is not possible to know yet if all pieces are found or not.
The difference is that earlier network was mostly broken and now it is mostly working.
Present situation can be well described with Pareto principle: already achieved 80% of results correspond to only 20% of all work need to be done.
2 Likes
How does it seem in regards to the aims above?
1 Like
The way I see it is, Maidsafe is near if not at the point where getting the funds to expand the team shouldn’t be hard.
I guess the question is do they want/need a much bigger team?
3 Likes
The question is what “20% part” consists of.
If it is something deep, which requires architectural changes, then more people won’t help much.
If it is just progressing of what is already done, then yes, expansion may help.
Not time but how many price changes have occurred. If no price change for 3 months then no reason the quote couldn’t be valid. But really how many people are going to wait months to upload that record. Maybe in theory
The idea is to not honour a price if the price has changed too many times since. Time is immaterial in this.
Sections do not exist anymore.
Well the node doesn’t need to keep track of any, thats the beauty of this. The node only has to validate that it signed the quote the client is giving it. And only needs to remember the price it charged for the previous 1 or 2 or 3 changes.
If the node churns then it cannot store the record anyhow so it would reject it wouldn’t it.
The thing is, there is someone who has a vision for this project and knows what it takes to make it happen, and that person is @dirvine (and the team).
If you believe in this project, you have to trust someone and assume that they know what they are doing - and if David said in the spring that he saw no more obstacles on the technical side and that all the elements necessary for the network to work were in place, then you have to trust him that this is the case.
In this case, we can see that MaidSafe is going after its own very efficiently.
5 Likes