Bitcoin Magazine
The Core Issue: Consensus Cleanup
Protocol developers often come across as 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, no matter their race, age, gender, nationality, or any other arbitrary criterion, is able to store and transfer value on a neutral monetary network more robust now than ever. That said, Bitcoin does have issues that many Bitcoiners are not aware of, but could threaten its long-term prospects if not addressed properly. The vulnerabilities fixed by the Consensus Cleanup are one such example.
The Consensus Cleanup (BIP 541) is a soft fork proposal aimed at patching multiple long-standing vulnerabilities within the Bitcoin consensus protocol. As a soft fork proposal, it is separate in nature to most other Bitcoin Core efforts featured in this edition. Although the proposal has historically been championed by individuals associated with the Bitcoin Core project, it really belongs to the broader category of Bitcoin protocol development.
We will walk through each of the proposal’s four items, describing the impact of the issue addressed and the remediation applied. We’ll discuss how the proposed mitigations evolved to address feedback as well as newfound vulnerabilities. We’ll finish with a brief overview of the current status of the soft fork proposal.
A vulnerability in Bitcoin’s Proof of Work
The Bitcoin network adjusts mining difficulty to maintain an average block rate of one per 10 minutes. An “off by one” bug (a common programming mistake) in its implementation opens up an attack called the Timewarp attack, whereby a majority of miners can artificially speed up the rate of block production by manipulating the difficulty downward.
This attack fortunately requires a 51%+ threshold of miners, but artificially speeding up the block rate is a critical issue. It means that full nodes are not in control of resource usage anymore, and that an attacker can considerably accelerate the bitcoin subsidy emission schedule.
Even though 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 for as long as they maintain their advantage. But the presence of this bug grants them the power to cripple the network within just 38 days by rapidly reducing the network difficulty.
Instead of taking down the network, it is more probable that an attacker would exploit this bug to a smaller extent. Current miners could coordinate to quadruple the block rate (to 2.5 minute blocks) while keeping the Bitcoin network in a seemingly functioning state, effectively quadrupling the available block space and stealing block subsidies from future miners. Short-sighted users may be incentivized to support this attack, as more available block space would mean -ceteris paribus- lower fees for onchain transactions. This would of course come at the expense of full-node runners and undermine the network’s long term stability.
The Timewarp attack exploits 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 mitigation is to link the timestamps of blocks 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 a positive amount of time. That is, for a given difficulty adjustment period, the last block may never have a timestamp earlier than the first block’s. Surprised this isn’t already the case? We were surprised it was at all necessary. Turns out this is a simple fix for a clever attack, related to Timewarp, that pseudonymous developer Zawy and Mark “Murch” Erhardt came up with when reviewing the Consensus Cleanup proposal.
Blocks that take hours to validate
Any miner can exploit certain expensive validation operations to create blocks that take a long time to verify. Whereas a normal Bitcoin block takes in 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 may leverage this to disrupt the entire network, while in a more economically rational variant of the attack, a miner can delay its competition just long enough to increase its profits without creating widespread network disruption.
Historical attempts to mitigate this issue have been tumultuous, because it requires imposing restrictions on Bitcoin’s scripting capabilities. Such restrictions have the potential of being confiscatory, which is paramount to avoid in any serious soft fork design.
Matt Corallo’s original 2019 Great Consensus Cleanup proposed to solve these long block validation times by invalidating a couple of obscure operations in non-Segwit (“legacy”) Script. Some raised concerns that although transactions using those operations had not been relayed nor mined by default by Bitcoin Core for years, someone, somewhere, may still be depending on it unbeknownst to everyone. Of course, this has to be weighed against the practical risk to all Bitcoin users of a miner exploiting this issue.
Even though the confiscation concern is fairly theoretical, there is a philosophical point on how to perform Bitcoin protocol development in trying to design an appropriate mitigation for the vulnerability with the smallest confiscatory surface possible. My later iteration of the Consensus Cleanup proposal addressed this concern by introducing a limit which pinpoints exactly the harmful behaviour, without invalidating any specific Bitcoin Script operation.
Forged proofs of payment
Bitcoin block headers contain a Merkle root that commits to all transactions in the block. This makes it possible to give a succinct proof that a given transaction is part of a chain with a certain amount of Proof of Work. This is commonly referred to as an “SPV proof”.
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 for an arbitrary fake (non-existent) transaction. This may be used to trick SPV verifiers, commonly used to validate incoming payments or deposits into a side-system. Mitigations exist that enable verifiers to reject such invalid proofs; however, these are often overlooked—even by cryptography experts—and can be cumbersome in certain contexts.
The Consensus Cleanup addresses this issue 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 anyone to spend), and have not been relayed or mined by default by Bitcoin Core since 2019. Alternative approaches were discussed, such as a round-about way of improving the existing mitigationa, but the authors chose to fix the root cause of the issue, eliminating both the need for implementers to apply the mitigation and the need for them to even know about the vulnerability in the first place.
a: committing to the Merkle tree depth in part of the block header’s version field
UTXO Doppelgängers: duplicate transactions
“Mirco… Mezzo… Macroflation—Overheated Economy” is the title of a blog post4 Russell O’Connor published in February 2012, in which he describes 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 would have an identical transaction identifier.
This was fixed by Bitcoin Core (then still called “Bitcoin”) developers with BIP 302, which required full nodes to perform additional validation when receiving a block. That extra validation was not strictly necessary to solve the issue, and was side-stepped with BIP 343 the same year. Unfortunately, the fix introduced in BIP 34 is imperfect and the BIP 30 extra validation will once again be required in 20 years. Beyond 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 block chain.
The Consensus Cleanup introduces a more robust, future-proof fix for the issue. All Bitcoin transactions, including the coinbase transactions, contain a field to “time lock” the transaction. The value of the field represents the last block height at which a transaction is invalid. The BIP 54 specifications require that all coinbase transactions set this field to the height of their block (minus 1).
Combined with a clever suggestion from Anthony Towns to make sure the timelock validation always occurs, this guarantees that no coinbase transaction with the same timelock value may have been included in a previous block. This in turn guarantees that no coinbase transaction may have the same unique identifier (hash) as any past one, without requiring BIP 30 validation.
An ounce of prevention is worth a pound of cure
The vulnerabilities addressed by the Consensus Cleanup (BIP 54) are not an existential threat to Bitcoin at the moment. While some have the potential to cripple the network, they are unlikely to be exploited for now. That said, this might change and it is paramount that we proactively mitigate long-term risks to the Bitcoin network, even if it means having to bear the short term burden of coordinating a soft fork.
The work on the Consensus Cleanup started with Matt Corallo’s original proposal in 2019. It came together 6 years later with my publication of BIP 54 and an implementation of the soft fork in Bitcoin Inquisition, a testbed for Bitcoin consensus changes. Throughout this time the proposal received considerable feedback, various alternatives were considered and mitigations for additional weaknesses were incorporated. I believe it is now ready to be shared with Bitcoin users for consideration.
The 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 Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!
This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full 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
This post The Core Issue: Consensus Cleanup first appeared on Bitcoin Magazine and is written by Antoine Poinsot.
