This is a segment from the Supply Shock newsletter. To read full editions, subscribe . Few things are built to stand the test of time. Bitcoin is. Engineers design bridges to last only around 100 years. Modern-day dams might be built that only make it to half that. Perhaps regular maintenance could stretch those numbers by a few decades. They would still crumble much sooner than Bitcoin was ever intended to. Today is the 11th anniversary of a testament to exactly that: BIP-42, the clutch proposal that averted a potential supply crisis 240 years from now. Bitcoin Core contributor Pieter Wuille submitted BIP-42 on April Fool’s Day, 2014, years after Satoshi Nakamoto’s last post. BIP-42 was based on a solution proposed by Gregory Maxwell . Fittingly, it was both very serious and deeply unserious at the same time. BIP-42 doubled as a roast of Satoshi Nakamoto ( source ) . As it turns out, Satoshi had made a grave but obscure error when coding the logic for bitcoin halvings. The block reward had been correctly set to halve every 210,000 blocks, all the way down to an unspendable fraction of a sat by the year 2140 or so. This is what makes the BTC supply predictably and provably finite. But the code was written in such a way that it determines the mining reward using the current block height. And when the block height gets too high — much higher than it is today — Satoshi would’ve had to write special rules informing the software how to process such a calculation safely. The exact impact of the bug isn’t really knowable, but the largest of unintended consequences would have been that the block reward reverted to its original state of 50 BTC. BTC’s supply issuance curve would be rebooted to 2009. Left unchecked, the bug would return again and again every two and a half centuries, making for potentially infinite bitcoins over the millennia. Bitcoin’s circulating supply would hit 126 million in the year 3417, without fixing the supply bug. “Although it is widely believed that Satoshi was an inflation-hating goldbug, he never said this, and in fact programmed Bitcoin’s money supply to grow indefinitely, forever,” Wuille wrote. What’s humbling is that BIP-42 aborted a cataclysmic event that would’ve occurred 10 generations from now — in the approximate year 2265, when the block height should reach 13.44 million (today, it’s under 890,000). That’s over a century after the last slice of spendable bitcoin is expected to be mined, in 2140. So, I suppose our great, great, great, great, great, great, great, great grandchildren will have Wuille and Maxwell to thank for making sure that’s so. — David Rizzo’s view, as the Bitcoin Historian It’s nice that David can have a laugh over BIP-42. It is one of the more objectively quirky events in Bitcoin development history. That said, a more sober assessment raises thorny questions about the management of the Bitcoin software. One that I always linger on is the natural tension over what defines a “bug” in Bitcoin. Should we consider BIP-42 through the lens of jurisprudence, it helped enshrine two interesting views. First is the assertion that the code which BIP-42 patches is indeed a “bug” because it contradicts what Satoshi wrote, namely, that Bitcoin would have a fixed supply. Second is the view that the code is a “bug” because it contradicts what he told users to expect (creating a kind of social contract). There’s a truth to both assertions, but it seems to get more problematic when compared to how other code debates were handled. Take the infamous “block size,” for instance. In this case, Satoshi said it would be raised over time, and it’s also what most (if not all early users) expected. Ergo, the unchanged block size checks similar boxes as BIP-42. Yet no action was ever taken to change it. How to square this circle? Perhaps there’s the issue of safety. It’s true that eliminating the block size could lead to DDOS attacks, block withholding attacks, and potentially contribute to Bitcoin’s ultimate centralization. Equally, it could be said that rebooting the Bitcoin supply would constitute economic attacks. So, perhaps this was what swayed the decision. I talked to Luke Jr. about this, and here’s what he had to say: “It was the behaviour everyone expected. And also there was no guarantee future CPUs would have the previous behavior for the existing code either.” Unfortunately, due to the tone of the patch, however, we might never know what all the participants had to say. Get the news in your inbox. Explore Blockworks newsletters: Blockworks Daily : The newsletter that helps thousands of investors understand crypto and the markets, by Byron Gilliam. Empire : Start your morning with the top news and analysis to inform your day in crypto. Forward Guidance : Reporting and analysis on the growing intersection of crypto and macroeconomics, policy and finance. 0xResearch : Alpha directly in your inbox. Market highlights, data, degen trade ideas, governance updates, token performance and more. Lightspeed : Built for Solana investors, developers and community members. The latest from one of crypto’s hottest networks. The Drop : For crypto collectors and traders, covering apps, games, memes and more. Supply Shock : Tracking Bitcoin’s rise from internet plaything worth less than a penny to global phenomenon disrupting money as we know it.
