Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Addressing Nothing-at-Stake concerns in POS consensus systems  (Read 1879 times)

0 Members and 1 Guest are viewing this topic.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Addressing Nothing-at-Stake concerns in POS consensus systems
« on: August 04, 2014, 07:51:30 PM »

After the discussion at https://bitsharestalk.org/index.php?topic=6584, I realize it is really important to have a coherent argument to address the POS vs POW debate. The hard part of getting other cryptocurrency fans, who are not already enlightened about POS, over to BitShares is going to be addressing all of their concerns about POS, Nothing-at-Stake, and their belief that POW is necessary for secure consensus. The other difficult challenge that will need to be addressed is convincing the POS believers, and NXTers in particular, that there is an appropriate balance between centralization and decentralization, and that hopefully DPOS has properly struck that balance to be decentralized enough (and with low enough barrier to entry) to be corruption-free and trustless, but centralized enough to be efficient (low transaction fees and fast block production). There is already great discussion on that topic happening at https://bitsharestalk.org/index.php?topic=5564. But this topic is not about the centralization vs decentralization argument but rather the POW vs POS argument.

This is a first draft, and I would appreciate feedback. I hope I didn't make mistakes in understanding some of the details of the technologies, but please correct me if I am wrong. I am also interested in what people think about my arguments about the economics of fake blockchain history attacks for resync periods less than the threshold (and whether 6 months is even an appropriate threshold or not). I really want to try to develop an argument that can address POW supporters' concerns and convince them that POS is the right way to go.

POW vs POS consensus systems

People in the POW (Proof-of-Work) community generally accept the concept of Nothing-at-Stake as a fundamental flaw in POS (Proof-of-Stake) consensus systems that make those systems, in their view, inferior to POW consensus systems. What is Nothing-at-Stake and is it actually a legitimate concern in practical POS systems? I hope that I will be able to convince people that it is not really an issue, and that, on the contrary, POS has many advantages to POW.

All consensus systems require all participants to maintain a consistent view of a shared database as the database is modified over time. In blockchain-based consensus systems, this database is a log of appended blocks of data, in which each block (other than the first block, called the genesis block) contains a hash of the content of the previous block. This forms a cryptographically secure chain of blocks such that modifying any block requires modifying all of the blocks that come after it in the chain. In a blockchain-based consensus system in which all participants are always connected to the network, consensus can be maintained as long as all participants can agree on which block to append next. Temporary network disruptions may cause some short forks which need to be resolved quickly. So, some other mechanism is also needed to resolve these forks. Finally, since all participants cannot be online all of the time, some mechanism is needed for participants to safely resync with the network after some period of time offline.

Deciding which block to append next:

POW systems use a stochastic computational process, called mining, to determine which block everyone agrees to accept and
append to the blockchain. It is essentially a cryptographic lottery in which the probability of winning is a function of a specific form of computational power (called hashing power) and the current consensus-accepted difficulty. Anyone can verify that a block won the cryptographic lottery by looking at the block and knowing the current difficulty.

The POS system in Peercoin also uses mining to determine which block everyone agrees to accept next. However, in this case the probability of success is a function of hashing power, the current consensus-accepted network-level difficulty, and the coin-age (product of the unspent transaction output value and elapsed time since transaction was created) of the stake used for block production. The function has a very strong dependence on the coin-age such that it is more profitable to buy more coins (or stake) to increase coin-age than to buy more computing power to increase hashing power. Again, anyone can verify that a block won the lottery by looking at the block, knowing the current network-level difficulty, and verifying that the coin-age used to produce the block is legitimate (which requires having a consistent view of the blockchain up to that point).

The POS system in BitShares is called Delegated Proof of Stake (DPOS), because it allows stake owners to delegate the power that their stake provides to other users called delegates. This power is the same power that stake provides in Peercoin and other POS systems: the power to create new blocks. Given a consistent view of the blockchain up to a certain point, anyone can know who the current active delegates are, the order in which these delegates will produce blocks in the current round, and thus which specific delegate is responsible to produce the next block. A cryptographic lottery in the form of mining is not necessary to determine who earns the right to produce the next block. Random values from the non-colluding delegates of the previous round determine the random ordering of the delegates for the next round. Stakeholders are able to vote for delegates using their stake through cryptographically-secure transactions that are stored in the blockchain, and the voting activity by the stakeholders can change the set of active delegates at any time.

Resolving short forks:

Due to the nondeterministic nature of mining as well as network propagation delays, short forks are possible in both POW systems and Peercoin-like POS systems. Network propagation delays may also cause extremely short forks in DPOS as well.

POW systems resolve the forks by agreeing to build on the chain with the most work done (the sum of the difficulty values at each block up to current head block in the blockchain). If everyone follows this rule, eventually all the nodes will come to a consensus on one particular chain, thus resolving the fork.

Peercoin-like POS systems can resolve the fork by building on a chain with the most amount of some other metric, like the total amount of coin-age consumed. Again, as long as everyone follows the same rule, the network will eventually naturally converge to just one of the forks.

