PoS is far inferior to PoW - why are so many people advocating switching to PoS

[Daedelus]

2. It does not bother to mention how many calculations are needed to secretly build a valid longer chain with a small stake in a specific PoS system. This is like saying sha512 algo can be cracked, without calculating how many tries one needs to crack it...

I'm eagerly awaiting a revised version that calculates needed computing power to n@s-attack, let's say current version of Nxt.

The tedious details that would go into trying to figure out precisely how NxT would be attacked don't resolve the problem that the paper is talking about, and more importantly, it's not the responsibility of us to put forward the security model.

The 'tedious detail' is what your argument is and relies upon. Until you provide this and show there is a problem, then there is no problem as it hasn't been articulated. It is in the same camp as stating categorically "The numbers 3 and 5 can never be used to give a sum of 23" and then not even attempting any calculations to check you are correct, as it isn't your "responsibility to put forward summation models".  



Below is paraphrased from Come-from-Beyond and is a question that was posed in May 2014. It has still gone unanswered (publicly at least, the silence of the initial Nothing at Stake zealots is telling I think).



Alice wants to attack the blockchain.
She owns private keys of 400 accounts totalling to 75% of the stake.
She is planning to rewrite the history from block 5'000.
Legit chain is at block 5'300 (less than 720).
Cumulative difficulty at block 5'000 is 8'000'000.
Cumulative difficulty at block 5'300 is 9'000'000.
How many SHA256 operations in average it's necessary to do to find a branch where cumulative difficulty at block 5'300 is at least 9'000'001?
Hint: Blocks from 5'000 to 5'300 were forged by 100% of the stake.



Without a detailed further explanation of the so called Nothing at Stake 'problem', further discussion is quite useless.

Bump.

I am genuinely interested in the answer,  I can only assume you are all busy with your calculators right now. I can wait.



My follow up question would then be...

Would doing this many SHA256 operations be at no cost?


If you still believe this would be free, check would it be possible to do. i.e. what is likelihood that you can do this many SHA256 operations to recalculate a better chain within the 720 block time limit?

[1714729443]

1714729443

[1714729443]

1714729443

[1714729443]

1714729443

[1714729443]

1714729443

[1714729443]

1714729443

[gatra]

2. It does not bother to mention how many calculations are needed to secretly build a valid longer chain with a small stake in a specific PoS system. This is like saying sha512 algo can be cracked, without calculating how many tries one needs to crack it...

I'm eagerly awaiting a revised version that calculates needed computing power to n@s-attack, let's say current version of Nxt.

The tedious details that would go into trying to figure out precisely how NxT would be attacked don't resolve the problem that the paper is talking about, and more importantly, it's not the responsibility of us to put forward the security model.

The 'tedious detail' is what your argument is and relies upon. Until you provide this and show there is a problem, then there is no problem as it hasn't been articulated. It is in the same camp as stating categorically "The numbers 3 and 5 can never be used to give a sum of 23" and then not even attempting any calculations to check you are correct, as it isn't your "responsibility to put forward summation models".  



Below is paraphrased from Come-from-Beyond and is a question that was posed in May 2014. It has still gone unanswered (publicly at least, the silence of the initial Nothing at Stake zealots is telling I think).



Alice wants to attack the blockchain.
She owns private keys of 400 accounts totalling to 75% of the stake.
She is planning to rewrite the history from block 5'000.
Legit chain is at block 5'300 (less than 720).
Cumulative difficulty at block 5'000 is 8'000'000.
Cumulative difficulty at block 5'300 is 9'000'000.
How many SHA256 operations in average it's necessary to do to find a branch where cumulative difficulty at block 5'300 is at least 9'000'001?
Hint: Blocks from 5'000 to 5'300 were forged by 100% of the stake.



Without a detailed further explanation of the so called Nothing at Stake 'problem', further discussion is quite useless.

Bump.

I am genuinely interested in the answer,  I can only assume you are all busy with your calculators right now. I can wait.



My follow up question would then be...

Would doing this many SHA256 operations be at no cost?


If you still believe this would be free, check would it be possible to do. i.e. what is likelihood that you can do this many SHA256 operations to recalculate a better chain within the 720 block time limit?

