Block Size, the history of choosing 1MB
The bitcoin block size is 1MB. Why was this number chosen? The reasoning of the past may have application to the reasoning in the present and future.
Original Code #
The block size is defined in code by
MAX_BLOCK_SIZE and is
MAX_BLOCK_SIZE first appears in commit a30b56ebe76ffff9f9cc8a6667186179413c6349 by s_nakamoto on Thu Jul 15 00:18:45 2010
You can verify this yourself:
git log -S MAX_BLOCK_SIZE --source --all
The line of code originally committed was (and still is)
static const unsigned int MAX_BLOCK_SIZE = 1000000;
Historical Context #
Let’s get some context around bitcoin at this period of time.
The next release about a day after
MAX_BLOCK_SIZE was introduced is version 0.3.1 rc1
Changelogs for bitcoin releases don’t go back to version 0.3.1, they start at v0.3.12. So the changelogs don’t contain any details about this change.
Coincidentally, there was a request for changelogs around the time 0.3.1 was released.
Discussion Of Change #
What did Satoshi have to say about this change?
bitcoin-dev mailing list archive only goes back to June 2011 so has no records from the time this change was made.
The sourceforge mailing list at the time says most conversation has moved to the forum (which is now at bitcointalk.org).
All Satoshi’s posts on the bitcoin forum are here
Posts from around this time can be found on page 18.
Searching all posts by Satoshi (performed on a locally cached version of these posts since the web search is extremely strictly rate limited)
1MB - Nothing
one meg - Nothing
MAX_BLOCK_SIZE - Nothing relevant
“The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.” - August 04, 2010, 04:25:36 PM - https://bitcointalk.org/index.php?topic=287.msg7524#msg7524
“We can phase in a change later if we get closer to needing it.” - October 03, 2010, 09:07:28 PM - https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139
“Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.” - August 05, 2010, 04:03:21 PM - https://bitcointalk.org/index.php?topic=287.msg7687#msg7687
“It would be nice to keep the blk*.dat files small as long as we can. The eventual solution will be to not care how big it gets. But for now, while it’s still small, it’s nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won’t matter much anymore.” - August 11, 2010, 11:28:50 PM - https://bitcointalk.org/index.php?t opic=287.msg8810#msg8810
There is no discussion around how the max block size change was decided or how the 1MB value was derived.
Spam management was only considered by setting the minimum output amount (called dust), not by using the max block size. Even though spam control was almost certainly the intent behind this change, it’s never actually stated anywhere.
Considering how important this issue has recently become in bitcoin, it seems unusual to ignore the history and instead dogmatically claim the original magic number is the best magic number. I don’t care whether 1MB is or isn’t the best number to have picked; to argue that ‘magic number picking’ has given us the best solution and should be retained is not an acceptable position to hold.
Science and engineering should be applied to arrive at an appropriate max block size that meets the goals and objectives of the bitcoin project. Maybe this science will conclude 1MB is indeed the best number to use right now, but I find that hard to believe. Maybe 999kB is better!
Of course, the engineering and science is easy to ask for, but hard to do. Let’s not allow that to justify the dogma currently being espoused.
There’s a great discussion from a few months ago about this on reddit: