This attack does not apply to DPOS...
Oh ok I understand this attack better now. Two questions then:
It seems like this affects NXT but not DPOS, because with DPOS once you miss a chance to produce a block it is gone forever - you cannot use old stake-votes to produce a longer chain if at least 51% of delegates have produced a block since then. Is this right?
Also, NXT claims that having clients reject chains built on anything but the most recent block they have seen solves not only this but 51%... this is true in theory but relies on unreasonable network connectivity assumptions. Is this right?
It seems like this affects NXT but not DPOS, because with DPOS once you miss a chance to produce a block it is gone forever - you cannot use old stake-votes to produce a longer chain if at least 51% of delegates have produced a block since then. Is this right?
Also, NXT claims that having clients reject chains built on anything but the most recent block they have seen solves not only this but 51%... this is true in theory but relies on unreasonable network connectivity assumptions. Is this right?
I was asking, not telling. It seems to me like it doesn't apply, but I'd like D&T or other anti-POS pros to explain if I'm wrong.
Not a pro (and not anti pos necessarily) but I will say this: the extent you rely on delegation/supernodes as a security mechanism is also the extent you dilute the trustless nature of the system and erode true distributed consensus.
Sure, but isn't it an improvement over bitcoin which effectively has delegated-proof-of-work with about 5 delegates selecting blocks on behalf of >80% of hash power?
Quote
So depending on the implementation there will be trade offs. You could obviously eliminate the n.a.s. Problem with a central authority but that puts us back at square one. If the dpos uses an automated mechanism to resolve conflicts, then it probably can be attacked by false chains in a similar fashion to the other poS systems.
The fork resolution is automatic and is just determined by which chain has more stake-vote counted by delegate signatures.
Your next point is exactly what I'm asking - how would an attacker make a false chain using old keys with stake in them, if they cannot ever generate a sequence of delegates where they have more than N delegates in a row? Each round of delegate signatures is done without shuffling in between - if you only have 40% of the stake at any given time you cannot generate a round (~1 hour) where you have more than 40% of the delegates. Once an hour has passed, how would you make a false chain?
