Minimum Number of Nodes before going live



I have tried to search for some answer to this question but cannot find it. Hence this thread.

I think, based on my readings on this forum, before the network goes live - there will be the introduction of testsafecoin - multiple instances of it I guess - and these testsafecoins will be on test nets - or beta - people can add nodes and farming will be tested etc.

Then one day, after a lot of stress tests and all - maid developers will announce that the Safe Net is live - or perhaps they will reset everything and then announce Safe Net is live - it’s really confusing and an update to this matter will be appreciated. This is what I could find in October.

Everyone agrees security of SAFE Net increases with the number of nodes - and that the Network is at its most vulnerable in the beginning stage

Is there a minimum number of nodes requirement before going live?

If network is most vulnerable in the beginning, and it becomes increasingly expensive to attack it as it grows - shouldn’t there be a minimum number of nodes that should be on the Beta - before the SAFE Net is declared live - this way, the network will attain a higher chance of success in the beginning.

Because the cost of attacking SAFE Net becomes increasingly prohibitive as it increases in size, so going live like at say 1000 nodes is just less secure as say going live with a million nodes.

What does the community thinks regarding having a minimum number of nodes in the network before going live?



And to add - most likely in a beta release. (inbetween each alpha and each beta there will be testnets)

Additionally when testing shows testsafecoin and the network are in the release candidate stages the testsafecoin will continue and be the real safecoin (most likely situation, but not certain)

Yes this is the most likely and has been suggested as the way its going.

The reason why there is not an update stating this is because it is uncertain and to make a definite announcement is fraught with hidden dangers. The dev team don’t know if during the beta tests with testsafecoin that a particular bug that they might have been chasing (and one that would prevent final release) requires the network to be reset when fixed.

So as good manners they do the sensible thing and suggest the path they wish to take without stating it as the definite path.

This is an interesting question.

For the network to exist it seems that you only need a small number of nodes (around 8-16)

For the network to have reasonable security against attacks, well that is unknown at this time and testing will reveal the tipping point. Some of the current development impacts on this in a large way and the results of the upcoming tests may give us a good understanding of the actual number needed.

That is a reasonable analysis of where we are at the moment. But with data chains and other development at the moment may make this much better in required numbers.

This current (security & more) development was always going happen, just that the attacks on the last testnets meant that the dev team decided to implement a certain amount of them before releasing any more testnets.

I’d say with the current situation we need a minimum of 10,000 nodes and maybe 50,000
With the current round of development finished maybe 5,000 to 20,000 nodes.

I’d also say that we need to have the knowledge that the final release candidates may still need a network reset if an attack is successful before the network is large enough to resist such an attack.

Also we know that Maidsafe will be starting the networks with a set of nodes that they run up into a network before releasing that network. This way we can have a good number of nodes running before announcing it. This should assist in resisting attacks that occur from the start.


Another hooray for @neo, my personal hero in this forum, for answering everybody’s questions, be it from a newcomer or a seasoned maidsafer, always with so much diligence, precision and selflessness !

I wish in my 3 years here I had become that knowledgeable, but I am so glad I can rely on you to remember the big and small picture, and also get new outlooks on the project.


Thank you Neo for your answer.

Are you aware what happens in the case of a reset? Do we lose our Safe coins due to the network reset (I mean every record of network is erased, like a reset of everything) or just the data that was stored on the malicious nodes (all 4 copies) will be gone?


A full reset would be everything, but since they are just testsafecoins at that time it is only a minor loss to enable a secure network.

Now depending on the attack and the results of the attack and perhaps the code change or bug fix needed will determine the kind of reset required (lose some data/all data). Without knowing the future and what the bug/attack is means I cannot give more than I’ve said.

The point really was that until the network is live we have to prepare ourselves that a reset may still be necessary and data persistence is not guaranteed until a live network is declared.


Thanks Neo - I was talking about the live version of SAFE net, especially in its early stage with low number of nodes - what’s been bothering me about SAFE net is the possibility of a successful sybil attack in the beginning after it is live, let’s say when SAFE Net is at 20k nodes

A sybil attack at this point will require around 5 million (my own calculation: lets say introducing 250k nodes over a period of two months so that nodes are well aged etc - cost of running one such node will not be more than $10 - obviously the attacker won’t be able to steal any data or SAFE coins but I think they might be able to jam the network or just take all nodes offline suddenly to shock system)

If there is no minimum number of nodes before network goes live (like lets say 100k nodes so that the costs are really exorbitant) - then the only saving grace is that SAFE network can be resurrected - I was talking from this perspective - will this resurrection of SAFE Network - after lets say 85% of its nodes have gone suddenly offline or malicious - will this resurrected version of SAFE Net be a reset version where some data is lost forever and some SAFE coins are lost - or will the resurrection be such that there is no change to SAFE coin balances and data etc

Hope you get what I’m trying to say. I am thinking to invest in Maidsafe coins and trying to do the research, not trying to spread fear. As Maidsafe is trying to achieve distributed consensus without a datachain (something completely new) - I am just worried that it will be a really vulnerable network when it goes live and is in its early stage - one option will be to not convert Maidsafe coins into Safe coins after enough time has passed that one is satisfied - another would be to not go live before lets say 100k nodes or so - in this case the cost of attacking is really really high - reseting in beta is perfectly fine - I am just trying to think what will happen after the Network has gone live and is attacked. Thanks once again.