There is no answer because the question makes no sense.
first answer this: why do you think there are many SHA256 operations involved? how would a large hashrate benefit an attacker?
it's not a matter of hashrate, it's 300 blocks * 60 seconds * 400 accounts = 7200000. Hashing that many SHA256 takes less than one second on a modern cpu.

The question is not clear because it talks about "the stake", but what is "the stake"? the total amount of coins? or the amount of coins actively forging at the given time? were your 400 accounts forging on the main chain at block 5000 or not?

If you control more coins at block 5000 than those that were forging at block 5000 then you can simply rewrite everything.

[Daedelus]

Alice wants to attack the blockchain.
She owns private keys of 400 accounts totalling to 75% of the stake.
She is planning to rewrite the history from block 5'000.
Legit chain is at block 5'300 (less than 720).
Cumulative difficulty at block 5'000 is 8'000'000.
Cumulative difficulty at block 5'300 is 9'000'000.
How many SHA256 operations in average it's necessary to do to find a branch where cumulative difficulty at block 5'300 is at least 9'000'001?
Hint: Blocks from 5'000 to 5'300 were forged by 100% of the stake.

There is no answer because the question makes no sense.
first answer this: why do you think there are many SHA256 operations involved? how would a large hashrate benefit an attacker?
it's not a matter of hashrate, it's 300 blocks * 60 seconds * 400 accounts = 7200000. Hashing that many SHA256 takes less than one second on a modern cpu.

The question is not clear because it talks about "the stake", but what is "the stake"? the total amount of coins? or the amount of coins actively forging at the given time? were your 400 accounts forging on the main chain at block 5000 or not?

If you control more coins at block 5000 than those that were forging at block 5000 then you can simply rewrite everything.

why do you think there are many SHA256 operations involved?
That is what is required to calculate a longer chain that stands a chance of being accepted as legitimate.

The better chain needs to almost mirror the honest one in terms of certain properties.

The retargeting algo in Nxt plays an important role in this.

how would a large hashrate benefit an attacker?
See above.

it's not a matter of hashrate, it's 300 blocks * 60 seconds * 400 accounts = 7200000
Which POS implementation is this possible in? It doesn't look very secure.

what is "the stake"?
The stake is Alice's coins, 75% of all coins in existence.

were your 400 accounts forging on the main chain at block 5000 or not?
Assume worst case for coin, best in favour of the attacker.

[DumbFruit]

I have no idea what you're going on about.

[Daedelus]

I have no idea what you're going on about.

I know   Search nxtforum for "BaseTarget adjustment algorithm" thread (leads to Blind Shooter algorithm and how it interacts with the retargeting algo, in the same thread) if you are genuinely interested. I get the impression no one on BTT is, they just listen to the echo and then repeat it.

The above makes the Nothing at Stake 'problem' wishful thinking. At least in Nxt it does.

[digitalindustry]

This is what I have been repeatedly saying. As long as the Cartel controls Bitcoin, they shouldn't start arguing about vulnerabilities in other systems or claim they are decentralized. All it needs is the government or a bad actor to gain control of a couple of pools and Bitcoin is done.

At least with PoS, the attacker has to gain control of the coins through some means. Hacking exchanges won't give them enough so they will actually have to buy out the coins. Thats another key difference, anybody holding a PoS coin has a say in the network, Bitcoin holders don't.

now think harder and see if you can find an answer that would be the the best possible solution for both problems.

wait!

what about a continual PoW

and a PoS

or just continual PoW

[phillipsjk]

I have no idea what you're going on about.

I know   Search nxtforum for "BaseTarget adjustment algorithm" thread (leads to Blind Shooter algorithm and how it interacts with the retargeting algo, in the same thread) if you are genuinely interested. I get the impression no one on BTT is, they just listen to the echo and then repeat it.

The above makes the Nothing at Stake 'problem' wishful thinking. At least in Nxt it does.

I tried that: https://nxtforum.org/proof-of-stake-algorithm/basetarget-adjustment-algorithm/ (linked from cite note 9 on the Wiki) requires me to log in.

A bank such a JP Morgan with a FPGA super computer can conceivably do it (without figuring out how many operations are actually required).

