This article is part of our complete guide to Bitcoin and altcoin hacks. Here we cover Bitcoin and altcoin security incidents from the year 2010.
We’ll get started with what was, arguably, Bitcoin’s worse technical moment to this day – its worse hack, ever.
The year was 2010 and Bitcoin was just over 1 year old.
Bitcoin isn’t just the handsome looking graphical window you see when you run Bitcoin Core (or your favorite alternative wallet).
In the background, a daemon, which is a spooky name given by Unix hackers to processes that run all the time behind the scenes, listens for new network data, verifies the data and commits it to your local copy of the blockchain.
This background process can run either through the graphical interface you see or on its own, by running a program called bitcoind (the “d” stands for daemon).
On August 15th, 2010, Jeff Garzik, one of the early Bitcoin Core developers, noticed something strange going on with block 74638.
Several 92,233,720,368.54277039 (~92 billion) BTC transfers were mined in this block. This astronomic number by far overflowed the maximum number of Bitcoins allowed by the system (21 million BTC).
Something was seriously broken.
It turns out that versions of bitcoind before 0.3.11 would not check for certain erroneous conditions in transactions, such as numeric overflows.
The system could then blindly commit invalid TX’s into the blockchain.
In modern computers when a number is negative, it is marked by a single bit being turned on, usually at the leftmost position. If the computer interprets this bit as being part of the number and not a sign, it doubles the number value. But if it’s interpreted to mean “negative number” then it plays no part in the magnitude of the number, it just means that everything to the right of it is a negative number.
So if you mix signed and unsigned numbers in clever ways, you end up with serious problems.
Imagine if I made a Bitcoin transaction so big, to the point the amounts added up to a number the computer cannot handle. In this case we get something called an overflow. When a number overflows in computer programs, it inverts its signal. If they were positive, the result comes out negative. In fact, checking for sign inversion is one way to detect integer overflows.
It just so happened that bitcoind did not check for overflows in versions < 0.3.11. So someone crafted transactions containing 92233720368.54277039 Bitcoins, which added up resulted in a negative number. This negative number was interpreted as un unsigned value, which would consider the leftmost 1 bit to be part of the number. As you can imagine this results in an astronomical value. So, out of nowhere, over 180 billion BTC were minted.
Here’s where Bitcoin’s amazing core dev team showed their prowess.
Just a couple of hours after the detection of this flaw, the Bitcoin Core code had been patched and distributed to users from around the globe. This kind of agility is rare even in today’s largest and most popular open source projects.
The Bitcoin blockchain was forked and the one block containing the malicious coins was made deliberately invalid. A new chain grew, now starting from the valid end.
Had the attacker been more subtle about the exploit, finding ways to exploit the overflow by crafting smaller amounts, it might have taken longer to detect the security flaw.
This was the only time Bitcoin itself has ever been hacked and the only time Bitcoin ever reversed a transaction.
There was no other option. Leaving the invalid transaction in the chain would break Bitcoin forever by recognizing hundreds of billions of coins when the software-coded maximum is 21 million BTC.
It was a tense moment. For a few hours in August 2010 it seemed like Bitcoin was doomed.
If anything of the sort happened today, BTC price would like drop to zero instantly and would cost hundreds of billions of U$ in damages.
Fortunately, things were simpler back in 2010.
Return to the main article: The complete guide to Bitcoin and altcoin hacks