If he cannot ever accumulate 51% worth of old-private-key, (it appears to me based on my current understanding) in dpos he can still eventually control 100% of the delegates with <51% old-stake by selectively broadcasting valid tx and controlling certain few addresses and ex-delegate accounts. For example, the normal network history might have some individuals rise from #107 and #108 up to #97 and #98, displacing my delegate at position #99. If I control the alternative chain, I can instead avoid brodcasting the tx that bumps my delegate.
You need nearly all of the top 101 delegates under your control at the same point in time in the blockchain history in order to continue the fake history in a way that could appear plausibly legitimate to your victim's client. If you do not have nearly all of the top 101 delegates under your control at the same point in time, you cannot continue the history for long enough (without making it obviously apparent that it is an attack) to gain control of all of the top 101 delegates.
Let me explain with an example. Time t = 0 is when the DAC begins building on the genesis block. One year later, at t = 1, we have the following delegate ranking. There are 101 good delegates in the top 101 spots: good-delegate-1, good-delegate-2, ..., good-delegate-101. They each have 20% approval. The next 101 slots are filled by your evil delegates: evil-delegate-1, ..., evil-delegate-101. They each have 2% approval, all from the 2% stake you control. The next 101 slots are filled by 101 other good delegates, good-delegate-102 to good-delegate-202, each with only 1% approval. Over the course of the next year, from t = 1 to t = 2, stakeholders start moving away their votes from good-delegate-1 ... good-delegate-101 to good-delegate-102 ... good-delegate-202. This is a slow process in which one good delegate is replaced by the other good delegate one at a time. In fact, stakeholders vote according to the following peculiar pattern. They first take all of their votes away from good-delegate-k (1 <= k <= 101) and vote for the null slate, allowing one of your evil delegates to briefly get into spot 101. Then, they use that stake to vote for good-delegate-(k+101), who replaces your evil delegate on the active delegate list. At no time do you have more than one of your evil delegates as an active delegate in the true blockchain. Can you fork off of a snapshot of the blockchain between t=1 and t=2 and generate a plausible fake blockchain that gives all of your evil delegates the top 101 slots by cleverly filtering out certain transactions?
The answer is no. You may think that you can just filter out all of the transactions that change their vote from the null slate to good-delegate-(k+101), but keep the transactions that changed the vote from good-delegate-k to the null slate in the first place. If you could do this, you would end up with all of your evil delegates in the top 101 slots with 2% approval, and the rest of the good delegates at lower slots with either 1% approval or less. But you cannot do this, because you did not have nearly all of your evil delegates simultaneously in the top 101 slots at any point in time. The first time you would need to filter out one of these problematic transactions, you would be forced to filter out all of the blocks produced by good delegates after that point (otherwise the hash link would be broken). Now you might think you can just quickly fill in all of the transactions that change the vote to the null slate into one of the blocks produced by your delegate, so that you can have all of your evil delegates take over the next round. Not only would this look incredibly suspicious, but the conditions needed to pull this off are incredibly improbable. In practice, there will be many other transactions that those unvoting transactions depend on. You can't just stuff all of them into one block, you want to disperse them over multiple sequential blocks. However, since you do not control nearly all of the active delegates yet, you need to wait multiple rounds before you can fit all of those prerequisite transactions and the unvoting transactions that finally give you full control of all the delegates. But how many rounds of mostly missed blocks would that result in? It would be highly suspicious behavior that the client could warn user about. But if this is not satisfying enough, there is another measure that can be taken to be extra cautious. We can bring back TaPOS on top of DPOS. The transactions do not need to reference the previous block, they can reference a block well enough in the past that is well establish. The point is that TaPOS would make it impossible to even include those unvoting transactions in your fake blockchain.
In long range NaS, the attacker has access to many private keys that used to own BTS (some assume 51% stake worth). With this he can control 100% of the delegates, at the cost only of recovering old private keys that are no longer in use. This may cost very little, as old private keys are not worth much to their previous owners, but the attacker can buy them (and check that he is getting what he paid for) and use them to attack the network. Over time, the number-of-old-private-keys increases drastically, as does the stake-of-old-key, the age-of-key, and the potential-attack-damage. So over 50 years or so this might be a problem.
I am glad you recognize that even if an attacker was able to get other stakeholder's old private keys it would take many years to get enough (>51%) to create a plausible fake blockchain in order to attempt a double-spend attack. Another approach would be to aim for the private keys of old delegates. Either way, we can pretty much guarantee that users have updated their clients multiple times over this period. The client software needs to at least contain a hash of the genesis block so that it knows it is on the right chain. But every time there is a new version of the client, the developer can easily put in a recent checkpoint (a hash of a recent block) as a sanity check. That checkpoint immediately kills any attempt of attacking with a fake blockchain where the fork point is older than the checkpoint.
I think it's important to mention that having this checkpoint does not make things any more centralized or even require relying on the developer. A full audit of the code (including the checkpoint) is still possible since the auditors have a copy of the legitimate blockchain up to the point of the version upgrade, just like they would have a copy of the legitimate genesis block (or a means of determining whether the genesis block was legitimate) when doing a full audit of the first version of the code. And a regular user is always going to end up relying on other parties to determine if he is running the same program everyone else is running. Some trust is necessary. Bitcoin users need to trust their wallet developers, or trust the auditors who say that a particular version of the wallet software is safe to use (through a signed hash of the executable or source archive).
Topic: How Do Bitshares DACs Solve The "Nothing At Stake" Problem (Read 17355 times)
