Protocol developers often appear more pessimistic about Bitcoin’s future than most Bitcoiners. Daily exposure to Bitcoin’s imperfections certainly shapes a sober perspective, and it’s important to reflect on what Bitcoin has achieved. Anyone in the world, regardless of race, age, gender, nationality or any other arbitrary criteria, is able to store and transfer value on a neutral monetary network that is more robust now than ever. That said, Bitcoin has problems that many Bitcoiners are unaware of, but which could threaten its long-term prospects if not properly addressed. The vulnerabilities fixed by Consensus Cleanup are one such example.
Consensus Cleanup (BIP 541) is a soft fork proposal that aims to patch several long-standing vulnerabilities within the Bitcoin consensus protocol. As a soft fork proposal, it is inherently separate from most other Bitcoin Core initiatives discussed in this edition. Although the proposal has historically been championed by people associated with the Bitcoin Core project, it really belongs in the broader category of Bitcoin protocol development.
We will review each of the proposal’s four points and describe the impact of the problem addressed and the remedy used. We will discuss how the proposed limitations evolved to address feedback as well as newly discovered vulnerabilities. We conclude with a brief overview of the current status of the soft fork proposal.
The Bitcoin network adjusts mining difficulty to maintain an average block rate of one per block. 10 minutes. An “off by one” flaw (a common programming error) in its implementation opens up an attack called the Timewarp attack, whereby a majority of miners can artificially speed up the block production rate by manipulating the difficulty downward.
This attack fortunately requires a 51%+ threshold for miners, but artificially speeding up the block rate is a critical issue. This means that full nodes no longer have control over resource consumption, and an attacker can significantly accelerate the emission schedule for bitcoin support.
Although it requires a “51% miner”, it is a significant departure from the standard Bitcoin threat model. A 51% attack traditionally enables a miner to prevent the confirmation of a transaction as long as they maintain their advantage. But the presence of this bug gives them the power to paralyze the network within just 38 days by quickly reducing the network problems.
Instead of taking down the network, it is more likely that an attacker will exploit this flaw to a lesser extent. Current miners could coordinate to quadruple the block rate (to 2.5 minute blocks) while keeping the Bitcoin network in an apparently working state, effectively quadrupling the available block space and stealing block grants from future miners. Short-sighted users may be incentivized to support this attack, as more available block space would mean – otherwise paribus – lower fees for onchain transactions. This would obviously come at the expense of full-node runners and undermine the long-term stability of the network.
The timewarp attack takes advantage of the fact that difficulty adjustment periods do not overlap, allowing block timestamps to be set so that a new period appears to start before the previous one has finished. Because making them overlap would be a hard fork, the next best workaround is to concatenate block timestamps at the boundaries of difficulty adjustment periods. The BIP 54 specifications mandate that the first block of a period cannot have a timestamp earlier than the previous period’s last block by more than two hours.
In addition, the BIP 54 specifications mandate that a difficulty adjustment period must always take positive time. That is, for a given difficulty adjustment period, the last block must never have a timestamp earlier than that of the first block. Surprised this isn’t already the case? We were surprised that it was even necessary. It turns out that this is a simple solution to a clever attack, related to Timewarp, that the pseudonymous developer Zawy and Mark “Murch” Erhardt came up with when they were reviewing the Consensus Cleanup proposal.
Any miner can exploit certain expensive validation operations to create blocks that take a long time to verify. While a normal Bitcoin block takes on the order of a hundred milliseconds to validate, validation times for these “attack blocks” range from more than ten minutes on a high-end computer to up to ten hours on a Raspberry Pi (a popular full-node hardware choice).
An externally motivated attacker can exploit this to disrupt the entire network, while in a more economically rational variant of the attack, a miner can delay his competition just long enough to increase his profits without causing widespread network disruption.
Historical attempts to mitigate this problem have been tumultuous because it requires imposing restrictions on Bitcoin’s scripting capabilities. Such restrictions have the potential to be confiscatory, which is crucial to avoid in any serious soft fork design.
Matt Corallo’s original 2019 Great Consensus Cleanup suggested solving these long block validation times by invalidating a few obscure operations in non-Segwit (“legacy”) script. Some raised concerns that even though transactions using these operations had not been relayed or mined by default by Bitcoin Core for years, someone, somewhere, may still be relying on it without everyone knowing. Of course, this must be weighed against the practical risk to all Bitcoin users of a miner exploiting this issue.
Although the confiscation concern is quite theoretical, there is a philosophical point in how to conduct Bitcoin protocol development in trying to design an appropriate mitigation of the vulnerability with the smallest confiscation surface possible. My later iteration of the Consensus Cleanup proposal addressed this concern by introducing a boundary that pinpoints the malicious behavior without invalidating any specific Bitcoin Script operation.
Bitcoin block headers contain a Merkle root that commits to all transactions in the block. This makes it possible to provide concise proof that a given transaction is part of a chain with a certain amount of Proof of Work. This is commonly called an “SPV certificate”.
Due to a weakness in the design of the Merkle tree, including a specifically crafted 64-byte transaction in a block, allows an attacker to forge such a proof of an arbitrary fake (non-existent) transaction. This can be used to fool SPV verifiers that are commonly used to validate incoming payments or deposits into a side system. Limitations exist that allow verifiers to reject such invalid proofs; however, these are often overlooked – even by cryptography experts – and can be troublesome in certain contexts.
Consensus Cleanup solves this problem by invalidating transactions whose serialized size is exactly 64 bytes. Such transactions cannot be secure in the first place (they can only ever burn funds or leave them for someone to spend), and have not been passed or mined by default by Bitcoin Core since 2019. Alternative approaches were discussed, such as a round-the-clock way to improve the existing mitigation-onehowever, the authors chose to address the root cause of the problem, which eliminates both the need for implementers to apply the mitigation and the need for them to even know about the vulnerability in the first place.
-one: commits the depth of the Merkle tree in part of the block header’s version field
“Mirco… Mezzo… Macroflation—Overheated Economy” is the title of a blog post4 Russell O’Connor published in February 2012 describing how Bitcoin transactions can be duplicated. This was a critical flaw in Bitcoin, which broke the fundamental assumption that transaction identifiers (hashes) are unique. This is because miners’ coinbase transactions have a single blank input, meaning that any coinbase transaction with the same outputs will have an identical transaction ID.
This was fixed by Bitcoin Core (then still called “Bitcoin”) developers with BIP 302which required full nodes to perform additional validation upon receiving a block. The extra validation was not strictly necessary to solve the problem, and was bypassed with BIP 343 same year. Unfortunately, the correction introduced in BIP 34 is imperfect, and BIP 30 additional validation will again be required in 20 years. In addition to not being strictly necessary, this validation cannot be performed by alternative Bitcoin client designs such as Utreexo and would effectively prevent them from fully validating the blockchain.
Consensus Cleanup introduces a more robust, future-proof solution to the problem. All Bitcoin transactions, including the coinbase transactions, contain a field to “timelock” the transaction. The value of the field represents the last block height at which a transaction is invalid. The BIP 54 specifications require all coinbase transactions to set this field to the height of their block (minus 1).
Combined with a clever suggestion by Anthony Towns to ensure that the timelock validation always happens, this guarantees that no coinbase transaction with the same timelock value can be included in a previous block. This in turn guarantees that no coinbase transaction can have the same unique identifier (hash) as any before, without requiring BIP 30 validation.
The vulnerabilities addressed by the Consensus Cleanup (BIP 54) are not currently an existential threat to Bitcoin. While some have the potential to cripple the network, they are unlikely to be exploited at the moment. That said, this could change, and it is imperative that we proactively mitigate long-term risks to the Bitcoin network, even if that means bearing the short-term burden of coordinating a soft fork.
Work on the Consensus Cleanup started with Matt Corallo’s original proposal in 2019. It came together 6 years later with my release of BIP 54 and an implementation of the soft fork in Bitcoin Inquisition, a testbed for Bitcoin consensus changes. During this time, the proposal received significant feedback, various alternatives were considered, and remedies for additional weaknesses were incorporated. I think it is now ready to be shared with Bitcoin users for consideration.
Consensus Cleanup is a soft fork. Bitcoin protocol developers choose which improvements to prioritize and make available to the public. But the ultimate decision to adopt a change to Bitcoin’s consensus rules rests with the users. The choice is yours.
Don’t miss your chance to own The core problem — with articles written by many core developers explaining the projects they themselves work on!
This piece is the letter from the editor in the latest print edition of Bitcoin Magazine, The Core Issue. We share it here as an early look at the ideas explored throughout the issue.
[1] https://github.com/bitcoin/bips/blob/master/bip-0054.md
[2] https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
[3] https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
[4] https://r6.ca/blog/20120206T005236Z.html