Block generation time is targeted at 60 seconds, but variations in probabilities have resulted in an average block generation time of 80 seconds, with occasionally very long block intervals. An adjustment to the forging algorithm has been suggested by mthcl and modeled by Sebastien256 on NxtForum.org[9].

According to that, the updated algorithm was as suggestion. How are we supposed to analyze the specific PoS algorithm in NXT if you keep moving the goal-posts?

[devphp]

A bank such a JP Morgan with a FPGA super computer can conceivably do it (without figuring out how many operations are actually required).

I wouldn't be wrong to suppose no math will follow to back this statement, would I?

[Daedelus]

A bank such a JP Morgan with a FPGA super computer can conceivably do it (without figuring out how many operations are actually required).

How can you be so sure, should I take you at your word.

Try this one.
https://nxtforum.org/proof-of-stake-algorithm/forging-2088/msg35543/#msg35543
It is also in the whitepaper section.

Here is OP of BaseTarget adjustment Algorithm without any following discussion. I'd argue the discussion is more illuminating. mthcl is a Maths Professor on sabbatical and has spent many hours looking at the Nxt algos, suggesting this improvement. Sabastian256, a Maths Phd, did the required modelling that mthcl needed throughout the thread.

Blind Shooter/Retargetting you will have to log in for if you're interested, it is in the same sub forum.

Some thoughts about the BaseTarget adjustment algorithm, described here. In more mathematical terms, this algorithm dynamically readjusts the rate of the Exponential random variable which is approximately the time until next block, to ensure that #[blocks per period of time] remains constant regardless of how much stake is actually forging.

The algorithm currently in use can be described in the following way (R_n stands for the rate of that Exponential random variable at time n):

__________________________________________________
R₀=1;

Let X be an Exponential random variable with rate R_n (one may put X=(1/R_n) ln U, where U is a Uniform[0,1] random variable)

if X ≥ 2, then R_n+1=2R_n

if X ≤ 1/2, then R_n+1=R_n/2

if X ∈ (1/2,2), then R_n+1=XR_n  (note that XR_n = ln U, so  XR_n is an Exponential(1) random variable)
___________________________________________________

The idea was R_n should fluctuate around 1, so we'll have one block per minute in average. In fact, it turns out that this is not the case. Additionally, with this algorithm the rate occasionally becomes rather close to 0, leading to long intervals between the blocks (note that the expectation of an Exponential(r) random variable equals 1/r). The first problem (average rate is not 1) is easy to correct by a simple rescaling, but the second one (occasional very long block time) is more serious, since it is an inherent feature of this algorithm.

So, I propose a modified version of this algorithm. Let γ ∈ (0,1] be a parameter (γ=1 corresponds to the current version of the algorithm). Then (abbreviating also β=(1 - γ/2)^-1)

_________________________________________________
R₀=1;

Let X be an Exponential random variable with rate R_n (one may put X=(1/R_n) ln U, where U is a Uniform[0,1] random variable)

if X ≥ 2, then R_n+1=2R_n

if X ≤ 1/2, then R_n+1=R_n/β

if X ∈ (1,2), then R_n+1=XR_n

if X ∈ (1/2,1), then R_n+1=(1-γ(1-X))R_n
___________________________________________________

In words, we make it easier to increase the rate than to decrease it (which happens when X is "too small"). This is justified by the following observation: if Y is an Exponential(1) random variable, then P[Y<1/n]=1-e^-1/n≈1/n and P[Y>n]=e^-n, and the latter is much smaller, than the former. In other words, the Exponential distribution is quite "asymmetric"; even for n=2, we get P[Y<1/2]≈0.393 and P[Y>2]≈0.135.

Now, to evaluate how does the modified algorithm works, there are two methods. First, one can do simulations. Otherwise, we can write the balance equation for the density f of the stationary measure of the above process in the following way:

(1)   f(x) = e^-xf(x/2)/2 + β(1-e^-βx/2)f(βx) + e^-x ∫ f(s) ds + γ^-1e^-x/γ  ∫ e^(1-γ)s/γ f(s) ds, where the first integral is taken from x/2 to x, and the second one from x to βx.

Here, f(x) is positive for x>0 and ∫f(s) ds (from 0 to ∞) = 1 (since f is a density).

