Yet another possible solution for the blocksize debate.

[Jet Cash]

I've found the whole discussion and debate really interesting, and there are a lot of things that I've learnt over the last few days. One of these is that many blocks are submitted before they are full. So instead of increasing the capacity of blocks, why not ensure that the capacity is utilised more efficiently. A minimum size for new blocks could reduce the current block problem, and leave the blockchain existing in its current form. If the restriction was only imposed on new blocks, then all existing blocks would remain valid.

[7788bitcoin]

I am not an expert in the topic, but what you have just typed does not make any sense to me. Obviously you (or maybe me) do not understand the problems and issues of blocksize...

[Lauda]

You want to include another parameter called the minimum block size? What is this supposed to do actually, prevent mining of empty blocks? What happens when the mempool becomes empty and there are not enough transactions to include into the block to reach the minimum? I don't see how this complication would help.

[CIYAM]

Having empty blocks (i.e. blocks that only reward the miner with the block reward) has been an issue in the past but as the reward dwindles and fees become more important there should be a natural incentive to include as many txs as possible (this is a key part of the original design).

[pawel7777]

I've found the whole discussion and debate really interesting, and there are a lot of things that I've learnt over the last few days. One of these is that many blocks are submitted before they are full. So instead of increasing the capacity of blocks, why not ensure that the capacity is utilised more efficiently. A minimum size for new blocks could reduce the current block problem, and leave the blockchain existing in its current form. If the restriction was only imposed on new blocks, then all existing blocks would remain valid.

I'm not sure if that's do-able. Even if, what would happen if there's a period of low activity (few txs made), not enough to fill the block to min size.
But most of all, at what size would you set the minimum? If you set this at 0.5mb them miners could just limit themselves to 0.55mb etc. So for that to work, you'd have to set the minimum pretty close to max block size and that's not feasible.

[Jet Cash]

I'm still trying to understand the complexities of the blockchain, so apologies if I have misunderstood the situation.

I guess I was thinking of the situation based on old concepts. For example if a milk supplier collects milk from farmers by picking up churns, and he finds that he can't get all of the churns on his lorry. Then, if most of the churns are half empty, then making farmers use bigger churns isn't going to help him. Obviously there are a variety of solution - variable churn sizes, less frequent collections, pooling of farm output etc. But a simple knee jerk doubling of the churn size will only help a small portion of the problem.

I guess I'm saying where blocks are used inefficiently, then an improvement in efficiency is the way to go for a sustainable future.

[CIYAM]

Eventually the block reward will dwindle to zero and then the only BTC that miners will make are the fees.

The next halving is expected in July this year (block reward down to 12.5 BTC) so I think naturally we'll be seeing "more efficient" usage of blocks even then.

[Lauda]

I'm not sure if that's do-able. Even if, what would happen if there's a period of low activity (few txs made), not enough to fill the block to min size.
But most of all, at what size would you set the minimum? If you set this at 0.5mb them miners could just limit themselves to 0.55mb etc. So for that to work, you'd have to set the minimum pretty close to max block size and that's not feasible.

I think you misunderstood the problem. You don't have to put the minimum close to the maximum block size. Currently some miners tend to occasionally mine empty blocks. However if you put up a minimum limit 0.5 MB they could not mine blocks smaller than this and thus there would be quite an improvement as a lot of transactions would be included. Obviously there are other problems with this.

I guess I'm saying where blocks are used inefficiently, then an improvement in efficiency is the way to go for a sustainable future.

Yeah your solution wouldn't work even if possibly implemented. The question still remains what happens when there are not enough transactions to be included in the block; the miner can't mine it?

[Jet Cash]

Yeah your solution wouldn't work even if possibly implemented. The question still remains what happens when there are not enough transactions to be included in the block; the miner can't mine it?

Well the obviously solution would be to make him wait, but I can't see miners accepting that.

So if there aren't enough transactions to fill a block, why do we need larger blocks. I guess that sometimes there are too many blocks. What happened to the debate on variable sized blocks?

OK - another wild thought. How about the miner registering an incomplete block with confirmed transactions in it, and then adding more transactions to it later while he looks for a new block.

[Lauda]

Well the obviously solution would be to make him wait, but I can't see miners accepting that.

That would not make sense because the ~10 minute interval would be broken.

So if there aren't enough transactions to fill a block, why do we need larger blocks. I guess that sometimes there are too many blocks. What happened to the debate on variable sized blocks?

Technically there are, but they include a low fee or no feel at all and they don't get included. Sometimes at "peak times" there are more transactions than usually and a few blocks become full. Also you have to think for the future, Bitcoin can't take much more growth as it is. I have no idea what happened to the proposals related to a dynamic block size. The short term plan for Core is Segwit.

