<p>These three arguments are againt the block size increase ... Since the block size will increase then first argument is that trxns will easily inserted in the block i.e this thing will lower the trxn fees and then miners gonna lose their motive becoz trxn fees will be decreased, this may demotivate the miners (for example : suppose you are doing a job and you get 10$ for the job daily , what if that price drop to 5$ for the job daily and job is same....then you will be looking for other job or better option , that's the thing with miners) and miners will move to some better option. If no. of miners decreases then this will decrease the overall hashrate of bitcoin, so sad. Second argument is that it will divide the community becoz if we want to increase the block size in bitcoin blockchain then this increment in blocksize will cause a fork in the system which will make two parallel bitcoins so this will split the community. Third argument is that block size increase will cause centralization, since the network size will increase due to more trxns, the amount of processing power required to mine will increase as well. This will not help small mining pools and give mining powers to large scale mining pools and will increase centralization which is not acceptable in bitcoin community. This blocksize increase is still debatable in community.</p>

CC BY-SA 4.0
2018-09-15T13:02:24.533Z
2018-09-15T13:02:24.533Z
Rajesh Prajapati
<blockquote>
  <p><strong><em>Please note, this answer was written in Februar 2015. The debate has significantly evolved since then, but I haven't gotten around to updating this answer, yet.</em></strong></p>
</blockquote>

<p>I'm sorry, this kinda turned out less brief than it started. </p>

<p><strong><em>TL;DR: Very briefly, it is an issue of opposing ideologies:</em></strong><br>
Proponents wish to provide a common good to everyone and believe the increase in blocksize to be necessary to that end.<br>
Opponents feel that a) it is impossible to introduce a change of that magnitude to Bitcoin at this stage, b) bigger blocks will mess up mining dynamics, or c) the increase changes properties of Bitcoin that shouldn't be changed.</p>

<hr>

<h2>What happened before</h2>

<p>Originally, there was no blocksize limit. In fact, Satoshi Nakamoto was envisioning <a href="http://www.mail-archive.com/cryptography@metzdowd.com/msg09964.html" rel="noreferrer">"100 million transactions per day, [...] taking 100GB of bandwidth" even in 2008</a>. The blocksize limit was introduced later, when people where starting to play around with bitcoin, but before the value picked up significantly, when a worry came up that people might bloat the blockchain with cheap "spam transactions".¹<br>
The problem is that 1MiB of transactions provides such a small capacity that, we'd be limited to seven transactions per second at minimal transaction size, or extrapolating from current transaction sizes, around four transactions per second. The block limit has not been encountered yet, and is therefore not yet a serious restriction, however this is significantly less than competing global payment networks can handle.<br>
The thing is, that Bitcoin has become fairly valuable, and people want different things out of Bitcoin. The "apolitical money" is very political suddenly (as it always has been).  </p>

<hr>

<h2>Arguments against increasing</h2>

<p>There are quite a few different concerns here:  </p>

<p><strong>Bigger blocks will destroy the market for transaction fees</strong><br>
Increasing blocksize will make more room for transactions, which could reduce competition to be included in a block, in turn lowering transaction fees. In the long run, the block reward will dwindle, therefore less money would go towards mining, and the security of the Bitcoin network would wither with the lower income.</p>

<p><strong>Bandwidth requirements are too much for full nodes</strong><br>
At 20MB per block, full nodes would have to download 2.8GB transaction data per day. This will be not only challenging data storage, but might actually be beyond the bandwidth capacity/datacap of some full node maintainers. One must consider especially that full nodes also serve the requests of thin-clients, so upload capacity might be more important than download capacity. However, on internet contracts for home-users upload speed is often significantly lower than download speed.<br>
It has been suggested that a larger blocksize would quickly lead to a large increase of transaction numbers due to <a href="http://en.wikipedia.org/wiki/Induced_demand" rel="noreferrer">induced demand</a>.<br>
"Bigger blocks will lead to centralization."  </p>

