# 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:** 13

<div class="post-metadata">

**Author:** ![recent798](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/r/ecd19e/32.png) [@recent798](https://delvingbitcoin.org/u/recent798)\
**Post date:** [April 5, 2024, 4:17pm UTC](https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/13 "2024-04-05T16:17:19Z")

</div>

> [@AntoineP](#):
>
> A check that the coinbase transaction at block 490,897 can never be `bec6606bb10f77f5f0395cc86d0489fbef70c0615b177a326612d8bd7b84f84d` could be hardcoded in the client, but i think if there is a reorg this deep we have bigger problems anyways.

Fair enough. Though, a reorg at an early height doesn’t have to be problematic. It could normally happen, intentionally or accidentally. For example, if you yourself, or someone else fed blocks via `submitblock` or directly without announcement over P2P. I know that the new PoW DoS protection in headers-first download likely protects against a low-work reorg during IBD over P2P, but I don’t think it does over RPC.

---

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