@neo, thanks for the clarification; I had a feeling something wasn’t quite right with my understanding and you pinpointed it exactly.
@nice, I agree the code is moving really fast and until it settles down the work maintaining this would be more than the benefit it produces. Perhaps in the future it will be a good project, but for now it’s too unstable.
@smacz, as I progress on this project I’m finding the same thing as you - I find I’m writing disorganized and incomplete content. I think that’s a good reason to keep the work private for now, rather than publicize it and add to the confusion and noise that legacy documentation already creates. Reminds me of the xkcd about standards.
Having spent more time reading the wiki, rfcs, and readmes I think I’ll put this idea on the backburner for now. The concept is a good one, but the value:maintenance ratio is a bit low for me to pursue it.
I’ll definitely look into contributing to the wiki, but in the meantime will keep growing my knowledge and trying to create useful explanations from what I learn.
Here’s another explanation I worked on, but will be the last one I post until I pick this up later (possibly much later).
Attacking the network via the vault naming mechanism
An attacker that wants to modify or control data will try to minimize the distance between their vaults to gain control of consensus, so it’s important to understand how they can (or can’t) do that.
The vault name is the only variable in calculating distance to other vaults to form a close group, so this is where the attacker will focus their efforts. The name for a vault is generated by the following steps (outlined in fairly plain language in this long comment):
- The vault chooses a name for itself. See L124
- The network sends this new name back to the vault. Source code
- The vault must use this new name. Source code. Note the new node will not be added to the network unless it uses the new name. Source code
The third point is what makes it so difficult for an attacker to gain a foothold. It’s extremely difficult to predict the final name the network will issue, which ultimately means it’s extremely difficult to form a group of close nodes on the network.
The following topics are ones I planned to work on (I’m sure it’s not a complete list). The topics are ordered in roughly the lifecycle of the network
- Network bootstrapping
- Joining the network
- Initial connection (vault and client)
- Vault name allocation
- Client registration
- Client authentication
- Obtaining personas from the network
- Storing data
- Client upload and self-encryption
- Public vs Private data
- Mutable vs Immutable data
- Coordination between personas
- Vault consensus
- Handling client change-of-details
- Retrieving data
- Issued by authority
- Proof of resource
- New coin name / farm attempt
- Client balance
- Privacy and anonymity
- Monetary policy
- Converting from presale to safecoin
- Race conditions and propogation conflicts
- Brute force logins
- Manipulating vault naming to override consensus
- Ranking algorithm
- Bribing or hacking nodes to control close groups
- OS environment interacting with safe code
- Modifying the supplier of the software
- downloaded files
- verification signatures