This is not happening assuming tests up to then have been ok

There is at least one person @SwissPrivateBanker saying they will run 2000 vaults on their own and others saying they wish to run farms using datacentre resources. Its likely that there will be 50K nodes in the later beta networks (release candidates) and by then we will have many times the people we have now and the network as it goes live will likely to be a lot more than 50K nodes. We also have not heard how many nodes Maidsafe will be running to help ensure the security of the network as it goes live.

My response above answers this as well - we just don’t know what will be required and we have to assume it would be a full reset meaning no data.

remember that the conversion from MAID to Safecoin will be over a period of time (1+ years most likely) and more importantly not happen until the network is considered secure against such attacks. It would be foolish otherwise.

Until the next few tests and alphas are complete will we now what number of nodes would be required for a secure network against such attacks. Datachains and node aging are going to be a big factor in attacks succeeding and/or requiring a reset.

So I think the experience and expertise of the dev team will shine forth when its time to be going live and they will ensure the network has sufficient nodes to resist any such attack before declaring the network live and certainly before starting the MAID --> Safecoin conversion.


Thanks for your reply, certainly clears some doubt.


Hey @neo I am not sure if this figure will end up being correct. What is sure is that I intend to spend a lot of time and money understanding how to farm efficiently.
For the record, I will probably spend a few thousand dollars per months on farming during the first few months. I have planned to do that as I am very anxious my stake might be diluted when the currency is the most inflationnary.

I understand farming will be easy. But farming efficiently on an industrial scale will be another story. With the ip check, the xor algorithm, I think it will be more difficult and time consuming to maintain hundreds high yielding vaults than maintaining a standard mining rig, even if done through datacenters.


I basically used your figure as an example of people wanting to run (a lot of) multiple vaults to show that nodes will be a plenty in the early stages of the live system.

That is only for testnets/alpha/?betas. It is expected people may run more than one vault from each IP address. Even clients in the live system is expected to allow more than one per IP address (& proxy). These are only measures for small test networks

The limiting factor for vaults is the bandwidth. If we require 6Mbits/sec per vault then even a Gbit/sec link will only allow you 166 vaults, but of course storage is a factor then if you tried from only one machine on that link. But even data centres share their Gbit/sec network connections so even multiple machines would be limited to 166 for a group on the same network router. Thus you would need to locate the servers in different segments/regions of the world to maximise bandwidth allowed and certainly not too many machines on the same link.

That will be your friend. This means that even if you have 10 vaults (NATted) on the one IP address each will still appear far away in xor space (more like random locations). So then the chance of being given a chunk to store is pretty even.


First time I see an estimation of how many vaults one could run through a single rooter. That’s really cool. So a raspberry pi farm in my bedroom could be made of up to 166 vaults/devices ? Not sure my wife would like it but it’s great to have an estimation.[quote=“neo, post:10, topic:14358”]
the xor algorithm

That will be your friend.

I am not sure about this one. If you are trying to get a significant portion of the network faming power you surely have to spread your vaults geographically through droplets and datacenters in various continents, which is hard to maintain logistically speaking even on services like aws, azure or digital ocean. Minimizing centralization of the xor space is essential to maintaining the security of the network. So I doubt I would farm efficiently if I concentrate all my vaults on the same virtual server. Space centralization poses a risk to data integrity and the way the network is organised, through Xor distance optimization will prevent me from doing just that, isn’t it ?


Well the XOR is your friend. The reason is that XOR space is like random in IP space. So even if 2 vaults have the same IP, both vaults have the same average rate of receiving chunks. Its like you get a class full of kids and they pick a number out of a hat and you hand out lollies to specified numbers and the numbers you choose are relatively random (thats what chunking will do). It doesn’t matter if kids group together or all stay separate they still all have the same chance of getting a lolly.

When a vault goes online it is assigned an address in XOR space which is not allocated according to IP address or location but random and maybe weighted towards groups needing more nodes. This process has nothing to do with location or IP address. So your vaults are (approx) randomly allocated a position in XOR space.

NOW, the issue is not XOR space but bandwidth and/or resources. You are right in that you would not want to have 30 computers behind one data centre router. But if you have a couple then your fine since I doubt one computer will adequately handle 166 vaults due to the “random” times with group reorganisation and CPU usage increases. Too many vaults and the potential for the CPU to be 100% is possible if a couple or more such reorganisations occur together. And then its possible all your vaults on that maxed out machine will be dropped due to slow/no response. So maybe 10 vaults per machine, but we will know better after the alpha testing.[quote=“SwissPrivateBanker, post:11, topic:14358”]
Space centralization poses a risk to data integrity and the way the network is organised

Considering what I explained above the data integrity of the network should be fine assuming you don’t have most of the vaults in the network.

The issue would be if a fault occurred in the central datacentre which isolated your vaults, then you potentially lose the data stored on those vaults and the future opportunity to earn GET rewards from that data when your machines go back online. The network though because of the 8 chunk copies of each chunk will not lose any data and the network will make new copies when your large farm goes off line.


The reason for spreading your servers across a few locations is to do with bandwidth and uptime of the links (&computers) in the datacentres. And XOR space allows you to reduce the number of locations to a few