Quote from: CounterEntropy on August 20, 2015, 03:12:07 PM

Quote from: skang on August 20, 2015, 12:25:18 AM

Quote from: upal on August 19, 2015, 04:49:27 PM

To solve the blocksize problem, I wrote a proposal - http://upalc.com/maxblocksize.php. This is now being discussed among devs. If any of you have any input to provide, feel free to share.

Upal, the suggestion you make is to make the blocksize dynamic. This is same as keeping a large block size. For eg, if the block size was 50 mb, it does not mean that each block is 50mb even if it is not filling up. 50 mb is the 'upper limit'.

The suggestion is not at all same as keeping a fixed large block size. This is a demand driven approach, which might take down the max cap as well. For a fixed 50 MB max cap, one miner can clean the mempool while others will be forced to mine empty blocks and thereby losing economically. For this proposal, this wont happen as block size max cap will come down in next difficulty.

Yes this is not the same when we reach that large limit but for cases smaller than that it is the same. Anyways, I corrected myself in the thought process down the post where I write "This is same as having no blocksize limit" by which I meant "lets have no limits and lets simply keep the blocksize whatever the current demand is."

Quote from: CounterEntropy on August 20, 2015, 03:12:07 PM

Quote from: skang on August 20, 2015, 12:25:18 AM

So all the blocks, after calculation & decision as suggested by you, would be equal to the size of transactions in queue, a.k.a mempool.

I dont understand, why you are saying this ? He has suggested the max cap to be dynamic, not block size. A miner can always mine empty blocks if he wishes so.

Yes, the max cap. Of course we are talking about the max cap in all of this discussion because miners can mine empty blocks anyways. Stop nitpicking!

Quote from: CounterEntropy on August 20, 2015, 03:12:07 PM

Quote from: skang on August 20, 2015, 12:25:18 AM

I think you are concentrating on the wrong part of the problem. People are not saying that blocks sometimes are not full. Everybody agrees that that in future the blocks would get full as the transaction rises. So as per your algorithm it will simply keep rising to meet the demand. This is same as having no blocksize limit.

Nopes. It seems you did not get the problem. Almost everyone agrees that blocksize need to be increased if blocks are full. The contradiction is in the process of scaling. Both core devs Jeff Garzik & Pieter Wuille, who are opposed to XT, have suggested BIPs (100 & 103) to increase block size max cap. Gmaxwell, Peter Todd and Luke Dash Jr have questioned many times in Reddit that how fast the blocks will be full. But, if they are full, no one opposes block size max cap increase. As per XT's algorithm, block size will keep rising in a periodic manner without accounting for the real demand. In this proposed algorithm, block size may increase as well as decrease. You are assuming transactions will only rise, which may or may not happen in reality. We need an algo that is adaptive to the reality, not assumption. It is no way similar to having no block size max cap.

"But, if they are full, no one opposes block size max cap increase." Nope. Read my OP for the reason why big blocks are a problem.

Quote from: CounterEntropy on August 20, 2015, 03:12:07 PM

Quote from: skang on August 20, 2015, 12:25:18 AM

Anyways, dynamic blocksize has been proposed and discussed many times and there are many variations of dynamic block-size limits here : http://bitcoin-development.narkive.com/cr8x2evb/bitcoin-development-various-block-size-proposals

Yes, dynamic block size max cap has been proposed before and I think, the proposal we are discussing now, has also listed many of those other solutions. But, none of them has accounted for the previous block size to increase and decrease max cap. This is an unique proposal and I hope it gets its due merit.

Many of them have accounted for the previous block size to increase and decrease max cap. The list I mentioned are the advanced changes, after the discussions have happened on this proposal.
I hope it gets its due merit too, but googling 'dynamic bitcoin blocksize' will tell you why it already has.