The problem is that I don't know, how to solve the equation (1). I mean, most probably there is no closed-form analytic solution, and I'm not able to provide a numerical solution because of my lack of knowledge how to do it   But, provided that the solution of (1) is available, the quantities of interest may be obtained in the following way:

mean time to next block =  ∫s^-1f(s) ds (from 0 to ∞), and
probability that the rate becomes less than ε equals  ∫ f(s) ds (from 0 to ε)  (observe that if the rate is ε, then one should expect the next blocktime to be roughly 1/ε).

Hopefully, with some reasonable γ (say, γ=1/2), this algorithm would perform much better than the current one. So, I think that it would be important to investigate this (either by doing simulations, or by solving (1) numerically), since we'll probably need this retargeting algorithm even after the TF is in place.

[phillipsjk]

A bank such a JP Morgan with a FPGA super computer can conceivably do it (without figuring out how many operations are actually required).

I wouldn't be wrong to suppose no math will follow to back this statement, would I?

I say as much in the quote. Though, an FPGA should be an order of magnitude faster than a General-purpose computer (or even PoW hasher) for that type of problem.

[Daedelus]

A bank such a JP Morgan with a FPGA super computer can conceivably do it (without figuring out how many operations are actually required).

I wouldn't be wrong to suppose no math will follow to back this statement, would I?

I say as much in the quote. Though, an FPGA should be an order of magnitude faster than a General-purpose computer (or even PoW hasher) for that type of problem.

The discussion I saw estimated that recalculating a better chain to attack Nxt would take the current bitcoin network hashrate several times the age of the Universe to do. I wouldn't like to comment but I haven't seen any advances on that which are backed by any calcs.

You would also need to calculate this attack chain in 720 blocks otherwise it would be rejected.

[gatra]

why do you think there are many SHA256 operations involved?
That is what is required to calculate a longer chain that stands a chance of being accepted as legitimate.

The better chain needs to almost mirror the honest one in terms of certain properties.

The retargeting algo in Nxt plays an important role in this.

how would a large hashrate benefit an attacker?
See above.

We are talking about POS, right? and specifically you are talking about NXTs implementation, right?
The security of all POS coins is based on the premise that getting 75% of stake is hard, and it's not based on any brute force calculation of SHA256 hashes. Please explain exactly how would a large hashrate benefit an attacker?
No special hashrate (more than the number of accounts per second), is required to create the main chain, and also not any special hashrate would be required to create an attacking chain. You only need the staking power.
Regardless of the baseTarget ajustments (which I seen in the Java code for NXT v1.3.3, not in any documentation because reading NXT docs is terrible, you never know what is actually implemented and what not), if you have more coins than those that were at stake then you can rewrite up to 720 blocks. No need for much hashrate. This applies to all POS implementations that I have seen.

[DumbFruit]

NxT hashes every transaction consecutively in a block which is ultimately called the "payload". Is this what you're referring to?

    MessageDigest digest = Crypto.sha256();
        for (Transaction transaction : newTransactions.values()) {
            digest.update(transaction.getBytes());
        }

byte[] payloadHash = digest.digest();

https://github.com/Blackcomb/nxt/blob/master/src/java/nxt/BlockchainProcessorImpl.java


The BaseTarget thing is described here;
https://github.com/Blackcomb/nxt/blob/master/src/java/nxt/BlockImpl.java

However, that doesn't require very many SHA256 operations. It just relies on the hashes of previous signatures to figure out what the appropriate time until the next block should be at a minimum. It seems like reorgs would be trivial to pull off if you are/were a major stakeholder, and you wouldn't need anywhere near 51% of the coins.

[CoinHoarder]

More discussion about NaS attack: https://bitsharestalk.org/index.php?topic=6638.0

"Short fork" differences;

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.

Since "if he saw both, he always chooses the one that is supposed to come later in time", stakeholder 101 could choose not to include any of the previous 100 blocks because they were "too late".

There are only 101 stakeholders that matter in bitshares, I suppose the rest can all suck on a salty sausage? In which case, you really don't need anywhere near 51% of the stake, you only need enough so that you are wealthier than the next 50 wealthiest combined stakers. (Or had it within six months in the past.)

Basically, I have no idea what's going on here, it sounds pretty unworkable.

