This attack can’t be performed if LTC is using the MTP as the most recent timestamp in the difficulty calculation (like Zcash does).
Due to the powLimits of 1/4 and 4x, it appears the ZeitGeist attack is still possible in Litecoin despite “the hole” in BTC’s window being filled. The trick is to force the 4x limit rise in the target twice in a row, then “attempt” a 1/16 correction, but the code allows only a 1/4 correction due to the other limit. It assumes a >50% miner and requires him to selfishly mine for 8 windows (4 weeks?). A larger miner could do it in less time. Maybe Litecoin has some other protection such as limiting the number of blocks in a chain reorg. I’ve covered this and other types of timestamp attacks (smaller coins are subject too) here. (see bottom for this attack)
This example has only a 30% gain for the 51% miner verses a straight selfish mining attempt. If the 4,8,4,8 pattern is replaced with something like 4, 8, 12, 0.1, 4, 8, 12, 0.2, 4, 8, 12, 0.3, 4, 8, 12, 0.4, 4, 8, 12, 13, 14….22ish The 22ish point would have a real time equal to the 12 it’s sending. This looks like it would have something like 3x more blocks than straight selfish mining.
The fix is to remove or move the limits to next_target. Any argument for them seems to be weak and incomplete. My only evidence (other than the negative effects I’ve seen) is to say time span is not and should not be treated as distinct from target. Each time I’ve seen them activated it caused a problem.
The public chain will see the following before it gets reorg’d. It takes 2x longer to solve the blocks in the 1st window because the 51% just pulled his hashrate.
The recent attack on Verge appears to be based on this exact same problem (the 1/4 and 4x limits). The verge attack did not need to be selfish mining because their FTL (future time limit) was >> than their timespan while here it is the opposite. This by itself does not allow more than a average 50% drop in difficulty (I described this in the link above) even with 100% hashrate. The additional element needed is the same problem here. There is a 1/3 and 3x limit on the timespan in Verge. The attack was making target go up by exactly 3x more often than it went down to 1/3. It did this by not making forward times exceed the limit and exaggerating reverse times to purposefully trigger the 1/3 limit, so target was not allowed to drop as much as it needed to. When that reverse stamp passed out the back window (just like above) he did not have to use a large forward timestamp that would have exceeded the FTL enforced by nodes. By “owning the MTP” (same as above) he was not blocked in slowing up time.
It appears many coins with something like a powLimit are vulnerable.