litecoin-project / litecoin

Litecoin source tree
http://www.litecoin.org
MIT License
4.36k stars 3.03k forks source link

New timestamp attack vulnerability? #527

Open zawy12 opened 6 years ago

zawy12 commented 6 years ago

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 timespan is not and should not be treated as distinct from target. Each time I've seen them activated it caused a problem.

image

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.

image

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.

See the first link above for solution for fixing it.

zawy12 commented 5 years ago

I gave a terrible exposition of the attack above. Here is the sequence of timestamps on BTC that would allow an attacker to get unlimited blocks in 16 weeks, even if they plug the hole that allows a Zeitgeist attack. I assume this means it would take 4 weeks on LTC, if you have not fixed it in an update. The simplest fix is to not allow a timestamp that is unreasonably too far ahead of the previous block, like 24 hours.

image

zawy12 commented 1 month ago

Bitcoin's recent testnet4 upgrade included a fix to not just their 2015/2016 problem (that Litecoin fixed) but also part of the problem in this issue. Their new rule is to make sure the last block in a 2016 period was not more than 2 hours before the 1st block in the next period. I showed them that it didn't completely fix it and that they needed to add the rule that nTimespan is always positive (the last block in a period must always have a timestamp that's more than the 1st block). Another way to stop the problem is to require monotonic timestamps on all blocks (so "negative solvetimes" aren't possible). Murch investigated the attack in the link below. To understand and fix this problem, his initial post in this thread is all you need to know.

https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062