As to the bolded, yes it is obvious you have no idea how DPoS works and thus you cannot comprehend its vulnerabilities accurately. People that write about the subject as if they have some understanding of how everything works (but in reality they don't), is the main reason for all of the misinformation about PoS. Stuff like that leads people like the OP to conclude that "PoS is far inferior to PoW" by making that deduction on misinformation. Do everyone a favor and try to understand something before claiming it is insecure or that it won't work.

1. There are likely many more than 101 stakeholders as anyone that owns a fraction of a coin has a vote which decides who the 101 elected delegates will be. That vote is directly proportional to the amount of tokens they own. Technically (assuming all stakeholders vote) you need 51% of the currency supply to have total control of which delegates get elected.

2. A "round" is only applicable to predetermining the order that the delegates will produce a block in each "round" of 101 blocks. Thus, Arhag's reasoning still applies in the example you give of the last delegate in a round acting in a nefarious manner... the 102nd delegate (or N+1 as in Arhag's post) would submit two blocks, their block and a replacement for block 101, and the network would choose the last block provided as the valid one. What you proposed as being a vulnerability is simply not.

"Long fork" differences;

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.

Bolded favorite parts.
Not-too-distant-past = 6 months.
All the delegates in a given cycle = 101.

I think this is a great illustration of how much simpler and easier it is to reason about the security of Bitcoin, and how all the complexity of PoS gives the illusion of security (Bitshares in this case).

I look forward to casting off the yolk of Congress and the Fed in favor of my 101 overlords. /sarcasm

Again, you don't seem to comprehend DPoS or its vulnerabilities. I suggest you re-read the DPoS white paper and Arhag's posts explaining possible attack vectors before commenting on them further.

You seem to think that the check points are put in every 6 months. This is incorrect as checkpoints are written into the block chain every 10 seconds with every block containing a hash of the previous block, and also with every software update. This type of long range NaS attack is unreasonably possible due to the necessary set of conditions that need to exist for one to use this attack vector. Anyone with an updated client would be invulnerable to the NaS attack. It would only be possible if ALL of the following conditions are met:

1. Someone obtains the private keys to addresses which owned 51% of the money supply at some point in the chain's history.
2. The victim(s) has not updated their client and there has not been any client updates since that certain point in time.
3. The attacker is able to identify victims that have not updated their client since that certain point in time. FYI- there is no easy way to do this short of infecting the whole internet with trojans or something similar. IE... there is no easy way for the attacker to identify who has a recently updated block chain and who doesn't.

Optionally, the attacker could create a fake client that does all of the above (they would still need 51% of the money supply at some point) to perform this attack. This risk can be mitigated by users taking proper security procedures such as verifying the signature of updates and only downloading them from trusted sources (IE. the Bitshares website). Also, as Arhag mentioned, if someone created a fake client they could simply steal the victim's private keys instead of doing an elaborate attack that would require 51% of the money supply at some point in the chain. So in this case the NaS attack would be silly to perform as it is in the attackers best interest not to go through all that trouble.

By the way, I am not going to act like I am an expert because I am not. I realize it is hard to understand exactly how consensus algos work and the possible attack vectors, as I myself have a hard time comprehending everything. I do know and comprehend enough of DPoS though to be able to tell when someone is blatantly wrong in their assessment of it. This goes for anyone... if you see I have some error in my reasoning or understanding then please feel free to point it out. I learn something new every time I visit cryptocurrency forums and that is exactly why I am here... to learn. I believe I have a general understanding of DPoS and possible attack vectors though... at least a better understanding of it than you (at the moment.)

If everyone could achieve a basic understanding of how the different PoS algos function and possible attack vectors BEFORE TALKING ABOUT THEM, the spread of misinformation on these forums would not be as bad as it is today. These forums act like an echo chamber.. what one person reads from someone respectable, they take it as being true if and then repeat it to others on other threads. It is very dangerous to talk about something as if you understand it when in reality you don't. Most of the people I debate about PoS on here, I eventually find out sooner or later that they have some sort of misunderstanding of how it works and thus how "insecure" it is.

[CoinHoarder]

So.. you are going to cherry pick the version of PoS that best fits your argument? DPoS is PoS, it is just a variant of PoS.

