Brainstorm - The Network on the offensive


#21

I didn’t know this either! Very cool. Is this in the RFC??


#22

I’m new to this coin, but I still think these are interesting ideas so I’ll try to toss some thoughts in.

What if the lying was a glitch and not intentional? Like if hardware or software was acting up or some troll finds out about the lying = ignore thing and made a virus to kill nodes by making them lie or appear to lie?

Is it really needed to lie to them about their status?

It sounds to me that the lie would sow confusion between legitimate nodes having an error where their votes aren’t heard and bad actors calling for help. Knowing the truth about your age also could help bad actors out themselves when they go into support and ask why the node has “Benjamin Button Syndrome”- it keeps getting younger!

If someone is willing to make their node lie, is it a good idea to let them keep donating resources? They may have other malicious means on their systems if they are forcing a node to lie. Just a thought.

…but only nodes that aren’t de-aged may be tested or do the testing. Random aging up of a lying node wouldn’t be helpful.

That may create a shadow network of nothing but lying nodes and spam if there are enough shadow-zoned nodes at once. Also if it’s all just sent to a quiet corner that corner won’t be quiet for long. There’s also the chance someone legitimate may end up in that “quiet corner” and be stuck in the mess. Either way I don’t think that would be a good idea.

Is it possible to just silently dead-end them instead? Have the system ignore them entirely instead of redirecting it anywhere without letting them know it’s not going anywhere.


#23

Its been around for a long time in the thinking. Not sure of the RFC its in, but its been mentioned a few times

For example

Another one where a node goes bad because it doesn’t update


#24

There would be a metric used and bad nodes have to exhibit the sort of behaviour different to just a few communication problems.

But if a otherwise good node is not able to perform satisfactorily then its is going to hurt the network and should be removed. And its up to the person to fix the problems.

That is what will be happening from all indications of the discussions from the dev team.

It’ll prob take a little time for the bad actor node to realise that it is no longer a part of any section. Then it has to restart and go through the whole new node process again.


#25

It’s good to know there will be metrics used for differentiation.

If the node is otherwise good, just not performing satisfactorily, perhaps a warning and a pause would be in order? This could rescue an otherwise helpful node. If they don’t get better then they could stay out until they get better. Nodes that don’t improve stay out.


#26

How? People are not going to be watching their vaults since it would be a background task.

How the metrics are worked out would likely be dynamic since there will be adults available to take over the functions of the badly performing node. Its a balance between the network needs at the time and satisfying the people who supply the resources.


#27

From RFC-0045 Node Ageing

Relocating a node - “If a node cannot join in time then it will require to start on the network again at age 0.”

Subsequently joining the network - “On restart the node will join the network at it’s last known group. … then it [the last known section] sends a JoinRequest to D [the new section] on behalf of this node with the nodes existing correct age/2 (the age in the datachain divided by 2).”


#28

But the question was about removing bad actor nodes being in the rfc to back up what has been said in the forum by David.


#29

If the user supplies contact information perhaps the vault itself could contact them. Maybe an email, a popup window on the system hosting the vault, or something sent via the Maidsafe network itself via their Maidsafe browser would work? I know incorrect or blank contact information would possibly stop this, but it’s better than not knowing at all if something fixable has gone wrong.

It would be a message saying something like “Your vault (vault identifier here if applicable) is having an error. Your vault is on pause and will not be active until it is fixed. Please check on your vault and fix the problem so it can be re-activated.”

Going into your vault would bring up a list of what is wrong and links to find out how to fix it.

Rough Idea of how it would work:

  1. User makes a new vault and puts in some contact information for the vault to use.
  2. The vault is activated, but something goes wrong.
  3. The network “pauses” the vault by removing it from the system. It notifies the vault it has been paused.
  4. The vault uses the contact information to contact the vault owner. The vault remains offline otherwise.
  5. Vault owner finds out the vault needs maintenance and fixes their vault.
  6. Vault owner attempts to re-connect the vault to the network. This must be done manually!
  7. The network checks the vault.
  8. If it is OK, it is back online. If not, it repeats the “something went wrong” steps.

#30

I see what you are doing here. Vaults are just programs like any other. It can be linked to external (outside of SAFE) contact operations. That is the same way attackers coordinate. Everything you wonder about regarding out of band communication is possible. Having the network delay punishment might pose a problem though.


#31

I’m glad you see what I’m thinking about connecting to external operations.

Speaking of attackers coordinating, I noticed a loophole. To prevent a clever troll from exploiting the vault’s “you have an error” message system there should be an enforced wait period between message sendings and a limited number of messages that can be sent in a time period. Between the two it should be hard to make the vault spam anything.

The pause is basically a light punishment that doubles as a security measure. Being off the network removes potential threats as well as any chance of the vault owner gaining anything. If you have ever had to debug a program that is spazzing out you might also say being forced to fix your program can also be a punishment, but that might be just me. :wink:

The vault could even double-check itself before trying to go online for the “is it fixed?” test. It would throw an error if it’s still not fixed (or nothing has changed) and not even bother with trying the network. I know self-checking like that can get advanced so I understand if it’s not feasible. If possible, though, it would further punish those who think they can just ignore the message and try again by forcing them to fix things or go away.

Delaying harsher punishment will encourage more people to stay on the system. If the vault can be fixed and brought back online the population will naturally stay higher than if the vault is swiftly blacklisted/reset/banned/whatever. It also sounds less scary to newbies to hear “Pause, fix ,and come back” which may help with adoption.

Delaying harsher punishment also should cause some heartache to those who would try to attack Maidsafe by creating a virus that causes a vault to behave badly. If there is a means to exploit a safety measure in order to harm unsuspecting people, jerks will try to exploit it. Swift harsh punishments may be higher security, but they also can be more exploitable.


#32

What about ignoring them but not at the system level? A bit hard to imagine the details of this but at the broad conceptual level every vault keeps a local hierarchy of who they trust the most based on reliability etc, and they prioritise their incoming / outgoing gossip based on that. If a peer falls below a locally defined threshold they are deemed (locally only) as untrustworthy. The result is the vault may not forward gossip received from untrusted vaults, and may not send new gossip to untrusted vaults. The vault prefers to gossip with the most trusted peers so it should be a self-reinforcing mechanism.

This should not damage consensus so long as >2/3 vaults are locally trusted. There are no punishments, just a decline in activity to untrusted vaults. Also note this does not change who the vault considers to be elders etc, everyone still sees and agrees on the same network structure, so an untrusted elder is still considered by everyone to be an elder.

Even if the trust hierarchy for each vault is different it should work. It results in untrusted nodes becoming gradually worse laggards on the gossip graph, and if enough vaults locally distrust a vault it will become so far behind on the gossip it will be marked as misbehaving using normal verifiable ‘global’ misbehaviour rules (eg announcing a block that isn’t based on a valid history because they’re too far behind).

I shy away from the difficult logistics of announcing and enforcing punishments as a group. It would need some counterbalance to avoid constant requests for punishment, and the counterbalance is just more ‘punishment gossip’.

This does not replace enforceable punishments. If a vault signs and forwards invalid gossip it can be removed since it’s identifiable and verifiable bad behaviour. But for the types of misbehaviour which cannot be proven, I think that should only be enforced at the local level (but with eventual global consequence).

Neighbour Audit Request

How about a mechanism where if a group of vaults think their section is compromised they can request a neighbouring section to do an audit (maybe pay them in safecoin to perform it so it has to be worth the while of the requesters)? I haven’t got a good idea what the audit looks like but the idea of ‘punishing misbehaviour’ seems intimate with the idea of ‘audit’.

What does an audit look like? How is an audit initiated? Who has authority over the process? What are the inputs? What are the outputs? How are the outputs converted to pass / fail conditions? What consequences befall those who fail? Who has authority to enforce the consequences? Lots of tough questions.

I’m not sure if there can be an effective mechanism for this sort of ‘special’ audit. Audit should probably be inherent to the default network functions and be continuous.

Precedence

How does bitcoin manage misbehaviour? Mainly using the concept of banscore threshold to locally ignore misbehaving nodes (for some local definition of ‘misbehaving’).

This is a good definition / idea but it does not remove the concern that ‘passing a test now’ does not mean the vault will be trustworthy in the future. Switching trustworthiness is costless instant and secret.


My general feeling on the network attacking / testing vaults is it’s probably best not to encode it into the network layer, but try to keep it local as much as possible with ‘natural’ effects coming from that local action. A bit like the idea of ‘dumb pipes’.