# Great Consensus Cleanup Revival

**URL:** <https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710>\
**Category:** Protocol Design\
**Created:** [March 24, 2024, 5:29pm UTC](https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710 "2024-03-24T17:29:42Z")\
**Posts on this page:** 1\
**Showing post:** 54

<div class="post-metadata">

**Author:** ![ajtowns](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/ajtowns/32/417_2.png) [@ajtowns](https://delvingbitcoin.org/u/ajtowns)\
**Post date:** [November 27, 2024, 12:13am UTC](https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/54 "2024-11-27T00:13:24Z")

</div>

> [@AntoineP](#):
>
> in the form of requiring the timestamp of the last block in a retarget period to never be lower than the timestamp of the first block in this same period

Why this, rather than a rolling “past time limit” along the lines of [option 3 here](https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062/5)? (eg: as well as the monotonic median time past, we maintain a non-decreasing `earliest_time_past`, which is initially the genesis timestamp, and thereafter `max(earliest_time_past, block.nTimestamp - 2 hours)`, and add a new consensus rule `next_block.nTimestamp >= earliest_time_past` in addition to `next_block.nTimestamp > median_time_past`)

Having a rule that is applied consistently to every block seems somewhat better to me than a rule that only applies to every 2016th block to me. YMMV.

(Most of the discussion in that thread was about options 1 and 2, which replaced/simplified median time past, which I don’t think is a practical option)

---

_[View the full topic](https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710)._