Protocol developers often appear to be more pessimistic about Bitcoin’s future than most Bitcoiners. Daily exposure to Bitcoin’s imperfections certainly forms a sober perspective, and it’s important to reflect on what Bitcoin has achieved. Everyone around the world, regardless of race, age, gender, nationality, or any other criteria, can now store and transfer value on a more robust and neutral monetary network than ever before. That being said, there are issues with Bitcoin that many Bitcoiners are unaware of that could threaten its long-term prospects if not properly addressed. The vulnerabilities fixed by Consensus Cleanup are one example.
Consensus cleanup (BIP 54)1) is a soft fork proposal aimed at fixing multiple long-standing vulnerabilities within the Bitcoin consensus protocol. As a soft fork proposal, it is inherently separate from most of the other Bitcoin Core efforts covered in this edition. While this proposal has historically been supported by individuals associated with the Bitcoin Core project, it actually falls into the broader category of Bitcoin protocol development.
We will discuss each of the four sections of the proposal and discuss the impact of the issues addressed and the improvements applied. Describes how the proposed mitigations have evolved to address feedback and newly discovered vulnerabilities. Finally, I will briefly explain the current status of the soft fork proposal.
The Bitcoin network adjusts mining difficulty to maintain an average block rate of 1 block per 10 minutes. An “off by one” bug (a common programming mistake) in its implementation leads to an attack known as a Timewarp attack. This allows the majority of miners to artificially speed up block generation by lowering the difficulty.
Fortunately, this attack requires a miner threshold of 51% or higher, but artificially speeding up the block rate is a serious problem. This means that full nodes will no longer be able to control their resource usage, allowing attackers to significantly accelerate the Bitcoin subsidy drain schedule.
Although it requires a “51% miner,” it is a significant departure from the standard Bitcoin threat model. Traditionally, a 51% attack allows miners to prevent transactions from being confirmed as long as they maintain an advantage. However, the presence of this bug rapidly reduces network difficulties and can cripple a network within just 38 days.
Rather than bring down the network, attackers are more likely to exploit this bug on a small scale. Current miners can adjust their block rate to quadruple (down to 2.5 minute blocks) while keeping the Bitcoin network ostensibly functional, effectively quadrupling the available block space and stealing block subsidies from future miners. More available block space means lower fees for on-chain transactions, which could motivate short-sighted users to support this attack. Of course, this comes at the expense of full node runners, which compromises the long-term stability of the network.
Time warp attacks take advantage of the fact that difficulty adjustment periods do not overlap, allowing blocks to be timestamped so that a new period begins before the previous period ends. Since overlapping them will result in a hard fork, the next best mitigation is to link the block timestamps at the difficulty adjustment period boundaries. The BIP 54 specification states that the first block of a period cannot have a timestamp more than two hours earlier than the last block of the previous period.
Additionally, the BIP 54 specification mandates that the difficulty adjustment period always takes a positive amount of time. This means that the timestamp of the last block will never be earlier than the first block during a given difficulty adjustment period. Are you surprised that this isn’t already the case? We were surprised that it was necessary at all. This turned out to be a simple fix for a sophisticated Timewarp-related attack that pseudonymous developers Zawy and Mark “Murch” Erhardt came up with while considering a consensus cleanup proposal.
Any miner can abuse certain expensive validation operations to create blocks that take a long time to validate. While a typical Bitcoin block takes around 100 milliseconds to verify, these “attack blocks” take over 10 minutes to verify on a high-end computer and up to 10 hours on a Raspberry Pi (a popular choice for full-node hardware).
An externally motivated attacker could take advantage of this and disrupt the entire network, but a more economically rational attack variant would allow miners to slow down competition just long enough to increase profits without causing widespread network disruption.
Historical attempts to alleviate this problem have been rocky due to the need to impose limits on Bitcoin’s scripting capabilities. Such restrictions can be forfeited, and it is paramount to avoid this in the design of a full-fledged soft fork.
Matt Corallo’s original 2019 Great Consensus Cleanup proposed solving these long block validation times by disabling some ambiguous operations in non-Segwit (“legacy”) scripts. Some are concerned that someone, somewhere may be relying on Bitcoin Core without anyone knowing, even though transactions using these operations have not been relayed or mined by Bitcoin Core by default for many years. Of course, this must be weighed against the real risk to all Bitcoin users from miners exploiting this issue.
Although concerns about forfeiture are fairly theoretical, there are philosophical points to be made about how to conduct Bitcoin protocol development in minimizing the portions subject to forfeiture and designing appropriate mitigations for vulnerabilities. My subsequent consensus cleanup proposal addressed this concern by introducing restrictions that pinpoint harmful behavior without disabling specific Bitcoin script operations.
Bitcoin’s block header contains a Merkle root that commits all transactions within the block. This makes it possible to concisely prove that a particular transaction is part of a chain with a certain amount of proof of work. This is commonly referred to as “SPV proof.”
A weakness in the Merkle tree design, which includes a specially crafted 64-byte transaction within a block, allows an attacker to forge evidence of arbitrary bogus (non-existent) transactions. This can be used to fool SPV verifiers and is typically used to verify deposits and deposits into side systems. Mitigations exist that allow verifiers to reject such invalid proofs. However, these are often overlooked, even by cryptography experts, and can be tricky in some situations.
Consensus cleanup addresses this issue by invalidating transactions whose serialized size is exactly 64 bytes. Such transactions are inherently insecure (you can only burn your funds or leave them for someone else to use) and are not relayed or mined by Bitcoin Core by default since 2019. Alternative approaches were discussed, including roundabout ways to improve existing mitigation measures.beHowever, the authors chose to fix the root cause of the problem, eliminating both the need for implementers to apply mitigations and the need to know about the vulnerability in the first place.
be: commit to Merkle tree depth in part of version field of block header
“Mirco…Mezzo…Macroflation—An Overheating Economy” is the title of the blog post4 Russell O’Connor published in February 2012 and explained how Bitcoin transactions are replicated. This was a major flaw in Bitcoin, breaking the basic assumption that transaction identifiers (hashes) are unique. This is because a miner’s Coinbase transaction has a single blank input, and Coinbase transactions with the same output will have the same transaction ID.
This issue was fixed in BIP 30 by Bitcoin Core (still called “Bitcoin” at the time) developers.2This required the full node to perform additional validation when receiving blocks. This additional validation was not strictly necessary to resolve the issue, so it was avoided in BIP 34.3 It’s the same year. Unfortunately, the amendments introduced in BIP 34 are incomplete and additional validation of BIP 30 will be required again in 20 years. Not only is this verification not strictly necessary, but alternative Bitcoin client designs such as Utreexo cannot perform it, effectively preventing it from fully validating the block chain.
Consensus Cleanup introduces a more robust and future-proof fix for this issue. All Bitcoin transactions, including Coinbase transactions, include a field to “time lock” the transaction. The field value represents the height of the last block at which the transaction becomes invalid. The BIP 54 specification requires all Coinbase transactions to set this field to the block height (minus 1).
Combined with Anthony Towns’ wise suggestion to always ensure timelock validation, this ensures that no previous block contains a Coinbase transaction with the same timelock value. This ensures that no Coinbase transaction can have the same unique identifier (hash) as a past transaction without requiring BIP 30 validation.
The vulnerabilities addressed by Consensus Cleanup (BIP 54) are not an existential threat to Bitcoin at this time. Some have the potential to cripple the network, but are currently unlikely to be exploited. That said, this is subject to change, and it is paramount that we actively mitigate long-term risks to the Bitcoin network, even if we have to bear the short-term burden of adjusting for a soft fork.
The Consensus Cleanup effort began in 2019 with an initial proposal by Matt Corallo. Six years later, it came together with the publication of my BIP 54 and the implementation of a soft fork at Bitcoin Inquisition, a testbed for Bitcoin consensus changes. Throughout this period, the proposal received considerable feedback, various alternatives were considered, and mitigations for additional weaknesses were incorporated. I think it’s ready to be shared with Bitcoin users for consideration.
Consensus cleanup is a soft fork. Bitcoin protocol developers choose which improvements to prioritize and release to the public. However, the final decision on whether to adopt changes to Bitcoin’s consensus rules rests with users. The choice is yours.
Don’t miss your chance to get it core issue — Features articles written by many core developers describing the projects they work on.
This article is a letter from the editor published in the latest print edition of Bitcoin Magazine, the Core issue. I’m sharing 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
