Protocol developers tend to be more pessimistic about the future of Bitcoin than most Bitcoiners. Daily exposure to Bitcoin’s imperfections creates a sobering perspective, and it’s important to reflect on what Bitcoin has achieved. Anyone in the world, regardless of their race, age, gender, nationality, or any other arbitrary criteria, is able to store and transfer value in a neutral financial network that is stronger now than ever before. That said, Bitcoin has problems that many Bitcoiners are unaware of, but can threaten its long-term prospects if not properly addressed. The vulnerability fixed by Consensus Cleanup is one such example.
Consensus Cleanup (BIP 541) is a soft fork proposal intended to patch several long-standing vulnerabilities within the Bitcoin consensus protocol. As a soft fork proposal, it is inherently different from the many other Bitcoin Core initiatives featured in this program. Although this proposal has historically been promoted by people associated with the Bitcoin Core project, it is part of the wider field of development of the Bitcoin protocol.
We will go through the four elements of the proposal, explain the impact of the problem in question and the solutions used. We will discuss how the proposed mitigations evolved to address feedback and new vulnerabilities. We’ll finish with a brief look at the current state of the soft fork proposal.
The Bitcoin network adjusts the mining difficulty to maintain a rate of one block per 10 minutes. The “per-lock” bug (a common programming error) in its implementation opens up an attack called a Timewarp attack, where most miners can illegally speed up the block production rate by controlling the difficulty down.
This attack luckily requires a 51%+ miner limit, but artificially speeding up the block rate is a serious problem. It means that full nodes can no longer control the use of the resource, and that an attacker can greatly accelerate the process of issuing bitcoins.
Even if it requires a “51% miner”, it is a significant departure from the traditional Bitcoin threat model. A 51% attack traditionally allows a miner to block the verification of a transaction as long as he maintains his profit. But the presence of this bug gives them the ability to disable the network within 38 days by quickly reducing the network’s complexity.
Instead of bringing down the network, it is possible for an attacker to exploit this bug to a lesser extent. Current miners can coordinate to double the block rate (to 2.5 minute blocks) while keeping the Bitcoin network in a sane state, effectively doubling the available block space and stealing block funding from future miners. Short-sighted users may be motivated to support this attack, since the available block space would mean -ceteris paribus- lower payments for onchain payments. This will come at the expense of full node runners and harm the long-term stability of the network.
Timewarp attacks take advantage of the fact that difficulty adjustment periods do not overlap, allowing block timestamps to be set to show a new period begins before the previous one ends. Because making them overlap would be a hard fork, the next best mitigation is to link the timestamps of the blocks to the timestamps to fix the difficulty. The BIP 54 specification mandates that the first block of a period cannot have a timestamp earlier than the last block of a period by more than two hours.
In addition, the BIP 54 specifications mandate that the duration of the difficulty adjustment should always take a good amount of time. That is, at a certain time of processing complexity, the last block may not have a timestamp before the first block. Are you surprised this is not the case anymore? We were surprised that it was necessary. It turns out that this is a simple fix for a clever, Timewarp-related attack that anonymous developer Zawy and Mark “Murch” Erhardt came up with when reviewing the Consensus Cleanup proposal.
Any miner can use some expensive verification functions to create blocks that take a long time to verify. While a typical Bitcoin block takes on the order of a hundred milliseconds to be confirmed, the confirmation times of these “attack blocks” range from over ten minutes on a high-end computer to ten hours on a Raspberry Pi (a popular choice for fullnode hardware).
An externally motivated attacker could use this to disrupt the entire network, while in an economically viable alternative to the attack, a miner could delay his competition long enough to maximize his profits without causing widespread network disruption.
Historical attempts to mitigate this problem have been tumultuous, as they required placing limits on Bitcoin’s write power. Such restrictions have the potential to be eaten, which is very important to avoid in any serious fork design.
Matt Corallo’s original Great Consensus Cleanup of 2019 proposed solving these long block confirmation times by performing a few obscure tasks in a non-Segwit (“legacy”) Script. Some have raised concerns that even though transactions using those functions have not been transmitted or automatically mined by Bitcoin Core for years, someone, somewhere, may still be relying on them unbeknownst to everyone. Of course, this should be weighed against the real risk to all Bitcoin users of the miner who uses this issue.
Although concern about takeovers is a valid point, there is a philosophical point about how to go about developing the Bitcoin protocol in trying to design an appropriate risk mitigation with the smallest takeover area possible. My recent iteration of the Consensus Cleanup proposal addressed this concern by introducing a restriction that specifically targets harmful behavior, without doing 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 a small proof that a given work is part of a chain with a certain amount of Proof of Work. This is often called “SPV proof”.
Due to a weakness in the Merkle tree structure, including a specially designed 64-byte operation in a block allows an attacker to create such a (non-existent) fake proof of operation. This can be used to manipulate the SPV’s verifiers, which are usually used to verify incoming payments or deposits to the side’s system. Mitigation exists that allows verifiers to reject such invalid evidence; however, these are often overlooked—even by cryptographers—and can be difficult in certain situations.
Consensus Cleanup addresses this problem by creating invalid transactions whose serialized size is exactly 64 bytes. Such transactions cannot be secured in the first place (they can only burn the funds or leave them for anyone to spend), and they have not been transferred or mined automatically by Bitcoin Core since 2019. Other methods were discussed, such as how to improve existing reductions.abut the authors chose to fix the root of the problem, removing both the need for developers to use mitigations and the need for them to even know about the vulnerability in the first place.
a: commit to the depth of the Merkle tree in the version field part of the block header
“Mirco… Mezzo… Macroflation—Economy Overheated” is the title of the blog post4 Russell O’Connor published in February 2012, where he explained 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 coinbase operations for miners have a single null input, meaning any coinbase transaction that outputs the same will have the same transaction identifier.
This was fixed by the developers of Bitcoin Core (then still called “Bitcoin”) in BIP 302which required full nodes to perform additional verification when receiving a block. That extra validation wasn’t really needed to solve the problem, and was stepped aside with BIP 343 in the same year. Unfortunately, the correction introduced in BIP 34 is not complete and further verification of BIP 30 will be required again in 20 years. Although it is not really necessary, this verification cannot be done by other Bitcoin client projects like Utreexo and effectively prevents them from fully verifying the block chain.
Consensus Cleanup delivers robust, future-proof fixes for the problem. All Bitcoin transactions, including coinbase transactions, contain a transaction “timeout” field. The value of the field represents the length of the last block when the transaction is invalid. The BIP 54 specification requires that all coinbase operations set this field to its block length (minus 1).
Combined with a smart suggestion from Anthony Towns to ensure that timelock verification happens regularly, this ensures that no coinbase payment with the same timelock value could have been included in a previous block. This ensures that nothing coinbase does can have a unique identifier (hash) identical to all the previous ones, without requiring BIP 30 verification.
The vulnerability mentioned by the Consensus Cleanup (BIP 54) is not a threat to Bitcoin yet. Although some have the ability to disable the network, they are unlikely to be exploited yet. That said, this is subject to change and it is very important that we continuously reduce the long-term risks to the Bitcoin network, even if it means bearing the short-term burden of coordinating a soft fork.
The Consensus Cleanup project began with Matt Corallo’s original proposal in 2019. It came together after 6 years with my publication of BIP 54 and the initiation of a soft fork to Bitcoin Inquisition, a testing ground for Bitcoin consensus changes. During all this time the proposal received a great response, various alternatives were considered and it was combined with the reduction of additional weaknesses. I believe it is now ready to be shared with Bitcoin users for consideration.
Consensus Cleanup is a soft fork. The developers of the Bitcoin protocol choose which developments to prioritize and make available to the public. But the final decision to accept a change in Bitcoin’s consensus rules rests with the users. The choice is yours.
Don’t miss your chance to become an owner The Main Problem – featuring articles written by many Core Developers describing the projects they are working on themselves!
This piece is a Letter from the Editor featured in Bitcoin Magazine’s latest Print issue, The Core Issue. We share it here as an early look at the ideas explored throughout the entire issue.
[1] [2] [3] [4]
