Bitcoin Forum

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 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...

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.

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).

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'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.

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.

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.

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.

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

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.

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.

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).

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.

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.

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. :)

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...

Yes, there are complex dependencies between miners, users, developers, merchants and I would also add node operators now. On top of that every person can belong to any combination of these 5 groups. Bitcoin is not going to succeed if a solution only works for a few of the groups, but not for others.

i'm just saying that if a compromise with all the hard fork/soft fork drama is not reached, then we know who is going to win, and bitcoin will remain a niche market

but it will not die as many think..

I was working under the system that they would not try to cheat the system.

Correct. If you lose either one of those then you lose Bitcoin. Nodes are quite important IMO, without the majority of them Bitcoin would lose its decentralization.

You can close this thread if you want to (look at the lower left corner of the thread).

I'll close the thread if you think it has run its course, but some new points seem to have crept in, and I hope it can still be constructive. Minimum block sizes is obviously a losing concept. Variable block sizes may be a valid alternative though. I'd also like to explore the PoS concept to peg value to side chains. I tried to start a thread about this, but didn't get any replies.

Actually variable block sizes is a bit of a red herring atm. Should I leave the thread open for a couple of hours to see if it still gets some interest, and then close it?

Well technically it was mostly called a dynamic block size limit. There were a lot of discussions about it in the past (mostly before XT and Classic drama). It seems like it was mostly forgotten but the proposals are still there (BIP's). You could either leave the thread open and edit your original post (if you want to discuss this) as members tend to ignore other posts (spammers do) which could derail the thread, or close it and open a new one about dynamic block sizes. You could always do some research but finding the right information might be tricky as it is buried under thousands of posts. Here are a few links for you:
BIP 106 - Dynamically Controlled Bitcoin Block Size Max Cap (https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki)
BIP 107 - Dynamic limit on the block size (https://github.com/bitcoin/bips/blob/master/bip-0107.mediawiki)
ELI5: Why doesn't someone program a dynamic block size for bitcoin? (https://www.reddit.com/r/Bitcoin/comments/3xdt2v/eli5_why_doesnt_someone_program_a_dynamic_block/)