New Solution to Block Size Debate

[Hyena]

I was sleeping and then suddenly I woke up with this idea in my mind: remove the block size limit from every 6th block.

This guarantees that all TXs will be confirmed eventually (in an hour) while not impacting miners too much. Problem solved. Everyone can just STFU already and move on with their lives.

What is that? Do I hear someone complaining about the number 6 or saying that removing the size limit is too much? In that case, I wouldn't care if those constants were different. For example, every 18th block could have the size limit of 8 MiB, all the others would remain 1 MiB. Whatever configuration gets the most supporters.

Now get this idea out there, make it viral, comment, subscribe and question everything!

[lemipawa]

How would that be different from having a large block size limit or none at all? It would just guarantee that a transaction will be confirmed after 6 blocks, whereas no limit confirms after 1 block. There is also still the problem of hundereds of spam and microtransactions bloating the blockchain.

[pereira4]

So doing this would mean that transactions go from 10 minutes to 1 hour of confirmation? Then people would complain about confirmation time being way too slow. You can't please everyone... no matter what you propose, you'll get a group of haters.

[DooMAD]

That's certainly the kind of out-of-the-box thinking that can lead to breakthroughs, but it's difficult to tell on first impression if this would actually work or not.  Firstly, is there any chance miners might attempt to game the system by deliberately targeting or avoiding certain blocks if some will be different sizes?  And secondly, if the total size of all the transactions in the space of an hour added together was, for example, 12MB, would there effectively be any difference in the overall size of the blockchain by making some of the transactions wait a few extra blocks?

i.e.  Five blocks at 1MB and then one at 7MB  would be:  1MB + 1MB + 1MB + 1MB + 1MB + 7MB = 12MB
versus all the blocks being similar sizes over the same period:  2MB + 2MB + 2MB + 2MB + 2MB + 2MB = 12MB

Doesn't really seem to be much of a difference in practice.

Plus it still doesn't solve the issue where if the 1MB blocks are full, you have to guess what fee you need to pay to make it in.  Adding unneeded uncertainty to people's transactions isn't something I'm fond of, to put it mildly.  Bitcoin has a reputation for being fast and reliable and I don't feel we should risk jeopardising that in any way.

[achow101]

i.e.  Five blocks at 1MB and then one at 7MB  would be:  1MB + 1MB + 1MB + 1MB + 1MB + 7MB = 12MB
versus all the blocks being similar sizes over the same period:  2MB + 2MB + 2MB + 2MB + 2MB + 2MB = 12MB

Doesn't really seem to be much of a difference in practice.

Actually, that last block that is larger could become a problem. Miners with limited bandwidth in places such as China could have a high orphan rate after that last block because it would take longer for them to receive the block and begin mining on it. It could theoretically give the miner who mined that block an advantage. This is part of the reason why many Chinese miners were opposed to the 20 MB block size limit.

[goosoodude]

Well, this is out of the box thinking for sure, but the transactions closest to the sixth block would be the most likely on to get included to a block asap. I assume that this would create a troubling demand for transactions to be send when it's coming or a lot of transactions would gather waiting for about an hour in the case that the transactions/day number starts growing.

Something like that could certainly destabilize the fee market a lot. There might also be a lot of competition on who would mine the big block depending on if the fees are kept similar the the standard ones therefore increasing the reward since more transactions are included.

Surely sounds fun as an idea, I wonder how much work it would take for someone to create an alt-coin fork of BTC with such a feature.

[Hyena]

Thanks for the constructive feedback. I didn't think of the possibility that miners could start to avoid mining on those big blocks, for example. But then again, let's suppose that 90% of miners switch off their miners when it's time to mine that 6th block. I am absolutely sure that there will be at least one miner that is willing to confirm that block but it could take too much time for them. Perhaps mining the 6th block should be easier by design? Or, better yet, the mining of the 6th block would be done by proof of stake? Either way, there should be some mechanism for clearing the backlog of unconfirmed transactions and this could be it. We could even imagine if every 144th block was allowed to include all the unconfirmed txs to have the tx mempool cleared once a day.

goosoodude asked whether it would be a simple code change. I'm pretty sure it's would be very simple because all you have to do is to divide the current blockchain height by the number 6 and see if the remainder is zero to allow a bigger block to go through.

Anyway, I hope I got the ball rolling and that we get some more interesting ideas now.

[BTCjust]

it should have been 20M if chinese agreed.

[Lauda]

Thanks for the constructive feedback. I didn't think of the possibility that miners could start to avoid mining on those big blocks, for example. But then again, let's suppose that 90% of miners switch off their miners when it's time to mine that 6th block. I am absolutely sure that there will be at least one miner that is willing to confirm that block but it could take too much time for them. Perhaps mining the 6th block should be easier by design? Or, better yet, the mining of the 6th block would be done by proof of stake? Either way, there should be some mechanism for clearing the backlog of unconfirmed transactions and this could be it. We could even imagine if every 144th block was allowed to include all the unconfirmed txs to have the tx mempool cleared once a day.

