Bitcoin immutability or lack thereof is its best-kept secret. The proponents of the sound money claim that the leading crypto protocol by market cap is also the only one immutable, based on a series of narrations and word of mouth, rather than any evidence. However, there have been at least two instances in the history of the Bitcoin protocol, where the protocol’s immutability was broken in a centralized manner.
The first instance of Bitcoin immutability breaking was on Aug 15, 2010, roughly a year and a half after the launch – an event known technically as CVE-2010-5139: Bitcoin’s Value Overflow or informally as the Bitcoin 184 billion bug. It was broken for the second time on Mar 11, 2013 – an event recorded as CVE-2013-3220: BerkeleyDB to LevelDB Migration Incident. Let’s see some details.
First Bitcoin Immutability Breach CVE-2010-5139 On Aug 15, 2010
The Bitcoin 184 billion bugs or CVE-2010-5139: Bitcoin’s Value Overflow Incident occurred on Aug 15, 2010. As a result, the Bitcoin blockchain experienced downtime of 8 hrs: 27 min. Bitcoin core developer discovered that at block height 74,638 someone had exploited a value overflow bug in the code and created 184B (or 184,000,000,000) BTCs, that’s way outside the usual 21M (or 21,000,000) BTCs limit.
An unknown attacker had generated these insanely high numbers of Bitcoins, out of thin air and spread the amount over several addresses. Bitcoin core developer Jeff Garzik discovered the value overflow bug – resulting from malfunction of code verification logic and improper processing of large outputs sums.
It went unnoticed for almost two hours at that time, however the Bitcoin anonymous creator Satoshi Nakamoto released a new patched client version (0.3.10) within five hours to fix the issues. Afterward, network participants performed a soft fork and rejected the abnormal transactions generating a ridiculously high number of Bitcoins.
The resultant fork and bug patch rendered previously validated 51 blocks, invalid. Thus, the other valid transactions contained in those bugs, apart from the malicious ones producing the 184 billion Bitcoins were reversed and the chain was effectively rolled backed via block reorganization. There is no list of the reversed transactions in those reverted blocks available.
This incident showed co-ordination between community, miners and Bitcoin core devs, who had to rely on centralized decision making to fix the issue. This is the first instance that Bitcoin immutability was breached and the project was only 1.5 yrs old at that time. You can read the fascinating Bitcointalk thread on the topic here to get a glimpse of the activity happening back then. Ethereum co-founder Vitalik Buterin later described the bug as:
In August 2010, a transaction in block 74638 contained two outputs summing to over 184 billion – just over 2^64 satoshis. The result was an integer overflow bug, the digital equivalent of a mechanical odometer wrapping around to zero after the car drives 999,999 kilometers.
Second Bitcoin Immutability Breach CVE-2013-3220 On Mar 11, 2013
The second Bitcoin immutability breach or CVE-2013-3220: BerkeleyDB to LevelDB Migration bug occurred on Mar 11, 2013. This time, the Bitcoin blockchain experienced a downtime of 06 hrs: 20 min. On the fateful day, miners running client v0.8.0 produced large blocks, which weren’t compatible with miners running earlier version v0.7.0 at height 225,430. This caused a hard fork as the chain consensus was broken.
This unintentional hard fork was caused by the migration from Berkeley database to Level database and client versions not enforcing sufficient locking limits / improperly handling mem-pool transactions. Therefore, the chains diverged from each other. A non-malicious network participant was also able to execute a successful double-spend, which remains the only instance in Bitcoin’s history, where a double-spend has been successful.
However, detection and fix implementation were faster than before. It took 1 hour for the participants to discover the fork and the issue was resolved within a few hours, thanks to centralized decision making and core developers’ collusion with the miners. Bitcoin core developer noted the following in his incident post mortem report.
A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected fork of the blockchain. The pre-0.8-incompatible chain (from here on, the 0.8 chains) at that point had around 60% of the mining hash power ensuring the split did not automatically resolve (as would have occurred if the pre-0.8 chain outpaced the 0.8 chains in total work, forcing 0.8 nodes to reorganize to the pre-0.8 chain).
In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed the majority hash power on the chain without the larger block, thus eventually causing the 0.8 nodes to reorganize to the pre-0.8 chain. During this time there was at least one large double spend. However, it was done by someone experimenting to see if it was possible and was not intended to be malicious.
The second Bitcoin immutability breach saw 24 previously valid blocks, invalidated. Therefore, transactions were once again reversed and the chain rollbacked in a centralized manner. Its rectification was only made possible, because large mining pool operators (Slush, BTC Guild etc.) running client v0.8.0 were successfully persuaded by Bitcoin core devs to downgrade their software to v0.7.0, contribute their hash power and revert back to the previously valid chain.
The overflow caused the software to think that the transaction contained only a small amount of BTC while in reality the outputs together had thousands of times more than the 21 million that should ever exist. A new version of the Bitcoin software had to be published, the blockchain was forked, and a new, valid, chain overtook the old one at block 74691 – 53 blocks after the original fork. This time, it only took 24 blocks, and it was not even a life-critical threat to the system – if the developers had done nothing, then Bitcoin would have carried on nonetheless, only causing inconvenience to those bitcoind and BitcoinQt users who were on 0.7 and would have had to upgrade.
Thus, the majority hash power was exploited to breach Bitcoin immutability by centrally deciding on which chain was valid. There was no particular reason for selecting the v0.8.0 over v0.7.0 chain and it appears to be an arbitrary decision by Bitcoin core devs. It was also made possible, because the hash power wasn’t equally distributed and large mining pool operators were able to tip the scales in favor of v0.7.0 on core devs request, since they controlled over 70% of the Bitcoin mining hash rate.
Later, Bitcoin core dev Pieter Wuille initiated the Bitcoin’s Can you guys stop trading? moment by asking miners to not mine on the v0.8.0 chain. It was reported that at that time, 25 BTCs or $26,000 worth of mining rewards were lost and of course the double-spend tx was reversed. Though, most of the affected transactions were later included in the new chain. This incident showed that Bitcoin immutability is highly dependent on human factors or social consensus and isn’t anywhere similar to fundamental limits, as is widely claimed.
Forgotten History
Bitcoin immutability has never been under much discussion and has always been taken for granted. It’s surprising that despite clear on-chain records and established history, the community still chooses to misleadingly report the protocol as immutable. It’s understandable seeing that the two instances in Bitcoin’s history that it’s anything but such. There have been other instances, where several bugs were found in the code, but never exploited on the mainnet, after being quietly fixed by the core devs without much prior disclosure.
This is a reference to CVE-2018-17144: Bitcoin’s Inventory Out-of-Memory Denial-of-Service, where miners could have exploited a Denial of Service (DoS) vulnerability and CVE-2018-17145: Inflation Bug Vulnerability – another bug which could have caused Bitcoin’s supply to inflate past the 21M limit. Both of these bugs had the potential of causing rollbacks but were fixed well before causing any problems. The protocol hasn’t encountered any other major issues since then, but Bitcoin immutability remains a shared myth to date.
Bitcoin is clearly not at all the direct democracy that many of its early adherents imagined, and, some worry, if a centralized core of the Bitcoin community is powerful enough to successfully undertake these emergency measures to set right the Bitcoin blockchain, what else is it powerful enough to do? Force double spends to reverse million-dollar thefts? Block or even redirect transactions known to originate from Silk Road? Perhaps even modify Bitcoin’s sacred 21 million currency supply limit?