The Bitcoin Blocksize: A Summary
rusty.ozlabs.org
The Bitcoin Blocksize: A Summary
1–10 of 96 posts
Re: The Bitcoin Blocksize: A Summary
#2Something 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.
Re: The Bitcoin Blocksize: A Summary
#3Something 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.
Also not addressed, why not decrease block dissemination time to 5 min, will that not do the same as doubling the block size?
Re: The Bitcoin Blocksize: A Summary
#4Something 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.
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.
Re: The Bitcoin Blocksize: A Summary
#5Something 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.
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.
Re: The Bitcoin Blocksize: A Summary
#6Something 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.
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-...
Re: The Bitcoin Blocksize: A Summary
#7An important thing to consider is that, while there probably is an ideal block size for the current set of conditions (risk of centralization, average Bitcoin network latency, rate of transactions), there's no a priori reason that it should be 1 MB. It may well be less than 1 MB, or it may well be more. 1 MB is arbitrary. My best guess is that the optimal current block size is somewhat larger than 1 MB.
Re: The Bitcoin Blocksize: A Summary
#8Something 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.
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…
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).
Re: The Bitcoin Blocksize: A Summary
#9The problem with bitcoin is the idea that it even requires a mining pool or transaction fee.
Bitcoin will die the moment someone figures out how to build a decentralized crypto-currency that doesn't need a stupid idea like "mining" to be functional and secure.
Re: The Bitcoin Blocksize: A Summary
#10Something 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.
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 aucti…
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.