[pawel7777]

I'm not sure if that's do-able. Even if, what would happen if there's a period of low activity (few txs made), not enough to fill the block to min size.
But most of all, at what size would you set the minimum? If you set this at 0.5mb them miners could just limit themselves to 0.55mb etc. So for that to work, you'd have to set the minimum pretty close to max block size and that's not feasible.

I think you misunderstood the problem. You don't have to put the minimum close to the maximum block size. Currently some miners tend to occasionally mine empty blocks. However if you put up a minimum limit 0.5 MB they could not mine blocks smaller than this and thus there would be quite an improvement as a lot of transactions would be included. Obviously there are other problems with this.

Well, OP clearly stated that he's looking to maximise utilisation of block size rather than just to prevent empty blocks. So I assumed he was referring more to mining pools capping block size at 0.75mb instead of 1mb.

[Lauda]

Well, OP clearly stated that he's looking to maximise utilisation of block size rather than just to prevent empty blocks. So I assumed he was referring more to mining pools capping block size at 0.75mb instead of 1mb.

That doesn't matter though. Even if the minimum is set at 0.1 MB there is going to be improvement as there will be no empty blocks (even though there aren't many these days). However this can be problematic on many levels and doesn't really do much. The miners include what they want.

[Jet Cash]

So really the whole blocksize debate is just to help the miners and not the users.

[Lauda]

So really the whole blocksize debate is just to help the miners and not the users.

Technically we need to scale for the future. Bitcoin's current capacity isn't nearly enough to be used at a global level. However, the current debate which includes a political fork is about taking over development not about helping the ecosystem. Segwit will increase the transaction capacity and fix other things. Essentially Bitcoin needs second layer solutions to be able to scale to Visa levels and beyond (look into the Lightning Network if you're interested).

[Wobberdk]

You want to include another parameter called the minimum block size? What is this supposed to do actually, prevent mining of empty blocks? What happens when the mempool becomes empty and there are not enough transactions to include into the block to reach the minimum? I don't see how this complication would help.

This sums up the flaws in this ideia. I'm not trying to spoil the debate though, I think we should analyse every possible idea and make sure we're covering every possibility.

[Jet Cash]

You want to include another parameter called the minimum block size? What is this supposed to do actually, prevent mining of empty blocks? What happens when the mempool becomes empty and there are not enough transactions to include into the block to reach the minimum? I don't see how this complication would help.

This sums up the flaws in this ideia. I'm not trying to spoil the debate though, I think we should analyse every possible idea and make sure we're covering every possibility.

Apologies for the idea, it was really for my education. I think variable block sizes would be better than min/max restrictions. They will allow Bitcoin to expand without constant changes. I've no idea if that is practical, or how it could be implemented.

As I posted somewhere else, I think the future of Bitcoin lies in adding proof of stake to proof or work, that could reduce the influence of miners. Also the creation of altcoins in side chains, with their value underpinned by PoS on the main Bitcoin blockchain. This could turn Bitcoin into a reserve currency as its value increases. SegWit seems a good step towards this goal.

[CIYAM]

As I posted somewhere else, I think the future of Bitcoin lies in adding proof of stake to proof or work, that could reduce the influence of miners.

The problem with "Proof Of Stake" is what is called the "Nothing At Stake" (or NAS) problem (you might want to do some research into that).

So far no real solution to this problem has been found so any blockchain secured by POS would be less secure than the current POW implementation.

The idea of having POS side-chains does make sense and likely will be occurring.

[shorena]

Well the obviously solution would be to make him wait, but I can't see miners accepting that.

That would not make sense because the ~10 minute interval would be broken.
-snip-

No, miners would just fill the blocks with TX they created. The "efficiency" can be simulated hence the average interval would not be broken, miners would create pseudo filled blocks instead of actually filled because its impossible to distinguish between a "legit" TX and one just created to fill the block to the minimum requirement.

[Jet Cash]

No, miners would just fill the blocks with TX they created. The "efficiency" can be simulated hence the average interval would not be broken, miners would create pseudo filled blocks instead of actually filled because its impossible to distinguish between a "legit" TX and one just created to fill the block to the minimum requirement.

OK - that would be counter-productive, so I'd better forget that idea.

[Amph]

So really the whole blocksize debate is just to help the miners and not the users.

well they are the backbone, without miners there is no bitcoin, that is a fact, but merchants are important too because without them there is no adoption, but there is still bitcoin, after all there were no merchants at the beginning and bitcoin was alive, but there were miners

so you can draw your own conclusions...