Hmhmm - for the record - I share the fear about the feedback of adding nodes only if needed on the price for storing data on safe =O
But I guess it would make an attack more time (and because of that money) intense… So I think adding vaults only on a need basis makes sense in my mind - the impact on storage costs/farming reward is somehow hard to grasp for me for now…
Do you happen to have a more in depth concept/analysis on how those two aspects are meant to work together to protect the network @maidsafe …?
Not really, the issue is an attacker able to flood the network is obviously bad. Also though the larger the network the more secure, it is. I don’t think these are in opposition. The debate is probably about how to make the network as large as possible, but stable. This is really the key. So as more people use the network it will increase in size by attracting farmers due to need. We have not detailed the split algorithm effectively (yet) as this is a node count only, ie. when a section has X nodes we split (or merge), however, this fundamental point above means that we have to consider the bandwidth load as well as space available as well. That will mean sections may wish to take on several infants at once (similar to your findings @tfa ) but not at any time.
It is a balance though and needs an RFC to detail the algorithm and thought process there.
exactly what i meant - yes … it doesn’t necessarily become complex and doesn’t need to have a large impact on each other … but as soon as you have 2 (no matter how simple) control systems there might be effects you don’t expect in advance … but we will see and know more as soon as there is an RFC and it makes sense to discuss/simulate different edge cases
I failed miserably at explaining the SAFE Network, I was even called a scammer because they didn’t believe that something could be without a blockchain or server. I suggested that they take a look on Youtube, but they didn’t want to (this is not my fault anymore, if your not even curious to see something in action…).
The meeting was a joke they basically were trying to sell a coin.
I did meet a guy who will probably sign up to the forum, more interesting I met a guy who is actively developing apps but using iota/Ethereum/uport. he’s from https://www.ictu.nl/ an organisation trying to create apps to connect governments to the cryptospace (he’s secretly hacking away the government) His apps are impressive and I whispered in his ear about the SAFE Network. I promised to send some details about the SAFE Network, I want to send something else than safenetwork.tech, I send two devs there already and never got any feedback from them, probably still studying it.
Maybe in the future I can do SAFE meetups here, because they said they were open for new speakers. Today I found out that it’s better to not talk about SAFE, but just show it (we had no internet connection )
Would it be easier if vaults came in fixed sizes? It would be trivial to measure the free space ratio.
As my (not fully confident) understanding goes, chunks are assigned to sections by their XOR distance from the section ID, which assures that chunks are uniformly distributed across the sections. If the number of vaults within a section falls within a narrow range, then it would make sense to make each vault responsible for roughly the same number of chunks (well, a given number of chunks; vaults can still come in different sizes, just not arbitrary sizes).
When a new vault is allowed to join, it would be assigned the smallest acceptable size the section allows at the moment (e.g. 32768 chunks) and then it would be given chunks until it filled up to the same level as the other vaults in the section. At that point, it could request its size to be raised (e.g. to 65536 chunks), or it could stay as it is.
If vaults are assigned a known number of chunks, each section would know how full the network really is just by looking at its own vaults. It would be easy to decide when to accept a new vault to join (e.g. we want 80% full, 20% for cache.) It wouldn’t be a big mistake if a new node is accepted by “accident” because it could still be denied a size upgrade at a later point.
Sorry if I’m talking rubbish. I tried to find relevant information but couldn’t figure out the exact details about some things. For example, is the Safecoin economy still relevant for the free space calculation? I think I read something about that, but I’m not sure.
There is so much to think about that we created the RFC process. This is being restarted now as it fell behind. It is there that we will look deep into ideas. Any ideas should be thought out in detail and put in an RFC then the whole team will investigate it in detail. At least if the RFCs’ are in our path to launch, i.e. if they implement the network fundamentals as we posted in the update. It is time to launch and we need to get on that path, fast. Anything that is thought out in that path will be considered in great detail.
Sorry to be picky, but I really wouldn’t say it is. BAT is hosted on a decentralised platform (Ethereum) but its utility and therefore value is tied to a centralised platform, therefore it must be classed as a centralised token. Like a share of a company. Some large companies have their stocks and shares available on multiple exchanges like NYSE, Nasdaq and Frankfurt, but I don’t think that makes them any more decentralised as the value is based on the ongoing success of the company.
I’m only being this picky as I feel Brave benefit, at the cost of BAT buyers, from the allure and illusion of ‘being like Bitcoin’ when terms like decentralisation are used to describe their model.
Yes it will depend on how they work together or if one is in effect a control system working before the other kicks in. For example it could be while there is so much spare space and nodes that the price is effectively at the minimum, we see the node addition limitation control system in operation. Then when spare space starts dropping then the limitation control system starts allowing more nodes.
This way the node addition control system is at max limitation when there is a large glut of spare space and releases control as spare space drops and the price control system effective takes over.
This is actually a common system used in electronics. One such use is the muting of audio as the input drops to very low levels (s/n ratio rising) to prevent having a noisy output. Quality devices doing the function of Phones, 2-way radios, etc used to use it analogue style, but now digital signal processing has it built in.
So we see that usually only one control system is affecting the system and there is a well defined cross over stage that can be modelled very well.
And in fact when @dirvine mentioned it, the suggestion I mentioned for SAFE is what I considered it to be like.