There should be no confusion here. Please don't claim PoS has some features that are present only in DPoS as a supporting argument for PoS. When the title shows DPoS I will consider it fair to use those features as part of the discussion. I don't think PoS is the same as DPoS. What do you think?

A lot of people (me including) use the term PoS as more of a broad term that includes all consensus algorithms that are not based on PoW. This includes many different variants of PoS... PoS as in Peercoin, transparent forging as in Nxt, DPoS as in Bitshares, etc, etc...

Many people would refer to Bitshares and Nxt as being PoS even though they are actually a variant of it. I agree it is confusing, but a term was needed to differentiate PoW coins from non-PoW coins and I think PoS is a natural choice since it was the first non-PoW consensus algo. As long as people realize that there are different variants of PoS, each functioning differently and with their own sets of pros and cons, then I don't see any issues with the terminology.

Let's consider Proof Of Waste for a second. 51% of Bitcoin's hash power is on 2 to 3 mining pools. The paid NOTHING to obtain it. You are entrusting them directly (or indirectly when they get "hacked") to not fork your coin. By the way... this statement I can back up with facts and readily available data.

First, it's not "waste". It's a highly specific impossible to forge or reuse effort to ensure security while also fairly converting value (energy) into tokens, bridging the outside and indise economy seamlessly.

The pools and their costs argument is only temporarily valid. The pools paid nothing, but they have nothing long-term. If they fuck up, miners will move quickly, miners paid A LOT of money for their power and have not usually recouped. I am entrusting the miners that need to collaborate and play fairly to profit.

You see the difference now?

It is waste in that it wastes electricity and processing power unnecessarily as has been proven by PoS. This is something Bytemaster (Bitshares main dev) came up with, for the Bitshares community to refer to PoW as Proof Of Waste to point out the fact that it is unnecessary to expend these resources simply to secure a block chain, as is proven by PoS and all of its variants.

I will concede you have a point as to the pools only being able to mount an attack temporarily before everyone switches pools. However, I stick to the fact that you simply made up "as it happens for many coins an exchange owns more than 51% of the supply", and you have no proof of this and it is not true. The point was that there are different attack vectors for PoW that exist other than achieving 51% of the hash power. Both PoW and PoS variants have vulnerabilities and different pros and cons. There is no perfect solution, and I believe that PoW is often touted on these forums as being a perfect solution when in actuality it is not.

[neuroMode]

Myriadcoin's multi-PoW framework helps with the decentralization of mining that some of you may be concerned about. More than you think, actually.

[BombaUcigasa]

Let's consider Proof Of Waste for a second. 51% of Bitcoin's hash power is on 2 to 3 mining pools. The paid NOTHING to obtain it. You are entrusting them directly (or indirectly when they get "hacked") to not fork your coin. By the way... this statement I can back up with facts and readily available data.

First, it's not "waste". It's a highly specific impossible to forge or reuse effort to ensure security while also fairly converting value (energy) into tokens, bridging the outside and indise economy seamlessly.

The pools and their costs argument is only temporarily valid. The pools paid nothing, but they have nothing long-term. If they fuck up, miners will move quickly, miners paid A LOT of money for their power and have not usually recouped. I am entrusting the miners that need to collaborate and play fairly to profit.

You see the difference now?

It is waste in that it wastes electricity and processing power unnecessarily as has been proven by PoS. This is something Bytemaster (Bitshares main dev) came up with, for the Bitshares community to refer to PoW as Proof Of Waste to point out the fact that it is unnecessary to expend these resources simply to secure a block chain, as is proven by PoS and all of its variants.

I will concede you have a point as to the pools only being able to mount an attack temporarily before everyone switches pools. However, I stick to the fact that you simply made up "as it happens for many coins an exchange owns more than 51% of the supply", and you have no proof of this and it is not true. The point was that there are different attack vectors for PoW that exist other than achieving 51% of the hash power. Both PoW and PoS variants have vulnerabilities and different pros and cons. There is no perfect solution, and I believe that PoW is often touted on these forums as being a perfect solution when in actuality it is not.

I disagree again.

