Satoshi Nakamoto, the founder(s) of Bitcoin, added the block size limit in Bitcoin v0.3.1 on the 7th of September 2010. The block size limit efficiently limits the transactions per second limit of Bitcoin to about seven.
This post argues that adding the block size limit was a reaction to concerns over the spam attacks that were designed to exploit a flaw in the Bitcoin full node database and crash all Bitcoin Nodes. The transaction flooding also caused the Bitcoin full nodes to perform unnecessary work. Possibly bringing the network to a halt.
Why was the Bitcoin block size limit set and Bitcoin’s capacity limited to seven transactions per second? Let’s explore the circumstances:
Adding the block size limit was a quick and silent fix to defend an early and vulnerable Bitcoin network from being flooded by cheap transactions, causing the Bitcoin full node software to perform extra unnecessary work and crash.
In the early days of Bitcoin, there was an infancy problem: Transactions were too cheap, and there was a legitimate concern of too many transactions bloating the Bitcoin network cheaply and breaking things simply because Bitcoin and its software were still experimental and not battle-tested at scale:
Bitcoin price was low: Creating a spam attack and flooding the network with transactions was cheap because the Bitcoin used to pay transaction fees was cheap. Thus, there was effectively no limit on how many transactions could be broadcasted to the network per second.
Bitcoin was launched while it was still very early and not largely tested at scale. There were no guarantees that anything was secure or finished. Many people joined Satoshi to help improve the Bitcoin software and helped improve the code. Still, there were also adversaries or possibly someone testing attack vectors to see how secure Bitcoin was.
The spam attack on Bitcoin was archived under the name CVE-2010–5138, which was essentially an attack where someone flooded the Bitcoin network with transactions that contained extra data. Essentially, creating a denial-of-service (DOS) attack.
Let’s explore further.
Transaction Flooding attack CVE-2010–5138
On July 29 2010, it was discovered that block 71036 contained several transactions with a ton of OP_CHECKSIG commands. There should only ever be one such command. This caused every node to do extra unnecessary work, and it could have been used as a denial-of-service attack. (…)
It was discovered that the minor transaction flooding attack caused the Bitcoin software nodes to do unnecessary work, and notability slowed them down. The incident also indicated a weakness in the database used in the Bitcoin software, where it crashed under large loads. The database was several years later replaced in a later update when BerkleyDB was replaced with LevelDB. Still, after the transaction flooding attack (CVE-2010–5138), Satoshi had to take urgent steps to defend the network against the spam attack. Therefore, a block size limit was introduced to prevent Bitcoin nodes from crashing or drastically slowing down, thus preventing the Bitcoin network from grinding to a complete halt or significantly slowing down if someone decided to make a larger transaction flooding attack.
There was no explanation from Satoshi for why he added the block size limit; neither when deploying the new software, there was no mention of a block size limit being added in the release notes of Bitcoin Bitcoin 0.3.1. This is likely because Satoshi wanted to quickly deploy a defense against the attackers flooding Bitcoin with cheap transactions without alerting the attackers or any other nefarious actors about the defense strategy before it was completely deployed.
Bitcoin was an experimental technology whose security model wasn’t fully tested. A large, sustained maliciously transaction flooding attack likely would have:
- Crashed Bitcoin nodes due to issues with the database.
- Slowed down block validation significantly due to unnecessary processing.
- Made the network unusable for normal users.
According to Theymos, the administrator of Bitcoin Talk and the early Bitcoin Reddit page, Satoshi was never in the “group chat” (IRC) and almost never explained why he did anything, especially not setting the block size limit:
Satoshi never used IRC, and he rarely explained his motivations for anything. In this case, he kept the change secret and told people who discovered it to keep it quiet until it was over with so that controversy or attackers wouldn’t cause havok with the ongoing rule change. — Theymos, 2015
Satoshi Nakamoto simply deployed the block size limit in a new version of the Bitcoin software without any explanation, and we never got any answer from Satoshi as to why it was added. Later, on the Bitcoin Talk forum, Satoshi indicated that the block size limit was a bagatelle we could easily increase.
Bitcoin was launched on Jan 3rd, 2009, as experimental software running in production before it was adequately tested and proven secure for different attack vectors. Satoshi Nakamoto, Bitcoin, was busy improving the software and did not have capacity to do everything properly at once:
If you don’t believe it or don’t get it, I don’t have the time to try to convince you, sorry. — Satoshi Nakamoto, July 29, 2010,
There are no records of any prior explanation from Satoshi as to why the block size limit was added. After silently adding the block size to (likely) prevent the Bitcoin network from crashing, Satoshi added a tutorial on the Bitcoin Talk forum on how the block size limit could be increased and removed in the future:
It can be phased in, like:
if (blocknumber > 115000)
maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete.
When we’re near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade. — Satoshi Nakamoto, October 04, 2010
We know that Satoshi, according to the early Bitcoin developer Mike Hearn, wanted to scale Bitcoin to compete with the VISA credit card networking that processes a huge amount of transactions per day:
The existing Visa credit card network processes about 15 million Internet purchases per day worldwide. Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. It never really hits a scale ceiling. (…) — Satoshi Nakamoto April 2009
Notably, Gavin Andresen (Bitcoin developer, later lead maintainer of Bitcoin Core after Satoshi Nakamoto disappeared) stated on June 3rd 2014 that:
The plan from the beginning was to support huge blocks. The 1MB hard limit was always a temporary denial-of-service (DOS) prevention measure.
Later, the notable Bitcoin developer Ray Dillinger confirms the transaction flooding (DOS attack) theory:
I’m the guy who went over the blockchain stuff in Satoshi’s first cut of the bitcoin code. Satoshi didn’t have a 1MB limit in it. The limit was originally Hal Finney’s idea. Both Satoshi and I objected that it wouldn’t scale at 1MB. Hal was concerned about a potential DoS attack though, and after discussion, Satoshi agreed… But all 3 of us agreed that 1MB had to be temporary because it would never scale. — Ray Dillinger, February 07, 2015
Mike Hearn (another early Bitcoin developer) quotes his previously private correspondence with Satoshi in a blog post from May 5th 2015:
A higher limit can be phased in once we have actual use closer to the limit and make sure it’s working OK. — Satoshi Nakamoto, 2010
It is evident that the block size limit temporarily prevented Bitcoin from crashing until we were sure it was working OK in the early days. Now that the Bitcoin full node database has been upgraded and the Bitcoin price has increased, it would be costly and otherwise unfeasible for an attacker to perform such transactions as flooding or a DOS attack.
Finally, Satoshi says we can phase in a change (of block size) if we get closer to needing it:
We can phase in a change later if we get closer to needing it. — Satoshi Nakamoto, October 03, 2010,
Obviously we need it now because, the Bitcoin block size limit is serving no other purpose than acting as an invisible growth wall, as the following image from Peter R.’s post on the topic illustrates:
