I have two proposals to improve the security of the safe network.
The second depends on the premise of the first, so if the first is not seen as desirable the second one has no relevance. I think together these two ideas are potentially better than the current design for vault relocation.
This is quite a confronting proposal (even to me) so all feedback is most welcome and will be taken in the best spirit.
1. Secure Random Relocation
The existing relocation mechanism has several benefits:
Vault relocation ensures resources are periodically moved to different parts of the network, preventing deliberate concentration of resources and thus preventing control of consensus.
Vaults are relocated to the ‘most in need’ section, which helps the network stay healthy where it matters most depending on the current state of the network at the time of relocation.
But the relocation mechanism has several drawbacks:
Vaults are relocated to a neighbouring section which means once the vault is initially located in the network their future possible locations are very restricted .
Vaults are required to brute-force a public key matching their new section prefix, which becomes expontentially more difficult as the section prefix grows. This is liketly to exclude all but the most powerful participants for large networks . This affects the scalability of the network.
The requirement for brute-forcable public keys means targeting a section in order to control consensus is and must always be a viable option.
The initial joining mechanism uses a random piece of data from the section (eg the last block hash) to ensure the new location for the vault is random. This is intended to prevent targeting the initial join to any specific section. However, this leaves an attacker with an amount of time (ie the amount of time between blocks) to brute-force their join to a specific section. This window-between-blocks means more powerful attackers have a better chance of succefully targeting a section than weaker attackers. This drawback of using time-dependent-randomness could be eliminated by using an ‘on demand’ source of randomness rather than ‘historical’ source of randomness.
This proposal aims to mitigate these drawbacks without compromising the benefits.
Vaults should be relocated to a random section on the network rather than to the ‘most needy’ neighbour.
The challenge is ensuring the chosen section is indeed random and not targeted.
One possible proposal that works well within the existing design is to have elders each generate 256 random bits, and then XOR all these values together to get a combined random value V.
If V were to be the new public key, find the new section prefix for that hypothetical key.
Send a request to that section for a relocation of the target vault.
The target vault brute-forces a new public key matching the new section prefix and once complete that vault is relocated to the new random section.
By combining random numbers from all elders there is no way for any single elder to bias the target section. An attacker would need to control all elders in order to control the relocation mechanism, and controlling all elders is extremely difficult, especially when relocation is random rather than neighbourly. This makes the relocation mechanism even more secure than the quorum mechanism, which is itself already extremely secure.
Targeting a section to control consensus becomes much more difficult, needing about 50% of all nodes for random relocation compared to about 5% for neighbourhood relocation + targeting .
Vaults are very evenly distributed through the network due to the statistically even distribution of randomness.
Less coordination between sections is required since there is no need to find the best neighbour. This is especially true when the best neighbour is found via recursion. This means less time required to conduct the relocation, less bandwidth consumption, less computation required since there is no need to measure the suitability of each neighbour.
The vault is not targeted to the ‘most in need’ section within the neighbourhood, which may lead to some sections doing more work or being in worse condition than if they had help targeted toward them in times of need.
A keypair must still be brute-forced which may exclude some participants, especially in large networks. The time taken to brute-force may also delay the relocation which has run-on effects for the smooth operation of the network.
There may be negative implications for connectedness between sections, which is currently proposed to be on a neighbour basis. This proposal may require communication to any other section on the network, which may be more onerous than maintaining neighbourhood connections.
Random relocation solves some problems but leaves others remaining (ie having to brute-force public keys).
The next proposal (HDKeypairs) suggests an efficient means to solving the brute-force issue. It also makes this implementation redundant, removing the need for all elders to agree on a random target. The second proposal is extremely efficient because it a) removes the need to brute-force a public key and b) does not require any cooperation between elders to achieve the desired outcome of random relocation. But it depends on accepting that random relocation is preferable (or at least equal) to neighbourhood relocation.
2. HDKeypairs instead of Keypairs
Relocations on the safe network require the relocating vault to brute-force a public key that matches the destination section prefix chosen by the network. For large networks this requirement can become extremely difficult (approx 30m for a network of 1B nodes ).
This proposal removes the need for brute-force computation and replaces it with an efficient alternative using Hierarchical Deterministic Keypairs (HDKeypairs).
Currently there is no way for the network to take an existing public key and modify it in such a way that the vault can apply the same modification to the corresponding private key. This would be useful since the network could determine the random modification required and the vault would simply apply that modification rather than have to brute-force a private key that matches the modified public key.
This proposal suggests a modification scheme for public keys that can be directly applied to private keys, thus avoiding the need to brute-force the private key.
What is desired is a way to easily pick a new keypair that is known to relocate to a different section, but does not involve sharing the private key.
This can be achieved using the same ideas found in Bitcoin BIP32 HD keys .
The vault derives a HD private / public keypair
For this example, the entropy used to obtain the initial keypair is BIP39 mnemonic
abandon abandon ability. In practice the root HDkeypair would be sourced from any secure entropy.
The root / original hdkey is generated by the vault:
This HDkeypair has corresponding public / private keys which can be used for naming and signing etc .
privkey (WIF encoded here but is regular bits at the lowest level):
The xpub is shared to the network, the xprv is kept secret to the vault.
Upon needing to relocate, the network gives the vault a random derivation depth, for this example 185 is used. This may be sourced any way, eg the last byte of the latest block hash.
The network derives the new HDpubkey from the existing HDpubkey using the random depth 185. This gives the new HDpubkey for the vault to use.
The network derives the new HDpubkey from prior HDpubkey at depth 185, which is
and gives new pubkey
3a (option targeting step). Instead of generating one key at the random depth (eg key 185) the section can generate ten keys starting at the random depth (eg keys 185, 186, 187… 194). The ten sections corresponding to these pubkeys can be checked for their health and the one with the most need for a relocation can be selected.
The vault can use the random derivation depth supplied by the network to derive their new HDprivkey from prior HDprivkey at depth 185, which is
This gives new privkey
The vault also can also derive the same HDpubkey and pubkey as the network.
The vault and the network are both in sync with a new keypair and no need to bruteforce a new private key.
The current section for the vault can locate the matching section for the new public key, then request that section to accept the newly renamed vault. The new section can confirm the randomness of the relocation based on the latest datachain block (or whatever random source is utilised). The vault is immediately able to sign messages for the new public key derived by the network. The public key is not just used to determine the new section prefix, it’s the actual public key the vault must use.
This can be repeated again for the next relocation, continually extending the derivation path with new random depths sourced from the network. The vault and network are traversing a key-tree rather than a sequential set of keys.
The network is never exposed to the private key so retains security.
The vault is not required to brute force a private key that matches a random section prefix so is very fast for both the vault and the network.
Removing the brute-force means performing relocation is constant-time regardless of the size of the network or the computational power of the vault or luck of the find. This improves the equality of participants and removes advantage from having access to greater resources.
The relocation is securely random since the network decides the random portion, not the vault. This means a) there is no ability for the vault to modify or manipulate the result in any way and b) it’s extremely fast to obtain the new keypair in a secure way.
The inability to move far away from the neighbourhood is removed. Vaults may move anywhere in the network and should result in a very even distribution of vaults regardless of how the vault initially attempts to place itself in the network.
The problem in Proposal 1 of the time-between-blocks giving more powerful attackers some advantage over less powerful attackers is now removed. Once the initial HDKeypair is decided there is no way to affect the distribution of possible future keys regardless how much time passes between the random data being known and the join being initiated. Future relocations will be evenly and randomly distributed so there’s no benefit to starting in a particular part of the network.
All existing operations remain as currently designed, eg signing and verifying messages, use of public keys as names, datachain structure and operation, ageing etc.
HDpubkeys need not be stored in blocks. They must be kept in memory for the purpose of deriving future keys, but do not add data to any permanent storage requirements.
Vaults cannot be relocated to the part of the network needing the most help so there may be times where some parts of the network that are less healthy than others.
HDPubkeys are larger than pubkeys (approx 512 vs 256 bits) so have some additional overhead for memory and bandwidth etc compared to plain pubkeys.
Derivation requires some additional computation for the section compared to purely random keys, but is negligible (perhaps even a slight improvement depending on the specific method for obtaining a purely random key).
There may be complications in deciding the new depth to use, especially around the time new blocks are being proposed / finalised. But this complication applies to all consensus operations so this technique would be comparable to most other alternatives.
In theory the depth could be constant without affecting the security, eg 0, but this is something for further discussion.
The design of a BIP32-like mechanism for EdDSA keys has not yet been formalised.
Which is preferable: targeted relocation or random relocation?
On one hand targeted is good because it lets vaults relocate to the place they are most needed by the network (eg to prevent a merge or assist a split or enhance section equality).
On the other hand random is fine because it should balance the network well in a natural and statistical way. ‘Bad health’ should be unlikely and temporary with secure random relocation.
I think further investigation is needed. It requires having an agreed concept of ‘sickness’ or ‘health’ and then seeing how much the targeted relocation mechanism benefits the health vs the cost of brute-force pubkey generation and all that goes with that.
I strongly suspect that the network will rarely become unhealthy, especially with random relocation. I also strongly suspect that the cost of needing to brute-force private keys is not worth the supposed benefits.
I think it’s flawed to measure ‘sickness’ for the purpose of helping via relocation. This implies that enough of the factors of health can be known for the measure to be meaningful. However I think many of the important measures of health are not possible to measure. For example the network can’t know if vaults are coordinating between themselves out-of-channel, or know if an attacker is performing an offline analysis for some kind of unique targeting attacking.
I think having simple but certain mechanisms (in this case HDKeypairs for random relocation) is the safest way to account for unknown variables in the health of the network. I also think random relocation is a more elegant solution than the conditions and meddling of neighbourhood relocation.
I can see the appeal of ‘intervention’ and optimization of the relocations, but to my intuition the risks and costs of being able to make it work are too high compared to the benefit.
 https://safenetforum.org/t/analysing-the-google-attack/18621/63 and https://safenetforum.org/t/analysing-the-google-attack/18621/65
neighbourhood-based relocation means vaults can only ever be reassigned to a very small subset of the network. If an attacker can target one part of the network their vaults are likely to stay concentrated there rather than spread evenly across the network.
 Data Chains - Deeper Dive and following posts
the need for brute-forcing pubkeys and how easy or hard that might be.
note BIP32 operates on ECDSA keys whereas the SAFE network uses EdDSA so the details may need some tweaking. But BIP32 provides an implemented platform upon which the idea can be demonstrated.
tool for working with BIP32 HDKeypairs