Miners typically include the highest-paying transactions first, naturally. If there is a consistent backlog of transactions waiting to be included, low-fee or no-fee transactions may have to wait a long time, perhaps indefinitely. This creates fee pressure - at least in a scenario where Bitcoin clients are intelligent about fees and are able to add fees to pending transactions so that block space is effectively auctioned out. This is not necessarily today's scenario, but Bitcoin is working towards it.

But if blocks are not consistently full and there's no significant backlog, there is room for cheap transactions. This has been the case up to now. If the block size limit were to be increased, the assumption goes, there would again be room for cheap transactions - until they fill up again.

In practice, we don't know if miners would actually include cheap transactions if it makes their blocks significantly bigger. Their incentives seem to be against it, since bigger blocks have higher orphan rates.

> In practice, we don't know if miners would actually include cheap transactions if it makes their blocks significantly bigger. Their incentives seem to be against it, since bigger blocks have higher orphan rates.

This is incorrect in fact. The Google search term you'll need is selfish mining. It's a well studied phenomenon that for sufficiently large miner they stand to benefit from having larger blocks.

I think your last paragraph is right.

Right now there's a default transaction inclusion policy in Bitcoin Core that only includes a small number of low to zero fee transactions. Under current conditions zero fee transactions have to wait a while to be confirmed.

There's no proposal to change the default allowance for below standard fee transactions if the block size increases, so assuming cheap means zero or very low fee the increase in size will come from standard fee transactions which means increasing capacity won't drive down existing fees.

If the pending transactions fit in a block, there's not much incentive to not include them -- it doesn't cost much, so miners can include them all in order to maximise fee revenue. But when there are more pending transactions than fit in a block, miners will sort by fee and include the biggest fees and reject the lowest fees. By growing blocksize, you avoid the situation where there are more pending transactions than can fit in a block.

Miners will likely omit transactions that offer a fee that is lower than their cost of mining (at least eventually). This sacrifices some small amount of revenue on the current block, but should lead to higher revenue over the long term (assuming their cost levels make bitcoin an attractive transaction system).

> Miners will likely omit transactions that offer a fee that is lower than their cost of mining (at least eventually).

The marginal cost of each transaction in the block is approximately zero.

The only effort is from propagation speed, however thanks to the relay network that effect is almost nothing.

http://bitcoinrelaynetwork.org/

The cost of mining a single transaction is approximately the electricity cost to mine a block divided by the number of transactions in the block.

Say it is $0.15. A miner can make extra revenue at ~0 cost by filling a block with $0.10 offered fee transactions, but if there are many of them, they may choose not to, from the belief that enough of them will turn into $0.16 offered fees in the future (the cost is clearly ~0 in the short term, it's harder to say what it costs them in the long term to propagate the impression that low fee offers will still eventually clear).

> they may choose not to, from the belief that enough of them will turn into $0.16 offered fees in the future

Another miner will pickup those transactions and mine them.

Blocks are either full and there are fees or blocks are not full and fees are approximately zero.

Unfortunately the block size cannot be limited by individual miners.

This is only true while there is a glorious block reward subsidizing everything.

(Which I realize is for a long time in terms of there being a block reward, but if bitcoin falls by 50%, so does the reward...)

The marginal cost of mining is actually relatively small for large scale operations compared to the fixed costs.

(In general you cannot get 10+ MW of power without agreeing to pay for installed capacity and energy separately)

However, that would only become a problem after centralization, correct? Otherwise, it would require a concerted effort by most/all miners to take the same approach, rather than competing for staying power etc.

I think you have the reasoning backwards. The argument the small-blockers are making isn't that we want to keep block size small to attempt to increase fees. Instead they're saying we want to keep block size small to avoid centralization pressures, and if this means higher fees then so be it.

> Ultimately miners decide which transactions to include in a block or reject so if miners feel they need to get a certain fee per transaction that is their prerogative regardless of the block size.

Again the issue is a bit more complex. A miner can of course enforce any fee policy they want, but that policy will only have a significant effect if it is enforced by a large pool. And suppose a large pool decided that they will accept all transactions, regardless of fees, up to the max block size, then all other miners have to deal with the consequences of this decision, because they have to validate the blocks produced by the large pool. This is what Rusty is calling large miners attacking smaller miners.

Also not addressed, why not decrease block dissemination time to 5 min, will that not do the same as doubling the block size?

For the same reasons that they made it 10 min rather than less to begin with [1]

[1] http://bitcoin.stackexchange.com/questions/1863/why-was-the-...

Right, bigger blocks take longer to propagate so you get more forking with a block that's too big compared to the time interval.

This might change if Gavin's IBLT proposal [0] gets implemented. Basic idea is that the miners have most of the transactions already (otherwise they couldn't mine), so you don't have to transmit them again in the block itself. You just need a small fixed-size data structure that lets miners reconstruct the full block from the transactions they have already.

Another idea is GHOST [1], which shortens the block time by letting all the forks take part in the consensus process, and get rewarded even if they don't end up in the final linear chain. It was proposed as a Bitcoin modification but just got its first production launch with Ethereum.

[0] https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2

[1] https://eprint.iacr.org/2013/881.pdf

> This might change if Gavin's IBLT proposal [0] gets implemented.

Such a thing already exists, blocksize has little to no effect on propagation time to other miners.

http://bitcoinrelaynetwork.org/

Edit: not that this is not IBLT but another actually implemented setup

Because lowering the interblock time has a more detrimental effects, and raising it has more beneficial effects. To achieve maximum scalability you actually want the longest possible interblock time you can stand. 10 minutes is actually alright in that regard. I would have gone with 15 minutes myself.