Consensus 28/32 or 8/8?

And if you read David’s replies it seems as though there is also a “queue” list even before the infant stage. Nothing happens while in the queue and they just wait to become infants. Where as an infant starts proving itself.

Is it (theoretically) possible to change a standard vault’s behaviour (progammed to be ‘good’) to be disruptive, without it losing its elders status?
E.g replace/change the good vault executable by means of reboot or ‘on the fly’.

A couple of bad actors could then put their ‘elder vault-section address’-lists side by side and select only the elder vaults of the sections where they (combined) have more than 1 third of the elders and make only these elder node vaults disruptive.

That is the premise this discussion is based on. And yes its easy enough.

Nothing so difficult. Just a if statement inserted in the code will decide when to act bad. No resets or disruption in the operations of the node.

They don’t get to decide that. The section that a node is allocated to is decided by consensus and a node has no ability to allocate their own address because no one will listen to them if they do.

1 Like

Let me try to be a bit clearer:

That an altered vault executable can be disruptive that is clear to me.
What I mean: imagine someone starts with the default, correct vault executable and wants to change its behaviour when it’s reached elder status: is that possible? Because this means that bad intentions from the start are not a requirement anymore, which gives more possibilities to the (turned) bad actors…

And yes, it is clear to me you can’t decide in which section your vaults and up being.
But I assume you can generate from the vault’s logging an ‘elder vault-section address’-list you have at a certain time and compare this with similar lists of other people and pick the ones you have more than 1/3 together…
Edit: I assume here of course that you can get such an ‘elder vault-section address’-list from vaults with the default, unaltered executable.

An attacker would not do that. They would have their own version that acts good until some trigger causes the code to do bad things to the section. The trigger could simply be a received message from a central source which monitors all the attacking nodes waiting for the right time.

To do as you suggest can cause issue. Like node age halving and potential relocation.

That is what coordination is about. If the attacker adds 20000 nodes then they have to monitor all of them to see when they have enough in a particular section to mount an attack.

The attacker mods to the code can reveal any information that the node works with. Not encrypted blocks etc, but messages between section nodes etc can be revealed to the attacker. Also section address prefix, other node ip addresses and so on.

1 Like

I hope you’re right, I’m just brainstorming.
It can cause issue, but my plan of attack doesn’t need that much preparation or number of vaults.
Also someone can offer a lot of money to get control of a couple of wanted elder nodes…
Am I correct that a vault in a certain section knows the IP addresses of the other section nodes? Then you can try to track the owners of the (elder) vaults of this section and try to ‘convince’ them to turn bad?

2 Likes

Yes this is possible. I’ve not used it but CRIU seems to do this. Someone could easily write a little wrapper around it to make the job as easy as a double click.

Using this tool, you can freeze a running application (or part of it) and checkpoint it as a collection of files on disk. You can then use the files to restore the application and run it exactly as it was during the time of the freeze. With this feature, application live migration, snapshots, remote debugging, and many other things are possible.

2 Likes

Could somebody explain what an ‘attack’ exactly is? Is it somebody stealing safecoins? Sorry for sounding a bit daft…

  • steal safecoins that the section looks after
  • create safecoins for unused safecoin addresses that the section looks after and take them
  • disrupt operations
  • delete/corrupt data
  • and other similar things
4 Likes

I see, so stealing safecoins from a section is ultimately stealing from the whole network? But isnt the whole network in complete consensus anyway? So trying to steal from a section would be pointless? If that makes sense…

1 Like

No. The point of Sections is to split up the network into different parts all looking after their piece of the network.

So each section looks after a section of the XOR address space and consensus is how the section makes decisions on what should be done when requests are made for resources it controls.

4 Likes

The ‘attack’ I was thinking of is managing >= 1/3 number of elder nodes of a section, what means you could disrupt that section. Meaining that you could make that section deliver no or garbage chunks, if I understand correctly.
A more difficult attack is managing > 2/3 of elder nodes of a section (if you haven’t noticed 1/3 + 2/3 = 1…). And I’ve read here that you could control a section in that case and e.g. you could steal safecoin controlled by that section.

3 Likes

Thanks neo & draw, makes sense now. I was always under the impression the WHOLE network was one big autonomous entity. But the different sections are actually what make up this entity, ie speaking to one another. I think.

4 Likes

Could these IP addresses be obfuscated in any way? Something like onion routing? Like that the traffic between elders is passed through a bit younger node, or something like that?

I think not: you could for example get the established connections of the vault be checking the output of a commando like netstat. As a Safe Network client you don’t know exactly where your data will be stored on the network (IP addresses are scrubbed), but that’s not the case here.
Although I don’t know how difficult it is to detect the aged nodes.

Just to summarise, no node can or should be trusted in a distributed network. It is only the consensus of many nodes which can be trusted (assuming the network has not been compromised).

3 Likes

No, IP addresses are always scrubbed.

Nodes only know the xor addresses of other nodes in the network.

1 Like

It could be that I’m mistaken, but in my understanding the vaults (or what I call nodes) in 1 section communicate with each other on ip level, and there is no ‘Safe Network’ persona (client or data manager) ‘between’ them. If there are persona’s (= sections, level higher) involved I understand that you can communicate with only knowing the Xor address. So the nodes in 1 section know each other IP adresses (is that not the routing table that was discussed in the past).

I’ll leave it to somebody who knows the code, but there is a routing table for xor routing, so maybe that’s what you are referring to. It seems an unlikely choice to create a security hole by abandoning xor addresses/routing in any part of the network, so I believe you are mistaken until somebody proves different.

2 Likes

Aware this discussion is based on someone having done that, but was hoping there might be a few more barriers in the way first!
Is it not possible for others communicating with a vault to check that the code is exactly as issued? Or just not desirable? I think I’d sort of assumed this was done as part of PoR.
Intuitively to a non-technical person like me, someone being able to modify the code and still be a trusted vault sounds kind of worrying in these situations! Given there is a direct line of communication, could a bad actor with modified code even distribute malware to other vaults? I presume the nature of the files/communications/programs means this isn’t a possibility, but seems worth asking. Still trying to understand all the ins and outs of the thing, and finding info at every turn in this thread.
(Sorry if these are naive questions)