Node Ageing RFC


#41

So at what age is the influence given?


#42

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.


#43

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.


#44

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 https://github.com/dirvine/resource_proof

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.


#45

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.


#46

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.


#47

Good question… I would also be glad to hear an answer :slight_smile:


#48

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


#49

Thank you very much for your answer! :slight_smile:


#50

@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


#51

No, I hope it will be part of data chains part 1 though. So not long.


#52

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. :innocent:


#53

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 :wink: ). 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 :wink: 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.


#54

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 :beers:


#55

Yes!!! Now that’s wtff im talking about :smile: !! Very clear and reassuring. My mind is definitely at ease. :sleeping:

Datachains to me was the last potentially stifling hurdle. Whew!.. From the looks of it though we have it in the bag. :wink: 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 :v: :sunglasses:

Watch in awe others, watch in awe… :smirk: :+1:


#56

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