Some people feel that it will be important in the future to introduce some scarcity into the mining market by having a block size limit. The idea is that this will force transactors to bid up transaction fees in order to get their transaction into the block. This may be necessary as the freshly minted BTC subsidy becomes less and less significant over time.

If this idea is going to work, it's safe to assume that the size limit will be hit every 10 minutes. otherwise, it's not effectively forcing transactors to bid up the fees. But if that is the case, won't a backlog of transactions start accruing such that the average wait time grows infinitely? For example, if the limit is (more or less) 2000 transactions per block but the protocol puts a limit at 1500 transactions per block, it seems like there's no way around building up a stock of unconfirmed transactions that grows unbounded at a rate of 500 transactions every 10 minutes.

So it seems to me that a limit on block size can serve the original purpose of preventing some kinds of one-off spam attacks, but it can't be a long term solution to the tragedy of the commons problem. Please confirm or correct my understanding?

1 Answer 1


Your analysis seems to assume unconfirmed transactions will sit in the queue forever. That's not the case. When someone realizes that their transaction will never confirm, they can create a double spend with a higher fee. When the double spend is confirmed, the earlier transaction becomes invalid (barring a chain reorganization).

I think it's an open question about how much we should be restricting block sizes. The current hard limit of 1 MB seems to be a comfortable place for miners with current technology and for full node operators with current disk space and bandwidth limitations. As fast block propagation technology improves, block chain pruning technology gets deployed, and higher-bandwidth connections become more common, we will likely see a push towards higher block size limits.

We will also hopefully see technology and techniques developed that allow for alternative ways to pay for block chain security, so we aren't so dependent on transaction fees.

  • My primary concern is that the size of the transaction queue will grow unboundedly. Is that not the case? I agree with you that it is not the case that all transactions will wait infinitely. But I do suspect that the average wait time will grow without bound.
    – Nick
    Jan 18, 2015 at 19:13
  • 2
    That is very unlikely to be the case. People will not make transactions that won't confirm, and if they do accidentally create such transactions, they can create double-spends that will confirm. Imagine we were talking about something besides Bitcoin: if a city reduces the number of available subway trains, will the line of riders increase unboundedly? No---because people will adapt to the situation. Jan 18, 2015 at 19:28
  • Could you expand on "adapt to the situation." How will bitcoin protocol users adapt to the situation of not being able to transact? It sounds like you're implying that a blocksize limit will result in a reduction of the volume of transactions and an increased transaction price a la a profit maximizing monopolist. Is that right? I might be undesirable that, say, the least wealthy 10% of the population will be excluded from the network by design.
    – Nick
    Jan 18, 2015 at 21:43
  • You seem to be asking about the consequences of inelastic demand in the face of reduced supply. I'm saying that scenario is unlikely to result in unbounded growth in pending transactions because users will change their behavior to prevent their transactions from getting stuck in the queue. Beyond that, your questions are more about what type of uses we should prioritize Bitcoin for---and that's an opinion-oriented question for which I can't provide an objective answer. Jan 18, 2015 at 22:02
  • 1
    If you don't think it's worth paying the higher fee, you won't create a transaction. Jan 18, 2015 at 23:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.