<p><strong>Consensus may not be achievable</strong><br>
Once the first block larger than the 1MiB limit will be mined, a hardfork will occur between the network participants that refuse blocks greater than the limit, and network participants that accept it.<br>
Blocks mined on the old network remain compatible to the new network, but not the other way around. Some voices have announced that they would use the fork as an opportunity to double-spend all their Bitcoins, spending them to themselves on the 1MiB-chain, and selling them on the 20MiB-chain, to profit and drive the new chain in the ground. 
Some users suggest that this supporters of that proposal have sufficient Bitcoin holdings and support that they can essentially force failure of the blocksize increase, they presume that exchanges would land on different sides in the discussion, but all users would quickly flock to the "safe old chain", once the "civil war" starts.</p>

<p><strong>Bitcoin is destroying viability of altcoins</strong><br>
An increased Bitcoin blocksize would decrease demand for other blockchains, hurting investors of altcoins.</p>

<p><strong>Bitcoin is not meant for every person on the planet to pay for their every cup of coffee</strong><br>
Some people feel that Bitcoin should be an exclusive privilege for settling between companies and the super-rich. A bigger blocksize would dilute the exclusiveness. They argue that something that is useful, but universally available is worthless. Bitcoin instead is meant to "<a href="http://trilema.com/2015/lets-address-some-of-the-more-common-pseudo-arguments-raised-by-the-very-stupid-people-that-like-the-gavin-scamcoin-proposal/" rel="noreferrer">force the poor to yield to the rich, universally, as a matter of course</a>".</p>

<p><strong>People are feeling that something is being decided without them being consulted</strong></p>

<ul>
<li>"There is only one proposal, we have no choice."</li>
<li>"We cannot predict how quickly bandwidth will grow, the proposed increase it too much."</li>
<li>"There is no consensus, forking without community support is a dead-end."</li>
<li>"There will be huge problems if we do this."</li>
<li>"Why haven't the miners been asked?"</li>
</ul>

<p>I have trouble relating to these last statements, as the discussion about the blocksize limit has been going on for years.</p>

<hr>

<h2>Arguments for increasing</h2>

<p><strong>The transaction capacity is too low to support a global payment network</strong><br>
4.4 tps (transaction per second) are too few to support a global payment network.<br>
At current network capacity, a bigger demand for transactions would cause regular users to be priced out of the blockchain. One would have to wait forever to have a transaction included in a block, and Bitcoin would eventually only get used to settle between banks, mayor corporations, and the super-rich. The blockchain instead should be accessible to everyone, and therefore the blocksize must be increased. Often, this is followed by the <a href="http://en.wikipedia.org/wiki/Appeal_to_authority" rel="noreferrer"><em>argumentum ab auctoritate</em></a>, that the blocksize limit was always meant to be temporary, and the fork being necessary to achieve the vision Satoshi outlined in the <a href="http://bitcoin.org/bitcoin.pdf" rel="noreferrer">original whitepaper</a>.</p>

<p><strong>Greater blocksize will increase total transaction fees</strong><br>
Even in a bigger block, transactions are not a free resource, as they cost bandwidth, data storage, and cause slower block propagation. Already, miners are not always including all transactions. Therefore, a market for transaction fees would exist even with bigger blocks, and more transactions would cause a higher total of transaction fees.</p>

<p><strong>Effective blocksize will not increase over night</strong><br>
The blockchain of the past six years is smaller than 30GiB. It is wrong to assume that with the introduction of a larger limit, the blocks would suddenly fill up quickly, when they haven't done so before.</p>

<p><strong>Consensus will be achieved before the hardfork is initiated</strong><br>
Major payment providers, exchanges, and mining pools will side with the hardfork supporters, causing the opponents to find themselves to be such a small minority that they will be stuck on an irrelevant alternative chain.</p>

