Network size and the cost benefit of an attack

There’s some crossover point in network size where an attack becomes unfeasible.

A larger network means a) more attacking vaults are required so the cost is higher and b) less safecoin can be stolen per section so the benefit is less.

The exact crossover point depends on exchange rates and costs and average vaults per section etc, but the result is that a larger network is generally more secure because it’s less desirable to attack. It’d be cool to have a tool that could pull in all this live data and report what a secure size of network would be.

As an example, using a safecoin price (SP) of $0.50 USD and a lifetime vault cost (VC) of $1.00, a secure network size would be at least 464K vaults.

VPS = vaults per section = 50 (assumed)
NS = network size (we want to calculate this)

Q = Quorum = 0.5
TC = total safecoin = 2^32

TS = total sections = NS / VPS
SCPS = safecoin per section = TC / TS
TAV = total attacking vaults required = NS * Q
B = benefit of attacking = SCPS * SP
C = cost of attacking = TAV * VC

The section is on the fringe of secure when B = C

Substituting in


(TC / TS) * SP = (NS * Q) * VC

(TC / (NS / VPS)) * SP = (NS * Q) * VC

Solving for NS

NS = ((TC * VPS * SP) / (Q * VC))^0.5

Using the assumed values

NS = ((2^32*50*0.5)/(0.5*1))^0.5 = 463,410 vaults as a minimum to make an attack unviable.

There are some intuitive results that come out of this:

Increasing exchange rate but same cost means the attack is more beneficial, so there must be a larger network to make the attack more expensive. Doubling only the exchange rate results in a network of 655K vaults being the new minimum secure size.

Increasing vault cost but same exchange rate means the attack is less beneficial, so there can be a smaller network. Doubling only the vault cost results in a network of 328K vaults being the new minimum secure size.

It’s a little scary to think the exchange rate can be used as a dial for security, and that higher exchange rate means a larger network is required, but the results are pretty fascinating.

Some rambling observations…

Ageing is a security feature because it increases lifetime vault cost.

Datacentres have a lower lifetime vault cost than a small scale farmer due to economies of scale.

Home users have a theoretically zero lifetime vault cost since it’s included as part of their other internet / computing costs which they’d pay even if they weren’t farming.

Adding the idea of a distribution of various vault costs across the network makes this calculation a bit more challenging.

Total attacking vaults required may be less than NS * Q, especially for small networks.

This is a pretty complex thing to model accurately, and the formula derived above is the most basic starting point. It’d be cool to dive a bit deeper but it escalates in complexity fairly rapidly.


This and the extreme decentralization that sections offer are what makes this project so exciting and a good prospect. Cool modeling @mav always get excited to see what you’re poking at :slight_smile:


in my country the top 10 torrents in our biggest torrent tracker are downloaded 8 134 428 times… I think the number of vaults from home will surprise us all.

Personally, I will not be surprised if we pass 1 million vaults in the first month :wink:


Does this assume someone wants to attack the network for nefarious reasons, yet wants the attack to be at worst cost-neutral?

1 Like

That would be lot of new Safecoins to replace one torrent tracker.

For reference, link to discussion on this:

1 Like

The formula can be rearranged to work out the maximum price of safecoin for a specific network size before an attack becomes viable. Yes - ensuring security means there is a maximum possible value for the price of safecoin (probably something of interest to those in the price and trading topic).

SP = (NS^2 * Q * VC) / (TC * VPS)

For example, assuming the same parameters as the original post ($1 lifetime cost per vault, 50 vaults per section) a network with 5M vaults could support a maximum safecoin price of $58.21 before it would be viable to attack the network.

This also works in reverse - if the network is very large it means a high safecoin price can safely be sustained, but if the network is small a high price can become dangerous.

If the price suddenly rose it would allow existing operators to increase the size of the network and hopefully prevent an attack becoming viable. Sort of a nice self-reinforcing mechanism there, albeit also sort of centralising.

If an attack were to happen and all the stolen coins suddenly sold it would reduce the price, possibly to the point an attack is no longer viable. But perhaps this is extending the concept a bit too far! Regardless, market depth is another important factor in the success of an attack since it decreases the benefit to the attacker during a large rapid sale.

The boundary between viability somewhat indicates a model for growth. If price goes up above the boundary into viable attack territory, network size should increase to bring the attack back to non-viability. If price goes up again above the boundary, the network should increase in size again.

Maybe price manipulation will have important consequences for the security of the network? Maybe the security model will end up naturally damping price manipulation (wouldn’t that be fascinating to take to the financial regulatory bodies)? Nobody can know exactly how the price and security will interact, especially during bear markets, but it will be very interesting to see since they are closely related.

