Vault address assignment

In the documentation, it states that Vaults are given a random address upon joining the network. The non-deterministic and random nature of the Vault address is one of the foundations of the security of the network.

I can’t find a reference to the algorithm that is used to assign the address. In the code, it looks like it is currently generated by the Vault itself.

Is there any documentation on how the Vault will get it’s address?

1 Like

Have you checked out the SystemDocs?


Pseudo implementation

This is a simplified process to describe the bare mechanism that underpins the self authentication process.

Creation of an Account

Here we will assume there are two inputs from the user of the system: keyword K, and password W. A salt (S) is also supplied or derived (in a repeatable way) from K and W.

To generate a unique identifier, we hash the concatenation of the keyword and the salt, H(U + S). PBKDF2 (Password Based Key Derivation File) is used here to strengthen any password keys used. This is required as user selected passwords are commonly weak. In this example Account specifies session data, i.e. user details or an index of references to further data.

Store On Network[H(K+S)] Symmetric EncryptPBKDF2[P][S]


Symmetric Decrypt [PBKDF2[P][S]] Get from network[H(K+S)]


Self authentication is for creating user accounts and keys. I am talking about the ID of the node used in the Kademlia routing layer (PMID), which is independent of the user.

Seems like you never got an answer to this. Let’s try to notify @dirvine and @anon86652309.

1 Like

From the system docs :smiley: There are two issues to consider as Dag points out here. One is vault address allocation, but also rank.

Q: How do you disallow vaults to be created off line?

Why couldn’t an attacker work offline to generate a large number of PMID’s (and their associated keys). Then, when a set of PMID’s are found that will make up a valid consensus group, the attacker registers only those Vaults that are required for the attack?

It looks to me like, to protect against a Sybil attack, two requirements are needed:

  1. It must not be possible to generate a valid PMID without the help of the network (which means the ID can’t simply be the hash of it’s key)

  2. A Vault must constantly work as a productive member of the network in order to maintain the validity of it’s PMID
    • Reply•Share ›
    David Irvine Dan Jasek • a day ago
    Yes you have got it :slight_smile:

  3. It must not be possible to generate a valid PMID without the help of the network (which means the ID can’t simply be the hash of it’s key)

A Pmid packet is uploaded and the close members of that group agree a nonce (based on distance to target) and this is added to the packet. This alters where the PMID is then stored and the ID associated with it. We are looking at another mechanism for the nonce which is more verifiable over time, I will update you on that.

  1. A Vault must constantly work as a productive member of the network in order to maintain the validity of it’s PMID

Yes this is where the vault rank comes in, at a certain rank the vault is a passive member of the network and stores only. So poor vaults (and new ones) are not part of the decision making. As rank improves then the decision making


What stops an attacker from rejoining the network over and over until it gets an ID with the desired closeness to it’s target? Especially if the network is relatively small it won’t take that many tries to get a closest address right?

1 Like

First problem is that the attacker would have to know what the address of the target vault is–not a trivial matter.

Next, even if it did manage to know the address of the target vault and continually re-join the network in order to get close, it wouldn’t have a consensus of vaults, so if it tried to do anything out of agreement with the others, it would be marginalized.

Then, even if it were to get a majority of nodes to agree on an untoward action, it could only affect a limited number of chunks, which are also duplicated elsewhere on the network.

That’s even assuming that one could target a data particle that was meaningful to the attacker in some way.

Also, network churn continually changes the interrelationships of the various components, so that an attacker can’t get solid footing in relation to any set of participants.

What protects the system mostly is the broad-based interaction amongst a large number of participant nodes which have very limited ability to know the overall scene, but can only do verifiable actions which other nodes are also doing, and thus vetting. And the underlying data being handled is identified only as an encrypted chunk which would be of little use by itself, even if decrypted.

Out of apparent chaos, comes security.


If you can do it with one, you could do it with many right?

I was concerned about SafeCoin being stolen.

If your vaults are occasionally part of a TransactionManager group you could lie in wait until you see a large SafeCoin transaction coming along. Then you have your user target and your data target?

As I understand it, network ID’s only change on rejoining the network, so if your user target stays logged in long enough, you’d have enough time to rejoin with all your vaults until you have your user target surrounded with a majority. You could take your time to surround yourself first, by just not rejoining the network with the account you want to transfer the stolen SafeCoins to.

I’m probably missing something, I’m just being curious. :wink:

Safecoin transactions are just a specific type of data, handled largely like the other data on the network. I don’t think that one node has enough data to tell what’s going on, even on safecoin transactions, to do much. Also, I believe that the different persona have different groupings (i.e., the transction manager group is not the same as the data managers group, etc.) though I’m not as sure on this. Then, regardless, stealing safecoin will require that you have the private key of the previous owner (like in bitcoin, which is all verified on an open network, except the private keys).

Also, even if the attacker and target don’t go off and on the network, their relationship is not assured. Others entering and leaving the network will change the relationship amongst existing connections. So it’s a standing-on-shakey-ground situation all the time. If an attacker has one close connection, the process of getting another will likely change the relationship of the first and thus drop it off.

The attack vectors get exponentially more difficult in multiple directions with every turn. It’s diabolical, actually.

The worst an attacker could do is confuse things a bit, I think, and end up marginalized.


Due to the nature of how safecoin is setup, every vault will be a part of the consensus group of some amount of safecoin.
If you control all of the consensus groups in a chain responsible for a safecoin, you can steal it.

If it is possible to affect your Vault ID, or if it is possible to register for a very large number of vault ID’s, you will be able to steal safecoins. The question becomes: How much resources will be required to acquire ownership of enough Vault ID’s that at least some of them are in the right place to make up a consensus group.

@dirvine’s post explains that there are mechanisms to ensure the network has a hand in assigning a vault ID, and that a Vault must work as a valuable member of the network for a time before it is capable of being a member of safecoin consensus groups.
These two features ensure that an attacker cannot direct the ID of a vault it created, and that it will take a considerable amount of resources for an attacker to maintain the vaults required to pull off such an attack.

To answer @Seneca’s question. The clever bit is that an attacker cannot determine the exact Vault ID’s required to control a safecoin. Each consensus group within the chain is from a random location in the address space. An attacker could use the network to create a large number of Vault IDs. But the attacker would then have to maintain all of them to the point where their rank is high enough to be responsible for safecoins. The collection of consensus groups in a given safecoin chain will have changed by the time this happens.

So, the short version: Yes, an attacker will be capable of gaining control of a given consensus group, but the resources required to gain control of all the consensus groups in a given safecoin chain will be too great to be feasible.