The great consensus cleanup is a new BIP suggested by developer Matt Corallo to address different issues in the current Bitcoin consensus, the new set of consensus changes aim at reducing complexity of Bitcoin implementations, improving worst-case validation times and fixing vulnerabilities like timewarp.

One of the biggest change in this BIP is failing OP_CODESEPARATOR and FindAndDelete, these two codes drastically increase worst-case validation times for non-BIP 143 transactions while having very few uses, none of them enabling new functionalities or efficiency gains than switching to BIP 141. As such, there is almost no known use of them on the current Blockchain as they have been none standard since Bitcoin Core 0.16.1.

Another change is further restricting nTime fields on difficulty adjustment blocks, fixing the long-standing timewarp inflation vulnerability in Bitcoin’s difficulty adjustment blocks without the risk of bricking current hardware, the change limits the worst-case difficulty adjustment target to once every 600 seconds, limiting the attacking scenario to about 0.1% inflation rate, smaller than any historical inflation rate due to an unexpected growth in hash rate.

The first change is currently not being received well by developer Russel O’Connor, his comments are that:

OP_CODESEPARATOR is the only mechanism available that allows users to sign which particular branch they are authorizing for within scripts that have multiple possible conditions that reuse the same public key

This means that anyone using this feature will permanently lose their money in case this soft-fork is activated and its not acceptable to risk people’s money, his suggestion was to increase the transaction weight using this opcode suitable to temper the vulnerability caused by it, oar maximizing the number of OP_CODESEPARATOR allowed per script, this is being counter argued with that there is currently almost no known use of this opcode and as such keeping something that is a vulnerability in Bitcoin to not risk a few novel usages with no known users. This is a discussion that we’ll be following closely, as Russel mentioned Bitcoin has never made a soft-fork, since the time of Satoishi, that invalidated transactions that send secured inputs to secured outputs, but this could be its first time.

To follow the discussion more closely, you can checkout the mailing list thread here.