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

<div class="post-metadata">

**Author:** ![sjors](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/sjors/32/59_2.png) [@sjors](https://delvingbitcoin.org/u/sjors)\
**Post date:** [April 5, 2024, 5:07pm UTC](https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/14 "2024-04-05T17:07:05Z")

</div>

> [@AntoineP](#):
>
> Making absolutely sure txids are unique seems like a good property to have in Bitcoin. And making it so comes at very little cost as this rule would only take effect in 21 years (much more than the current lifetime of Bitcoin).

Ah, so I guess the rule could be: blocks (with more than one transaction) at or above 1,983,702 MUST have a witness commitment. That’s plenty of time to make sure all mining software does that by default.

This is probably the only new soft-fork rule that miners could violate by accident. Not requiring a witness commitment for “empty” (only a coinbase) blocks makes it safer, because who knows what custom code is out there to SPV/spy-mine in the brief interval between when a new block is seen and when it’s fully validated and the new template is ready.

> [@AntoineP](#):
>
> I have yet to check if there is any violation of this but i’d be surprised if there is a pre-Segwit coinbase transaction with an output pushing exactly the witness commitment header followed by 32 `0x00` bytes.

There isn’t, unless I missed it: [op return - When was the first OP\_RETURN output in a coinbase? - Bitcoin Stack Exchange](https://bitcoin.stackexchange.com/questions/121069/when-was-the-first-op-return-output-in-a-coinbase)

(actually that’s not exactly what you asked, but at least there’s no OP\_RETURN use in the coinbase before BIP30 and BIP34 kicked in)

> [@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.

This is not necessary. As explained in `validation.cpp`:

```cpp
// Block 490,897 was, in fact, mined with a different coinbase than
// block 176,684, but it is important to note that even if it hadn't been or
// is remined on an alternate fork with a duplicate coinbase, we would still
// not run into a BIP30 violation. This is because the coinbase for 176,684
// is spent in block 185,956 in transaction

```

So a re-org would have to go all the way back to `185,956`. That’s buried below multiple checkpoints. And although we might [get rid of checkpoints](https://github.com/bitcoin/bitcoin/pull/25725) completely, many nodes would consider a reorg that deep a hard fork.

---

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