Long Range Attack
(Redirected from Long-range attacks)
- Similar to a 51% attack but it goes further back in time.
- It is one the possible problems of PoS.
- A detailed post can be found here:
"Long range attack — Same mechanism as 51% attack (make a longer chain that rewrites the ledger in the attacker’s favor), but instead of starting the attack 6 blocks back, go much further back in the chain’s history (i.e. 60,000 blocks). This is a problem for PoS since there’s no proof of work (or equivalent time-intensive operation) required to rewrite a very long chain.
These two main challenges are solved via ideas from slasher (and its improved variations). The main points are that (1) validators are known, which allow for fault attribution at a validator level and (2) by having “slashing conditions” that strongly disincentivize certain actions, it is possible to mitigate these issues. Again, this example is crucial in understanding the Casper team’s view on consensus algorithm design: we can leverage economic mechanism design to a secure distributed system."
- From Vitalik's post:
"Essentially, by explicitly punishing double-signing, Slasher in a lot of ways, although not all, makes proof of stake act like a sort of simulated proof of work. An important incidental benefit of Slasher is the non-revert property. In proof of work, sometimes after one node mines one block some other node will immediately mine two blocks, and so some nodes will need to revert back one block upon seeing the longer chain. Here, every block requires two thirds of the signers to ratify it, and a signer cannot ratify two blocks at the same height without losing their gains in both chains, so assuming no malfeasance the blockchain will never revert. From the point of view of a decentralized application developer, this is a very desirable property as it means that “time” only moves in one direction, just like in a server-based environment.
However, Slasher is still vulnerable to one particular class of attack: long-range attacks. Instead of trying to start a fork from ten blocks behind the current head, suppose that an attacker tries to start a fork starting from ten thousand blocks behind, or even the genesis block - all that matters is that the depth of the fork must be greater than the duration of the reward lockup. At that point, because users’ funds are unlocked and they can move them to a new address to escape punishment, users have no disincentive against signing on both chains. In fact, we may even expect to see a black market of people selling their old private keys, culminating with an attacker single-handedly acquiring access to the keys that controlled over 50% of the currency supply at some point in history.
One approach to solving the long-range double-signing problem is transactions-as-proof-of-stake, an alternative PoS solution that does not have an incentive to double-sign because it’s the transactions that vote, and there is no reward for sending a transaction (in fact there’s a cost, and the reward is outside the network); however, this does nothing to stop the black key market problem. To properly deal with that issue, we will need to relax a hidden assumption."
"...the authors show that adversarial blockchains in Ouroboros exhibit a less dense block distribution after the point where they diverge from other versions of the chain. Simply put; the attacker’s chain will contain less blocks in the time period shortly after the divergence point, despite it potentially containing more blocks altogether and being the longest chain. Therefore, when multiple chains of similar length are available, the Plenitude Rule looks for the point at which the chains diverge and ‘went their own ways’ regarding their block distribution. It then divides the most recent past from the history of the chain into periods and determines for which version the block distribution after the divergence point is the most dense — which is the chain that will be selected. Due to this rule, nodes that are new to the network or have been offline for a while can (re)join and be guaranteed to download the correct version of the chain, as long as there are enough honest parties. This solves the bootstrapping problem and helps prevent long range attacks."
