Bitcoin-Core developer Matt Corallo has in recent times proposed a series of changes to the Bitcoin consensus code, dubbed “The Great Consensus Cleanup” in a new BIP, and submitted an associated pull request which implements the requisite code adjustments. The changes would be executed via a BIP-9 soft-fork in order to change a small proportion of consensus-related code and redecision some edge-case vulnerabilities related to validation of certain non-standard transactions, as well as a fix for the timewarp vulnerability, which impacted the Verge cryptocurrency last year. One element of the proposal suggests changes that would result in full invalidation of the non-standard OP_CODESEPARATOR opcode where used in non-BIP143 scripts. This risk was somewhat mitigated by changes in Bitcoin Core 0.16.1 in June last year, which ensured that such transactions using the potentially problematic opcode would not be relayed or mined as default. However, as the opcode vulnerability remains, a particularly motivated attacker could, in theory, make use of OP_CODESEPARATOR to roll out a form of denial-of-service attack on validating nodes and other miners, which is Corallo’s justification for moving to make these changes proactively. Issues with delays in validation can result in increasing numbers of orphaned blocks for miners, and in worse case scenarios would likely result in temporary breaks in consensus across different areas of the network. For a simple example, a Chinese miner might end up building on different blocks, if all his peers are busy validating a problematic block for over 30 minutes. This would cause a problem when the network comes back to consensus as there would be multiple concurrent blocks that would need to be orphaned to fully converge to consensus with the main, valid chain. The proposal has provoked some interesting discussion via the bitcoin-dev mailing list to dissect the trade-offs of making the changes to critical consensus code that Bitcoin relies upon. Russell O’Connor of Blockstream has responded with concerns that this could have the unintended consequence of preventing existing UTXOs being spent, if OP_CODESEPARATOR emerged as used in the construction of a P2SH address and it’s as-yet unknown redeemScript relies upon the non-standard opcode in order to spend the funds. O’Connor proposes an alternative path to the same goal through increasing the weight of transactions which utilise scripts containing the opcode, which would limit the number of such transactions that could be included in a single block, thereby limiting the risk of extreme validation times on any single block and almost entirely eliminating any serious risk from this particular vulnerability. Matt Corallo responded with his belief that no use of stated opcode has been detected on-chain, and that it is highly unlikely that anyone has moved funds into such an “esoteric” construction, without ever bothering to pull them out, even as a test (the only way such a transaction can be detected is when it is spent). That stated, Corallo did make a point of requesting that anyone reading who has used such non-standard transaction schemes should get in contact with the Bitcoin Core development team as a matter of priority. The risk of a timewarp attack is mitigated by adding a rule which ensures that the first block after a difficulty retarget must have a timestamp which is no earlier than 600 seconds before the previous block. This opcode is associated with a risk of attack due to its link to increased worst-case validation times, wherein an attacker could theoretically produce a block which would take up to 30 minutes to validate even on fast, modern hardware. The Bitcoin Optech newsletter last week outlined the proposal in greater detail, and includes a fantastic background of the specifics of both the legacy transaction validation and the time-warp attack involved with these edge case issues.