4 ms·

Something I haven't seen discussed that I'm curious about is why a larger max block size necessarily means lower transaction fees. Ultimately miners decide whi

by pmorici 11y ago

Something I haven't seen discussed that I'm curious about is why a larger max block size necessarily means lower transaction fees. 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.

kbenzle 11y ago
Also not addressed, why not decrease block dissemination time to 5 min, will that not do the same as doubling the block size?
- kardos 11y ago
  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-target-block-time-chosen-to-be-10-minutes http://bitcoin.stackexchange.com/questions/1863/why-was-the-...
  - DennisP 11y ago
    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 https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 [1] https://eprint.iacr.org/2013/881.pdf https://eprint.iacr.org/2013/881.pdf
    - pstrateman 11y ago
      > 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/ http://bitcoinrelaynetwork.org/ Edit: not that this is not IBLT but another actually implemented setup
- maaku 11y ago
  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.
haakon 11y ago
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.
- prolixus 11y ago
  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.
- maaku 11y ago
  > 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.
kardos 11y ago
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.
- maxerickson 11y ago
  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).
  - thekingofspain 11y ago
    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.
  - pstrateman 11y ago
    > 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/ http://bitcoinrelaynetwork.org/
    - maxerickson 11y ago
      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).
wsxcde 11y ago
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.

by pmorici 11y ago

kbenzle 11y ago

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

kardos 11y ago
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-target-block-time-chosen-to-be-10-minutes http://bitcoin.stackexchange.com/questions/1863/why-was-the-...
- DennisP 11y ago
  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 https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 [1] https://eprint.iacr.org/2013/881.pdf https://eprint.iacr.org/2013/881.pdf
  - pstrateman 11y ago
    > 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/ http://bitcoinrelaynetwork.org/ Edit: not that this is not IBLT but another actually implemented setup
maaku 11y ago
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.

haakon 11y ago

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.

prolixus 11y ago
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.
maaku 11y ago
> 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.

kardos 11y ago

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.

maxerickson 11y ago
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).
- thekingofspain 11y ago
  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.
- pstrateman 11y ago
  > 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/ http://bitcoinrelaynetwork.org/
  - maxerickson 11y ago
    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).

wsxcde 11y ago

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.