It is not waste, it is a conversion of energy value into coin value. PoS coins (various types as you mentioned) also use a method to get value into the coin itself:
- PoW stage: it's the same as a fully PoW coin, just that coin emission ends very quickly and is unfairly distributed with regards to future investors.
- gib muny: just "devs" ripping off investors and collecting pots of bitcoin (the irony) to give price decaying coins to them

There can be only one instance of proof when an exchange owns 51% of the supply, when all depositors account for all deposits in various known addresses and reach a 51% sum, otherwise it's not ensured that you can detect a 51% ownership.

Again, PoW attack vectors are valid for mere HOURS, while a PoS attack vector can be used FOREVER once it opens up. This is a very HUGE difference in the security model which reduces the effect of the attack.

Going back to the PoW "waste" which you pretty headed PoS supporters don't seem to understand not even 6 years after Bitcoin was invented. This is not "waste", it is a cost that is converted into new coins (scheduled or fees) from block rewards. The approximate cost to generate a block is found in the value of new tokens. This cost is real and significant, this gives value to Bitcoin.

The cost of generating PoS blocks is basically zero (5$ a month for electricity on donated hardware or a VPS bill). The value of the block rewards is thus zero, this gives no value to new PoS coins, the market cap remains the same, but new coins are added. Price per existing coin will be lower.

What does this mean? Let me show you:

PoW
Bitcoin: 0.7% price growth every day for 6 years, 5,678,828,589 USD market cap
Litecoin: oscilating but stable parity with Bitcoin for 3 years, 138,439,389 USD market cap
Namecoin: oscilating but stable parity with Bitcoin for 3 years, 10,064,647 USD market cap

Hybrid
Peercoin: oscilating but stable parity with Bitcoin for 2 years, 18,474,609 USD market cap
Novacoin: down the shitter in 2 years, 640,582 USD market cap
YACoin: down the shitter in 2 years, 37,320 USD market cap

PoS
I'll let you pick the best examples older than one year

[CoinHoarder]

Myriadcoin's multi-PoW framework helps with the decentralization of mining that some of you may be concerned about. More than you think, actually.

I agree. I have been touting Myriadcoin as one of the biggest innovations in the PoW cryptocurrency world. It is definitely a step forward. Unfortunately, it still doesn't change the fact that a lot of electricity and processing power is wasted in the process. Pretty much all scientists agree global warming is real and PoW only accelerates that. I see PoS or a variant of it as being the ideal solution for consensus mainly for this reason. Why increase emissions unnecessarily simply to reach decentralized consensus when it is not needed because PoS is sufficient at performing the same job? Also.. all of the processing power could actually be used to do something useful to society instead of simply securing a block chain, such as solving cancer or assisting other scientific research. Primecoin is a good example of a PoW algo that is actually useful to society.

These are my biggest concerns about PoW, not the centralization of it. All systems.. PoS and PoW.. inevitably tend towards centralization eventually. PoW tends towards centralization in mining pools and large farms setup with cheap power which utilize the economies of scale ASICs provide. PoS tends towards centralization with the need for check points to prevent certain attacks (or at least in the current variants of PoS.) DPoS works on the realization that all systems inevitably tend towards centralization, ad it gives you a way for stake holders to control that centralization. Stake holders choose who becomes a delegate, with PoW you cannot choose who secures the block chain.. whoever buys mining power can do it. This helps keep nefarious actors out. Also, you can vote in developers and people creating important core services for the coin as delegates to compensate them for doing so. Therefore, a DPoS coin can hire employees that work for the cryptocurrency... PoW can obviously only do this via donations. The use of only 101 delegates allows block times to be reduced to a little as 10 seconds and process many transactions a second.. something that is very hard to achieve (maybe impossible) with PoW. There are many benefits of DPoS over PoW in my mind which far outweigh the highly unlikely attack vectors, and that is why I support it over PoW alternatives.

[BombaUcigasa]

I have been touting Myriadcoin as one of the biggest innovations in the PoW cryptocurrency world. It is definitely a step forward. Unfortunately, it still doesn't change the fact that a lot of electricity and processing power is wasted in the process.

PoW or not, it doesn't use that much electricity now, it's basically useless... You can relax knowing that less than 200 USD worth of electricity is wasted daily to sustain this coin.

[CoinHoarder]

