<p>Increasing demand for on-chain transactions and static block size means transaction fees will be higher. They can't grow indefinitely since there is a finite amount of money anyone in the world is willing to pay for a transaction, but they might very well become quite large in the future.</p>
<p>This might not be a problem because as transaction fees rise, people are incentivised to adopt Layer 2 solutions like the Lightning Network. If this does become a problem, some people will simply stop using bitcoin and that will also reduce transaction fees.</p>

CC BY-SA 4.0
2021-06-24T12:59:02.127Z
"If this does become a problem, some people will simply stop using bitcoin and that will also reduce transaction fees." - I get the logic of that. I guess what I am struggling with is the notion that people eventually being forced off bitcoin contradicts the universality and accessibility of bitcoin, but wasn't it the whole point to achieve that?
csstudent1418
CC BY-SA 4.0
2021-06-24T12:54:29.103Z
2021-06-24T16:24:40.137Z
2021-06-24T16:24:40.137Z
Vojtěch Strnad
<p>The Bitcoin network processes around 10-30 transactions per second with segwit.</p>
<p>With an increasing amount of TX requests as more and more users join the network, how will the network eventually accommodate a surplus of transaction requests?</p>
<p>In other words, once we get to an average of 31 transaction requests per second, won't the mempool grow indefinitely with some users perpetually waiting for their TX to be processed?</p>
<p>Note: I am not asking what happens when the mempool is filled. For the sake of my question, I'd like to even assume an infinitely large mempool. I'm merely referring to the inevitable scenario that</p>
<p><code>rate of transaction processing &lt; rate of incoming transaction requests </code></p>
<p>To clarify further: Won't the network inevitably crash due to</p>
<ul>
<li>indefinitely growing / overflowing mempool or</li>
<li>indefinitely growing fees</li>
</ul>

CC BY-SA 4.0
2021-06-24T12:13:36.570Z
No, but I edit my questino and to clarify not.
csstudent1418
CC BY-SA 4.0
2021-06-24T12:28:20.770Z
Since nodes have finite resources, their mempools cannot grow indefinitely. As an aside, competition among transaction makers during mempool congestion naturally increases feerate which reduces demand.
RedGrittyBrick
CC BY-SA 4.0
2021-06-24T12:37:16.230Z
@RedGrittyBrick Let me rephrase: I get that mempool practically can't grow indefinitely. But then what happens at the above described point in time? Mempools get more and more filled causing an increasing amount of transaction requests to be dropped. Increasing feerates reduce demand: For ordinary goods, of course that is true. But for transactions? How can transaction demand be reduced like that, people HAVE to do their TXs no matter the fee right? So then the fees will grow indefinitely with increasing demand? My point is, one way or another the network is bound to crash?
csstudent1418
CC BY-SA 4.0
2021-06-24T12:41:58.983Z
@csstudent1418: People *don't* have to do their Bitcoin on-chain TX's no matter what.  I wouldn't buy a 0.1 BTC car if the TX fee were 1 BTC, neither would you. People switch to LN, other methods or to other currencies.
RedGrittyBrick
CC BY-SA 4.0
2021-06-24T12:54:54.390Z
@RedGrittyBrick But isn't this an extremely limiting factor to Bitcoin, in terms of not too many people being able to use it simultaneously? I just find it fascinating that you could essentially be "pushed" off the network like that, just when you needed to make an important transaction let's say.
csstudent1418
CC BY-SA 4.0
2021-06-24T13:45:29.870Z
@csstudent1418: Yes it is a limiting factor. One of many limiting factors. That's partly why there has been the development of LN, Liquid, etc. Also, if a transaction is important, it's presumably important enough that you would pay a reasonable extra amount to push it through. Otherwise, in the context of a digital cash system, is your transaction really important to you if you are not willing to pay a *reasonable* extra amount to expedite it?
RedGrittyBrick
<scalability><blockspace-market>
With constant TX throughput and increased TX requests will the mempool and/or fees grow indefinitely?
csstudent1418
# With constant TX throughput and increased TX requests will the mempool and/or fees grow indefinitely?

(Asked by: username_0 on 2021-06-24)

The Bitcoin network processes around 10-30 transactions per second with segwit.

With an increasing amount of TX requests as more and more users join the network, how will the network eventually accommodate a surplus of transaction requests?

In other words, once we get to an average of 31 transaction requests per second, won't the mempool grow indefinitely with some users perpetually waiting for their TX to be processed?

Note: I am not asking what happens when the mempool is filled. For the sake of my question, I'd like to even assume an infinitely large mempool. I'm merely referring to the inevitable scenario that

`rate of transaction processing < rate of incoming transaction requests`

To clarify further: Won't the network inevitably crash due to

* indefinitely growing / overflowing mempool or
* indefinitely growing fees

**Tags:** scalability, blockspace-market

> **Comments:**
> **username_0**: No, but I edit my questino and to clarify not.  
> **username_1**: Since nodes have finite resources, their mempools cannot grow indefinitely. As an aside, competition among transaction makers during mempool congestion naturally increases feerate which reduces demand.  
> **username_0**: @username_1 Let me rephrase: I get that mempool practically can't grow indefinitely. But then what happens at the above described point in time? Mempools get more and more filled causing an increasing amount of transaction requests to be dropped. Increasing feerates reduce demand: For ordinary goods, of course that is true. But for transactions? How can transaction demand be reduced like that, people HAVE to do their TXs no matter the fee right? So then the fees will grow indefinitely with increasing demand? My point is, one way or another the network is bound to crash?  
> **username_1**: @username_0: People *don't* have to do their Bitcoin on-chain TX's no matter what.  I wouldn't buy a 0.1 BTC car if the TX fee were 1 BTC, neither would you. People switch to LN, other methods or to other currencies.  
> **username_0**: @username_1 But isn't this an extremely limiting factor to Bitcoin, in terms of not too many people being able to use it simultaneously? I just find it fascinating that you could essentially be "pushed" off the network like that, just when you needed to make an important transaction let's say.  
> **username_1**: @username_0: Yes it is a limiting factor. One of many limiting factors. That's partly why there has been the development of LN, Liquid, etc. Also, if a transaction is important, it's presumably important enough that you would pay a reasonable extra amount to push it through. Otherwise, in the context of a digital cash system, is your transaction really important to you if you are not willing to pay a *reasonable* extra amount to expedite it?  

---

## 1 answers

### Answer by username_2 on 2021-06-24. Score: 3 | Accepted answer

Increasing demand for on-chain transactions and static block size means transaction fees will be higher. They can't grow indefinitely since there is a finite amount of money anyone in the world is willing to pay for a transaction, but they might very well become quite large in the future.

This might not be a problem because as transaction fees rise, people are incentivised to adopt Layer 2 solutions like the Lightning Network. If this does become a problem, some people will simply stop using bitcoin and that will also reduce transaction fees.

> **Comments:**
> **username_0**: "If this does become a problem, some people will simply stop using bitcoin and that will also reduce transaction fees." - I get the logic of that. I guess what I am struggling with is the notion that people eventually being forced off bitcoin contradicts the universality and accessibility of bitcoin, but wasn't it the whole point to achieve that?  

---

