As mentioned in the last chapter, the influx of users from Slashdot on July 11, 2010, caused a huge wave of interest in Satoshi Nakamoto's project. The network's use exploded, and the exchange rate increased tenfold, as did the computing power dedicated to the system. Thus, Bitcoin experienced unprecedented growth over the summer.

However, this success was accompanied by technical issues, with the discovery of some vulnerabilities in the software. Greater popularity meant more people inspecting the code and a higher likelihood of operational anomalies. And this is precisely what happened on August 15 with the value overflow incident, the first "breakdown" in Bitcoin's history, which lasted about 15 hours. This period was naturally marked by an improvement in the software, to anticipate various threats and correct flaws as much as possible.

The influx of users from Slashdot also necessitated improving the software. Found vulnerabilities needed to be corrected, and new features had to be integrated. Satoshi was thus under pressure: on July 18, he confided to Martti Malmi in private that he was "losing my mind there are so many things that need to be done." In two months, no fewer than eight sub-versions of the software were released! However, the creator of Bitcoin is not working on the code alone. He can count on Gavin Andresen, who arrived in June and is becoming increasingly involved in development (he is credited on the SourceForge repository as of July 9th). Some people are curious about how the system works and report issues when they encounter them, such as Christian Decker (cdecker) or Michael Marquardt (better known by the pseudonym Theymos). Satoshi is also supported by miners, who modify the code to find ways to optimize the generation of units, like ArtForz (the first person to set up a mining farm, as we will see in the next chapter), German developer Nils Schneider (tcatm), Michael Brown (knightmb), or BlackEye.

Finally, we can mention Jeff Garzik (using the pseudonym jgarzik on the forum), an American developer and contributor in the world of free software, notably for the Red Hat distribution, and a libertarian follower of the Austrian school of economics. He discovered Bitcoin through the article on Slashdot and almost immediately got involved in Bitcoin.

Jeff Garzik in 2013 (source: Benson Samuel)

Satoshi's first goal is to make the software and protocol more secure, to cope with the recent increase in usage. Together with Gavin Andresen, they consider the various attacks that could occur (including denial of service attacks) and strive to correct the vulnerabilities discovered. This is how a system of checkpoints is added on July 17th (v0.3.2), preventing the chain from being rewritten before a certain date, and the notion of work is integrated on July 25th (v0.3.3) to refine the mechanism for selecting the correct chain by the nodes.

Gavin and Satoshi also fix several bugs. The main one is the “1 RETURN bug,” a vulnerability in the scripting system that makes it possible to spend bitcoins from any address thanks to a specific script. This vulnerability is reported by ArtForz on July 28, who instead of exploiting the flaw and discreetly enriching himself, chooses to share his discovery with Satoshi and Gavin. Satoshi rushes to include the fix in the software (v0.3.6) and recommends that all users upgrade. Bitcoin thus escapes the worst. This vulnerability will later be registered with the MITRE Corporation under the identifier CVE-2010-5141.

The second goal was to improve the system's performance by modifying the protocol or optimizing the software's operation. It is in this category that the addition of OP_NOP operation codes to the internal script system falls, discreetly carried out by Satoshi on July 29 (v0.3.6), with the sole comment being the word "expansion." These operation codes are silent instructions that have no effect if present in a script, but do not invalidate the transaction. Consequently, one can modify the behavior of these instructions without making the scripts incompatible with an older protocol version, hence Satoshi's comment. These operation codes would notably allow for what would be called "soft forks" in 2015 and 2016, by transforming the instructions OP_NOP2 and OP_NOP3 into OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY (respectively).

Miners also share their discoveries to improve, directly or indirectly, the generation of bitcoins with the main software. First, Laszlo's personal optimization was integrated into the software on July 6 (v0.3.0). Then, the context caching for the SHA-256 hash function by Nils Schneider and the optimization of its calculation by BlackEye were added to the software on July 29 (v0.3.6). Finally, the parallelization of calculation on a single processor proposed by Nils Schneider (again) was integrated into the code on August 15 (v0.3.10).

All these improvements mean that Bitcoin is getting stronger daily in terms of software operation and mining performance. However, an event that deeply marks the community somewhat tarnishes this innovative momentum. The value overflow incident occurred in August and disrupted the network for about fifteen hours.

On August 15, 2010, around 5 PM (UTC), a block containing a transaction that created more than 184 billion bitcoins was added to the chain at height 74,638. This extraordinarily high issuance exploited a memory overflow vulnerability in the representation of quantities: the attacker created two transaction outputs of 92,233,720,368.54277039 BTC each, an amount close to the maximum units that can be represented by a signed 64-bit integer (the format used in the protocol).

One hour later, the problem was spotted by Jeff Garzik, who warned the community on the forum about a "strange block". Satoshi's response came around 9 PM: he published a preliminary code modification on the forum and advised people to "stop generating". After making some revisions and uploading them to Sourceforge, he eventually released a patch for Windows, Linux, and Mac OS X at 11:48 PM.

