Apr 9, 2017Nothing Considered: A look at Nothing at Stake Vulnerability for Cryptocurrencies

Nothing Considered: A look at Nothing at Stake Vulnerability for Cryptocurrencies

presstab, Core Developer, Pivx

1 INTRODUCTION

Nothing at stake is a routine argument launched against any and all Proof of Stake proof systems. Although the ar­gument has some interesting components to it, it is should be seen as something of very little concern for a Proof of Stake based cryptocurrency.

The nothing at stake argument is outlined by the Etherium wiki[1]:

However, this algorithm has one important flaw: there is “nothing at stake”. In the event of a fork, whether the fork is accidental or a malicious attempt to rewrite history and re­verse a transaction, the optimal strategy for any miner is to mine on every chain, so that the miner gets their reward no matter which fork wins. Thus, assuming a large number of economically interested miners, an attacker may be able to send a transaction in exchange for some digital good (usually another cryptocurrency), receive the good, then start a fork of the blockchain from one block behind the transaction and send the money to themselves instead, and even with 1% of the total stake the attacker’s fork would win because every­ one else is mining on both.

The essence of the argument is basically that very little resources are required to stake, if there are competing forks it is in the staker’s interest to stake on both forks. It is true that it requires very little resources to stake, in fact it is one of the primary motivators that Proof of Stake was con­ceived[2]. It is not true that requiring minimal resource consumption to create a stake means that “nothing is at stake”.

2 CASE I ­ INCIDENTAL FORK WITH COMPETING BEST BLOCKS

Consider the case where an incidental fork of the network occurs, network propagation problems cause a group of peers, Peer Group 1 (PG1), to see a certain block before Peer Group 2 (PG2) sees the block. PG2 then receives a dif­ ferent block and accepts it as the next block, causing a blockchain mismatch of at least 1 block at the top of the chain (also known as the best block).

The nothing at stake argument here would insist that it is in the PG2 node’s interest to stake on both the PG2 and PG1 chain. PG2 will want to earn their stake however they can and if the PG2 chain will be invalidated down the road, then they could have wasted valuable time stak­ing on PG2 instead of staking on PG1.

The problem with this line of thinking is that the Case I scenario is typically short lived and resolved automati­ cally by the coin’s software within a few minutes. Every coin’s software is a little bit different, but the typical coin will have a working and fully functional procedure to es­tablish which chain is the best chain and to orphan the in­valid blocks. So long as PG1 and PG2 have one node that communicate with the other node group, the blocks will propagate to both groups and the chain that has the most work will be selected as the main chain, the alternative chain will be orphaned.

Most Proof of Stake coins use work to determine what chain is the valid chain, typically this means a combina­tion of the difficulty level and the number of blocks on the chain. If a staker from PG2 decided to spend hours, if not days to create some altered code to run on both chains and stake on both chains, it would by definition be a large waste of resources for that staker because it would only take a few seconds for the unaltered coin software to tell the staker which chain should be considered the main chain. If the staker is connected to both chains (in order to stake on both) then it would absolutely be a waste to stake on the wrong chain (in this case PG2’s chain) instead of focusing on the main chain.

3 CASE II ­ MALICIOUS ACTOR SENDS COINS TO THIRD PARTY AND THEN REVERTS THE CHAIN

A malicious actor called hacker1337 sends 1000 FunStake­ Coins (FSC) in a transaction (tx1) to a third party coin ex­ change, ezex. Once ezex has acknowledged that hacker1337’s account contains 1,000 coins (typically requir­ing a certain quantity of blocks added to the blockchain after the transaction is added), hacker1337 uses their large amount of FSC holdings, and therefore staking power, to create an alternative fork that occurs the block before the tx1 is added to the chain. hacker1337 adds a differing transaction (tx2)to the forked chain that sends those coins to himself instead of to ezex. If hacker1337 successfully gets the forked chain to be accepted as the main chain, then ezex has given hacker1337 coins that do not belong to that account.

For this attack to be successful, the following condi­ tions must be met:

1. hacker1337 has a large amount of FSC.
2. hacker1337 has one of the largest staking capacities amongst FSC owners.
3. hacker1337 will gain more from launching this at­ tack than from the resulting decline in value of FSC that will likely happen when it is known to be vulnerable to attacks.

Condition 1 is somewhat obvious. Staking requires holding FSC. In order to be able to stake successively in a manner that could create a fork mentioned above, hacker1337 must have a large amount of FSC.

Condition 2 is perhaps the most important condition that must be met. Not only must hacker1337 have a large holding of FSC, but that also has to translate to be one of the highest staking capacities amongst all stakers of FSC. As mentioned in Case I, the main chain is determined by the chain that has the most work. hacker1337 will need to have so much staking power that they will be able to go back in time and stake much more rapidly than has oc­curred on the valid chain (the quicker the blocks come in, the higher the work will be). hacker1337 must therefore somehow have the capacity to outstake the rest of the holders of FSC for a period of time that will allow the forked chain to surpass the main chain in amount of work.

