So at what age is the influence given?
as your age increases so does your influence. So the influence increases with age, wich corresponds directly to work done on the network over time.
1 Like
Since you already do work at age 1, but do not have influence, how is it determined? It cannot be x work. Neither can it be x level if it really starts at 1 and not 0.
Work is forwarding and answering requests on the network. As you age you are in longer lasting groups. So the more age the more you have proven.
There is a debate whether nodes aged less than X ever need to get the data and respond to requests, but merely forward messages. This is not concluded yet, but it would mean that nodes not on the network for at least X chrn events could not influence the network until proven.
I like that idea as new nodes are like infants and should be allowed to go on and off while not upsetting the network adversely. New nodes will have done a resource_proof prior to joining. This means they must have “paid” more to join than the network has to “pay” to confirm them onto the network. An example can be found here GitHub - maidsafe/resource_proof: A 'proof' of bandwidth, cpu and storage for nodes in a decentralised network
If you have rust installed then do cargo install resource_proof and play around with that (resource_proof -h). You can see it is a measure of cpu and bandwidth with the possibility of later also testing memory. The values should be network calculated but will probably be set by us initially.
6 Likes
I was thinking about this one. How can we have both relay_nodes that don’t know what a client is doing while at the same time these nodes need to sign stuff. I have still no idea when someone is a relay_node (just a pipe into a group) and when it becomes a full node knowing all that’s going on in a group.
1 Like
A question that rises upon me is: "Do vaults survive when there are network interruptions up to a few minutes and does age gradually decreases?
Does the data survive these interruptions when only the network connection goes down ?
I’m asking this because if some future rulings make some isp to implement connection interrupts every few hour to non-business accounts this would be problematic to run vaults from home.
For more than 2 minutes, yes it would be an issue. It’s all part of the tests though to confirm these parts. Compared with everything else it’s not a difficult issue though. It would require the same IP etc. though as colluding groups cannot be allowed to “sell” vault keys and create groups, so security prevents long pauses. The rules are that such pauses mean that the vault is relocated only on restart and cannot predict it’s new location. Hope that helps
6 Likes
@dirvine is node aging already part of the preliminary test 17? I was under the impression it was coming later, just to like to have my finger on the pulse so I can give good (but not overpromising) info
1 Like
No, I hope it will be part of data chains part 1 though. So not long.
2 Likes
Sorry to bother @dirvine . Is there any progress report on the viability of option B? Have other options manifested from ongoing internal meetings?
Is the implementation phase immanent or is more testing needed? If yes then what kind of testing and how much more before coding is in full swing for datachains pt1?
Sorry for all the questions but it’s been a while since the last detailed mention of datachains. 
1 Like
Option B is now the only option really, simulations have been done and shown it to work. I personally feel it’s way better and uses eventual consistency, which is what the network is (and so is real life 
). I did not wish to say too much previously but locking sequential solutions like option A are very unnatural and have way too many edge effects in real life, sounds great in papers as it’s easier to reason about, however “easy to reason about” is not maidsafe The code used to simulate should be the code we use in routing, we are not certain how much will be able to cut across, but hope that a lot can.
It’s gonna cause confusion soon though as Alpha 3 will be datachains part 1, that means the network secures, however not data (that’s part 2), so alpha 3 will be showing the network, but not the data, so will likely run parallel to alpha 2. Alpha 4 will have data chains part 2 and be pretty much vaults from home, secured and hopefully resistant to spam, however we do need to consider initial network size. When safecoin is in place this spam nonsense will be to costly in most situations though. It’s caused us too much extra effort to try and keep the community involved while building the network. Without al the bit’s it cannot be secured and stable while resistant to attack. We do the extra work though as we feel it’s worth it, but it’s a terrible pity we have to take these side tracks from just launch. All in all it’s worth the hassle though.
12 Likes
It is a pity but on the bright side we got through a lot of testnets without too many trouble makers. Here’s to being back on track 
4 Likes
Yes!!! Now that’s wtff im talking about 
!! Very clear and reassuring. My mind is definitely at ease. 
Datachains to me was the last potentially stifling hurdle. Whew!.. From the looks of it though we have it in the bag. Excellent work @maidsafe !!! Time to slap those remaining bolts on this beast and let it rip!
Can maidsafe deliver? That’s a resounding YES!!!
All of those behemoth parts have been independently tested and proven to work now its just a matter of time before they are robustly stitched together. Note that the Tor project is only now modularizing ALL of their code. Something that you @maidsafe have been doing since the jump. Like a bouse 
Watch in awe others, watch in awe… 
3 Likes
All I have to say Iam proud I learned alot today and this the process of being in the top 10%. Look forward to this EU project coming up cheers
1 Like
Age is surprisingly quite limited in range.
Age increments at an exponentially slower rate, incrementing after roughly double the previous amount of time [0]. This is described in RFC0045 Node Ageing.
For example, if a node starts at age 1 and then after 1 hour is age 2, it would take double that ie 2 hours to reach age 3, double again ie 4 hours to reach age 4, 8 hours to reach age 5, 16h to reach age 6 etc.
If we extrapolate this and work with accumulated time, we end up with age 7 coming after 5 days and age 17 coming after 15 years. Age 20 happens after 120 years.
So virtually all age will be roughly within the range 7-20.
Is it more useful to have a broader spread of age? Would a linear rather than exponential period for age increment be more useful? Considering that age is used to determine elders and to determine reward portions, it seems to me that exponential change maybe is losing too much information for no real need…? Age is a u8 (source) so can be 0-255 but in reality would probably only span a range of about 20 values.
Considering changing adoption rate over the lifetime of the network and section splits etc I appreciate this can get very complex to analyse, so I’d be interested to hear other thoughts about it.
[0] Ageing is event driven rather than time driven but I use the term interchangeably since all nodes see progress in the same way, so it doesn’t matter that the rate of events will vary against a wall clock in real life; substitute ‘years’ for ‘approx 2^n events’ if it’s bothersome.
3 Likes
Part of this has to do with trust psychology. If a node has been trustworthy for x amount of time, then we presume it is reasonable to assume that it will continue to be trustworthy for x more time. As you pointed out, the 255 levels used in the current node aging rfc are essentially a relative scaling/thresholding of the actual node age in terms of network events.
If you wanted a more linear measure to compare the expected trustworthiness of nodes then you could use the actual node age in terms of network event counts since the node came online.
I believe you would need to use a u256 to represent the same max number of network events currently represented by the u8.
5 Likes
Age is one factor… but how many nodes will age?.. I wonder rare providers do not blip in ways that see ip updated. The honorable node might suffer the good but occasionally reset ip address… some signed authentication of nodes might help fix that difference? 
I don’t read at the level of detail to know if nodes have a UUID, which will support then return to network after short time… though perhaps time is a problem on a network that doesn’t know time.
(One of the most exciting features might be a network that can recover, and perhaps nodes that acknowledge the newest that they have visibility of would be a route to rebooting… a never event perhaps but always be prepared. Strange occurrences might occur where regions and countries go offline for a time and recovering from that is important)
4 Likes
They do have a UUID and can return in a short time and not be noticed to have gone if fast enough return and they have mapped the same ports etc. The duration is based on churn events/ like age. So a busy network might not take you back, but a quiet one may.
9 Likes
Can we have a range for short time. milliSecs, Seconds, minutes, hours?
4 Likes
Its event driven and will change in relationship to network churn, but seconds to minutes generally. Should be enough to upgrade and restart though.
8 Likes