<p><strong>Technical issues will be fixed</strong><br>
Slower block propagation due to bigger blocks will be mitigated by Header-first synchronization and <a href="https://bitcoin.stackexchange.com/q/30648/5406">Inverted Bloom Lookup Tables</a>. Internet connections will speed up sufficiently in parallel to increasing traffic demands on the network. Datastorage issues will be solved by introduction of a pruned blockchain, where most "full nodes" only keep a limited number of the last blocks, and few full nodes maintain the complete blockchain.</p>

<hr>

<h2>Conclusion</h2>

<p>Personally, I think it is the natural progression of Bitcoin to increase the blocksize, as I see potential for Bitcoin to serve a broader audience. However, I do get some points of the contrarians, especially that it is hard to make predictions about how this will all play out.</p>

<hr>

<h2>Further reading is found here (and in a million other places):</h2>

<p><strong>About discussion:</strong>  </p>

<ul>
<li><a href="http://www.ofnumbers.com/2015/02/06/what-is-the-blockchain-hard-fork-missile-crisis/" rel="noreferrer">Tim Swanson: What is the blockchain hard fork “missile crisis?”</a> </li>
<li><a href="http://www.reddit.com/r/Bitcoin/comments/2uuyzd/poll_should_the_maximum_block_size_be_increased/" rel="noreferrer">Reddit: Should the maximum block size be increased soon</a></li>
<li><a href="http://www.quora.com/Who-will-win-the-Bitcoin-blocksize-war" rel="noreferrer">Quora: Who will win the Bitconi blocksize war?</a></li>
</ul>

<p><strong>Pro increase:</strong>  </p>

<ul>
<li><a href="https://blog.bitcoinfoundation.org/a-scalability-roadmap/" rel="noreferrer">Gavin Andresen: A Scalability Roadmap</a></li>
<li><a href="https://bitcointalk.org/index.php?topic=946236.0" rel="noreferrer">DeathAndTaxes: Permanently keeping the 1MB (anti-spam) restriction is a great idea,… if you are a bank.</a></li>
</ul>

<p><strong>Contra increase:</strong>²  </p>

<ul>
<li><a href="http://trilema.com/2015/lets-address-some-of-the-more-common-pseudo-arguments-raised-by-the-very-stupid-people-that-like-the-gavin-scamcoin-proposal/" rel="noreferrer">Mircea Popescu: Let's address some of the more common pseudo-arguments raised by the very stupid people that like the Gavin scamcoin proposal</a></li>
</ul>

<p>¹ Does anyone have links to the discussion on the introduction of the blocksize limit? I was looking for that.<br>
² I'm still looking for more representative contra-positions. Wading through a few threads of some forums gave me a skin rash, but hardly anything useful.</p>

CC BY-SA 3.0
2015-02-17T08:24:51.717Z
I'm currently busy with something else, so I kept this rather short. I'll be adding to my answer later today. If you have suggestions what I missed, feel free to (suggest an) edit or leave a comment.
Murch
CC BY-SA 3.0
2015-02-17T08:29:31.403Z
About "Big blocks propagate too slowly": Will it not be true that miners wont mine too big blocks if they risk orphaning it? Seems like this wouldnt be a problem in case of an increase...
user23381
CC BY-SA 3.0
2015-02-17T08:37:19.760Z
Yes, block size would be finding a balance due to that. However, 0.10 introduced "headers-first" block propagation, where block header of essentially fixed size will propagate much quicker. In addition with the upcoming (I think) inverted bloom filters transaction reconciliation a lot less data will have to be exchanged for propagation. (Just header first, and then only the transactions missing from the block will need to be acquired, everyone will be to assemble the block for themselves.) I'll add a bit more about that later to my answer.
Murch
CC BY-SA 3.0
2015-02-17T08:45:02.417Z
About "opponents sabotaging by double-spending": If block increase happens, then there will probably be a great consensus where pretty much all miners, merchants, wallets will upgrade to the hard fork, making any such threats mute. 