Although, DPOS is able to randomize the order of delegates within a round, the order of the delegates in a given round is known prior to any of the delegates producing blocks in that round. For this reason, block production order can be considered deterministic. Nevertheless, very small forks could be possible because of network issues. For example, if block N is delayed by the network for too long, the producer of block N+1 might assume that the producer of block N was not available to produce his block at his designated time slot, so instead will chain off block N-1. The producer of block N+2 may have seen block N and/or block N+1. If he saw both, he always chooses the one that is supposed to come later in time, on the other hand if he sees only one or the other, he builds off of the one he saw. Thus, the chain is built with either block N or block N+1 considered missing, but the network is able to quickly get back to a consensus on the true chain because of the deterministic ordering of block producers.

Resyncing with the network after some period of time offline:

So far, the assumption has been that all participants were well connected to the network and therefore able to easily maintain consensus on the blockchain. Under these assumptions POW does not provide any advantages over POS. But realistically, users cannot always be online. And yet, they need some way of reconnecting with the network and getting up to speed on the current state of the blockchain from where they last left it without allowing an attacker to fool them onto a fake chain. If an attacker is able to fool the user into believing in fake additions to the blockchain since the last block seen by the user's client, the attacker can break consensus and thus damage the value of the network. In particular, the user becomes vulnerable to a double-spend attack by the attacker since they think they are getting tokens of value in exchange for goods/services (due to belief in the fake transaction history) but others on the true chain know that those tokens are worthless and will therefore not accept them in exchange for goods/services.

POW resolves this issue by using the same method used to resolve short forks: pick the chain with the most work done. Attackers have no way of faking the block acceptance criteria. They need to put in the work necessary to match the difficulty requirements at that point in the blockchain. Attackers can create a fake blockchain history by putting in the necessary work, but if they have less than <50% hashing power, their accumulated amount of work will be less than the accumulated work of the true chain. As long as the true chain is made visible to the resyncing user, he can easily pick it over the fake chains.

