Consensus Cleanup BIP draft

[darosior]

This is a BIP draft for a Consensus Cleanup soft fork.

This proposal builds upon Matt Corallo's 2019 proposal, which i set to revive at the end of 2023. I eventually shared my research in a Delving Bitcoin post in early 2024 (along with a semi-private companion post for the redacted sensitive details). A number of people contributed ideas, testing and otherwise fruitful discussion. This led to settling on a list of mitigations, which i updated the mailing list about in February 2025.

I think it's now ready to be officially published as a BIP.

[vostrnad]

First pass of review, mostly copy editing suggestions so far.

[mzumsande]

Maybe reword this to make it clearer that minus 7200 is subtracted from the value of nTime, and not from height N-1 (so that no one unfamiliar with the context could read it as "block at height N - 7201").

[darosior]

Is this better?

Suggested change

	equal to the value of the `nTime` field of block at height `N-1` minus `7200`;
	equal to the value minus `7200` of the `nTime` field of block at height `N-1`;

[Sjors]

Concept ACK on the timewarp and Murch-Zawy fix, as well as the 64 byte transaction ban.

I still need to think about the worst case validation fix more, though the approach seems reasonable.

With respect to the nLockTime change, I need to get a sense of what pool software should take into account, especially since Bitoin Core does not construct the coinbase transaction.

We don't strictly need this change until height 1,983,702, but it seems better to enforce it at the same time as the rest of these changes. Otherwise we might end up with accidental forks several decades from now with nobody remembering this BIP.

I also still need to see and study the implementation(s), outside the timewarp fix, which I'm fairly familiar with by now.

[ariard]

There might be a problem with the math in this BIP.

Exposing said problem clearly might be a $5k a day wreck the whole LN style of exploit.

Asking for a friend who is curious on how to handle said problem.

[darosior]

@ariard i made sure you are on the private thread, if you want to discuss potentially sensitive details please do so there. Alternatively feel free to contact me privately.

[murchandamus]

Just a quick first look and some editorial comments as I see that this is still being edited and already getting quite a bit of feedback.

[darosior]

Thanks everyone for the review thus far. I think i've addressed everything.

[murchandamus]

This proposal looks mostly complete from an editorial standpoint. In a few segments, the style could be even more prosaic—the document could be a bit clearer by avoiding passive voice and directly referencing subjects and objects of sentences than referencing via noun phrases and pronouns. Some abstract ideas are referenced with different terms. It would be preferable if the same term is used for the same concept throughout.

[murchandamus]

Active voice is usually preferred in technical writing, because it is clearer:

Suggested change

	A limit is set on the number of potentially executed signature operations in validating a
	transaction. It applies to all transactions in the block except the coinbase transaction[^1]. For
	The number of potentially executed signature operations in validating a
	transaction is limited. The limit applies to all transactions except coinbase transactions[^1]. For

[darosior]

This is not active voice?

[murchandamus]

This doesn’t seem complete. The requirement to set and enforce the locktime is not backward-compatible for block producers.

[darosior]

I'm confused. This seems to directly follow for any consensus change: miners must take steps to produce blocks valid according to the new rules. I don't mind adding a sentence to this effect, but as far as i know the backwards compatibility section has always been used to discuss the backwards compatibility from the point of view of end users, not miners (since by definition block producers need to adapt if we are going to change block validity). See for instance the backwards compatibility section of the SegWit soft fork. Why change now?

[darosior]

I tried adding something to this effect but anything i come up with just seems needlessly redundant and vague. For instance:

Suggested change

	This proposal only tightens the block validation rules: there is no block that is valid under the
	rules proposed in this BIP but not under the existing Bitcoin consensus rules. As a consequence
	these changes are backward-compatible with unupgraded node software. That said, the authors strongly
	encourage node operators to upgrade in order to fully validate all consensus rules.
	This proposal only tightens the block validation rules: there is no block that is valid under the
	rules proposed in this BIP but not under the existing Bitcoin consensus rules. As a consequence
	these changes are backward-compatible with unupgraded node software. That said, the authors strongly
	encourage node operators to upgrade in order to fully validate all consensus rules.
	As with any consensus change, miners need to take precautions to produce blocks compatible with the
	new rules. In particular this BIP introduces restrictions on the coinbase transaction and block
	header timestamp, which are often set by closed source pool software.

[zawy12]

Instead of
"This proposal only tightens the block validation rules: there is no block that is valid under the
rules proposed in this BIP but not under the existing Bitcoin consensus rules. As a consequence
these changes are backward-compatible with unupgraded node software. That said, the authors strongly
encourage node operators to upgrade in order to fully validate all consensus rules."
I would say
"The proposal tightens the block validation rules. It doesn't invalidate any existing blocks to be backwards-compatible. Nodes should upgrade to ensure future blocks that are invalid under the proposal are not validated."

[luke-jr]

nLockTime is the most ideal location to put an extranonce, so it seems like a bad idea to burn it for no good reason.

[Sjors]

@luke-jr why would miners switch to something different from the current extraNonce?

[darosior]

It would have been better to bring up conceptual feedback on the mailing list. "For no good reason" is unnecessarily aggressive, the point here is not to make things invalid just for the sake of it. Please engage charitably to foster productive discussions.

To your point, it's my understanding that nLockTime makes for a good extranonce because it's serialized at the very end of the coinbase transaction. Rolling it does not require re-hashing the whole transaction as you can just cache a midstate for the first 64 bytes. Could you provide more details about how you expect it to be used exactly, and under what circumstances the operation it improves may become a bottleneck?

[luke-jr]

@luke-jr why would miners switch to something different from the current extraNonce?

There is no "current extraNonce". Extranonces can be anywhere in theory. But this particular location, as @darosior says, minimises the need to re-hash a lot of data to roll it. That means it can more practically be done on ASICs or MCUs with nearly no latency.

[ariard]

@ariard i made sure you are on the private thread, if you want to discuss potentially sensitive details please do so there. Alternatively feel free to contact me privately.

The friend said the potential problem is not related on the timewarp fix.