IBLT looks interesting. Have heard from others that its not exactly O(1) as claimed by gavin, which, if its the case, will still hold back miners from generating astronomically large blocks.
user23381
CC BY-SA 3.0
2015-02-17T10:50:55.140Z
Well, it depends on the size of the consensus. If there were to be a significant minority, it could create some headache. The header has a constant size, so why would it not be constant?
Murch
CC BY-SA 3.0
2015-02-17T11:02:30.630Z
It seems reasonable to assume that the set of transactions from each miner will be somewhat different, meaning some transactions may have to be sent and the more transactions a block can include, the larger the difference will be in the transactions sets across all miners.
user23381
CC BY-SA 3.0
2015-02-17T11:03:54.363Z
Ah, I see. Yes, the reconciliation of the transaction pools will not be constant of course, I was thinking just about the header propagation. However, a sufficiently connected node should have almost all transactions that are included in the block, unless there were some transactions that the successful miner didn't share in advance. However, he'd hamper his own propagation that way, so I am not sure why it would be useful to hold back information (unless there is a very juicy fee attached on a transaction that is only known to said miner).
Murch
CC BY-SA 3.0
2015-02-19T14:58:35.163Z
@murch "making all blocks being exchanged on basis of header first". Inverted bloom filters is more like "transactions first" as in even before the header exists and has been mined. Nitpick, but headers-first usually refers to when the node is catching up and downloading old blocks where it will now since 0.10 download the headers first.
Jannes
CC BY-SA 3.0
2015-02-19T16:48:47.060Z
@Jannes: Good catch, I hadn't thought of IBLT being at work before the block is found as well. But headers-first is also more or less a guarantee on block propagation speed, because people will be able to assemble the block on basis of their UTXO pool, with the header as guide. Or has that been implemented already?
Murch
CC BY-SA 3.0
2015-06-08T14:35:06.587Z
Also see [BlockSizeDebate Argument collection on GitHub](https://github.com/gappleto97/BlockSizeDebate/blob/master/README.md#argument3-pro-the-limit-was-intended-as-a-temporary-measure)
Murch
CC BY-SA 3.0
2017-06-06T07:56:28.710Z
"A bigger blocksize would dilute the exclusiveness." - This one seems a bit like weasel words. I don't think anyone's going around saying "bitcoin should only be for the super rich". Seems like a disingenuous way to frame that point.
B T
CC BY-SA 4.0
2021-01-04T12:41:46.600Z
I find https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007869.html to be one the best thread on the subject (sums up numerous previous discussions scattered on bitcointalk and IRC logs). Could probably be added to the contra section.
Antoine Poinsot
CC BY-SA 3.0
2015-02-17T08:21:18.447Z
2015-08-21T16:29:50.680Z
2017-04-13T12:47:33.743Z
Murch
<p>Can someone give a quick point by point list, what arguments the proponents and opponents of increased blocksize have for their case?</p>

<block><scalability><block-size-increase>
What are the arguments for and against the increase of the block size limit?
user23381
# What are the arguments for and against the increase of the block size limit?

(Asked by: username_0 on 2015-02-17)

Can someone give a quick point by point list, what arguments the proponents and opponents of increased blocksize have for their case?

**Tags:** block, scalability, block-size-increase


---

## 2 answers

### Answer by username_2 on 2015-02-17. Score: 21 | Accepted answer

> ***Please note, this answer was written in Februar 2015. The debate has significantly evolved since then, but I haven't gotten around to updating this answer, yet.***

I'm sorry, this kinda turned out less brief than it started.

***TL;DR: Very briefly, it is an issue of opposing ideologies:***  
Proponents wish to provide a common good to everyone and believe the increase in blocksize to be necessary to that end.  
Opponents feel that a) it is impossible to introduce a change of that magnitude to Bitcoin at this stage, b) bigger blocks will mess up mining dynamics, or c) the increase changes properties of Bitcoin that shouldn't be changed.

