LordFestival on Nostr: people say bitcoin has never been hacked. mostly true, but in august 2010 someone ...
people say bitcoin has never been hacked. mostly true, but in august 2010 someone created 184 billion BTC out of thin air and it sat in the chain for about a day
block 74638. one transaction, two outputs, each worth around 92 billion BTC
the bug was simple. the node checked that every output value was non-negative, and that total outputs didn't exceed total inputs. what it didn't check was what happens when you add two huge int64 values together. the sum overflowed, wrapped around to a negative number, and a negative number is obviously less than the inputs. check passed. block valid
so for a few hours the actual consensus rules of bitcoin said this was fine
jeff garzik spotted it, satoshi pushed a patch within roughly 5 hours, and 0.3.10 added range checks so no single output and no total can exceed MAX_MONEY (21M BTC). nodes that upgraded rejected the bad block, miners started building a new chain from before it, and once that chain got longer everyone reorged onto it. the 184 billion coins just stopped existing
what i find interesting looking back:
the fix was a soft fork. it only made the rules stricter, so it didn't need everyone to agree on anything new, just enough hashrate to outpace the bad chain
it only worked because the network was tiny. a handful of people, most of them reading the same forum. try coordinating that today with exchanges, custodians, lightning nodes and thousands of independent node operators. you'd get a mess
and it's the reason MAX_MONEY checks are all over the codebase now. a lot of "boring" defensive code in bitcoin core exists because something like this happened once
sanity checks on value ranges are not optional. learned the hard way at block 74638
#bitcoin #bitcoindev #history
Published at
2026-10-21 22:05:09 UTCEvent JSON
{
"id": "32cd1b3547c2de39ae831cde6dc1c5d6d01c53ec0ba8635fe9ac00799e73a2ba",
"pubkey": "36b6eec48a79bee9b4718ab9bbe44a3591fc52d1a4eaa1c0025669c0a6afb3d0",
"created_at": 1792620309,
"kind": 1,
"tags": [
[
"t",
"bitcoin"
],
[
"t",
"bitcoindev"
],
[
"t",
"history"
],
[
"client",
"Nostrich"
]
],
"content": "people say bitcoin has never been hacked. mostly true, but in august 2010 someone created 184 billion BTC out of thin air and it sat in the chain for about a day\n\nblock 74638. one transaction, two outputs, each worth around 92 billion BTC\n\nthe bug was simple. the node checked that every output value was non-negative, and that total outputs didn't exceed total inputs. what it didn't check was what happens when you add two huge int64 values together. the sum overflowed, wrapped around to a negative number, and a negative number is obviously less than the inputs. check passed. block valid\n\nso for a few hours the actual consensus rules of bitcoin said this was fine\n\njeff garzik spotted it, satoshi pushed a patch within roughly 5 hours, and 0.3.10 added range checks so no single output and no total can exceed MAX_MONEY (21M BTC). nodes that upgraded rejected the bad block, miners started building a new chain from before it, and once that chain got longer everyone reorged onto it. the 184 billion coins just stopped existing\n\nwhat i find interesting looking back:\n\nthe fix was a soft fork. it only made the rules stricter, so it didn't need everyone to agree on anything new, just enough hashrate to outpace the bad chain\n\nit only worked because the network was tiny. a handful of people, most of them reading the same forum. try coordinating that today with exchanges, custodians, lightning nodes and thousands of independent node operators. you'd get a mess\n\nand it's the reason MAX_MONEY checks are all over the codebase now. a lot of \"boring\" defensive code in bitcoin core exists because something like this happened once\n\nsanity checks on value ranges are not optional. learned the hard way at block 74638\n\n#bitcoin #bitcoindev #history",
"sig": "8cf7bec4920509114b3986969efbce85b6a1ea689241c5b854c9cb3de4e1b7c2be61142fe66a77e9fb0ab4c40f8c2e2b194a0a027399133e1ebfb0d397bc684d"
}