Yet another possible solution for the blocksize debate.

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: Jet Cash on February 02, 2016, 08:07:10 AM

Variable block sizes may be a valid alternative though. 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
BIP 107 - Dynamic limit on the block size
ELI5: Why doesn't someone program a dynamic block size for bitcoin?

Jet Cash

legendary

Activity: 2800

Merit: 2472

https://JetCash.com

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?

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: shorena on February 02, 2016, 07:09:39 AM

Quote from: Lauda on February 02, 2016, 06:18:56 AM

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.

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

Quote from: shorena on February 02, 2016, 07:20:53 AM

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.

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.

Quote from: Jet Cash on February 02, 2016, 07:14:03 AM

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

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

Amph

legendary

Activity: 3248

Merit: 1070

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

shorena

copper member

Activity: 1498

Merit: 1528

No I dont escrow anymore.

Quote from: Amph on February 02, 2016, 07:14:49 AM

Quote from: Jet Cash on February 02, 2016, 06:31:22 AM

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

Amph

legendary

Activity: 3248

Merit: 1070

Quote from: Jet Cash on February 02, 2016, 06:31:22 AM

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

Jet Cash

legendary

Activity: 2800

Merit: 2472

https://JetCash.com

Quote from: shorena on February 02, 2016, 07:09:39 AM

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.

shorena

copper member

Activity: 1498

Merit: 1528

No I dont escrow anymore.

Quote from: Lauda on February 02, 2016, 06:18:56 AM

Quote from: Jet Cash on February 02, 2016, 06:12:26 AM

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.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Jet Cash on February 02, 2016, 06:58:56 AM

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.

Jet Cash

legendary

Activity: 2800

Merit: 2472

https://JetCash.com

Quote from: Wobberdk on February 02, 2016, 06:40:49 AM

Quote from: Lauda on February 02, 2016, 05:44:45 AM

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.

Wobberdk

full member

Activity: 126

Merit: 100

Quote from: Lauda on February 02, 2016, 05:44:45 AM

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.

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: Jet Cash on February 02, 2016, 06:31:22 AM

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

Jet Cash

legendary

Activity: 2800

Merit: 2472

https://JetCash.com

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

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: pawel7777 on February 02, 2016, 06:23:58 AM

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.

pawel7777

legendary

Activity: 2436

Merit: 1561

Quote from: Lauda on February 02, 2016, 06:06:39 AM

Quote from: pawel7777 on February 02, 2016, 05:48:07 AM

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

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: Jet Cash on February 02, 2016, 06:12:26 AM

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.

Quote from: Jet Cash on February 02, 2016, 06:12:26 AM

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.

Jet Cash

legendary

Activity: 2800

Merit: 2472

https://JetCash.com

Quote from: Lauda on February 02, 2016, 06:06:39 AM

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

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: pawel7777 on February 02, 2016, 05:48:07 AM

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.

Quote from: Jet Cash on February 02, 2016, 05:59:02 AM

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?

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

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.

Jet Cash

legendary

Activity: 2800

Merit: 2472

https://JetCash.com

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.

Topic: Yet another possible solution for the blocksize debate. (Read 957 times)