Gavin Andresen: Rising Transaction Fees Could Price Poor Out of Bitcoin

[Foxpup]

Increase the max block size isn't going to do much if most miners aren't already using that max.  A significant portion of the blocks created today are 250KB or less in size.

Increasing the max block size especially isn't going to do much if most miners don't upgrade. Bitcoin 0.9 no longer produces such blocks (I think).

[1715267892]

1715267892

[1715267892]

1715267892

[1715267892]

1715267892

[1715267892]

1715267892

[1715267892]

1715267892

[DeathAndTaxes]

Increase the max block size isn't going to do much if most miners aren't already using that max.  A significant portion of the blocks created today are 250KB or less in size.

Increasing the max block size especially isn't going to do much if most miners don't upgrade. Bitcoin 0.9 no longer produces such blocks (I think).

I think you are misunderstanding, the cap has been 1MB for a long time now.   Most blocks are less than 250KB.  So raising the cap isn't going to make those blocks larger.  For one reason or another miners are producing smaller blocks.  Now if the block size was consistently close to 1MB and paying tx were having to wait multiple blocks then yes raising the cap is going to help but we aren't there yet.  If miner X is choosing to produce a block that is 87KB why would raising the cap from 1MB to 20MB change anything?

[Foxpup]

Most blocks are less than 250KB.  So raising the cap isn't going to make those blocks larger.  For one reason or another miners are producing smaller blocks.

Specifically, the reason is that Bitcoin versions prior to 0.9 do not produce blocks larger than 250kB unless there are transactions paying more than double the minimum required fee (which is almost never the case). Some pools (notably Eligius) removed this restriction, but most kept the default policy. Miners using Bitcoin 0.9 should only be producing small blocks if there are absolutely no more fee-paying transactions in the memory pool (unless they've modified their clients to restore the old behaviour).

[DeathAndTaxes]

Most blocks are less than 250KB.  So raising the cap isn't going to make those blocks larger.  For one reason or another miners are producing smaller blocks.

Specifically, the reason is that Bitcoin versions prior to 0.9 do not produce blocks larger than 250kB unless there are transactions paying more than double the minimum required fee (which is almost never the case). Some pools (notably Eligius) removed this restriction, but most kept the default policy. Miners using Bitcoin 0.9 should only be producing small blocks if there are absolutely no more fee-paying transactions in the memory pool (unless they've modified their clients to restore the old behaviour).

or set a single config parameter "blockmaxsize"  to 250KB.  No modification of the client is required.

The double fee requirement was for blocks over 500KB.
v0.8.6 set the default max block size to 350KB.
v0.9.0 set the default max block size to 700KB.

It is very likely major miners are setting the "blockmaxsize" and other mining parameters.

[Foxpup]

The double fee requirement was for blocks over 500KB.

Source? In every version I've seen until 0.9, it's always been 250kB. It was never 500kB as far as I know.

[tspacepilot]

Is there a possibility that a minimum block size could be implemented?  Would this help the issue?

[btcxyzzz]

Block chain transaction volume is no higher than it was 2 years ago. This is a non-problem unless Bitcoin use increases, which doesn't seem to be happening.

I'm surprised it even have tendency to fall. Why is that? Answer is simple, the sea of altcoins...

[nkocevar]

Fortunately, there is always Dogecoin to transact micro payments.

But you have to think about the tediousness of constantly switching back and forth from DOGE to BTC whenever you want to make a micro transaction. Although you could always just keep a small amount of doge. 

[devphp]

Fortunately, there is always Dogecoin to transact micro payments.

But you have to think about the tediousness of constantly switching back and forth from DOGE to BTC whenever you want to make a micro transaction. Although you could always just keep a small amount of doge. 

Yeah, just keep small amount of Dogecoin, like you keep small change in your physical wallet to buy a coffee for example.

[DeathAndTaxes]

Block chain transaction volume is no higher than it was 2 years ago. This is a non-problem unless Bitcoin use increases, which doesn't seem to be happening.

I'm surprised it even have tendency to fall. Why is that? Answer is simple, the sea of altcoins...

It hasn't fallen.  On a day to day basis there is a lot of volatility in the number of transactions.  Volume also tends to spike when the price makes major moves (highest volume days tend to be around ATHs and ATLs).  If you look at transaction volume on a moving average it has steadily increased.

[Peter R]

Block chain transaction volume is no higher than it was 2 years ago. This is a non-problem unless Bitcoin use increases, which doesn't seem to be happening.

I'm surprised it even have tendency to fall. Why is that? Answer is simple, the sea of altcoins...

It's not falling.  It's rising.  

The number of transactions per block is what affects how full the blocks are, not the total output volume.  The number of transactions per day has been steadily increasing:



The above chart is distorted by the "on-chain" gambling bubble of mid 2012 to mid 2013.  Most gambling now takes place off-chain (in fact, just-dice.com processes over 100 bets per second).  If we attempt to remove the "on-chain gambling" bubble to get a better sense of organic growth in the number of transactions per day in the bitcoin economy, we finds its been growing exponentially at approximately 320% per year.  

[Peter R]

Most blocks are less than 250KB.  So raising the cap isn't going to make those blocks larger.  For one reason or another miners are producing smaller blocks.

Specifically, the reason is that Bitcoin versions prior to 0.9 do not produce blocks larger than 250kB unless there are transactions paying more than double the minimum required fee (which is almost never the case). Some pools (notably Eligius) removed this restriction, but most kept the default policy. Miners using Bitcoin 0.9 should only be producing small blocks if there are absolutely no more fee-paying transactions in the memory pool (unless they've modified their clients to restore the old behaviour).

This would increase the aggregate cost of orphans.  Orphan costs are reduced when blocksize variance is minimized.  To keep blocksize variance low, a pool of unconfirmed transactions larger than the average blocksize is required.  

If miners were completely cooperative, to minimize the tragedy-of-the-commons effect they would agree on informal best practices for filling up blocks (not enforced).  This will probably never happen, but the fact that there is almost always a pool of unconfirmed transactions while most blocks aren't even close to full shows that miners are cooperating to a certain extent for the benefit of the network.  

[tspacepilot]

Is there a possibility that a minimum block size could be implemented?  Would this help the issue?

Death and Taxes, if I understand the discussion correctly, implementing  minimum block size seems like it would be the solution.   The issue would be that if you hit a period in which there were very few transactions waiting to be confirmed then perhaps they would have to wait till more transactions arrived in order to meet the minimum.  However, that shouldn't ever be a problem given the graphs and predictions you're showing us about the volume of transactions.  Also, perhaps this transaction minimum would be implemented as a percentage of transactions waiting to be confirmed.   This would obviously mess with difficulty, but that can be adjusted, right?  Can we have a little discussion about the possibility of a min_block_size parameter?