Module 5 · The Bitcoin Story / 5.1
Pizza, a broken exchange, and a disagreement.
Early Bitcoin history makes more sense when we separate the lessons.
In May 2010, a programmer named Laszlo Hanyecz offered 10,000 bitcoin for two pizzas. A few days later, he reported that the trade had happened.
It is easy to turn this into a story about what lunch would cost at a later price. The more useful detail is simpler: two people found a way to exchange bitcoin for something they wanted.
A network becomes something people use.
Bitcoin began as an experiment among a small group of participants. They ran software, sent test payments and found ways to exchange the units. Some early websites called faucets gave small amounts away so people could try the network.
The pizza trade is a well-documented early goods purchase. It did not prove that bitcoin would become valuable forever, or that every merchant already accepted it. It showed a particular exchange taking place.
This connects to the first lesson. Acceptance comes from people making a trade possible. The future price is not evidence that someone was foolish to use an asset for its intended purpose at the time.
The software was not beyond mistakes.
In August 2010, an arithmetic bug allowed an invalidly large issuance. Participants adopted a fix and a corrected history. This was a software failure and a coordinated response, not a demonstration that code can never break.
In March 2013, an incompatibility between software versions split the network’s history temporarily. Miners and developers coordinated a response; the incident is documented in BIP50. It included disruption and a double spend.
Later vulnerabilities also mattered. A serious inflation-related flaw disclosed in 2018 was fixed; the Bitcoin Core disclosure reported no known exploitation on the Bitcoin main network. The history cannot honestly be summarized as “only one bug.”
These events show why software review, diverse scrutiny, deployment choices and incident response remain part of security. A network can recover from a problem without making the original problem imaginary.
An exchange is another layer of trust.
Mt. Gox was a major exchange where customers traded and left assets in custody. In 2014 it stopped withdrawals and entered insolvency proceedings after large losses.
A customer balance on that website was not the same as direct control of a Bitcoin output. The exchange could fail to meet its obligations while the network continued processing transactions.
The resulting rehabilitation and repayments took years. The details belong to the custody failure, not to a failure of every cryptographic signature. People outside the exchange avoided that particular exposure, but they could still suffer falling prices or unrelated losses.
Early speculation and illicit marketplaces also shaped Bitcoin’s reputation. These are further questions about use, markets and law. They should not be collapsed into a single claim that either “Bitcoin worked perfectly” or “everything broke.”
A service failure example, not a claim that protocol failures never happen.
A disagreement about what to protect.
As use grew, participants disagreed about increasing transaction capacity. Larger blocks can hold more data, but they also increase the work of downloading, processing and storing history. The cost of independent verification was part of the debate.
Supporters of larger blocks emphasized lower congestion and on-chain use. Others emphasized keeping validation accessible and developing additional layers. These were competing priorities, not a simple contest between people who wanted progress and people who did not.
SegWit changed how transaction data was accounted for and addressed a transaction-malleability issue important to later payment protocols. It activated in 2017. Bitcoin Cash began a separate larger-block history that year. A further proposed Bitcoin hard fork, often called SegWit2x, was called off.
The practical lesson is that powerful organizations could not settle adoption merely by announcing an agreement. Developers, miners, node operators, businesses and users all affected the result. It did not create a permanent rule that one group always wins every future dispute.
A little more history
The scaling debate also involved a user-activated soft-fork proposal: participants could choose software that enforced a particular activation policy. Signalling, coordination and economic support all mattered; raw node counts were not a universal election.
The early price booms, market crashes and periods of quieter development are context, not a timing strategy. A quiet period does not prove that every surviving project is building something useful.
The idea to keep
The pizzas teach acceptance. The software incidents teach validation and coordination. Mt. Gox teaches custody. The capacity debate teaches tradeoffs and adoption. History becomes useful when each event keeps its own lesson.