Evicting vaults - brainstorm


#61

Okay, I didn’t realize there was a ‘baby’ phase that wasn’t able to farm.

But if I can go from senior to child and still farm - then is there no disincentive here? – or no incentive to push to go beyond child? I get that the network will push you beyond child automatically if you are a well behaved node … but if there is no incentive, then this is where I wonder why the baddies wouldn’t care if they got to senior stage, then disrupted something and got kicked back down to child (where they can still farm) - then rinse wash repeat. Perhaps the network can monitor this history as well and start kicking such nodes down to baby instead of child?


#62

But if you stay online for too short then you go from adult (farming) to child (wait to farm) and then if you don’t reach age high enough before turning off then you will be at baby.

We only need people to stay online long enough to farm. They are then helping the network farming and security.

The network decides if a node is doing enough work and farming & node duties are enough to pay the farmer what he/she is worth and that is working.

The node halving is the network ways of dis-incentivising you from turning off, and/or not staying on long enough each time. Why should someone who has earned farming status not be paid for doing the farming (which includes node duties) There is a lot more to being a node than just becoming an elder. There is routing, hop passing on of chunks, caching and these+farming is arguably the most costly for a node to do. Being an elder is more responsibility but also has the advantage that restarting is not going to stop them from farming when they return and if old enough be able to be an elder again.

The incentive is to age far enough so that you don’t loose earning ability when restarting. As I mentioned above the most costly part for a node is farming+node duties and the elder duties while more costly has the advantage that they don’t lose the ability to farm immediately on restart. But if they do it too often (restart) then they won’t last long as elder and haivng immediate farming after restarts,

I don’t think a child can farm. In any case any delays in being able to farm will make it harder for those who restart too often and be on for too long. Those will be babies most of the time since they are continually knocked back to babies.


#63

Is there anywhere I can find algebraic equations that show how this is ‘currently’ supposed to work? As it stands it’s too vague for me and hence impossible for me to analyse how to really improve (if possible) on the status quo.


#64

Not sure. This is being worked on at the moment and alpha 3 will be testing this stuff (not the actual farming obviously since alpha 3)


#65

OK, if you all insist on trying to reason about this :wink: I have a suggestion. If reason is a suitable approach let’s see if we converge on any widely agreed options. So far I’m happiest with this one :laughing:


#66

right … so I would have to look at the repo itself - as they don’t publish the general framework of conditionals, loops, and algebra anywhere. bummer. I’ll have to improve my RUST skills.


#67

I guess I really don’t understand any of this enough to know what is a good option or not. I do like the approach of allowing the network to adjust things in a more fluid way - giving it more of an A.I. system - that way the network can adapt more gracefully to attacks and to changing circumstances. Although I do understand that such A.I. systems are more finicky and take more time to test – and tweak!


#68

I think we need to do that, go slowly with any decision (I know you meant other things, and I am being cheeky) As long as the time scale is very long and most of the time these old nodes will have restarted a few times. That can be a catch all for nodes that never switch off.

Can I suggest that after alpha 3 & 4 testing we will have a lot of data to be able to work with and hopefully give an indication on the direction ageing/tiers would go.


#69

I agree, it feels to me that a lot of this discussion may be cart before the horse speculation. We need data and testnets and clearer understandings of how these testnets are (will be) working.


#70

Sorry Tyler. I swear I read somewhere either on this forum or the dev forum that farming rate was tiered and that higher node age led to higher farming reward rates in order to incentivise 24/7 operation and good behavior… I guess I must be remembering future events again… Hate when that happens! :wink:

Yes, it is an obviously good idea. (IMO)


#71

@Nigel Did you read this comment in the PoS thread? I concluded that I’m against it.

The cost/penalty that I spoke of would have to be denial of a farming reward, after having already invested (time and resources) by running the punished node.

I’m not against bio mimicry in theory, but remember that the attacker can see everything we’re doing. They can just adapt their nodes to take into account whichever strategy we come up with. One can easily make cloud based computing nodes “behave” like home users by disconnecting periodically, or even lowering their network performance.

What you should focus on is on things which are not easy for an attacker to change. For example you can deny attack vectors from large cloud computing platforms by blacklisting the well-known cloud platform IP address ranges, or at least taking source IP into account when calculating consensus privileges. The strategy can also limit the amount of privileged nodes coming from the same IP block, forcing attackers to take more distributed approaches.

