Account creation attack!

@Ghaunt I feel your thought process is very helpful and it seems people with your way of thinking would be very helpful in contributing to the project and making the overall system stronger. My thinking is, “why would anyone want to destroy something that empowers the spirit that drives humans to resist the current design of centralized control? Doesn’t the SAFE network speak to all genius idea hackers of the world? What is the purpose of attacking the real people of the world?” My idealistic personal theory is the geniuses of the world have the universal ability to resist brain washing techniques that have been used by war creators throughout history and almost always end up making the right decisions for the innocent people of the world. The proof in my theory is computers…nothing beyond that evidence is needed. The moment the few maniac psychopaths of the world gave up just enough control to the geniuses (blinded by their pathology and possibility of computer tech.) and became dependant on computers…they lost the ability to control the world.

The realistic part of me sees the possibility/past-evidence that there are people who have the genius ability and still choose to destroy the world, but then believing in that leaves one conclusion anyway…great, you can temporally disrupt the natural flow of life; so what.

NODE: How can you change the world


Maidsafe don’t give space, is the farmers who can.

Maybe you can create a program to generate multiple account but you can’t upload data without pay safecoin. The real problem for the attackers is that is much more expensive, in computational terms, made the calculation for create a new account (a minimum of 2000 iterations of SHA512(concatenate(password-bytes, pin-bytes))) that store 32 bytes for a short time, a trivial task for the network

That’s new for me too. Seems a very short time.

Could you explain what happens if:

1./ Some guy create a new account to receive a payment. Give the address to the payer but this takes more than 10 minutes to make the transfer (This case is more than probable if you change bitcoin by safecoin).

2./Some guy create a new account and begin to farmer but 10 minutes later still have not safecoin.

ATM the 10 mins is an arbitrary time, testing will show the most efficient period here I think. The balance is in crazies trying to flood rubbish on the network and getting enough time for people to do as you say (Even farm etc.) We just need to take care as the network initially is small side attacks like excessive vandalism are more dangerous, how much so really is down to testing. We will get a decent balance though.


Would there be a way for the group to limit the account creation time? That would minimise any single attack. Botnets doing it is another issue.

EDIT: I just re-read my post and maybe is not saying what I wanted it to say. I was thinking that the group could deliberate take so many seconds to return the IDs for account creation. This way a user is limited to the number they can attempt to create in a set time period.


I like this idea.

Many people will set up a SAFE account for “future” use… which may be a few days or even months ahead. Time expiration on the account is a serious inconvenience as exampled by @digipl above.

Some video sites use a 1 minute wait period to reduce DDOS bot spamming. Similar strategy could apply to SAFE account creation.

1 minute wait time = 10 minutes to make 10 accounts.

Here is an alternative idea.

Wallet creation via Vault
Run a vault which automatically creates a (temporary) wallet account during that session. HOWEVER, the wallet becomes (permanent) once the first Safecoin is received from farming or payment.

This provides a way for someone to create a temp wallet without funding but requires resources from running a vault, which limits creation spamming.

  • The temp wallet remains active during the vault session. This encourages people to run vaults by default.
  • There’s no wait time.
  • If someone wants to send you Safecoin, just run a vault to get a temp wallet address to receive payment, which then becomes permanent.

If the vault session ends (disconnected) AND there is no Safecoin in the wallet, then the temp wallet expires.

The one drawback is people might assume once they create a temp wallet address that it will be permanent, which can be avoided by clearly tagging the wallet as (temporary) when viewing the address.


I don’t know why this post get switched from one category to another lol. If it’s not cyber-security, it’s certainly not a feature. But about development I’m not sure.

I don’t care anyway it’s just funny.

I read, reread, reread, reread and now I think I understand more what you want to say. (Like I said I’m not really comfortable with my English.)

It is assumed clients will pay at least one safecoin to create an account.

For that above I think it should be some fraction of safecoins. 1 safecoin to create an account it’s a lot. And could discourage people.

But, a solution I have in mind. If I understand the MaidManager keep track of the accounts closest to them. So the MaidManager is responsible to store the encrypted key for each account (I’m not sure where…). Here my solution. For the new account the MaidManager track it with a “timestamp” and with a “lock”. The lock is when they are online and when the new node goes offline the timestamp is updated and it’s unlocked for deletion. After 24h (1 day) which I’m more confortable with than a 10 min, (Personally I would prefer more) the account is deleted. It’s not a problem because they can create the same account with the same credential because there account is empty anyway and it’s no longer in the network. After people paid to store their account, it’s no longer needed to keep tracking of this. The only thing that is needed is the key are stored to the network (Except in case the network got full and data need to be sacrificed).