Let's consider Proof Of Waste for a second. 51% of Bitcoin's hash power is on 2 to 3 mining pools. The paid NOTHING to obtain it. You are entrusting them directly (or indirectly when they get "hacked") to not fork your coin. By the way... this statement I can back up with facts and readily available data.

First, it's not "waste". It's a highly specific impossible to forge or reuse effort to ensure security while also fairly converting value (energy) into tokens, bridging the outside and indise economy seamlessly.

The pools and their costs argument is only temporarily valid. The pools paid nothing, but they have nothing long-term. If they fuck up, miners will move quickly, miners paid A LOT of money for their power and have not usually recouped. I am entrusting the miners that need to collaborate and play fairly to profit.

You see the difference now?

It is waste in that it wastes electricity and processing power unnecessarily as has been proven by PoS. This is something Bytemaster (Bitshares main dev) came up with, for the Bitshares community to refer to PoW as Proof Of Waste to point out the fact that it is unnecessary to expend these resources simply to secure a block chain, as is proven by PoS and all of its variants.

I will concede you have a point as to the pools only being able to mount an attack temporarily before everyone switches pools. However, I stick to the fact that you simply made up "as it happens for many coins an exchange owns more than 51% of the supply", and you have no proof of this and it is not true. The point was that there are different attack vectors for PoW that exist other than achieving 51% of the hash power. Both PoW and PoS variants have vulnerabilities and different pros and cons. There is no perfect solution, and I believe that PoW is often touted on these forums as being a perfect solution when in actuality it is not.

I disagree again.

It is not waste, it is a conversion of energy value into coin value. PoS coins (various types as you mentioned) also use a method to get value into the coin itself:
- PoW stage: it's the same as a fully PoW coin, just that coin emission ends very quickly and is unfairly distributed with regards to future investors.
- gib muny: just "devs" ripping off investors and collecting pots of bitcoin (the irony) to give price decaying coins to them

There can be only one instance of proof when an exchange owns 51% of the supply, when all depositors account for all deposits in various known addresses and reach a 51% sum, otherwise it's not ensured that you can detect a 51% ownership.

Again, PoW attack vectors are valid for mere HOURS, while a PoS attack vector can be used FOREVER once it opens up. This is a very HUGE difference in the security model which reduces the effect of the attack.

This is not accurate. All decentralized consensus algos are vulnerable to 51% attacks whether it be PoS or PoW. Someone with enough hash power to 51% a PoW network can do so forever, or until the PoW network forks and changes PoW algos. Someone with 51% stake of a PoS coin can 51% the coin forever, or until the PoS network forks and burns the attacker's stake.

Going back to the PoW "waste" which you pretty headed PoS supporters don't seem to understand not even 6 years after Bitcoin was invented. This is not "waste", it is a cost that is converted into new coins (scheduled or fees) from block rewards. The approximate cost to generate a block is found in the value of new tokens. This cost is real and significant, this gives value to Bitcoin.

The cost of generating PoS blocks is basically zero (5$ a month for electricity on donated hardware or a VPS bill). The value of the block rewards is thus zero, this gives no value to new PoS coins, the market cap remains the same, but new coins are added. Price per existing coin will be lower.

What does this mean? Let me show you:

PoW
Bitcoin: 0.7% price growth every day for 6 years, 5,678,828,589 USD market cap
Litecoin: oscilating but stable parity with Bitcoin for 3 years, 138,439,389 USD market cap
Namecoin: oscilating but stable parity with Bitcoin for 3 years, 10,064,647 USD market cap

Hybrid
Peercoin: oscilating but stable parity with Bitcoin for 2 years, 18,474,609 USD market cap
Novacoin: down the shitter in 2 years, 640,582 USD market cap
YACoin: down the shitter in 2 years, 37,320 USD market cap

PoS
I'll let you pick the best examples older than one year

It is waste though in that it wastes electricity and processing power unnecessarily to achieve decentralized consensus. As to your price examples... purely PoS coins havent even been out a full year so it is too early to make those comparisons, but I speculate that it will be no different than PoW coins. Bitshares for instance has increased in value this year, whereas Bitcoin has gone down in value. You can cherry pick data points that support your argument, but it doesn't necessarily mean what you are saying is true.