Some more notes on the depths of complexity if this model were to be taken further

  • safecoin price is not a fixed value. Market depth would affect the price as coins are sold. There’s also a time risk, where attacker coins want to be sold quickly but the faster they sell the more they impact the market. Safecoin price is also not just exposed to market depth, there are also arbitrary market conditions such as bitfinex speed bumps or mtgox security flaws, not to mention AML / KYC hurdles to manage.

  • quorum is only formed by elders, not by all vaults in the section, so age distribution of attacking vaults vs other vaults must be accounted for in lifetime vault cost.

  • safecoin quantities are not evenly distributed by section. Section prefixes may differ in length which means sections will each be in charge of different numbers of safecoins. An attacker may get lucky and be part of a section with relatively more coins or be unlucky and in a section with relatively less coins. This adds uncertainty to the value for safecoins per section, which affects the benefit obtained from the attack.

  • age distribution is not even across sections. In some sections the attacker may only require very old vaults to obtain quorum but in others they may require relatively young vaults. This adds uncertainty to the lifetime vault cost.

  • vaults are not evenly distributed through every section, so the attacker may have many vaults in one section and none in others. This affects the total attacking vaults required to obtain quorum, usually resulting in a lower total number of attacking vaults (see the birthday paradox thread as posted by @drehb above).


Yes the model is based on cost-neutral assumption since that is the crossover point between the attack being viable vs not viable. There are scenarios (see post above) where the attack may be cost-beneficial or cost-prohibitive.


I think you can also add to the “hard to model” list the fact that the whole time an attacker is “building his attack force” he must maintain nodes in good standing, which will farm. If he’s dedicated, any extra coin earned on top of server costs will be used to add more servers, compounding his growth. Rate of growth depends on how many chunks are stored on his servers and how often he wins the “chunk return” race, and the safecoin “lottery”.

1 Like

@mav, I’ve done some preliminary tests on limiting the infant as SAFE intends to do and it has a big effect on the number & timing of bad nodes being added to the network. I am still working on it and putting the data into graphs that are meaningful, but this was one fact that became evident early on.

I am thinking that will also affect the cost benefit curves since it changes the required number of bad actor nodes to successfully disrupt an existing network.

Also your curves are affected by timing.

  • If the attack can occur starting in conjunction with the network starting then you need much less nodes than
  • if you start the attack after a period of time then you need more nodes to be added. (assuming you want the attack to succeed within a reasonable time.)

Some live charting / data for these calculations with your own parameters:


I think there are other factors, not taken into account, that substantially modify these calculations.

1.-You can spend several times the same safecoins until the network begins to suspect that something bad is happening. How many times? It will depend on many factors (number of potential buyers, velocity of circulation of the safecoin, etc…).
2.-The benefit of the attacker, who controls a section, would be a lot greater going short against the safecoin than selling the coins of that section. Using leverage, these gains could be huge.


This is way bigger than SafeCoin price to fiat conversion.

Two more attack vectors:
Space - usable:
The attack has to also be measured against cloud storage space. If storage space can be bought now and allotted for later (empty space reserved for future) than an attacker who controls even 1 section that is in charge of just 1 safecoin can get it, buy space (now it’s owned by the network again), take it again … Ad infinitum. He could control the whole safe storage space before long. Not only could he control it all, but now sell that space as a massive cloud storage provider for fiat outside the network and the service just backend to safe.
Interestingly enough, if this were to happen, the network would still work as intended (mostly). Farmers would still get paid just fine, but people would end up paying fiat for the space to the attacker. Space to non-attacker would be really expensive though due to space/price dynamic.

If this were to happen once compute is enabled, holy cow. Max out every CPU on the network, talk about a distributed super computer.

Space - junk
In a similar scenario with the change of not being allowed to reserve space:
Same safecoin to space thing happens but attacker fills network with garbage data with his single coin. Profit happens by taking a large stake in short side of safe as @digipl mentioned.

Basically, if a single group is taken over, the network is toast. Profit can happen regardless of SafeCoin price.


Agreed @digipl and @wes. The potential benefits to an attacker need a lot more exploration like you’re doing, and the uncertainties of cost of the attack need to be clarified.

Maybe another step up the complexity ladder can be reframing the situation as ‘what duration will an attack be likely to last and how much damage can be executed in that time’. It may not be possible to flip hundreds of thousands of safecoins in a section within the time the section is being controlled, whether due to network factors or computation factors or whatever.

The other thing about stealing safecoin mutabledata vs sending legit transactions is the wallet aspect. What happens to the existing safecoin wallets? What happens when the old users try to spend those coins they no longer own but are still ‘in their wallet’? Will this be detectable by the user and / or network? Will the routing of the transaction be affected? It’s one thing to change the data at the safecoin address but transactions have effects outside the malicious section. Presumably a similar idea is at play with PUT balance. See RFC-0012 - Safecoin Implementation - Account Management for the current thinking on this (it’s quite old).