goosoodude asked whether it would be a simple code change. I'm pretty sure it's would be very simple because all you have to do is to divide the current blockchain height by the number 6 and see if the remainder is zero to allow a bigger block to go through.

Anyway, I hope I got the ball rolling and that we get some more interesting ideas now.

Actually your solution wouldn't even work. We already have miners that occasionally mine a block with 0 transactions in it. What would be stopping them from implementing a counter in the mining software so that they do the same on this 'unlimited block'? Nothing really.
Besides, the solution isn't good because it can't handle enough transactions.

[Argwai96]

it should have been 20M if chinese agreed.

arent most of the chinese miners calling for a 8mb size block ? what if 70% agreeds for the 20mb

[brunoshady]

6 blocks will still be too long of a wait, couldnt they just alternate between the size limit for every block?

[DooMAD]

6 blocks will still be too long of a wait, couldnt they just alternate between the size limit for every block?

We could alternate, but again, it still doesn't make the transactions any smaller overall, so delaying them by a single block or six makes no discernible difference in the end.  The overall outcome is that the size of the blockchain still grows by the amount of transactions that are processed.  There's no solution involving delaying transactions that means we eventually process fewer of them, which means there's no real benefit in delaying them to begin with.

[MicroGuy]

it should have been 20M if chinese agreed.

arent most of the chinese miners calling for a 8mb size block ? what if 70% agreeds for the 20mb

I predict that the ultimate decision regarding blocksize will be made by Coinbase.

[Meuh6879]

i like the gradual increase of block ...

now : 1Mb
2017 : 4Mb
2019 : 8Mb
...etcs...

[jeannemadrigal2]

I like this out of the box thinking.  I am not sure that this is the best solution to the limit, if there is an increase why not just make it every block?  With this solution you are basically averaging up the block size, no?  So in stead why not just make a small increase, like make the limit 1.5 mb, or 2mb instead?  This is a really good discussion though, if we can have discussions like this without trolls and fud, then we will generate some nice ideas.  I have faith in the talent and intelligence of this community.

[Hyena]

Actually your solution wouldn't even work. We already have miners that occasionally mine a block with 0 transactions in it. What would be stopping them from implementing a counter in the mining software so that they do the same on this 'unlimited block'? Nothing really.
Besides, the solution isn't good because it can't handle enough transactions.

Actually you are overly pessimistic about it and not even thinking about the possibility that not all miners are selfish.

So let's say 9 out of 10 miners are selfish and decide not to include any TXs in the 6th fat block that has no size limit. For the sake of simplicity, let's assume that each of those miners has equally 10% of the hashing power.

Because we have 1 good miner, 10% of blocks will be found by them. That means 10% of the potentially fat blocks (6th blocks) are mined by a righteous miner. The righteous miner will include all unconfirmed transactions in the fat block so the backlog of transactions gets regularly cleared. The only penalty is that instead of once per hour the backlog is cleared once per 10 hours.

And that was pretty much the worst case scenario. In reality, we would have more like 70% of the miners righteous and 30% of them selfish. That means the backlog is cleared once in every ~8 blocks.

[Amph]

i like the gradual increase of block ...

now : 1Mb
2017 : 4Mb
2019 : 8Mb
...etcs...

following a better logic, which follow the supply table, should be 4 by 2016 8 by 2020 and so on, this if we assume that the adoption will be inversely proportional to the halving

[coins101]

Blocks sizes could be based on a dynamic model, say a moving average.

This allows for block size re-targeting.

If transactions keep going up, miners can still earn fees on the leading edge cases, but eventually block sizes will go up to accommodate the majority of transactions.

If the network sees a quiet period, blocks can scale back down, again letting miners earn some fees.

How the re-targeting model should work.....err, that's above my pay grade.

[jbrnt]

Blocks sizes could be based on a dynamic model, say a moving average.
This allows for block size re-targeting.

Satoshi himself said the same thing. He said the blocksize limit is best to be determined by a formula. I think it is easier to arrive at a consensus with a fixed limit. If we have a forumla, we will have more arguments and delays. The 8M limit suggested by the Chinese miners is a good start. It will buy us plenty of time to fix this for the long term.

[Klestin]

Blocks sizes could be based on a dynamic model, say a moving average.

This allows for block size re-targeting.

If transactions keep going up, miners can still earn fees on the leading edge cases, but eventually block sizes will go up to accommodate the majority of transactions.

If the network sees a quiet period, blocks can scale back down, again letting miners earn some fees.

How the re-targeting model should work.....err, that's above my pay grade.

Nobody is talking about increasing the block size - only the maximum block size.  The idea that "blocks can scale back down" in a "quiet period" is not new.  Block sizes automatically vary based on the number of outstanding transactions, and the miner's preferences.  If the limit were changed to 20MB today, it would absolutely, positively have ZERO immediate effect on the block sizes.  They'll continue to be only as large as they have to be.  The only difference that raising the limit will have is that when more than 1MB is needed for a particular block (will likely happen at least a few times this year), the transactions won't have to queue.  That's it.