So, as long as people keep there client open no need to delete there newly created account and if they want to keep there account active after going offline they should do, one buy the storage needed with safecoin or if they don’t have it, farm it, wait and keep there connection open until they farm enough and buy it.

Of course they should get warned about anything. “After you log off, if you are not online before 24h, your account will get deleted if you don’t pay for the storage, but you will be able to rejoin the network with the same credential at anytime and navigate the public safe network. If you want to keep your account you must stay online until you can get some safecoin from someone or wait for your one vault to give you some.” (That one is the apps job).

And they should be warned for this too: “If you run a vault and turn it off you will be penalized for data lost… You will still be able to access your account but the ability to store data to the network will be limited if you don’t have safecoin to pay for it.” (Still the apps job).

I want the best for MaidSafe, @dirvine I trust you and your team. You can do the best. You can predict almost or everything in the future that can happen and put it in your project safe security. People try to give a problem with the project (like me) and you always have an answer to it. I’m jealous (not really seriously). I was thinking about that and searched the internet for some project for decentralized storage and never find one in the past (Or the one was just not secure enough for me). I was thinking how I could make it and never be able to find the answer. And I found MaidSafe.

I’m currently trying to look at the code and studying it. It’s complex. I am willing to be able to contribute like @MrAnderson said but the only thing I can do for now it’s reasoning and give my though. But if I’m getting comfortable enough or find something wrong with the code or the protocol I will give feedback on this forum.

1 Like

This is nice in some ways, but does break a core network issue really. The SAFE network does not use or respect time and will not try and transmit any time related information. So local time is OK, where nodes have a few minutes cache etc. This though is local. So how can it be?

The groups have 2 main settings

  1. Close group size
  2. Quorum size

The difference between these is the error margin, this takes care of many things such as churn, small changes in what nodes believe to be the current network state (who is still there, who is new etc.) and more. So consider group_size - Quorum as the number of nodes that can be in disagreement.

The whole network works on the premise that everything is event driven and each node knows what to do based on what it sees. It does not trust time though as there is no way to synchronise shared time without some hardware and even then it becomes centralised.

However, and this is important, there is an opportunity to share duration, a duration is OK as it is still local, but can be group consensus agreed (I don’t know the time, but in 2 mins this will happen etc.).

So with that in mind there is a possibility to introduce shared or agreed, duration. We have not taken that step yet though and instead always found an approach that does not use duration.

As things progress then duration may be a valid shared unit of value, I perceive it will, but in all honesty I have had enormous fights in not letting time be in involved, it’s like linear thinking instead of XOR and people start using it all over the place. We have had the same with people wanting to track every message through all persona’s from start to finish (a colossal error). When duration gets shared it must be strictly duration, times and timers are really really hellish in decentralised systems (unless you trust network time servers, which I don’t, I also question time as a measure at all, but that gets very deep very fast).

In our C++ code there were timers introduced where people implemented these and almost hid them from me or would not discuss them while I was around as they knew of my hatred for them (not timers but overuse of them, like raw pointers or void pointer conversions). I was devastated to find this out so close to launch, it was a very hard time for me. The core of the design had been broken and badly so. This actually led to a situation where

  1. A put request failed (sometimes crashing systems)
  2. A supplementary Get for the data (that failed to put) was successful

The seemingly, oh let’s use a timer here, it will be simpler, soon almost killed the project and led to huge disagreements as timer friendly people tried to defend their position of we must know everything (so expect every node responses all the way through the chain) with including timers (who knows how long things take, so what to set timer at) and I was literally on my knees looking up to the sky for many nights wondering, how do I get out of this. It really was hell, and the Engineers who had done this wanted to defend it totally, even though it did not work and I could show huge security holes (not even over yet, the scars run deep :slight_smile: ).

So time is scary, durations very locally are not as bad, but can be overused so easily that it is scary, so massive care is needed with any timer, if you see what I mean. Sharing durations may be possible, but even more care required and agreeing actual time, IMHO is impossible without centralisation and belief in a dimension I don’t know that we can.

I hope this makes sense, but at least I hope you will see where I tread lightly with time/timers/durations etc.) They are useful, but very easily to useful and there is almost always a better more natural way. I tend to use local duration as a temp measure and a TODO item on code. I know they are wrong and will be replaced.

