How to Hack Bitcoin: A History of Bitcoin Hacks
Published: 2020-12-05 at block 660071
Bitcoin Price: $18,975
Table of Contents
- Hacking Bitcoin
- Can Bitcoin Be Hacked / Has Bitcoin Been Hacked?
- What Is Bitcoin’s Uptime / Downtime?
- What Is CVE-2010-5139: Bitcoin’s Value Overflow Incident?
- What is CVE-2013-3220: Bitcoin’s Migration From BerkeleyDB to LevelDB Incident?
- What is CVE-2018-17144 / CVE-2018-17145: Bitcoin’s Inventory Out-of-Memory Denial-of-Service / Inflation Bug Vulnerability?
- How to Secure Bitcoin?
- Is Bitcoin Secure?
- Can Bitcoin Be Shut Down?
Hacking Bitcoin
Though Bitcoin is often considered an impenetrable peer-to-peer network, it is still susceptible to “hacks”. In the past, people “hacked” Bitcoin by exploiting bugs that were introduced into the Bitcoin codebase. Such exploits have previously allowed for double spends, transaction censorship, artificial supply inflation past the 21 million cap, etc.
As the Bitcoin codebase grows in complexity, you can expect the number of bugs introduced to increase in lockstep, though rigorous review and testing certainly help mitigate their impact.
Read on to learn about the history of Bitcoin's hacks and what we can do to ensure a more secure Bitcoin network moving forward.
Can Bitcoin Be Hacked / Has Bitcoin Been Hacked?
Many mistakenly equate Bitcoin exchange hacks (like Mt. Gox, Bitfinex, etc.) to Bitcoin itself getting hacked. This is an incorrect assertion. Still, the Bitcoin network has been “hacked” in the past through other means. In Bitcoin’s history of vulnerabilities, there have been three major bugs, two of which were exploited and resulted in chain rollbacks:
- CVE-2010-5139: Bitcoin’s Value Overflow Incident (Exploited)
- CVE-2013-3220: Bitcoin’s Migration From BerkeleyDB to LevelDB Incident (Exploited)
- CVE-2018-17144 / CVE-2018-17145: Bitcoin’s Inventory Out-of-Memory Denial-of-Service / Inflation Bug Vulnerability
Still, for a 12 year old piece of software with virtually no loss of funds, nearly 100% uptime, and a $350 billion bounty on its head (ie. the market cap as of 2020-12-05), Bitcoin is still regarded as one of the most secure networks ever created.
What Is Bitcoin’s Uptime / Downtime?
Many consider Bitcoin’s uptime to be 99.98% (as of 2020-12-05, Bitcoin has gone 2,826 days without downtime), with the only downtime events being related to the two exploited bugs:
- CVE-2010-5139: Bitcoin’s Value Overflow Incident - 8 hours and 27 minutes of downtime
- CVE-2013-3220: Bitcoin’s Migration From BerkeleyDB to LevelDB Incident - 6 hours and 20 minutes of downtime
Wikipedia defines uptime as “a measure of system reliability, expressed as the percentage of time a machine, typically a computer, has been working and available. Uptime is the opposite of downtime.”
What Is CVE-2010-5139: Bitcoin’s Value Overflow Incident?
On August 15th 2010, Jeff Garzik discovered in block 74,638 that an unknown entity exploited a value overflow bug in Bitcoin’s code. This allowed the attacker to create over 184 billion bitcoin amongst 3 addresses, well beyond the 21 million supply cap. This was possible because the code for checking Bitcoin transactions didn't work correctly when summing very large outputs.
Within five hours of the discovery, Satoshi Nakamoto published a new version of the Bitcoin client (0.3.10) with a fix that contained a soft fork. Network participants would soon pivot over to this new client and soft fork; by block height 74,691, they rejected the overflow transactions and adopted the “good” blockchain.
But in doing so, the network essentially made previously-valid blocks, which included the exploited transactions, invalid. Though the community achieved social consensus on which chain to roll back to, rollbacks have received much criticism both inside and outside the Bitcoin community. The criticism stems from the implications of rollbacks, such as a revision of history, censored transactions, loss of funds, a higher likelihood for double spends, etc.
How serious was this event? The lead maintainer of the Bitcoin repository on Github, Wladimir Van Der Laan said, “it was the worst problem ever.”
However, at this stage in Bitcoin’s life, the bug was perceived more as a growing pain. The price of bitcoin would jump from ~$0.07 and hit an all-time-high of nearly $0.40 later that year.
What is CVE-2013-3220: Bitcoin’s Migration From BerkeleyDB to LevelDB Incident?
On March 11th 2013, a bitcoin miner running version 0.8.0 created a large block at height 225,430 that was incompatible with earlier versions of Bitcoin. This led to a hard fork between network participants who were running version 0.8.0 and those running older versions. During this hard fork, a non-malicious actor was able to execute a large double spend, pushing Core developers to figure out the root cause. It turns out, the unplanned chain split was caused by a migration from Berkeley DB to Level DB, which did not implement the same locking limits.
Large mining pool operators who were running version 0.8.0, like Marek Palatinus of Slush and Michael Marsee (Eleuthria) of BTCGuild, were asked to switch back to version 0.7. By redirecting hashpower, miners could help the network reorganize around the pre-0.8 chain (which did not include the larger block) and make all Bitcoin software compatible again.
Slush and BTCGuild quickly downgraded their nodes despite having to sacrifice significant amounts of miner revenue. During this time, deposits to major exchanges and payments via BitPay were also temporarily suspended. The network finally succeeded in its chain rollback on August 16th 2013 when block 252,451 was accepted by the main network, as noted in BIP50 - Gavin Andreesen’s post-mortem.
Just like with CVE-2010-5139 (Bitcoin’s Value Overflow Incident), the Bitcoin network made previously-valid blocks invalid by rolling back to another chain, and criticisms of centralized coordination once again rose to the forefront. Still, with the crisis averted, the price of bitcoin would hit another ATH of about $1,200 later that year.
What is CVE-2018-17144 / CVE-2018-17145: Bitcoin’s Inventory Out-of-Memory Denial-of-Service / Inflation Bug Vulnerability?
On September 17th 2018, developer Awemany (aka: Beardnboobies) disclosed a vulnerability to Bitcoin Core developers. This vulnerability could allow a miner to double-spend bitcoins, with the potential to inflate bitcoin past the 21 million hard cap. Compared to the other bugs listed above, this one was never exploited on mainnet. But the severity of the bug was so great that Core developers initially kept it a secret, in order to fix the exploit in a timely manner.
What enabled this critical bug? In 2016, version 0.14 of Bitcoin included what seemed to be a 600 microsecond optimization. But the optimization removed what was believed to be a redundant check on newly-received blocks. The removal of this check introduced a denial-of-service (DoS) vulnerability that could be exploited by miners (CVE-2018-17145). This issue alone could’ve shut down a chunk of the network.
But then in 2017, another issue was introduced into the codebase. Version 0.15.0 edited code that was supposed to catch unexpected errors. Instead, the change did the opposite, allowing miners to double spend bitcoin (though this was never exploited on mainnet), with the potential to inflate the supply beyond the 21 million ceiling (CVE-2018-17144).
So a day after Awemany reported the double-spend issue, Bitcoin Core developers fixed it and pushed out an update (0.16.3). However, they initially only disclosed the less serious DoS vulnerability in the release notes. Why? Because during this time, they would push businesses and miners like SlushPool to upgrade, to minimize the chance of a chain split from occurring.
They would continue to delay publication of the full issue until after the new version had both the majority of the hashrate and enough adoption by users. The developers would officially disclose CVE-2018-17144 on September 20th 2018. A day later, Core developers warned users that for the following week, they should only consider transactions with 200 confirmations to be irreversible, instead of the standard 6.
Jimmy Song notes in his analysis of CVE-2018-17144 what could’ve happened if the bug was exploited:
- 0.14.x nodes would have crashed
- Older nodes and many alternative clients would have rejected that block
- Many block explorers run on custom software and not core, so at least some would have rejected the block and wouldn’t have shown any transactions from that block
- Depending on the software miners were running we may have ended up with a chain split.
“Because of these irregularities, people on the network would soon have tracked this down, probably have alerted some developers and the core developers would have fixed it. If there was a fork, the social consensus at that point about which is the right chain would start getting discussed and the chain creating unexpected inflation would have likely lost out.”
In other words, another rollback.
How to Secure Bitcoin?
As demonstrated throughout Bitcoin’s history, mining pools have the incentive to act in the best interest of Bitcoin. Though it seems 51% attacks are less likely to happen as a result, bugs in the Bitcoin codebase remain as prime targets for exploitation. Increasing the amount of review and testing that code changes receive can help secure Bitcoin.
If you or your organization are invested in the future of Bitcoin, consider hiring or sponsoring developers who actively review and write tests for the Bitcoin codebase, and please do not rush development. You might find the following resources helpful:
- https://brink.dev/
- https://bitcoincore.reviews/
- https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
- https://bitcoinops.org/
If you are looking to secure your own bitcoin holdings, there are many tutorials online. You may want to look up keywords like “cold storage,” “hardware wallets,” “backup seed phrase,” etc.
Is Bitcoin Secure?
For a 12 year old piece of software with virtually no loss of funds, nearly 100% uptime, and a $350 billion bounty on its head (ie. the market cap as of 2020-12-05), Bitcoin is still regarded as one of the most secure networks ever created. Though bugs in Bitcoin’s codebase have been exploited in the past; though wallet users have been scammed out of their bitcoins by malicious actors; etc. - social consensus amongst node operators, miners, developers, businesses, and other participants ensures Bitcoin’s security and value.
Can Bitcoin Be Shut Down?
Though Bitcoin hasn’t worked as expected in the past (see: CVE-2010-5139 and CVE-2013-3220), Bitcoin is one of the most resilient and censorship-resistant networks that has ever existed. As a peer-to-peer network, it has never been shut down and likely never will be, as long as one computer is running Bitcoin software. However, services like merchants and exchanges can be shut down according to local law.
Hope you found this blog post insightful - if you did, make sure to subscribe to the newsletter to stay up to date on the latest posts!
What else would you like to learn more about? Let me know on Telegram!
