hmmmhmm - as long as there is no limit for account-creation frequency the problem remains … doesn’t it …?
is it possible to differentiate between a new account creation and a regular get request …? (…ideally that shouldn’t be possible … but … it would help right now ^^)
Can’t we just add one of those “click on all the pictures with street signs in them” things at registration?
Obviously I’m a tech-tard, but aren’t those things designed for exactly this kind of problem?
Problem is these CAPTCHAs rely on a central server…
Which is not to say that we coouldn’t implement it fairly quickly.
Be interesting to see if the CAPTCHA server(s) got DDOS’d as the next phase of the attack…
Edit : I have only implemented CAPTCHAs as plug-ins so I could be talking crap… But what’s new?
This is hard to do. Here’s the thing:
Vaults <==> Proxy_node <==> Client
So if you want to implement something like a captcha you need to do it at the Vault level. The Proxy_node is quite dumb and only allows for a encrypted connection from the Client to the group of Vaults.
So most simple idea is to limit the upload speed from the Client at the Proxy_node. Only allow for 50 KB./sec instead of the 200 KB./sec we see now. That way you slow the attack down with 75%. If you update the average storage to 25 GB per Vault instead of the current 5 GB. You slow the attack down another 5 times.
Just a thought though, devs will probably know some other tricks here.
Ah I see. Thanks for the explanation, I was wondering why it was an issue given how common those kinds of solutions are.
Scaling is an answer… I wonder also you could put some exponential on the number of PUTs required to add data to a network near capacity. The cost must be relative to the impact on the network and PUTs are the measure of spend atm.
I really love to quote this one here 
I’m kind of surprised this only happened now. Is it because the project has reached a point where some feel threatened?
It should probably have been anticipated and accounted for by now… not everyone stands to gain from a successful network.
I’ve been able to add a small file to the netwerk an hour ago.
Bigger files were not possible.
What happens if the number of vaults should increase significantly in this network: from 150 now to 200?
Will some chunks of the 150 older full vaults be ‘moved’ to the empty 150 newer ones, so that there are more then 50 vaults available to accept new chunks?
I think this is not the case, but I could be wrong.
EDIT: the old vaults are only filled at 50% of their capacity, like mentioned earlier in this thread.
Implement a CAPTCHA for creating an account, uploading, etc.
I see some people suggest implementing a test Safecoin, but there is a development plan in place already and any disruptions to that will only increase the time it takes to finish.
But updating existing SDs still works perfectly, because this control is only done in method handling PUT requests and not in method handling POST requests.
This means that safe://galaxy site is still up-to-date because I respect the following constraints:
I only create or update files with a size below 3KB
I do this inside a fixed set of directories with a size below 100KB
I did this way to pay a few units from my put balance at initial creation, and then pay nothing more. I couldn’t do it another way because otherwise I would have run out of put balance very rapidly.
As an unintended consequence of this design, my site is still operational when the network is full.
What about a proof of work for account creation?
Set the difficultly such that it takes about an 30 mins for an average pc to create an account.
Most of us don’t care at this stage if it takes 30 mins, to create an account but this would slow down a script.
Another possibility is that the client managers wait a fixed duration before creating the account. That way there is no fine balance to find between discomfort of users with low cost device and hindrance for the attacker using a very powerful station.
Mmmh sure but doesnt it simply shift the account flood in time instead of diluting it in time ?
Unfortunately this would be ineffective if a malicious user would use a botnet for account creation.
I love the idea! And not so much because of its content (I do not know how practical it is), but because of its spirit! Implementing SafeCoin, no matter how basic, would be to hold the bull by its horn!
Another one could be a challenge sent back that needs solving. Rather like a captcha but simpler for the client managers to do. This would be some temp code until testsafecoin comes on the scene. I’ve seen ones where you have to solve a simple maths problem shown in images. Simple image manipulation s/w in linux before sending the challenge would prevent simple recognition by s/w.
(testsafecoin) Even basic is still a lot of work programming and testing etc.
Also how do you get the coin to people to do testing of the network? You cannot just say do farming because then there will be nothing to ever farm because noone can get coin. If you give any free coin/PUTs then the exploit can continue with or without testsafecoin (no matter how basic).
Better to have a sort of challenge which helps to reduce the possibility of bots/scripts.
Doesn’t this stifle use/testing? Better to just challenge the person creating the account as a substitute to buying your way into testing.
And then one of rich whales in the BTC world can simply pay a BTC for what 1000’s of accounts? They could swamp the number of people here.
We want as wide as possible range of people testing and this includes those who have no crypto resources to pay. From out-of-work to carers to the too young to have financial resources to pay even a little to do testing. So if any payment is required the rich become the majority testers and some of those rich may be trying to subvert SAFE.
Whereas a challenge subroutine can be solved by those without other resources to pay and becomes much more inclusive.
So there ends my contribution as to why a coin is not a solution to the problem 
A faucet would just drip test safecoin into the system. Not as good as farming, but relatively easy to implement, I suspect.