Hopefully that helps a little, it’s my opinion anyway, I am not always correct, but have seen the devastation when Engineers do use time more freely than the likes of me who is terrified of it :wink:


Unfortunately, many governments would have an incentive to hack SAFE as well as anyone enjoying the status-quo of centralization and collection of everyone’s personal digital data like the NSA. David Cameron wants encryption without backdoors to become illegal (which is preposterous because then it wouldn’t be encryption). And most people do not think Cameron is a hacker or a psychopath.

These are good examples. Here are a couple of ideas/suggestions that might work:

(1) Is it possible then to make an account have read-only status with no storage rights onto the network until it is prepaid for? Only when it is paid for can they get write-access. That would eliminate the time constraint.

(2) And this read-only account could be allowed to receive safecoin but never send safecoin until storage is paid for. This would also allow one to farm until safecoin is received if the user doesn’t want to buy safecoin on the market or cannot do so easily. This too would eliminate the time constraint while offering infrequent one-off users some use and value without any upfront commitments with safecoin.

Both read-only and receive-only access could make SAFE adoption much quicker and easier.


Interesting. How does the network timestamp file/data changes or does it not provide this information?

It does on the client machine for that individual. This works as content and metadata are split in SAFE, your metadata is unique to you (or for private shares, another story though) and the content is deduplicated.

When the Drive module gets pushed out then timestamps will appear in your local disk as you seen them, We set these to UTC though previously and probably will again.


In this RFC we have this:

It is assumed clients will pay at least one safecoin to create an
account. This payment will be converted immediately to Mb of storage
space and the client can query this figure at any time.

In my opinion this is a very big mistake.


Most people will want to open the first account in the SAFE network to gain some Safecoin in farming. If we forced to have a safecoin (how?) or spend the first won Safecoin to acquire space, the feeling is that the safe network takes away the profits of your work. In fact, psychologically is worse: “The safe network stole my money”. This can be devastating for the network.

Of course, sooner or later, everyone will need to spend safecoin to use the network for things like send messages but we cannot force to do that from the beginning. This must be a natural and free process.

So I think is better allow the creation of accounts and farming without obligation to spend Safecoin.

In this case we have the problem of the account creation attack. To deal with that we can force, in the creation process, the new node perform some calculation, a kind of simple POW. (ej. sign some random data from the group). The idea, as always, is “easy for the network, harder for the possible attacker”.


I think that you can run a vault, which may receive safecoin, without having an account or storing any data on the network. I may be mixing something up, and I have questions such as what happens to that coin when you shut the vault node down, but I thought I had read something to that effect…

1 Like

It’s a good thing we have test, etc. So I think we can see how it works for a couple of weeks, and see if people really get put off by anything, and we’re any of us are welcome to refute, and suggest a different approach.

  1. This is a very simple approach to a balancing algorithm, it could be argued this could be modeled.
  1. Initial feedback and analysis may not reflect network usage as new applications and use profiles alter over time.
  1. It is very likely the agreed algorithm will evolve over time, which may not be clearly understood by all the community, therefore clear RFC proposals and discussions should certainly take place when such change may happen.

Has this view regarding time and timers been mentioned in the project documentation anywhere, or in the source code? If not, would it be beneficial to do so?

It seems possible that core developers in the semi-distant future might not be aware of how risky time/timers were considered by David and (I’m guessing) some of the other MaidSafe developers. Perhaps related documentation or comments in the source code could ensure sufficient awareness of the issue, so that future developers might at least be appropriately cautious before making any changes that might introduce time-related risks.

I don’t have enough technical knowledge to have a strong opinion on the issue myself; I just thought I’d throw that thought out there.


Time is something. If we don’t need time, why put something we don’t need in the documentation? If we are going to put everything we don’t need, the list will never end. But I understand what you mean.

Apologies in advance if this was already proposed before (I only visit these forums every 6 months or so).
Also I know that what I am about to propose will not popular with everyone in this forum, because it’s one of the main criticisms used against other cryptocurrency projects but…

Why not add a bit of proof-of-work to the process of creating an account, and whilst we’re at it why not pick Adam Back’s Hashcash algorithm, which was after-all created to solve this exact same problem (spam), before Satoshi Nakamoto decided to (ab)use it for a very different purpose.


The proof will be purchasing upload resources with a safecoin.

It has been said that there is no need to create an account to download.