# Zawy’s Alternating Timestamp Attack

**URL:** <https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062>\
**Category:** Protocol Design\
**Created:** [August 9, 2024, 2:21pm UTC](https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062 "2024-08-09T14:21:27Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![murch](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/murch/32/139_2.png) [@murch](https://delvingbitcoin.org/u/murch)\
**Post date:** [August 12, 2024, 3:26pm UTC](https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062/6 "2024-08-12T15:26:36Z")

</div>

> [@zawy](#):
>
> difficulty would drop to match his hashrate

Right, I forgot to account for the difficulty drop for the honest miners as well.

> [@zawy](#):
>
> the 2nd best option in my mind is doing a past-time limit on every block, not just the 2016 transition. This would be slightly simpler code and “more attractive” logic. If it’s good and safe for the 2016 transition then its better to do it on all blocks. It would prevent the need to restrict nActualtimespan and removes the main reason MTP exists.

I don’t see how this would remove the need for MTP. As far as I can tell, the MTP requirement leads to a stronger monotonicity than requiring that every block cannot be more than 2h in the past from its predecessor. If an attacker can move the date back by two hours with each block, they can achieve a negative elapsed time of 24 weeks in a single difficulty period, then they can bring back the timestamp to the actual time while reducing the difficulty maximally for at least three subsequent difficulty periods.

> [@zawy](#):
>
> In fact, there’s a benefit if the past time limit is applied to every block: the future time limit can be removed.

I also don’t see why the rule against moving time back would allow for the future limit on timestamps to be removed. If nodes would not enforce the future limit, an attacker could increase the timestamp by an average of 40 minutes with each block and reduce the difficulty by a factor 4 every difficulty period without doing anything else than pushing the chaintip off into the future.

It seems to me that requiring blocks to be monotonic could be a pain if a miner ever put future timestamps on blocks, and I don’t think I follow how you got to the conclusions about it being easier or better to make a bunch of sweeping consensus rule changes. If anything, the consensus changes should be as small as possible, and just requiring that in a difficulty period the first block has a lower timestamp than the last block seems to mitigate the attack you discovered and is a much smaller change. It’s not clear to me what benefit you see in introducing a 2h-past limit for the other blocks, or trying to impose monotonicity on all blocks. Clearly, only the timestamps of the first and the last block in each difficulty period matter for the difficulty rule.

---

_[View the full topic](https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062)._