Maybe there can be some way to correlate the account with the safecoin, since it’s a very high chance the account MD will be in a different section to the safecoin MD. This way if the safecoin owner is changed the attacked section would be punishable because it wouldn’t match the account data. Likewise any coins without a corresponding account can be assumed to have been stolen. I’m not clear on the mechanics of it yet but the idea of two sections holding each other accountable, the account section and the safecoin section… I think there may be something in that.


If we need to create an entire control system, which seems extremely complicated, between the section that owns the safecoin and the one that owns the account. Would it not be better to consider, for the safecoin, mandatory double consensus of two different sections? A priori it seems much easier and safer.
We know that it’s means complicating and slowing down the safecoins transactions but if we think that the safecoin needs to be protected in a special way, and I do, for me is the right path.

An I do because the security of the network is going to be measured by the safety of the safecoins. If someone manages to make a safecoin fraudulent ownership transfer, the network will be dead. If someone control a section but fails to steal any safecoin the network could survive.

We know that, in many cases, there will be mutable data whose value is greater that of any safecoin, but as conducting targeted attacks are extremely complicated, the safecoins remains the weakest link in the security chain as they are evenly distributed and they have the power to, if they fall into bad hands, destroy the network.

1 Like

While your answer “feels” right, that the coins should be afforded an extra level of protection, I can’t help the other thought on principle that all data should be protected so the same level. The coin is just a mutable data to the network. As in, it’s just got a different tag, otherwise identical as far as the network is concerned, it should be protected the same as everything else. If it needs better security, so does the MD tracking my stock portfolio.


Sure, but that sounds potentially just as complex as the account / safecoin correlation technique. Both techniques would benefit from some further exploration.

Not sure that I agree a priori that double consensus much easier or safer. It may be, but it may not be.

But overall I don’t think safecoin should be subject to special security rules. The account / safecoin correlation technique is not a special security rule for safecoin. It only affects the ability to punish; it doesn’t change the way mutable data or safecoin is created / transfered etc. It seems like the double consensus would affect creation / transfer etc of safecoin so it affects the fungibility of data security.

An interesting quote from The Economic Limits of Bitcoin and the Blockchain by Eric Budish which relates to the discussions in this topic:

In particular, the [economic and security] model suggests that Bitcoin would be majority attacked if it became sufficiently economically important — e.g., if it became a “store of value” akin to gold — which suggests that there are intrinsic economic limits to how economically important it can become in the first place.

And from the conclusion

An interesting open question raised by this paper — perhaps more for computer scientists than for economists, or perhaps requiring both perspectives — is whether there is some other approach to generating anonymous, decentralized trust in a public ledger that is less economically constrained by the possibility of an attack.

I think SAFE poses a reasonable response to this question, since the protection of all data will be very important, not just the protection of safecoins, so this makes SAFE significantly less economically constrained by the possibility of an attack. There is ‘some other approach’ to generating trust in a public ledger - extend the value of the network beyond economic incentives, ie to the utility of information itself rather than the abstract value transfer it represents. Plus the network property that the benefit of the attack decreases as the network grows (via disjoint sections reducing the reward due to dilution of safecoin responsibility).


@mav please you spell this out? Since you raised this issue its been niggling at me so I’m keen to understand your reasoning here.


But one important thing that separates Safecoin MD from other data MD is that Safecoin MD will allways be worth market price, which could be very high, no matter to who the Safecoin MD belongs to. Regular data MD has to me a very small chance of being worth anywhere near what a Safecoin MD can be worth. The cost/benefit of stealing random MD would almost certain be significant low compared to stealing Safecoin MD? All measures needed, should in my perspective be taken, to secure the most important MD that would be monetary beneficial to attack and that could destroy the network trust, reputation and therefore also it’s success.

Mutable Data itself are managed differently according to the degree of danger that an action can cause. While doing some actions like creating, modifying or deleting some data only need the permission of the DataManagers, change the ownership need the signature of the owner.
Require the signature of the owners is much safer than not, but, in the end, the network give priority to other considerations such as speed and ease of management and allows certain actions without an specific signature and accept a global one.

The double consensus, or chained consensus, is expand this same policy. The safecoin management will represents a tiny part of all the data that the network must manage but will have the enormous power to be able to destroy the network. And if this extra work, of an small part of all data transactions, maybe will be assumable, expand to all MD will not because it would suppose an enormous extra work for the network which, significantly, will worsen its performance.

As almost everything in life it is a matter of choice. Or increase security in this particular case with the good part (more secure) and bad (complexity, slow transactions) or we keep what we have with the good (all the MDs are equal) and the bad (if an attacker controls one section the network is screwed).