Author: Antoine Poinsot
Source: https://bitcoinmagazine.com/print/the-core-issue-consensus-cleanup
Regarding the future of Bitcoin, its protocol developers are generally more pessimistic than most Bitcoiners. Daily exposure to Bitcoin's imperfections certainly gives them a more sober perspective, but this also reflects Bitcoin's achievements. Anyone in the world, regardless of race, age, gender, nationality, or any other standard, can store and transfer value on a neutral monetary network, and this network continues to grow day by day. That said, Bitcoin still has some problems that many Bitcoiners haven't noticed, which, if not properly addressed, could threaten its future. The vulnerabilities fixed by "Consensus Cleanup" are one such example.
"Consensus Rule Cleanup" (BIP 54 1 ) is a soft fork proposal intended to fix several long-standing vulnerabilities in the Bitcoin consensus protocol. Unlike most of Bitcoin Core development work discussed in this journal (Bitcoin Magazine's "The Core Issue"), it is a soft fork proposal. Although this proposal has historically been led by several developers involved in Bitcoin Core project, it actually falls under the broader category of "Bitcoin protocol development."
This article will introduce all four measures in this proposal, outlining the problems they are intended to address, their impact, and the findings of the remediation measures. We will explain how these mitigation measures were refined by incorporating feedback and addressing newly discovered vulnerabilities. Finally, we will provide an overview of the current status of this soft fork proposal.
A vulnerability in Bitcoin's proof-of-work mechanism
The Bitcoin network maintains a mining rate of one new block every 10 minutes on average by adjusting its mining difficulty. However, there is a "one-off error" (a common programming mistake) in the implementation of this difficulty adjustment mechanism that allows an attack called "time warping" to occur: miners who control the majority of the mining hash power can arbitrarily speed up the block production rate by lowering the difficulty.
Fortunately, this attack requires control of more than 51% of the mining hashrate; however, arbitrarily accelerating block production is a fatal flaw. It means that full nodes will no longer control resource usage, and attackers can significantly speed up the distribution of Bitcoin block subsidies (new currency).
While this attack requires "51% of the miners," it differs significantly from the standard threat model facing Bitcoin. A traditional "51% attack" allows a single miner to prevent the confirmation of a transaction (provided they maintain their hash power advantage). However, this vulnerability allows attackers to cripple the entire network within 38 days by rapidly reducing mining difficulty.
However, attackers might not cripple the entire network, but rather exploit this bug on a smaller scale. Current miners could collude to quadruple the block production rate (mining a block every 2.5 minutes) while keeping the Bitcoin network appearing normal. Essentially, this would quadruple the available block space and steal block subsidies from future miners. Short-term users might be incentivized to support such an attack because more available block space means lower transaction fees within the blockchain (assuming other conditions remain unchanged). Of course, this comes at the cost of operating full nodes and reduces the network's long-term stability.
Time warp attacks exploit the fact that difficulty adjustment cycles do not overlap. Therefore, the timestamp of a block in a new cycle can be set earlier than the last block of the previous cycle. Since overlapping difficulty adjustment cycles would result in a hard fork, the best compromise is to correlate the timestamps of blocks on the boundary of the difficulty adjustment cycles. BIP 54 stipulates that the timestamp of the first block of a difficulty adjustment cycle cannot be more than two hours earlier than the last block of the previous cycle.
Furthermore, BIP 54 stipulates that a difficulty adjustment cycle must take a positive number of minutes. That is, within a difficulty adjustment cycle, the timestamp of the last block cannot be earlier than the timestamp of the first block. Are you surprised that Bitcoin has never had this rule? We were surprised too, that it was necessary. Reality shows that this is a simple fix for a clever attack related to time warping, discovered by the developer, using the pseudonym "Zawy," and Mark "Murch" Erhardt while reviewing consensus rule cleanup proposals.
Blocks that require several hours to verify
Any miner can exploit some tedious verification operations to create blocks that take a very long time to verify. While a normal Bitcoin block can be verified in the order of 100 milliseconds, these "attack blocks" can take more than 10 minutes on high-end computers and more than 10 hours on Raspberry Pi (the latter being the hardware commonly used to run full nodes).
A malicious attacker might use this attack to destroy the entire network; while in a more economically advantageous variant, a miner could use it to delay their competitors, increase their own profits, and prevent the collapse from spreading throughout the network.
Historically, attempts to solve this problem have been fraught with difficulties because solutions require imposing limitations on Bitcoin's scripting capabilities. Such limitations could potentially lead to "forfeiture," and should be absolutely avoided in any serious soft fork design.
(Translator's note: The "confiscation" mentioned here refers to the fact that due to the disabling of certain uses of the script, the coins contained in the script can no longer be spent.)
Matt Corallo's "Great Consensus Cleanup," first proposed in 2019, suggested disabling certain rare operations in non-Segregated Witness scripts (often called "legacy scripts") to address the long verification time issue. Some have worried that while transactions using these operations haven't been forwarded or mined by the default Bitcoin Core configuration for years, some individuals might still be using them in certain places, unnoticed. Of course, this risk must be weighed against the risk that a single miner exploiting this vulnerability could pose to all Bitcoin users.
While this concern about forfeiture is almost entirely theoretical, it is also a philosophical question: how to design appropriate mitigation measures in the development of the Bitcoin protocol that address vulnerabilities while minimizing the possibility of forfeiture. My later improvement to the consensus rule cleanup proposal addressed this concern by adding a restriction that precisely defines harmful behavior without disabling any specific Bitcoin script operations.
Forged payment evidence
The Bitcoin block header contains a Merkle root that commits to all transactions within the block. This allows us to create a compact form of evidence that a transaction has been confirmed by a blockchain with a certain amount of proof-of-work. This is what we commonly refer to as "SPV evidence."
However, due to a design flaw in the Merkle tree, an attacker could potentially forge SPV evidence for a fake (non-existent) transaction if a block contains a carefully crafted 64-byte transaction. This could be used to deceive SPV validators (typically used to verify incoming payments or deposits into a subsystem). Mitigations exist to allow validators to reject such invalid evidence; however, they are often overlooked—even by cryptographers—and can be problematic in certain situations.
The consensus rule cleanup proposal addresses this issue by disabling transactions with a serialization size of exactly 64 bytes (within the consensus rules). Such transactions are inherently insecure (they can only be used to burn through funds or be spent by anyone), and since 2019, the default Bitcoin Core configuration has stopped forwarding and mining such transactions. Other approaches have been discussed, such as a workaround to improve existing mitigations, but the authors of the proposal chose to address the root cause of the problem, eliminating both the need for software developers to flaunt their mitigations and the need for them to be aware of the vulnerability.
Note a: The depth of the Merkle tree is committed in the version number field of the block header.
UTXO clone: Overlapping transactions
"Small...Medium...Large Inflation - Overheating Economy" was the title of a blog post Russell O'Connor published in February 2012. In this post, he discussed the possibility of overlapping Bitcoin transactions. This was once a fatal flaw in Bitcoin, breaking the fundamental assumption that transaction identifiers (hash values) are unique. The problem stemmed from the fact that a miner's coinbase transaction had only one empty input, meaning that any coinbase transaction with the same output would have the exact same transaction identifier.
(Translator's note: A coinbase transaction is the first transaction in a block, used to allow the miner who produced the block to receive transaction fees and block rewards; it can be done without spending any UTXO.)
At the time, the developers of Bitcoin Core (then called "Bitcoin") fixed this vulnerability with BIP 30 2 , which required full nodes to perform additional verification upon receiving blocks. This additional verification was not absolutely necessary and was bypassed in BIP 34 3 , implemented in the same year. Unfortunately, the fix in BIP 34 was not perfect, and 20 years later we will need to reintroduce BIP 30 verification. Besides not being absolutely necessary, this verification measure cannot be executed by alternative Bitcoin clients (such as Utreexo) and would actually prevent them from fully verifying the blockchain.
The consensus rule cleanup proposal incorporates a more reliable and time-tested fix. All Bitcoin transactions, including Coinbase transactions, include a field that determines the transaction's "effective date." This field's value represents the block height of the last block before the transaction was considered invalid. BIP 54 mandates that all Coinbase transactions must set this field to their block height minus one.
Combining this with a wise suggestion from Anthony Towns—ensuring that time-lock verification is always running—it ensures that coinbase transactions in previous blocks cannot use the same time-lock value. In turn, this ensures that no two coinbase transactions will have the same transaction identifier (hash value), and eliminates the need for BIP 30 verification.
Prevention is better than cure
The vulnerabilities addressed by consensus rule cleanup (BIP 54) are not an imminent existential threat to Bitcoin. While some of them could potentially cripple the entire network, they are unlikely to be exploited at present. Nevertheless, the situation could change, and proactively mitigating long-term risks to the Bitcoin network is absolutely necessary, even if it requires the short-term burden of coordinating soft forks.
The work on the consensus rule cleanup proposal originated from an original proposal by Matt Corallo in 2019. Six years later, with the release of BIP 54 and the corresponding soft fork implementation of Bitcoin Inquisition (a testnet for Bitcoin consensus changes), this proposal finally bore fruit. During this time, the proposal received a great deal of feedback, and we discussed many alternatives and added mitigations to other weaknesses. I believe it is now ready to be shared with Bitcoin users.
Consensus rule cleanup is a soft fork. Bitcoin protocol developers choose which improvements to implement first and make them public. However, the final decision on whether to adopt a change to the Bitcoin consensus rules rests with the users. The choice is yours.
(over)
References
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
