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 1000000 bytes.

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

All Satoshi’s posts on the bitcoin forum are here;u=3;sa=showPosts

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 -

“block size”
“We can phase in a change later if we get closer to needing it.” - October 03, 2010, 09:07:28 PM -

“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 -

“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 - opic=287.msg8810#msg8810

Conclusion #

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.

Addendum #

There’s a great discussion from a few months ago about this on reddit:


Now read this

Engineering a bitcoin max_block_size

Engineering # The crucial and unique task of the engineer is to identify, understand, and interpret the constraints on a design in order to produce a successful result. Constraints # An engineer finds an acceptable solution within the... Continue →