Consensus 28/32 or 8/8?

[happybeing]

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.

[david-beinn]

@neo

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.

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)

[thc]

@david-beinn

someone being able to modify the code and still be a trusted vault sounds kind of worrying in these situations!

If the code was closed source, so that only executables were distributed, you would feel safer, but you would only be safer from script-kiddies. It would be possible for the executable to be studied, reverse engineered, modified by skilled programmers, and the modified version used to join the network. So your feelings of safety would be misplaced.

SAFE code is open source, so anybody can get the source code, modify it slightly, compile it, and join the network. This may seem less safe to you, but it does two things. It let’s you (and computer security experts) easily audit what the code that you are running on your computer is actually doing. It also forces the network developers to design the network assuming that many of the participants are hostile. Designing with this assumption is the much safer option.

[Traktion]

@draw

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,

@dirvine

An important issue for very large sections is connectivity. A node cannot maintain much more than 100 active connections

I think that answers your question with agreement?

Edit: or maybe not… I suppose they could be proxy connections via a node outside the section. I seem to remember that being mentioned, but I thought that may have been related to user requests?

[dirvine]

@Traktion

I think that answers your question with agreement?

Proxy really only applies to

1. A client
2. A joining node

Then the network of vaults establishes. So every vault knows it’s sections/groups IP:port and its neighbors IP:port. Clients go through a proxy the whole time and their IP is scrubbed on hop 1. Vaults IP is scrubbed on hop 1 as well, but they do communicate directly with each other via IP:port (encrypted communications though).

[happybeing]

Apologies @draw, it appears you are correct and that IP addresses are known within a section.

[riddim]

side node - i came back to the chained section thing … but because somehow i didn’t get the calculations right i just went with the monte-carlo-simulation (2000 sections - 8 elders per section … )

because a simulation run with a couple hundred rounds is relatively time-consuming i did only take 500 here

he re-check is just super-simple an extension of the standard-monte-carlo where the algorithm checks if the one randomly selected other section is in control too

22/32 with 100k sections will follow …probably tomorrow xD …

here we go (no time so only graph)

EDIT: i added a simulation for 3 chained groups just show that the effectivity of chaining sections decreases rapidly with the number of chained sections

[oetyng]

@riddim

sure you need to consider the effects of having a large global network and there comes benefits with it (and the statistical fluctuations that come with size) … but when do you think this will be reality? how long do you plan on ‘supporting the network’ ? And when the network is global and a thing … Don’t you think the network might have new enemies that have some additional financial resources? Oo america pays more than 50 billion each year for their secret services … europe pays 80 billion each month

My statement has nothing to do with lowering requirement on an established network.
And setting other rules is not the same as supporting the network.

All I am saying is that rules can be dynamic based on network phase/size. They don’t have to be same for all phases and sizes.
So it’s about not requiring same rules for widely different conditions.
In several other topics the answer to questions about robustness have been “comes with numbers”. And in that light, the challenges of the infant state of the network, a rare occasion, might be better solved by other rules.

[digipl]

Curious Whitepaper about trust mechanisms to a Kademlia P2P Network.

Basically it deals with the same problems that Safe has to solve. The biggest difference is in the structure, carried out by Safe, with the disjoin sections.

Most proposed solutions are already implemented in Safe but it is a very interesting reading.

Dissertation_Kohnen.pdf

[mav]

@riddim

i “chained 2 groups” (so it’s not only enough to have the majority in one group - but you need 5/8 in another group as well [that you can’t decide on and the network selects for you] where you’d need a majority too to do bad stuff …)

I agree this increases security but I have some thoughts about barriers for implementation.

• Ideally security should be fungible, data should be fungible. Safecoin should not have ‘special’ rules for security (in this case chained group security). I’ve assumed the chaining mechanism is only applied to safecoin. If it’s for all data this point does not apply.

• The non-chunk / non-xor-named / non-section-prefix-matching data stored by vaults is going to become bigger. For example, datachains are not kept as chunks on the network, they are ‘magical background data’ stored by each vault. With chained group security each vault also has to track ‘magical background data’ for chained verification. How far does this go? I think vaults should be focused on their chunks, not ‘other stuff’, and the chained group idea is a step in the wrong direction from a data perspective. This affects merges and splits especially since there is special non-xor-named vault and section state that must be managed alongside xor-named chunks.

• It makes the idea of a section slightly broken. Who is in charge of the data now? It’s two sections. That means that the number of effective sections is reduced, instead creating psuedosections of combined real+chained sections. It’s still better than blockchain but imo it breaks the benefit and conceptual perimeter of a section.

I’m generally in favour of sections being held accountable by another section to increase security, but the design is pretty important to maintain fungibility of data, sections and security. And overall performance.

We all intuitively know what accountability is, but it’s worth reading the wikipedia about it since it contains some very strong structural guides about how to achieve it. https://en.wikipedia.org/wiki/Accountability

In particular for this case “the expectation of account-giving” is important for state management beyond end-user data.