POS tries to resolve this issue by also making it difficult for attackers to fake the block acceptance criteria. In the case of Peercoin-like POS systems, it needs to be difficult for attackers to get coin-age (which is ultimately dependent on the amount of stake in the attacker's control). In the case of DPOS, it needs to be difficult for the attacker to get control of the delegates. Because of the way delegates work, the attacker would actually need to control nearly all of the 101 delegates to fake the blockchain history (see here and here for details). However, if the attacker controlled more than 50% of the stake, he could vote in all of his own delegates. So all POS systems are ultimately vulnerable if the attacker is able to get the majority of the stake. For a POS system to be secure from fake blockchain history attacks, the majority of the stake in the system needs to be kept away from the control of an attacker during the time a user is offline. However, if an attacker was able to capture only a small minority of the stake while the user was offline, the attacker cannot create a fake blockchain that the user would accept as valid.

POW supporters like to point out that the attacker does not need to control >50% on a live system; as long as an attacker controls >50% of the stake at any point in time t on the blockchain, that attacker could easily build a fake blockchain from that point forward that would fool a user's client if its last resync point was before time t. For a completely new user synchronizing from the genesis block, this means the attacker only needs to control >50% of the stake at any point in time in the history of the blockchain. This is the meaning behind the Nothing-at-Stake name. The users who owned >50% of the stake in the system in the past, may no longer own any stake in the system in the present. While it would be foolish for a present-day >50% stake holder to harm the network, someone who held >50% of the stake in the past but holds nothing at stake in the present has nothing to lose with an attack attempt.

As bad as this may look for POS systems, with more careful analysis, it is clear it is not actually a problem. A user in a POS system will always have a checkpoint in the not-too-distant past. This checkpoint either comes from the last block of the locally-saved, trusted blockchain (or perhaps just the locally-saved hash of the last seen block), or it can be hardcoded into the particular version of the wallet. As long as that checkpoint is in the not-too-distant past, users would not be vulnerable to fake blockchain history attacks in realistic scenarios. If the checkpoint is older than some threshold, then other measures are needed. This threshold can vary depending on the circumstances of the network and the paranoia of the user, but I think a threshold of 6 months is sufficient in most realistic scenarios.

Resyncing after being offline for less than 6 months should not be a cause for concern of fake blockchain history attacks. The only way such an attack can successfully work is if the attacker obtains ownership of >50% of the stake existing at some point during that 6 month period. The attacker would like to buy old private keys at very low cost from users who had stake in the system in the 6 month period but now no longer do. They have to no longer have stake in the system otherwise they would be foolish to sell old private keys to someone whose only purpose for buying old keys is clearly to attack the system and thus reduce the value of the seller's existing stake. But the attacker will not be able to find enough private key sellers that match that criteria, because it is extremely unlikely for stakeholders with >50% of the stake to completely exit out of the system within a 6 month period. The attacker is forced to legitimately buy into the system at a high cost if he wants to attack the network. But an attacker who grows his stake over some period of time until it reaches >50% would likely not attack the network while still holding the stake, otherwise they would cause the most damage to themselves. If the attacker is able to begin and finish selling their >50% of stake during that 6 month period, then the attacker has the opportunity to carry out a fake blockchain history attack against the victim who was offline for 6 months. However, the price one pays trading assets depends on how quickly they need to finish the trade. The attacker can take his time building up the stake to not have to overpay in order to incentivize stake holders to sell, but he is forced to sell at a discount to incentivize enough people to buy to quickly sell off his stake before the 6 month deadline. Pulling off this kind of buy-sell cycle is going to cost the attacker a lot of money. It is only rational to do this if this one buy-sell cycle provides him with enough opportunity to recover his costs through double-spend attacks. But the only people he can attack are people who were offline for about 6 months. Most people would be resyncing at much higher frequencies than that, which would be really hard to attack. Trying to sell >50% of stake in one week would cause a flash crash of the price of the coin (hurting the attacker the most). Also, from a practical manner, the attacker doesn't have any good way of knowing who has been offline during the same time period they set up the buy-sell cycle to actually target these individuals. So, even if there are a decent number of people out there that the attacker could target to make his money back, it isn't trivial to identify them.

So what about resyncing after being offline for more than 6 months? With the exception of resyncing from a genesis block on a new computer, it would be a very unusual circumstance to be doing this. The vast majority of people would be resyncing on a much more frequent basis. Nevertheless, in these rare cases, users would follow the same procedure that users who are resyncing from a genesis block on a new computer would follow. First, if the user already has an up-to-date blockchain on one computer and they just want to set up their wallet on a new computer, the clients could provide an easy method for the existing trusted client to communicate a hash of a recent block to the new client. Since a user obviously trusts himself and the client he has already been using, he can carry over that trust to the new device. What about a completely new user who has never been part of this network before? Or someone who lost their hard drive (but still has a backup of their private keys) and wants to reinstall the client from scratch on their computer? In these cases, the users would rely on the snapshot hardcoded in the latest version of the client software (which would be <6 months old). A new user needs to download the client software anyway; and, they need to have some way of trusting the software they download. If the attacker was able to provide a fake client with a fake snapshot, they would again be vulnerable to the fake blockchain history attack. But if the attacker was able to provide a fake client, the user would be compromised in so many ways. The fake client could just steal the user's private keys! Or if they are using a hardware wallet, the fake client could present a false view of the blockchain to make the user think he got paid when he didn't.

Ultimately there has to be some trust when it comes to these consensus technologies. Bitcoin users may not worry about fake blockchain histories because of POW, but if their wallet is compromised none of that matters. Therefore, Bitcoin users still need to somehow trust the Bitcoin client software they run on their computers. They can compile from source, but they still need to trust that the source is safe. They can rely on other people to audit the source code and tell them it is safe, but then they are just putting the trust on the auditors. Those auditors could collude together to attack the user. If the user is really geeky, he can audit the source code himself, which would take a very long time.

Similarly, in a POS system, the users also typically rely on either the developers or auditors to tell them that a particular client is safe to use. But that also carries with it the information of the most recent snapshot. If the developers try to change the snapshot hash to carry out a massive fake blockchain attack, auditors who have the legitimate blockchain up to the time of the client upgrade stored locally on their computer can check to see that the snapshot hash does not match any of the blocks on their stored blockchain and sound the alarms. If the user does not want to trust the developer or the auditors, he can audit the source code himself, but he would also need to somehow verify the latest snapshot hash. If he has a stored version of the blockchain up to client upgrade time, he can verify it the same way the auditors did. If he is evaluating this starting from scratch, then he needs to ask people he trusts that have already been on the network for a while that the hash is correct (and thus whether this program he has on is computer is going to connect him to the thing everyone else is already connected to). This may seem like a lot of work, but it is far less work than the code audit.

Advantages of POS over POW:

The point of all of the above was to show that in realistic scenarios, the cost of a 51% attack is too high to benefit the attacker. It is typically too expensive to get 51% of hashing power of a high hash rate proof of work coin for the minimal benefits it provides (killing the network and/or difficult to acheive double-spends). And, it is typically too expensive to get 51% of the stake in a high market cap coin for the minimal benefits it provides (killing the network and/or difficult to acheive double-spends). But users trade the guarantee that fake blockchain history attacks are virtually impossible in POW systems for an assurance that fake blockchain history attacks are merely highly improbable in POS systems. If that was the only difference between POW and POS, it would make sense to use POW. However, there are a few very important ways that POS is actually superior to POW.

In a POW system, if the attacker has enough hashing power to attack a POW system, he can also attack any other weaker POW system that uses a similar hashing algorithm. On the otherhand, buying up 51% of the stake of a POS system does not give the attacker any advantage for attacking another POS system. On the contrary, it is likely going to consume the attacker's money, leaving him too little money left over to do it again. This is incredibly important when one realizes what would likely happen if someone was foolish enough to try to buy 51% of the stake in a DPOS DAC only to kill it by taking over the delegates and refusing to sign blocks. People can take a snapshot of the failed DAC, identify the unspent transaction outputs which were voting for the corrupt delegates at the time of the DAC failure, and create a new genesis block from that snapshot with those particular unspent transaction outputs made void. A DAC identical to the previous failed one is created using this new genesis block, which takes stake control away from the attacker leaving the other innocent 49% of stake holders with 100% of the stake of the new DAC. Those who sold to the attacker should be happy because they made a voluntary exchange and got out before the DAC failed; those who did not sell to the attacker are also happy because they doubled their stake in a DAC that will quickly regain its old value, which should hopefully compensate them for the brief outage of the DAC.

The other major benefit of POS over POW is the cost needed to secure the network. In a POW system, the security of the network is directly tied to the cost of mining. If the cost of mining is cheap, an attacker can afford to gain more than 50% of the hashing power. No amount of clever mining algorithms or ASICs will change that relationship. As the electricity cost per gigahash goes down, the difficulty will go up to keep the total cost of mining high enough to secure the network. At some point when growth in the value of the system saturates and it can no longer support large coin inflation to pay miners, like is the case in Bitcoin currently, the cost of securing the network will fall entirely on the transaction fees. POW will either have higher transaction fees than POS systems to secure the network, or if users do not accept transactions fees that are too high, the security of the network will get worse. POS systems do not suffer from these issues because they do not need to waste the money from fees on electricity to secure the network. And in fact, as the system gets bigger (meaning the market cap grows) the POS system becomes even more secure naturally because it becomes harder for an attacker to acquire >50% of the stake.

Offline luckybit

Re: Addressing Nothing-at-Stake concerns in POS consensus systems
« Reply #1 on: August 04, 2014, 09:34:43 PM »
After the discussion at https://bitsharestalk.org/index.php?topic=6584, I realize it is really important to have a coherent argument to address the POS vs POW debate.

POW supporters like to point out that the attacker does not need to control >50% on a live system; as long as an attacker controls >50% of the stake at any point in time t on the blockchain, that attacker could easily build a fake blockchain from that point forward that would fool a user's client if its last resync point was before time t. For a completely new user synchronizing from the genesis block, this means the attacker only needs to control >50% of the stake at any point in time in the history of the blockchain. This is the meaning behind the Nothing-at-Stake name. The users who owned >50% of the stake in the system in the past, may no longer own any stake in the system in the present. While it would be foolish for a present-day >50% stake holder to harm the network, someone who held >50% of the stake in the past but holds nothing at stake in the present has nothing to lose with an attack attempt.

As bad as this may look for POS systems, with more careful analysis, it is clear it is not actually a problem. A user in a POS system will always have a checkpoint in the not-too-distant past. This checkpoint either comes from the last block of the locally-saved, trusted blockchain (or perhaps just the locally-saved hash of the last seen block), or it can be hardcoded into the particular version of the wallet. As long as that checkpoint is in the not-too-distant past, users would not be vulnerable to fake blockchain history attacks in realistic scenarios. If the checkpoint is older than some threshold, then other measures are needed. This threshold can vary depending on the circumstances of the network and the paranoia of the user, but I think a threshold of 6 months is sufficient in most realistic scenarios.

Resyncing after being offline for less than 6 months should not be a cause for concern of fake blockchain history attacks. The only way such an attack can successfully work is if the attacker obtains ownership of >50% of the stake existing at some point during that 6 month period. The attacker would like to buy old private keys at very low cost from users who had stake in the system in the 6 month period but now no longer do. They have to no longer have stake in the system otherwise they would be foolish to sell old private keys to someone whose only purpose for buying old keys is clearly to attack the system and thus reduce the value of the seller's existing stake. But the attacker will not be able to find enough private key sellers that match that criteria, because it is extremely unlikely for stakeholders with >50% of the stake to completely exit out of the system within a 6 month period. The attacker is forced to legitimately buy into the system at a high cost if he wants to attack the network. But an attacker who grows his stake over some period of time until it reaches >50% would likely not attack the network while still holding the stake, otherwise they would cause the most damage to themselves. If the attacker is able to begin and finish selling their >50% of stake during that 6 month period, then the attacker has the opportunity to carry out a fake blockchain history attack against the victim who was offline for 6 months. However, the price one pays trading assets depends on how quickly they need to finish the trade. The attacker can take his time building up the stake to not have to overpay in order to incentivize stake holders to sell, but he is forced to sell at a discount to incentivize enough people to buy to quickly sell off his stake before the 6 month deadline. Pulling off this kind of buy-sell cycle is going to cost the attacker a lot of money. It is only rational to do this if this one buy-sell cycle provides him with enough opportunity to recover his costs through double-spend attacks. But the only people he can attack are people who were offline for about 6 months. Most people would be resyncing at much higher frequencies than that, which would be really hard to attack. Trying to sell >50% of stake in one week would cause a flash crash of the price of the coin (hurting the attacker the most). Also, from a practical manner, the attacker doesn't have any good way of knowing who has been offline during the same time period they set up the buy-sell cycle to actually target these individuals. So, even if there are a decent number of people out there that the attacker could target to make his money back, it isn't trivial to identify them.

So what about resyncing after being offline for more than 6 months? With the exception of resyncing from a genesis block on a new computer, it would be a very unusual circumstance to be doing this. The vast majority of people would be resyncing on a much more frequent basis. Nevertheless, in these rare cases, users would follow the same procedure that users who are resyncing from a genesis block on a new computer would follow. First, if the user already has an up-to-date blockchain on one computer and they just want to set up their wallet on a new computer, the clients could provide an easy method for the existing trusted client to communicate a hash of a recent block to the new client. Since a user obviously trusts himself and the client he has already been using, he can carry over that trust to the new device. What about a completely new user who has never been part of this network before? Or someone who lost their hard drive (but still has a backup of their private keys) and wants to reinstall the client from scratch on their computer? In these cases, the users would rely on the snapshot hardcoded in the latest version of the client software (which would be <6 months old). A new user needs to download the client software anyway; and, they need to have some way of trusting the software they download. If the attacker was able to provide a fake client with a fake snapshot, they would again be vulnerable to the fake blockchain history attack. But if the attacker was able to provide a fake client, the user would be compromised in so many ways. The fake client could just steal the user's private keys! Or if they are using a hardware wallet, the fake client could present a false view of the blockchain to make the user think he got paid when he didn't.

Ultimately there has to be some trust when it comes to these consensus technologies. Bitcoin users may not worry about fake blockchain histories because of POW, but if their wallet is compromised none of that matters. Therefore, Bitcoin users still need to somehow trust the Bitcoin client software they run on their computers. They can compile from source, but they still need to trust that the source is safe. They can rely on other people to audit the source code and tell them it is safe, but then they are just putting the trust on the auditors. Those auditors could collude together to attack the user. If the user is really geeky, he can audit the source code himself, which would take a very long time.

Similarly, in a POS system, the users also typically rely on either the developers or auditors to tell them that a particular client is safe to use. But that also carries with it the information of the most recent snapshot. If the developers try to change the snapshot hash to carry out a massive fake blockchain attack, auditors who have the legitimate blockchain up to the time of the client upgrade stored locally on their computer can check to see that the snapshot hash does not match any of the blocks on their stored blockchain and sound the alarms. If the user does not want to trust the developer or the auditors, he can audit the source code himself, but he would also need to somehow verify the latest snapshot hash. If he has a stored version of the blockchain up to client upgrade time, he can verify it the same way the auditors did. If he is evaluating this starting from scratch, then he needs to ask people he trusts that have already been on the network for a while that the hash is correct (and thus whether this program he has on is computer is going to connect him to the thing everyone else is already connected to). This may seem like a lot of work, but it is far less work than the code audit.

Advantages of POS over POW:

The point of all of the above was to show that in realistic scenarios, the cost of a 51% attack is too high to benefit the attacker. It is typically too expensive to get 51% of hashing power of a high hash rate proof of work coin for the minimal benefits it provides (killing the network and/or difficult to acheive double-spends). And, it is typically too expensive to get 51% of the stake in a high market cap coin for the minimal benefits it provides (killing the network and/or difficult to acheive double-spends). But users trade the guarantee that fake blockchain history attacks are virtually impossible in POW systems for an assurance that fake blockchain history attacks are merely highly improbable in POS systems. If that was the only difference between POW and POS, it would make sense to use POW. However, there are a few very important ways that POS is actually superior to POW.

In a POW system, if the attacker has enough hashing power to attack a POW system, he can also attack any other weaker POW system that uses a similar hashing algorithm. On the otherhand, buying up 51% of the stake of a POS system does not give the attacker any advantage for attacking another POS system. On the contrary, it is likely going to consume the attacker's money, leaving him too little money left over to do it again. This is incredibly important when one realizes what would likely happen if someone was foolish enough to try to buy 51% of the stake in a DPOS DAC only to kill it by taking over the delegates and refusing to sign blocks. People can take a snapshot of the failed DAC, identify the unspent transaction outputs which were voting for the corrupt delegates at the time of the DAC failure, and create a new genesis block from that snapshot with those particular unspent transaction outputs made void. A DAC identical to the previous failed one is created using this new genesis block, which takes stake control away from the attacker leaving the other innocent 49% of stake holders with 100% of the stake of the new DAC. Those who sold to the attacker should be happy because they made a voluntary exchange and got out before the DAC failed; those who did not sell to the attacker are also happy because they doubled their stake in a DAC that will quickly regain its old value, which should hopefully compensate them for the brief outage of the DAC.

The other major benefit of POS over POW is the cost needed to secure the network. In a POW system, the security of the network is directly tied to the cost of mining. If the cost of mining is cheap, an attacker can afford to gain more than 50% of the hashing power. No amount of clever mining algorithms or ASICs will change that relationship. As the electricity cost per gigahash goes down, the difficulty will go up to keep the total cost of mining high enough to secure the network. At some point when growth in the value of the system saturates and it can no longer support large coin inflation to pay miners, like is the case in Bitcoin currently, the cost of securing the network will fall entirely on the transaction fees. POW will either have higher transaction fees than POS systems to secure the network, or if users do not accept transactions fees that are too high, the security of the network will get worse. POS systems do not suffer from these issues because they do not need to waste the money from fees on electricity to secure the network. And in fact, as the system gets bigger (meaning the market cap grows) the POS system becomes even more secure naturally because it becomes harder for an attacker to acquire >50% of the stake.

I don't consider Proof of Work secure. With Proof of Work you have to trust hardware manufactuers and developers absolutely. With Proof of Stake you only have to trust developers absolutely.

So I might have to trust Bytemaster and his development team but at least I can read the code and kind of see what is going on. If I'm really paranoid I can compile the code myself.

Proof of Work requires I trust a bunch of different companies, mining pools and the core developers. If they all happen to be in collusion then it's centralized and corrupt.

Decentralization allows an organization to be more sustainable. A centralized network with humans in it will become corrupt eventually as corrupt humans enter into the key positions or as the humans in those positions get corrupted by the influence of other humans.

So the more decentralized it is the more anti-collusion properties it has. But there is the possibility that you could have more collusion resistance then necessary. The other challenge is coercion resistance which is difficult as well and the larger, more diverse, and more spread out the people are the less likely it is to collapse if certain people are coerced.

Delegates are almost like a board of directors or something similar. The reason it is collusion resistant is because you can detect when collusion is happening and quickly fire the delegates you can't trust.  In addition to this you don't have to trust hardware manufacturers or pool operators with the security of the entire network because Proof of Stake does not require any of that. The risk of coercion is also limited because once again delegates who show signs of being coerced can be removed.

It's not perfect yet and we don't know how much decentralization we will require. We don't know how long a delegate can last in these positions without being corrupted or how much damage a group of corrupt delegates could do. But in my opinion there are at least some self healing properties built in while with Proof of Work you don't have any of that.

In Proof of Work you basically have to trust the miners, the developers, and the hardware manufacturers. You can't fire these people on the spot and replace them if you find they are corrupt.

For example I don't think ASICs are good for security. I think that ASICs at this point are a security vulnerability because it centralizes way too much power into hardware manufacturers. But can I vote out the core developers who will not switch away from SHA-256? Bitcoin for better or worse is unchangeable. It's frozen in time with SHA-256, with increasingly centralized hashing power, with very centralized knowledge around the developers.  Developers will not lift the Max_Block_Size limit because of some fear of centralization but those same developers want to stick with SHA-256 which promotes centralization and insecurity?

So one point I want to make and a meme I would like people to remember is that security isn't difficulty. Bitcoin and Litecoin have a very high difficulty but that high difficulty comes from ASICs and that is a very centralized technology. That means these blockchains are centralizing around ASIC manufacturers which are pumping up the difficulty to make it seem more secure when in reality the way to make it secure is to rely on general purpose hardware spread across as many different computers as possible.

I don't consider it secure at all if we end up with one major monopoly which creates all the ASICs for the entire chain, which can mine in secret, and control the entire fate of Bitcoin/Litecoin. I don't think we should be forced to trust them and they only provide a higher difficulty which gives the illusion that things are more secure when in reality there could be a few people or eventually just one person who controls all that hashrate.
« Last Edit: August 04, 2014, 09:37:24 PM by luckybit »
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: Addressing Nothing-at-Stake concerns in POS consensus systems
« Reply #2 on: August 04, 2014, 10:15:14 PM »
Yup. All very great points for the decentralization vs centralization argument. I agree that POW is in practice very centralized.

I have to disagree with the argument that you have to trust the hardware manufacturers. The ASICs are simple enough that one can verify they can't do anything malicious. You don't need to trust the ASIC manufacturers; you need to trust the people who can afford to buy and use them. And, that goes back to the whole centralization argument. POW will naturally have the tendency to centralize and it is a problem.

Those are all great arguments for the centralization vs decentralization debate, but in this thread my intention was more to focus the discussion on blockchain forgeability. In particular, I would like have good arguments to show POW supporters that in practice it can be nearly as difficult to forge plausible fake blockchains in well designed POS systems as it is in POW with their largest work criterion.

I also realize I have been too kind to Peercoin POS in my first draft, since it does not at all address the game theory aspect that can lead to a lack of consensus when building the chain in naive POS systems like Peercoin. DPOS is of course not vulnerable to that because delegates will lose their jobs if they double sign a block. It is really important to clarify those differences between DPOS and the rest of POS. I just have to figure out how to appropriately put that in there now.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
Re: Addressing Nothing-at-Stake concerns in POS consensus systems
« Reply #3 on: August 04, 2014, 11:09:14 PM »
Whoever and wherever you came from, we can use more people like you.

I would suggest if possible to make a shorter version of your article. 

People who are busy are going to be hard-pressed to give your write up the time it deserves.

Shorter bullet points are better and allows people to take your succinct and insightful points elsewhere.

Thanks for helping out Bitshares.

Would you mind this being put on wiki.bitshares.org ?
I speak for myself and only myself.

Offline bytemaster

Re: Addressing Nothing-at-Stake concerns in POS consensus systems
« Reply #4 on: August 04, 2014, 11:19:40 PM »
I thought it was well written

I would like to include something like this on our blog




Sent from my iPhone using Tapatalk
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline luckybit

Re: Addressing Nothing-at-Stake concerns in POS consensus systems
« Reply #5 on: August 04, 2014, 11:43:52 PM »
Yup. All very great points for the decentralization vs centralization argument. I agree that POW is in practice very centralized.

I have to
 disagree with the argument that you have to trust the hardware manufacturers. The ASICs are simple enough that one can verify they can't do anything malicious. You don't need to trust the ASIC manufacturers; you need to trust the people who can afford to buy and use them. And, that goes back to the whole centralization argument. POW will naturally have the tendency to centralize and it is a problem.
I disagree on this. There are hardware trojans which cannot easily be detected and it's not so much in just the design of the chipset but also in the foundries which make them. My intention in my response is to show that PoW is more centralized, less cost efficient, and theoretically more insecure than DPoS.

For security you have to trust everyone in the process chain which produces the chipset. So for that reason I would say you're trusting hardware manufacturers not to do anything malicious when clearly it's theoretically possible which makes it just as valid of an attack as the "nothing at stake" attack. The risk of either of these attacks in practice might be quite low when there is a market cap in the 8 billion dollar range but if it's in the trillion dollar range I wouldn't feel so safe with PoW anymore if the chipsets are special purpose, created by a limited number of manufacturers, because when something is special purpose it means it's only designed to do one thing and that invites risk.

The people making ASICs for mining Bitcoins are making a chipset which only does that and this means if they want to try to slip a trojan into it then it's much easier to do. A general purpose CPU like Intel and AMD it is much harder because these chips aren't exclusively set up to mine Bitcoin SHA-256. I will reveal more about this in private but I have documents which show there is a theoretical vulnerability here.

No one has done either of these attacks yet but if the market cap were high enough that someone could gain by attempting it then they might. Also with ASICs there is nothing stopping miners from mining in secret with their own chipsets to give themselves a permanent unfair advantage. This means the only way to mine will be to make the chip yourself otherwise it's an entirely unfair and in my opinion also insecure process.

My response to PoW supporters is why do you think it makes sense to trust so many entites when you could switch to PoS which doesn't require as much trust? There is no defense against collusion in PoW and you're assuming hardware manufacturers and developers wont get together in secret to control the network.
--------------------------------------------------------------------

Now onto what this thread is really about. As for blockchain forgeability I think it is a theoretical attack but if you conduct a risk assessment you'll find that the probability of that attack being successful is very slim. It's even slim for Peercoin and while it is very possible it's also very improbable to occur. I would assume if the market cap for Peercoin were to get high enough it would be attempted and this is assuming the Peercoin community does nothing between now and that time in the future to modify their protocol.

DPoS I don't view as being vulnerable to this at all. Nxt probably isn't vulnerable either but I will have to learn more about transparent forging to be sure.

If it requires 50% of the delegates to do under DPoS then the only way I could see this being possible is through coercion of the individuals who control 50% of the delegates. If this attack were to ever take place it would be stopped as these delegates would eventually be found to be either coerced or colluding and fired. Once they get fired more than likely the future delegates would be selected based on the measures they would take to prevent similar attacks such as that from occurring in the future.

Also the economics make it so delegates will not want to be fired as the market cap gets higher. At the same time the risk of attack I would expect to go up as the market cap gets higher. So if the incentives work you would expect more of the delegates to have information security backgrounds, and to be much more organized in their operations as the market cap rises. The chance of coercion would be limited, and collusion seems very unlikely as the network matures (because there will be a wider pool to select delegates from).

I think the main difference between PoW and DPoS is that DPoS is adaptive. It is far more flexible. In my opinion that is a better foundation to build upon than something static and currently the Bitcoin PoW seems static.

You rightly identify that DPoS in particular is more cost efficient to secure. We reach this conclusion from different angles but this is something we agree on. When I factor in the cost I'm assuming that there is a cost associated with secure hardware manufacturing as well and that we cannot trust the hardware in the long term just as we cannot trust the software. I concluded that the more entities you have to trust to secure the network the more costly it is to secure it.

So if you have to audit hardware and software, if you have to trust hardware and software makers, if you have to somehow set things up so they cannot collude with each other, then PoW is at an extreme disadvantage. Also PoW can't adapt quickly in practice so while it might be able to claim it's secure from a theoretical blockchain forgeability attack it comes at the cost of less long term sustainability and insecurity against other kinds of attacks.

« Last Edit: August 05, 2014, 12:12:13 AM by luckybit »
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Stan

  • Hero Member
  • *****
  • Posts: 2809
  • You need to think BIGGER, Pinky...
    • View Profile
    • Cryptonomex
  • BTS: Stan
Re: Addressing Nothing-at-Stake concerns in POS consensus systems
« Reply #6 on: August 05, 2014, 12:03:17 AM »
I thought it was well written

I would like to include something like this on our blog


Let me know when this reaches "final draft" and I'll post it on the blog.
Anything said on these forums does not constitute an intent to create a legal obligation or contract of any kind.   These are merely my opinions which I reserve the right to change at any time.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2487
    • View Profile
Re: Addressing Nothing-at-Stake concerns in POS consensus systems
« Reply #7 on: August 05, 2014, 01:33:35 AM »
+1 for the precise but very understandable language! Many (in this and other fields) need to hide their lack of clear concept with obscure models and fancy words.
 

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12175
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: Addressing Nothing-at-Stake concerns in POS consensus systems
« Reply #8 on: August 05, 2014, 08:11:14 AM »
+1 for the precise but very understandable language! Many (in this and other fields) need to hide their lack of clear concept with obscure models and fancy words.
 
+%5

Finally we have some very good writers who just "get it"!! Awesome work!
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2487
    • View Profile
Re: Addressing Nothing-at-Stake concerns in POS consensus systems
« Reply #9 on: January 07, 2015, 11:32:36 PM »
Talking to bitcoiners the nothing at stake problem is the #1 issue they bring up. Would it make sense to put this to a more prominent place (blog or bm blog)?

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: Addressing Nothing-at-Stake concerns in POS consensus systems
« Reply #10 on: January 08, 2015, 01:09:27 AM »
Talking to bitcoiners the nothing at stake problem is the #1 issue they bring up. Would it make sense to put this to a more prominent place (blog or bm blog)?

I am definitely in favor of having a good argument against Nothing-at-Stake on somewhere like bytemaster's blog.

And there are definitely points from the OP that I think make sense to reuse in that argument, but as it stands I am not confident enough in it as a great comprehensive rebuttal to Nothing-at-Stake. I think a great argument would formalize the DPOS consensus algorithm better and go through various possible attacks and explain the economics for each. This is a significant undertaking. Also, I don't even feel confident enough in my knowledge of DPOS details (fork resolution, chain reorganization limits, etc.) to do an accurate job myself. But I am happy to work with a knowledgeable dev on this.

A first step might be to argue how we ultimately use social consensus as a way of deciding which fork is real, but DPOS allows us to maintain consensus automatically as long as certain assumptions hold (enough delegates don't double sign, a fake blockchain history is not created using older keys of delegates/stakeholders that were either compromised or purchased for cheap, etc.). We hold the position that those assumptions can be broken but it is incredibly rare (convincing people of this through economical/psychological arguments is another large undertaking) that the inconvenience of having to resort to social consensus in those situations is acceptable to the users as it allows us to gain incredibly efficiency (fast confirmation speed, low cost, environmentally friendly, etc.) in the network when it is operating normally.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2487
    • View Profile
Re: Addressing Nothing-at-Stake concerns in POS consensus systems
« Reply #11 on: January 08, 2015, 11:09:03 AM »
Talking to bitcoiners the nothing at stake problem is the #1 issue they bring up. Would it make sense to put this to a more prominent place (blog or bm blog)?

I am definitely in favor of having a good argument against Nothing-at-Stake on somewhere like bytemaster's blog.

And there are definitely points from the OP that I think make sense to reuse in that argument, but as it stands I am not confident enough in it as a great comprehensive rebuttal to Nothing-at-Stake. I think a great argument would formalize the DPOS consensus algorithm better and go through various possible attacks and explain the economics for each. This is a significant undertaking. Also, I don't even feel confident enough in my knowledge of DPOS details (fork resolution, chain reorganization limits, etc.) to do an accurate job myself. But I am happy to work with a knowledgeable dev on this.

A first step might be to argue how we ultimately use social consensus as a way of deciding which fork is real, but DPOS allows us to maintain consensus automatically as long as certain assumptions hold (enough delegates don't double sign, a fake blockchain history is not created using older keys of delegates/stakeholders that were either compromised or purchased for cheap, etc.). We hold the position that those assumptions can be broken but it is incredibly rare (convincing people of this through economical/psychological arguments is another large undertaking) that the inconvenience of having to resort to social consensus in those situations is acceptable to the users as it allows us to gain incredibly efficiency (fast confirmation speed, low cost, environmentally friendly, etc.) in the network when it is operating normally.
Sounds great! I will try to help as much as I can (maybe with the psychological part).
Also see http://www.reddit.com/r/CryptoCurrency/comments/2rpear/nothing_at_stake_nothing_to_fear/http://bytemaster.bitshares.org/article/2015/01/08/Nothing-at-Stake-Nothing-to-Fear/?r=refer-o-matic
« Last Edit: January 08, 2015, 01:32:03 PM by delulo »

Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BTS: starspirit
Re: Addressing Nothing-at-Stake concerns in POS consensus systems
« Reply #12 on: January 14, 2015, 12:21:03 AM »
arhag,

I finally read your full post here after procrastinating on it for ages, because I'm not very knowledgeable on the technicals of PoW v PoS. However I must belatedly credit you on an excellent post - I found it very simple and informative.

 +5% +5%


 

Google+