Node age and relocation

Thanks David, the detail was helpful. Maybe this needs is own topic?

Immediately before becoming an Elder an adult node will be storing a lot, so it doesn’t help if Elders don’t store - you still need to relocate the data of a newly promoted adult.

So ironically, it is better to have Elders store data so they don’t have to distribute all their chunks when an adult becomes an elder.

I think no longer doing relocation after a certain age is a good and secure compromise. It isn’t necessary to relocate all the way until becoming a elder in order to prevent sybil attacks, it is only necessary to relocate enough times to make that impractically expensive. So the key is to ensure that is maintained even as hardware characteristics change.

I think over time it gets harder to target one section due to the increase in number of sections, but other factors may make it easier such as the cost of running a node decreasing for example. That too is double edged because it probably means the attacker has more other nodes to compete with. :crazy_face:

So it may be tricky to make sure the scheme remains robust enough. Time for someone to do the maths! :thinking:

4 Likes

For the attacker, the fee is a small problem unlike Dolores from the Dominican Republic to whom it is a barrier, But if by honeypotting in some way, the node joining process had no fee but took 15 mins or more then we may make mass attacks very difficult but merely a “slight security delay, madam. our apologies” for Dolores…

or something like that… Attackers may well value speed of attack over cost.

1 Like

If you count the long haul as infinite years of trying and a lot of cash at stake then no number is big enough though.

They should get nowhere close to being elders at age 20 when the network has grown reasonably. At the early stage as with all decentralised systems an attack is much simpler.

can then target that section when another of their nodes get there at age 20.

They would have to guess each section of their age all the way from 5->20 and could not target a section in that way.

We looked at this previously too. However Elder churn is the worst for us, it means we probably become and elder in a new section and then DKG plus we have to then demote an Adult (demote is an anti pattern, i.e. it’s not monotonic growth, so makes any crdt like logical clock fail). The other thing is relocating bad nodes together into a new section is very similar to trying to target a section.

Adults on the other hand being locked into a section makes that target very simple. So a vandalism attack can happen easier then. It’s not network takeover, but sabbutage by folk with a smallish amount of cash, if that makes sense?

If elders only store a very small amount of that this may not be an issue. (I would hope)

This is true if we allow clients to directly interact with Adult though (just to keep in mind)

I think elders storing here will not change your thoughts too much, safe to almost ignore that fact iff we keep nodes storage to a minimum. Of course some may feel differently and elders should store much more.

I feel it could for sure.

I feel it has legs. So we mess younger nodes around and cause data relocations, but never demotions and upsetting elders. So less section keys which is good as it keeps section key churn very low or at lest less churn in elders. There is a train of thought that new keys frequently can be more secure, but that’s for another day.

Exactly, there is a lot of this thinking here. So much we think we can change for security actually can remove security where that is through larger numbers of nodes (bigger network should always be more secure than smaller networks)

I think so. Especially motivated rich attackers/vandals may cost in the destruction cost in terms of increasing their own income via some competitor etc.

4 Likes

I missed this succinct explanation of the Sybil attack protection. It’s spot on. It does not need to be infinitely secure over infinite time, but more costly than the cost-benefit of doing that attack is.

The other attack is the vandalism attack, so we have to make untested nodes almost irrelevant until they build enough trust by doing loads of good work and staking their cash.

7 Likes

I don’t like the sound of this. Intentionally complicating the onboarding process, thereby aggravating a substantial number of potential converts, does not seem user friendly to me. I feel simplicity is a necessary ingredient to get the kind of usage we hope for. Requiring a 15-minute investment these days is asking too much, me thinks. Possibly some kind of security slider, at random times, like coinmarketcap.com uses? That doesn’t take much time to solve but it does require a user response that a bot probably could not accomplish.

2 Likes

I haven’t fully considered the DKG churn aspect. If that bad, then yes, this isn’t the right path. Thanks for sharing that datapoint.

4 Likes

I wish I had the technical capability to fork and try remove some key security measures for testing purposes! I’d very curious to try the current network with, say, node age simply declared by nodes. Of course not for public consumption, but would make it very effective (I believe?) to test churn in a distributed, but obviously still controlled testnet! Bamboogarden fund ? :pray:

1 Like