Such a group would need an exploitable weakness in Safenetwork. I may have identified another such weakness.
Imagine a group with significant resources, like a botnet, a group striving to cripple Safenetwork.
Such a group might try this:
Create a group of vaults on their botnet to generate Safecoin
Use all this Safecoin to create more identities and vaults
Once they have enough identities,they restart all their vaults with hardly any storage capacity or cache. They create as much extra minivaults as possible.
They start them all generating and requesting as much Structured Data as possible.
As creating Structured Data does not cost any Safecoin, such an adversary can continue to fill up all available vault storage and waste all Safenetwork bandwidth with impunity.
The weakness I found here is, that farmers provide at least three resources, but the Safecoin economy is based on only one resource.
I admire how David has designed Safecoin, I am just saying we need at least three coins:
Safegold to pay for Immutable Data
Safesilver to pay for Structured Data
Safecopper to pay for Bandwidth
I am rather sure we should not try to extend Safecoin use to cover all possible resources. The elegance and simplicity of the current Safecoin design can only suffer. Instead we should apply the current design independently to at least these three resources and create a âFarmers Marketâ as soon as possible, where any Safecoin type can be traded for any other. Supply and demand will then do the necessary balancing that would be too complicated to leave to any algorithm.
David has already described why Safecoin for immutable data is a necessity for Safenet.
The scenario above makes clear why structured data needs its own price/coin.
Bandwidth gets its own Safecoin type because I expect that it will be easy to construct a similar scenario, just using random hashkeys, to waste bandwidth. I also included bandwidth because I can see an additional advantage if some content can be requested with priority. Wouldnât it be nice to have the first five minutes of a film asap by paying a few coppers extra?
I thought a while if âcacheâ should be valued as an independent resource also, but could not decide. AFAICS use and cost are reasonably balanced for intermediate vaults, with Safenetwork as a whole winning and responsible vaults losing in a zero-sum game. Caches seem to have two mayor functions: saving bandwidth by offering extra vault space and first line of defense against attacks like described above. For now I guess that makes a nickel coin superfluous.
For the future two resources I hope to see developed, will also need their own coin:
Safeplatinum to pay for calculations
Safeiridium to pay for mesh connections, even if we integrate mesh connections in Safenet, they are sufficiently different that they need their own coin. They will form a layer below the Kademlia layer that powers the normal Safenet.
Basically since GETting data doesnât cost anything, youâre saying someone could feasibly create a butt-load of vaults that all GET as much data as they can, clogging the networkâs bandwidth.
Is that right? Iâm not sure what you mean by creating StructuredData costs nothing, I donât think thatâs the case (because itâs a PUT, and PUTs cost Safecoin).
In the DDOS attack, only a few nodes would become clogged because of the caching aspect.
Let me find more information for you, I wanted to quote some of it but seemingly the systemdocs are goneâŚ
Edit:
As a side note, it seems to be in the final plan that you wonât even have to login to the network to GET data, which means that you wonât have to spend any Safecoin at all to make 1,000,000+ vaults. You only have to sign yourself onto the network to PUT (signing on costs Safecoin and PUTting costs Safecoin).
I believe I saw plans that limits a vaults message frequency to their close-group? So if 1,000,000 vaults were all rewriting SD, theyâre still accessing it through their close-group, who may not themselves be able to handle the message frequency (or will flat-out block excessive requests) making small clusters of nodes go offline.
Definitely an interesting attack @Lazarus_Long. I would like to see dirvineâs perspective, however I dare not ping him and draw his attention away from coding
Yes, that is how the idea for this post started. Normal DDOS is out, can I think of something similar?
Now that is an Oops I remembered incorrectly.
For me as a database professional, SD will be much more important than ID, so it worried me that people seemed to get something for nothing, as that will invariably lead to misuse, as soon as someone finds out a workaround.
Hmm, Iâm not entirely sure if that applies to this SD overwriting attack. This attack depends on what the cost of updating SD is (not Safecoin cost but cpu time, memory used, bandwidth, etc).
Iâm still pretty sure this attack is already stopped to some degree by each nodeâs close-group, but I base that on nothing.
A Safecoin is only a type of SD so can, or canât, suffer the overwriting attack like the rest of SD. If the cost, for the attacker, of signing the SD update is more computationally expensive than, for the network, the verification, all is Ok. If not, we have a problem.
Yes and SD space is capped too. IIRC, you get 10 times less space (than immutable data per Safecoin), but unlimited rewrites.
I think there is a potential DoS attack in the shape of excessive rewrites, but not from filling storage space.
I would expect that excessive rewrites would put more load on the storage vaults, limiting resources to serve other data. In turn, in could increase the coat of storage.
Whether such an attack would be worthwhile is a good question. As SDs arenât cached, nor do-duplicated, âunlimitedâ rewrites could potentially have an impact. Presumably, a cap could be levied or a charge per write could be implemented if it was a problem though.
Now that is certainly something that has to be tried. If nothing else, I would consider the ability to prevent disks enter the power saving mode (or RAID, for those experts who think it will be useful for SAFE, ;-)) a small victory.
And I agree there are potential solutions to reduce the attack vector. Guess we will get to see first hand in the early days of the network.
Although someone said that âmass scanningâ through SD address space has some sort of prevention mechanism so I guess we have to wait and see what they have planned in that area
If they are interchangeable without friction, and if theyâre divisible down to dust values, then theyâre functionally the same currency, so the three currencies are functionally mere names for the same currency.
When we had the gold standard (Iâm thinking of pre-WW1), the currencies of the day were approximately the same currency.
With digital currencies, potentially frictionless, the approximation to the same currency is even closer. The difficulty and cost of exchanging them one for one another is all that makes them distinct currencies.
With fiat money you can buy milk , a prostitute or a house. I donât see any conceptional reason why different commodities would require separate currencies. The very essence of currency is that itâs the most marketable commodity. Having gold and silver together made sense because gold is so much more valuable. That means itâs inconvenient to use for small purchases. Digital currencies can be divided much better.
With regards to the attack, I have a question:
Could I put SD with the size of 1MB, and then rewrite with 1TB? I would suspect that the answer to that must be no because then nobody would use immutable data since itâs more expensive. And of course this would allow someone to deploy one million units of small, cheap SD units, only to then rewrite them with a million TB of data each.
The only sensible solution seems to me to be that the network charges at least for every rewrite of SD when the new size is larger than the previous one. Everything else would be some arbitrary limit on what you can do with SD. Is something like that planned?
In terms of the attack you could probably do that.
In terms of developing an app that doesnât make sense, even if you overwrite your 1MB wth 1TB of data, at the end of the day you end up with 1MB of stored data, it doesnât matter how many times you overwrite that 1MB, itâs still 1MB.
If you buy 1MB of SD. You have 1MB of space. Imagine that as a 1MB disk.
If youâre overwriting that 1MB with 1TB of data, youâre not extending that 1MB disk, youâre writing over it with 1MB of data, then youâre writing over that with 1MB of new data, and again and again.
If you actually did this, the only thing you would see after you were done, is the LAST megabyte of the 1TB.
I remembered incorrectly.