Condition 3 is also very important to take into account. If hacker1337 scams ezex and then keeps the FSC after, then hacker1337 has essentially sold their holdings of FSC at market rate, and then likely will be left with holdings of FSC that has declined in value due to market reactions resulting from public perception of FSC being vulnerable to double spend attacks. It is also likely that hacker1337’s address would be blacklisted in the future and create a situation where it would be difficult to cash in the rest of the value of hacker1337’s holdings.

For the attack to really work, hacker1337 would want to send tx2 to a different exchange creating a situation that hacker1337 is essentially given two times the value of the original FSC holdings. In fact, why not recursively per­ form this attack on every known merchant, exchange, member of the community, etc? Create a result that yields thousand of forks and thousands of double spends, and a great amount of fraudulent earnings for hacker1337.

So far Case II has had absolutely nothing to do with the nothing at stake problem. In fact it almost has nothing to do with Proof of Stake at all, and is more of a problem that affects all types of proof systems. For example, in the Case II scenario, replace the assumption that FSC is a Proof of Stake coin and assume it is Proof of Work. There are three highlighted conditions that must be met for the Proof of Stake attack, for the same attack but launched on a Proof of Work network only condition 2 must be met. The only thing hacker1337 needs is to have one of the largest mining capacities amongst FSC miners.

Even if hacker1337 were able to meet condition 2 (for ei­ther Proof of Stake or Proof of Work based systems) it is still extremely unlikely that simply having a large capac­ity in the particular proof system will result in the ability to create a more valid chain. In would almost definitely have to have another sub­condition added:

1. hacker1337 successfully prevents other major par­ticipants in the FSC’s proof system from participat­ing in proofing the chain during the attack period.

It is so unlikely that hacker1337 would be able to create a chain that would catch up to and surpass the main chain, that condition 2 must be done in conjunction with preventing other honest nodes from making the main chain more and more difficult to catch up to. Thus a DoS type attack much also be launched in order to give hacker1337 the ability to make a chain that will surpass the main chain.

This is the point of Case II where nothing at stake would actually make a clear difference between Proof of Work and Proof of Stake.

2. Since FSC is a Proof of Stake coin, all major partici­pants and stake holders have modified their wallet software to mine on every chain fork that arises.

If sub­condition 2 were met, then sub­condition 1 does not need to be met. In this case, yes this could be very problematic. hacker1337’s alternative chain would imme­diately have the support of all nodes because those nodes support all possible forks, because, as the folklore goes, they have nothing at stake (except for the entire value of their holdings of course, but for some reason this is con­sidered nothing). Since the alternative chain will have both the support of hacker1337’s robust staking capacity and the support of greedy nodes that are staking on both chains, it would be likely that the chain that hacker1337 is staking on will become the main chain.

In order for sub­condition 2 to be met, it is essential that there is some type of benefit for the majority of stakehold­ers to automatically publish stakes to every fork that arises. Case I shows that there is no reason for honest nodes to stake on other forks with less work. Since there is no reason for honest nodes to automatically stake on all forks, the nothing at stake argument for Case II essentially ends here.

One might be able to argue at this point that the argu­ment does not end here, because what if there are just a few extra major stake holders that have modified soft­ware running to stake on every fork? In this case, the ar­gument again is not a Proof of Stake specific argument, it is the same fundamental proof system argument that a malicious actor (or in this case group) has enough proof power to write a different chain that has more work. And again, for this argument, only condition 2 needs to be met for Proof of Work, but Proof of Stake has an additional 2 conditions that need to be met.

With any proof system, Case II can be completely avoided by having diversified holding of the ability to make proof. For Proof of Work it is ideal to have diversi­fied mining pools that easily keep each other in check and make it very improbable for Case II to be feasible.

For Proof of Stake it is ideal for the coins, and therefore staking power to be distributed across many nodes that will easily keep each other in check and make it very im­probable for Case II to be feasible.

CONCLUSION

For both cases of fork with honest nodes and cases of forks with malicious actors, there is in fact “something at stake”. For the particular arguments presented against Proof of Stake, it can be said that Proof of Stake may actu­ally have more robust incentives for its peers and proof holders to stay on the main chain than does the Proof of Work system. What is worth more, a person’s entire coin holdings for Proof of Stake miners or a few minutes of electricity consumption for Proof of Work miners?

REFERENCES

[1] Etherium Wiki, https://github.com/ethereum/wiki/wiki/Problems

[2] S. King, S. Nadal, “PPCoin: Peer­toPeer Crypto­Currency with Proof­of­Stake,” 2012. https://peercoin.net/assets/paper/peer­ coin­paper.pdf