---

## What happened before

Originally, there was no blocksize limit. In fact, Satoshi Nakamoto was envisioning ["100 million transactions per day, [...] taking 100GB of bandwidth" even in 2008](http://www.mail-archive.com/cryptography@metzdowd.com/msg09964.html). The blocksize limit was introduced later, when people where starting to play around with bitcoin, but before the value picked up significantly, when a worry came up that people might bloat the blockchain with cheap "spam transactions".¹  
The problem is that 1MiB of transactions provides such a small capacity that, we'd be limited to seven transactions per second at minimal transaction size, or extrapolating from current transaction sizes, around four transactions per second. The block limit has not been encountered yet, and is therefore not yet a serious restriction, however this is significantly less than competing global payment networks can handle.  
The thing is, that Bitcoin has become fairly valuable, and people want different things out of Bitcoin. The "apolitical money" is very political suddenly (as it always has been).

---

## Arguments against increasing

There are quite a few different concerns here:

**Bigger blocks will destroy the market for transaction fees**  
Increasing blocksize will make more room for transactions, which could reduce competition to be included in a block, in turn lowering transaction fees. In the long run, the block reward will dwindle, therefore less money would go towards mining, and the security of the Bitcoin network would wither with the lower income.

**Bandwidth requirements are too much for full nodes**  
At 20MB per block, full nodes would have to download 2.8GB transaction data per day. This will be not only challenging data storage, but might actually be beyond the bandwidth capacity/datacap of some full node maintainers. One must consider especially that full nodes also serve the requests of thin-clients, so upload capacity might be more important than download capacity. However, on internet contracts for home-users upload speed is often significantly lower than download speed.  
It has been suggested that a larger blocksize would quickly lead to a large increase of transaction numbers due to [induced demand](http://en.wikipedia.org/wiki/Induced_demand).  
"Bigger blocks will lead to centralization."

**Consensus may not be achievable**  
Once the first block larger than the 1MiB limit will be mined, a hardfork will occur between the network participants that refuse blocks greater than the limit, and network participants that accept it.  
Blocks mined on the old network remain compatible to the new network, but not the other way around. Some voices have announced that they would use the fork as an opportunity to double-spend all their Bitcoins, spending them to themselves on the 1MiB-chain, and selling them on the 20MiB-chain, to profit and drive the new chain in the ground.
Some users suggest that this supporters of that proposal have sufficient Bitcoin holdings and support that they can essentially force failure of the blocksize increase, they presume that exchanges would land on different sides in the discussion, but all users would quickly flock to the "safe old chain", once the "civil war" starts.

**Bitcoin is destroying viability of altcoins**  
An increased Bitcoin blocksize would decrease demand for other blockchains, hurting investors of altcoins.

**Bitcoin is not meant for every person on the planet to pay for their every cup of coffee**  
Some people feel that Bitcoin should be an exclusive privilege for settling between companies and the super-rich. A bigger blocksize would dilute the exclusiveness. They argue that something that is useful, but universally available is worthless. Bitcoin instead is meant to "[force the poor to yield to the rich, universally, as a matter of course](http://trilema.com/2015/lets-address-some-of-the-more-common-pseudo-arguments-raised-by-the-very-stupid-people-that-like-the-gavin-scamcoin-proposal/)".

**People are feeling that something is being decided without them being consulted**

* "There is only one proposal, we have no choice."
* "We cannot predict how quickly bandwidth will grow, the proposed increase it too much."
* "There is no consensus, forking without community support is a dead-end."
* "There will be huge problems if we do this."
* "Why haven't the miners been asked?"

I have trouble relating to these last statements, as the discussion about the blocksize limit has been going on for years.

---

## Arguments for increasing

**The transaction capacity is too low to support a global payment network**  
4.4 tps (transaction per second) are too few to support a global payment network.  
At current network capacity, a bigger demand for transactions would cause regular users to be priced out of the blockchain. One would have to wait forever to have a transaction included in a block, and Bitcoin would eventually only get used to settle between banks, mayor corporations, and the super-rich. The blockchain instead should be accessible to everyone, and therefore the blocksize must be increased. Often, this is followed by the [*argumentum ab auctoritate*](http://en.wikipedia.org/wiki/Appeal_to_authority), that the blocksize limit was always meant to be temporary, and the fork being necessary to achieve the vision Satoshi outlined in the [original whitepaper](http://bitcoin.org/bitcoin.pdf).

**Greater blocksize will increase total transaction fees**  
Even in a bigger block, transactions are not a free resource, as they cost bandwidth, data storage, and cause slower block propagation. Already, miners are not always including all transactions. Therefore, a market for transaction fees would exist even with bigger blocks, and more transactions would cause a higher total of transaction fees.

**Effective blocksize will not increase over night**  
The blockchain of the past six years is smaller than 30GiB. It is wrong to assume that with the introduction of a larger limit, the blocks would suddenly fill up quickly, when they haven't done so before.

**Consensus will be achieved before the hardfork is initiated**  
Major payment providers, exchanges, and mining pools will side with the hardfork supporters, causing the opponents to find themselves to be such a small minority that they will be stuck on an irrelevant alternative chain.

**Technical issues will be fixed**  
Slower block propagation due to bigger blocks will be mitigated by Header-first synchronization and [Inverted Bloom Lookup Tables](https://bitcoin.stackexchange.com/q/30648/5406). Internet connections will speed up sufficiently in parallel to increasing traffic demands on the network. Datastorage issues will be solved by introduction of a pruned blockchain, where most "full nodes" only keep a limited number of the last blocks, and few full nodes maintain the complete blockchain.

---

## Conclusion

Personally, I think it is the natural progression of Bitcoin to increase the blocksize, as I see potential for Bitcoin to serve a broader audience. However, I do get some points of the contrarians, especially that it is hard to make predictions about how this will all play out.

---

## Further reading is found here (and in a million other places):

**About discussion:**

* [Tim Swanson: What is the blockchain hard fork “missile crisis?”](http://www.ofnumbers.com/2015/02/06/what-is-the-blockchain-hard-fork-missile-crisis/)
* [Reddit: Should the maximum block size be increased soon](http://www.reddit.com/r/Bitcoin/comments/2uuyzd/poll_should_the_maximum_block_size_be_increased/)
* [Quora: Who will win the Bitconi blocksize war?](http://www.quora.com/Who-will-win-the-Bitcoin-blocksize-war)

**Pro increase:**

* [Gavin Andresen: A Scalability Roadmap](https://blog.bitcoinfoundation.org/a-scalability-roadmap/)
* [DeathAndTaxes: Permanently keeping the 1MB (anti-spam) restriction is a great idea,… if you are a bank.](https://bitcointalk.org/index.php?topic=946236.0)

**Contra increase:**²

* [Mircea Popescu: Let's address some of the more common pseudo-arguments raised by the very stupid people that like the Gavin scamcoin proposal](http://trilema.com/2015/lets-address-some-of-the-more-common-pseudo-arguments-raised-by-the-very-stupid-people-that-like-the-gavin-scamcoin-proposal/)

¹ Does anyone have links to the discussion on the introduction of the blocksize limit? I was looking for that.  
² I'm still looking for more representative contra-positions. Wading through a few threads of some forums gave me a skin rash, but hardly anything useful.

> **Comments:**
> **username_2**: I'm currently busy with something else, so I kept this rather short. I'll be adding to my answer later today. If you have suggestions what I missed, feel free to (suggest an) edit or leave a comment.  
> **username_0**: About "Big blocks propagate too slowly": Will it not be true that miners wont mine too big blocks if they risk orphaning it? Seems like this wouldnt be a problem in case of an increase...  
> **username_2**: Yes, block size would be finding a balance due to that. However, 0.10 introduced "headers-first" block propagation, where block header of essentially fixed size will propagate much quicker. In addition with the upcoming (I think) inverted bloom filters transaction reconciliation a lot less data will have to be exchanged for propagation. (Just header first, and then only the transactions missing from the block will need to be acquired, everyone will be to assemble the block for themselves.) I'll add a bit more about that later to my answer.  
> **username_0**: About "opponents sabotaging by double-spending": If block increase happens, then there will probably be a great consensus where pretty much all miners, merchants, wallets will upgrade to the hard fork, making any such threats mute.   IBLT looks interesting. Have heard from others that its not exactly O(1) as claimed by gavin, which, if its the case, will still hold back miners from generating astronomically large blocks.  
> **username_2**: Well, it depends on the size of the consensus. If there were to be a significant minority, it could create some headache. The header has a constant size, so why would it not be constant?  
> **username_0**: It seems reasonable to assume that the set of transactions from each miner will be somewhat different, meaning some transactions may have to be sent and the more transactions a block can include, the larger the difference will be in the transactions sets across all miners.  
> **username_2**: Ah, I see. Yes, the reconciliation of the transaction pools will not be constant of course, I was thinking just about the header propagation. However, a sufficiently connected node should have almost all transactions that are included in the block, unless there were some transactions that the successful miner didn't share in advance. However, he'd hamper his own propagation that way, so I am not sure why it would be useful to hold back information (unless there is a very juicy fee attached on a transaction that is only known to said miner).  
> **username_3**: @username_2 "making all blocks being exchanged on basis of header first". Inverted bloom filters is more like "transactions first" as in even before the header exists and has been mined. Nitpick, but headers-first usually refers to when the node is catching up and downloading old blocks where it will now since 0.10 download the headers first.  
> **username_2**: @username_3: Good catch, I hadn't thought of IBLT being at work before the block is found as well. But headers-first is also more or less a guarantee on block propagation speed, because people will be able to assemble the block on basis of their UTXO pool, with the header as guide. Or has that been implemented already?  
> **username_2**: Also see [BlockSizeDebate Argument collection on GitHub](https://github.com/gappleto97/BlockSizeDebate/blob/master/README.md#argument3-pro-the-limit-was-intended-as-a-temporary-measure)  
> **username_4**: "A bigger blocksize would dilute the exclusiveness." - This one seems a bit like weasel words. I don't think anyone's going around saying "bitcoin should only be for the super rich". Seems like a disingenuous way to frame that point.  
> **username_5**: I find https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007869.html to be one the best thread on the subject (sums up numerous previous discussions scattered on bitcointalk and IRC logs). Could probably be added to the contra section.  

---

### Answer by username_1 on 2018-09-15. Score: 0

These three arguments are againt the block size increase ... Since the block size will increase then first argument is that trxns will easily inserted in the block i.e this thing will lower the trxn fees and then miners gonna lose their motive becoz trxn fees will be decreased, this may demotivate the miners (for example : suppose you are doing a job and you get 10$ for the job daily , what if that price drop to 5$ for the job daily and job is same....then you will be looking for other job or better option , that's the thing with miners) and miners will move to some better option. If no. of miners decreases then this will decrease the overall hashrate of bitcoin, so sad. Second argument is that it will divide the community becoz if we want to increase the block size in bitcoin blockchain then this increment in blocksize will cause a fork in the system which will make two parallel bitcoins so this will split the community. Third argument is that block size increase will cause centralization, since the network size will increase due to more trxns, the amount of processing power required to mine will increase as well. This will not help small mining pools and give mining powers to large scale mining pools and will increase centralization which is not acceptable in bitcoin community. This blocksize increase is still debatable in community.


---