Ultimately, an attacker can always resort to mobilizing a consumer botnet against the network. This reinforces the argument against PoS. We may not be able to stop an attacker from mobilizing a large number of nodes, so perhaps we should focus on mobilizing an ever greater number of honest nodes.

We need Guilfoyle and his army of smart fridges! :wink:


#72

Just to state the obvious, but that’s why proof of work/stake/resource are good - they’re not strategies, they’re prerequisites that have a real cost to the attacker.

More evidence IMO that we need a clear simplified code/algebra explanation (wiki!) of the current thinking - it’s too easy to misunderstand/confuse/conflate ideas when we just have a worded explanation.


#73

Sometimes it’s important to re-state the obvious. I totally agree with those.

I’ll also re-state the need to put the attacker’s hat on and think like them. What would an attacker’s resources look like, and how can we make it as unlikely as possible that they reach 1/3 of all nodes?

What do honest nodes look like? How can we simultaneously maximize honest nodes whilst adding friction to dishonest ones?

In other words, what does an army of honest consumer devices have in abundance that an attacker would struggle to replicate? A vast array of unrelated IP addresses is just one example. We need more ideas. GPUs? What else?


#74

I’ve thought of the IP restriction idea before - I use such lists when I download torrents … but I think for the Safe Network those could be a problem - unless they are known black-hat IP ranges. The problem is that attackers can move around too easily - they can switch out VPN’s, the can route traffic through other IP’s - ranges that normal users will be using - so a really hard way to trap them.

IMO, proof of work - especially proof of human work seems the ultimate way - until really A.G.I. comes along, new variable tests that require a human to make a decision can always be used to put the hammer down on those running massive networks. They are a pain for users though. But ultimately if the network comes under fire, using such tests might be a fail-safe.

I’m not opposed to using some of each of proof work/stake/resource as well as some marginally variable farming rate and an adaptive A.I. system to tweak the network as required. I think we are still a long way from being able to really discuss the merits of any of it though as we need to be able to test out these concepts all working together with real people.


#75

Yes agreed; I’ve been using the rfcs and the wiki but it’s inconsistent and outdated. Would be good to have a better resource but safecoin has been near the bottom of the priority list for a long time now with respect to documentation and development.


#76

Yes, I got your point and I like the general idea you proposed for this very reason. My first round responses just focused on the “baddies” problem.

I was also operating under the thought process that eldership brought with it higher farmering/earning rates. If this does NOT end up being the case, then it doesn’t really seem like average joe/jane cares about the voting rights of their node. And since the probabilities hurt ‘goodies’ more than ‘baddies’, there really isn’t a reason to go down this road so we should all just listen to @neo and move on. Although I supposed other higher level network operations, or some yet to be determined network governance structure could use voting mechanisms, for which nodal voting rights get increased value.

However, if increased farming rates are associated with higher nodal age, than it is a different story. People are going to be really concerned (as you have outlined your own concerns) with their ability to compete with nodes having huge early adopter advantage and that essentially become immortals. In that case I think your idea has a lot of merit. At the same time, good immortals (nodes) are good for an immortalized data network too. I do admit that immortalized data via mortal nodes is a bit poetic though, so I have a hard time not brainstorming a little more on this.


#77

Maybe a “google like” “I’m not a robot” on SAFE that the vault owner has to answer to start the vault and once every 1000? datachain blocks and has till the next 500? datachain blocks to answer or be booted.

This would rid the commercialisation of vaults and ruin the dreams of running a thousand vaults. Headerless would not be ideal either since the owner has to respond every week or two.

And I am not serious because I know of the difficulty but it might give someone ideas.


#78

It might need to be a challenge by the node’s group that the user could respond to and the group could verify.

It’s a hard requirement and I hope we don’t have to go down the road in the end.


#79

That was the principle of it.

Yes it would be a pain in the arse.


#80

I’m not convinced this would be good for the network (Also violates the “E is for Everyone” clause…). Yes, we don’t want vault centralization in 2 or 3 or less than 10 hands. However, 1000 to 10000+ large commercial entities spread around the globe with each managing 1000+ vaults on a fiber optic backbone is only going to be good for SAFE. As long as a home user with 1 vault can earn no less than 1/1000th as much as a commercial entity running 1000 vaults, Everyone wins and all is fair… No?