<p>A block size limit is necessary to avoid a trivial DOS vector. See <a href="https://bitcoin.stackexchange.com/a/37303/101498">this answer</a> for some explanations. But from the body of your question it rather seems you are asking why the limit isn't <em>increased</em>.</p>
<p>First of all we should ask the obvious: what for? Such a change comes at the tremendous cost of a hard fork: there is nobody in charge of Bitcoin to say &quot;starting tomorrow blocks can be twice as large&quot;. Therefore the upsides of the increase should <em>at least</em> compensate for the cost of a hardfork. I'm not aware of any upside to an increase in the block size limit which i would consider meet this bar.</p>
<p>In addition, there is more costs to a block size increase than the sole use of a hard fork:</p>
<ul>
<li>It would proportionally increase the maximum rate at which the UTxO set can be bloated.</li>
<li>It would increase blocks propagation time, most likely leading to further mining pool centralization (see <a href="https://bitcoin.stackexchange.com/a/56494/101498">this</a> and <a href="https://bitcoin.stackexchange.com/a/113506/101498">this</a> answers for details).</li>
<li>It would increase the barrier to entry for running a fully-validating node.</li>
</ul>
<p>There is also more subjective objections to increasing the block size, which i don't think even need to be considered in this context. These include for instance uncertainty about miners' revenue in a low- or post-subsidy world. Or the fact that fiddling with the block size is tweaking the market for block space which is a can of worms in itself (what is the right value? If it's modified once and some, potentially unrelated, bad things happen there will be a lot of pressure to modify it again).</p>
<p>In conclusion, i believe the block size was never explicitly increased through a hard fork because it does not pass a technical risks/benefits analysis. And the technical community members did not yield to the huge amount of pressure that was once put on them to disregard the costs. At the end of the day, Bitcoin is a system in which all full participants validate, store and broadcast all the onchain transactions of every single other participant. This obviously cannot scale (only) by increasing the number of onchain transactions each participant can make.</p>

CC BY-SA 4.0
2023-10-24T09:16:35.713Z
2023-10-24T16:35:52.097Z
2023-10-24T16:35:52.097Z
Antoine Poinsot
<p>Because throughout 2012-2015, after Satoshi Nakamoto disappeared, &quot;no hard-forking upgrades&quot; became a de facto social rule of the Bitcoin network (BTC) so old non-upgraded nodes won't become stranded on upgrades.
This is why <a href="https://bitcoin.stackexchange.com/questions/43839/a-common-criticism-of-segregated-witness-is-that-it-is-unnecessarily-complex/115821#115821">SegWit</a> was the only possible way to increase TPS capacity without breaking UTXO view for old nodes (further increase via soft-forking would only be possible through <a href="https://blog.purse.io/ready-for-liftoff-a5533f4de0b6?gi=df2a2bf608b" rel="noreferrer">extension blocks</a>, which <strong>would</strong> break UTXO view for old nodes).</p>
<p>The other de facto social rule is that node running should be as widely accessible as possible. Thanks to increases in bandwidth and propagation tech such as <a href="https://bitcoinops.org/en/topics/compact-block-relay/" rel="noreferrer">compact block relay</a> block size limit could be higher without much risk of pool centralization (8 MB should be manageable today and wouldn't 8x the risk of centralization). However, it would mean that bandwidth-limited nodes couldn't keep up or would take too long for initial block download.
The Bitcoin network kept the limit low for this reason as well, and current stewardship of the project maintains that decision.</p>
<p>Bitcoin code is free open-source (MIT license) and anyone can fork the code and change the limit <strong>for himself</strong>.
However, he can't force others to accept the changed rules by running such software.
What happens if he manages to convince only a subset of the network to run patched node software?
A permanent hard fork, and then the forked network has to convince the social / markets layer to give it value, and use the value to bid for mining hashes.</p>
<p>We have seen this play out with <a href="https://bitcoin.stackexchange.com/questions/120027/what-are-the-last-common-blocks-of-bitcoin-and-its-hard-forks-bitcoin-cash-bit/120029#120029">main forks of Bitcoin</a>.</p>
<p>See also <a href="https://bitcoin.stackexchange.com/a/120001/137501">here</a> for a brief history of the blocksize limit, and <a href="https://hackernoon.com/the-great-bitcoin-scaling-debate-a-timeline-6108081dbada" rel="noreferrer">here</a> and <a href="https://www.reddit.com/r/btc/comments/bvj08f/an_incomplete_history_of_the_bitcoin_cashs_origin/" rel="noreferrer">here</a> for a timeline of events that led to the first permanent fork of Bitcoin.</p>
<p>Note that <a href="https://bitcoin.stackexchange.com/a/118315/137501">&quot;Nakamoto Consensus&quot;</a> doesn't decide which blockchain wins the branding / ticker. It is market &amp; social forces which map blockchains to recognized currencies.</p>

CC BY-SA 4.0
2023-10-24T07:18:41.410Z
2023-10-24T10:21:54.757Z
2023-10-24T10:21:54.757Z
bca-0353f40e
<p>Actually, the block size limit is no longer 1MB. That changed with the big <strong>segWit soft fork</strong>. Currently, block size is measured in virtual bytes, not bytes. The current block limit in virtual bytes is 4(v)MB. Looking at the &quot;real&quot; bytes, those 4v(MB) could go to around 3,8MB. However, the average is slightly less than 2MB.</p>
<p>Therefore, the block size has been increased from 1MB.</p>
<p><a href="https://mempool.space/" rel="nofollow noreferrer">Here</a> you can see the size of each block together will other related information (purple-blue chain/blocks).</p>
<p><a href="https://mempool.space/block/0000000000000000000236b979d361184d97ecfdda0197c3c24336f298aaadfe" rel="nofollow noreferrer">Block #813485</a> is interesting since it's size is 3.82MB.</p>

CC BY-SA 4.0
2023-10-24T19:26:57.903Z
While this answer correctly challenges the framing and explains how the blocksize was increased, it could be improved by elaborating on why there is a limit in the first place.
Murch
CC BY-SA 4.0
2023-10-23T23:35:48.980Z
2023-10-23T23:46:05.640Z
2023-10-23T23:46:05.640Z
dassd
<p>Storage costs are now ridiculously smaller than they were when the limit was introduced more than 10 years ago. I am concerned keeping this arbitrary limit set by Satoshi could be holding us back.</p>
<p>Why do we still have a 1MiB block limit?</p>

CC BY-SA 4.0
2023-10-24T15:37:40.370Z
[What are the arguments for and against the increase of the block size limit?](https://bitcoin.stackexchange.com/questions/36085/what-are-the-arguments-for-and-against-the-increase-of-the-block-size-limit)
qwr
<blockchain><blocksize><block-size-increase>
Why is there a block size limit and why not increasing it?
N. Matic
# Why is there a block size limit and why not increasing it?

(Asked by: username_0 on 2023-10-23)

Storage costs are now ridiculously smaller than they were when the limit was introduced more than 10 years ago. I am concerned keeping this arbitrary limit set by Satoshi could be holding us back.

Why do we still have a 1MiB block limit?

**Tags:** blockchain, blocksize, block-size-increase

> **Comments:**
> **username_1**: [What are the arguments for and against the increase of the block size limit?](https://bitcoin.stackexchange.com/questions/36085/what-are-the-arguments-for-and-against-the-increase-of-the-block-size-limit)  

---

## 3 answers

### Answer by username_2 on 2023-10-24. Score: 8

A block size limit is necessary to avoid a trivial DOS vector. See [this answer](https://bitcoin.stackexchange.com/a/37303/101498) for some explanations. But from the body of your question it rather seems you are asking why the limit isn't *increased*.

First of all we should ask the obvious: what for? Such a change comes at the tremendous cost of a hard fork: there is nobody in charge of Bitcoin to say "starting tomorrow blocks can be twice as large". Therefore the upsides of the increase should *at least* compensate for the cost of a hardfork. I'm not aware of any upside to an increase in the block size limit which i would consider meet this bar.

In addition, there is more costs to a block size increase than the sole use of a hard fork:

* It would proportionally increase the maximum rate at which the UTxO set can be bloated.
* It would increase blocks propagation time, most likely leading to further mining pool centralization (see [this](https://bitcoin.stackexchange.com/a/56494/101498) and [this](https://bitcoin.stackexchange.com/a/113506/101498) answers for details).
* It would increase the barrier to entry for running a fully-validating node.

There is also more subjective objections to increasing the block size, which i don't think even need to be considered in this context. These include for instance uncertainty about miners' revenue in a low- or post-subsidy world. Or the fact that fiddling with the block size is tweaking the market for block space which is a can of worms in itself (what is the right value? If it's modified once and some, potentially unrelated, bad things happen there will be a lot of pressure to modify it again).

In conclusion, i believe the block size was never explicitly increased through a hard fork because it does not pass a technical risks/benefits analysis. And the technical community members did not yield to the huge amount of pressure that was once put on them to disregard the costs. At the end of the day, Bitcoin is a system in which all full participants validate, store and broadcast all the onchain transactions of every single other participant. This obviously cannot scale (only) by increasing the number of onchain transactions each participant can make.


---

### Answer by username_3 on 2023-10-24. Score: 4

Because throughout 2012-2015, after Satoshi Nakamoto disappeared, "no hard-forking upgrades" became a de facto social rule of the Bitcoin network (BTC) so old non-upgraded nodes won't become stranded on upgrades.
This is why [SegWit](https://bitcoin.stackexchange.com/questions/43839/a-common-criticism-of-segregated-witness-is-that-it-is-unnecessarily-complex/115821#115821) was the only possible way to increase TPS capacity without breaking UTXO view for old nodes (further increase via soft-forking would only be possible through [extension blocks](https://blog.purse.io/ready-for-liftoff-a5533f4de0b6?gi=df2a2bf608b), which **would** break UTXO view for old nodes).

The other de facto social rule is that node running should be as widely accessible as possible. Thanks to increases in bandwidth and propagation tech such as [compact block relay](https://bitcoinops.org/en/topics/compact-block-relay/) block size limit could be higher without much risk of pool centralization (8 MB should be manageable today and wouldn't 8x the risk of centralization). However, it would mean that bandwidth-limited nodes couldn't keep up or would take too long for initial block download.
The Bitcoin network kept the limit low for this reason as well, and current stewardship of the project maintains that decision.

Bitcoin code is free open-source (MIT license) and anyone can fork the code and change the limit **for himself**.
However, he can't force others to accept the changed rules by running such software.
What happens if he manages to convince only a subset of the network to run patched node software?
A permanent hard fork, and then the forked network has to convince the social / markets layer to give it value, and use the value to bid for mining hashes.

We have seen this play out with [main forks of Bitcoin](https://bitcoin.stackexchange.com/questions/120027/what-are-the-last-common-blocks-of-bitcoin-and-its-hard-forks-bitcoin-cash-bit/120029#120029).

See also [here](https://bitcoin.stackexchange.com/a/120001/137501) for a brief history of the blocksize limit, and [here](https://hackernoon.com/the-great-bitcoin-scaling-debate-a-timeline-6108081dbada) and [here](https://www.reddit.com/r/btc/comments/bvj08f/an_incomplete_history_of_the_bitcoin_cashs_origin/) for a timeline of events that led to the first permanent fork of Bitcoin.

Note that ["Nakamoto Consensus"](https://bitcoin.stackexchange.com/a/118315/137501) doesn't decide which blockchain wins the branding / ticker. It is market & social forces which map blockchains to recognized currencies.


---

### Answer by username_4 on 2023-10-23. Score: 0

Actually, the block size limit is no longer 1MB. That changed with the big **segWit soft fork**. Currently, block size is measured in virtual bytes, not bytes. The current block limit in virtual bytes is 4(v)MB. Looking at the "real" bytes, those 4v(MB) could go to around 3,8MB. However, the average is slightly less than 2MB.

Therefore, the block size has been increased from 1MB.

[Here](https://mempool.space/) you can see the size of each block together will other related information (purple-blue chain/blocks).

[Block #813485](https://mempool.space/block/0000000000000000000236b979d361184d97ecfdda0197c3c24336f298aaadfe) is interesting since it's size is 3.82MB.

> **Comments:**
> **username_5**: While this answer correctly challenges the framing and explains how the blocksize was increased, it could be improved by elaborating on why there is a limit in the first place.  

---