This patch allowed miners to reject the incriminated transaction as invalid and to create an alternative branch that does not contain it. The first block of this branch was found at 11:53 PM.

The next morning, shortly after 8 AM, the conflictual situation was resolved. The correct chain became longer than the other, which meant all nodes had to follow this chain, whether they applied the patch or not. This incident disrupted network activity for about 15 hours, but the community's responsiveness was exemplary. Satoshi wrote around 1 PM:

After discovering the 1 RETURN bug in July, Satoshi Nakamoto did everything possible to protect the network against accidents. On August 3, he added a warning mechanism to the software that activates in case of a chain split (v0.3.8). However, this mechanism proved not to be useful for detecting the value overflow bug that emerged on the 15th, prompting Satoshi to expedite his plan to develop a more advanced mechanism.

In the days following the incident, Satoshi thus built an effective alert system on the network, which allowed him, with a private key, to warn nodes in case of technical problems and to suspend some API commands. On August 22, he presented his system on the forum. This announcement raised concerns among members, who saw in this system a centralizing element and a vulnerability that a state could exploit. Satoshi replied two days later, calling these considerations "paranoid" and specifying that the system could be manually disabled by users and that it would be temporary anyway.

On August 27, the alert system was officially integrated into the software (v0.3.11). The possibility of suspending functionalities was removed in December. In the following years, the warning system was used several times, notably for an accidental fork in 2013, before being definitively removed from the software in 2017.

Another element of the effort to improve the protocol and make it resistant to attacks is adding the transaction block size limit. This limit restricts the system's transactional capacity by requiring each block to be smaller than this size. Its initial goal was to prevent denial-of-service attacks against the network.

This parameter was added discreetly to the code by Satoshi on July 15 in the form of the constant MAX_BLOCK_SIZE (v0.3.1), which was then set to 1 megabyte (1,000,000 bytes). The programming of the implementation of the constraint was carried out on September 7 by the creator of Bitcoin, again without any public announcement from him (v0.3.12). It stipulated that the size limit (which also restricts the number of signature operators in the blocks) would come into effect starting from block 79,400. The activation occurred on September 12. This limitation was then quite benign: it allowed a throughput of 7 standard transactions per second, which was more than enough to support the economic activity of the time, even after the slashdotting.

Although Satoshi did not mention the existence of the block size limit, several people noticed its presence in the code over time. It was thus remarked upon as early as August 12 by a Russian-speaking forum member using the pseudonym throughput who stated, in a relatively favorable tone, that "Another interesting aspect is that the byte size of the block (so the number of transactions in it) is limited." Later, on September 30, it was Theymos who pointed out to another member that "Bitcoin won't allow blocks over 1MB, so assuming a (rather small) average transaction size of 216 bytes, Bitcoin can only handle 4,629 transactions every 10 minutes." Finally, the presence of this parameter affects Jeff Garzik who declares to be "much more concerned about scalability than government shutdown" and who asks how it is possible to "sell bitcoin to serious investors, with built-in limitations like the 463 transactions per minute limit." Consequently, on October 3rd, he proposes a patch on the forum to increase the block size limit to 7.168 MB to "match PayPal's average transaction rate." Theymos responds by saying that "applying this patch will make you incompatible with other Bitcoin clients." This message is endorsed by Satoshi Nakamoto who recommends not using the patch and states: "We can phase in a change later if we get closer to needing it." The latter clarifies his thoughts the next day by guiding how to make such a protocol change.

This discussion marks the beginning of the debate on scalability, which would eventually lead to a real civil war between 2015 and 2017, known as the blocksize war.

In September, Satoshi also introduced a new concept in the code: non-standard transactions. These are transactions that default-configured nodes do not relay, do not keep in their mempools, and do not include in the blocks they produce. However, these transactions remain valid, and the entire network accepts blocks containing them.

This normative distinction helps to limit the exploitation of potential vulnerabilities in Bitcoin's scripting system, which is quite rich and has not been sufficiently examined, at the cost of a temporary restriction on programmability. At this time, two types of output scripts are identified as standard by the network:

During the summer of 2010, a period rich in events, Satoshi dedicated himself to the software development of Bitcoin. The publication of the Bitcoin introductory text on Slashdot led to an unprecedented influx of users, which also put the system at risk. Consequently, the founder and those assisting him (notably Gavin Andresen) tried their best to correct vulnerabilities. However, the network did not escape a major incident, the value overflow incident, which led to the creation of an alert system managed by Satoshi within the software. Finally, this period was also marked by the addition of the block size limit, a fundamental element in the history of Bitcoin.

In the following months, technical, economic, and mining improvements emerged, gradually transforming Bitcoin into a collective project. The "Bitcoin community" finally came to life as an autonomous entity. We will study this in the next part of this course.