This would make sense if we were discussing a block size increase. However, nobody is proposing to increase the block size. What's being discussed is an over-time raise of the size LIMIT for blocks. Blocks are already dynamically sized to fit only the transactions that are actually in them.
If the system limited maximum block size based directly on prior block size, there would in effect be no limit - it could be made to increase as rapidly as you like by filling prior blocks.
Topic: Why not scale up the block size automatically after every N blocks mined? (Read 630 times)
August 21, 2015, 03:59:12 PM
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
August 21, 2015, 03:58:05 PM
I feel disgusted with every drama made caused by XT the core devs who work for blockstream who refuse all reasonable block size increase proposals.
fixed that for you.
August 21, 2015, 03:52:09 PM
I feel disgusted with every drama made caused by XT
I hate the drama too but we have to face it. How and when the blocksize limit will scale is also a problem for Core.
Perhaps the problem will solve.
August 21, 2015, 03:16:46 PM
I feel disgusted with every drama made caused by XT
I hate the drama too but we have to face it. How and when the blocksize limit will scale is also a problem for Core.
August 21, 2015, 07:07:05 AM
There is also possibility to change block size dynamically (for example according to last 2016 blocks) allowing both increase of max block size (if there is a big majority of nearly-full blocks) and decrease in max block size (if there is a big majority of under-filled blocks).
August 21, 2015, 05:10:35 AM
I feel disgusted with every drama made caused by XT
August 21, 2015, 05:04:45 AM
Quote
The misinterpretation is that once XT is activated, at times during the increase periods it can be stopped by another supermajority vote. That is, you get a chance to vote again every 2 years. That is incorrect, as the code specification clearly states (below link). Once started, we are on a linearly increasing block limit doubling schedule that cannot be stopped until 8Gb is reached. Furthermore, the increase is not a step function that occurs every 2 years, the limit increases with each block linearly.
source: http://wallstreettechnologist.com/2015/08/19/bitcoin-xt-vs-core-blocksize-limit-the-schism-that-divides-us-all/
August 21, 2015, 04:55:13 AM
Because Core devs don't want to do that...
That's why all the drama, and if you want that use Bitcoin XT client.
That's why all the drama, and if you want that use Bitcoin XT client.
No Bitcoin XT does not have a dynamic blocksize. It just doubles every 2 years.
What OP propose is to adjust the blocksize to the current transaction load every x blocks.
IMO it would be nice to scale the blocksize with every block calculated with a moving average over last x blocks.
why not just modify the core so that every 100 or so blocks mined the block size increases by a small %?
Instead of "100 blocks or so" it's 2 years and instead of "small %" it's 100%...
Yeah and this is not the same. First is like a step function and not dynamic.
With a MA the size is always in the range of the transaction load. So there is a incentive to pay a higher fee to get a fast transaction.
With the MA the blockchain space is always kept scarce for a given timeframe.
It's what OP wrote...
August 20, 2015, 12:32:58 PM
Because Core devs don't want to do that...
That's why all the drama, and if you want that use Bitcoin XT client.
That's why all the drama, and if you want that use Bitcoin XT client.
No Bitcoin XT does not have a dynamic blocksize. It just doubles every 2 years.
What OP propose is to adjust the blocksize to the current transaction load every x blocks.
IMO it would be nice to scale the blocksize with every block calculated with a moving average over last x blocks.
why not just modify the core so that every 100 or so blocks mined the block size increases by a small %?
Instead of "100 blocks or so" it's 2 years and instead of "small %" it's 100%...
Yeah and this is not the same. First is like a step function and not dynamic.
With a MA the size is always in the range of the transaction load. So there is a incentive to pay a higher fee to get a fast transaction.
With the MA the blockchain space is always kept scarce for a given timeframe.
August 20, 2015, 12:29:20 PM
Because Core devs don't want to do that...
That's why all the drama, and if you want that use Bitcoin XT client.
That's why all the drama, and if you want that use Bitcoin XT client.
No Bitcoin XT does not have a dynamic blocksize. It just doubles every 2 years.
What OP propose is to adjust the blocksize to the current transaction load every x blocks.
IMO it would be nice to scale the blocksize with every block calculated with a moving average over last x blocks.
why not just modify the core so that every 100 or so blocks mined the block size increases by a small %?
Instead of "100 blocks or so" it's 2 years and instead of "small %" it's 100%...
August 20, 2015, 12:28:25 PM
A variable blocksize limit determined by the average of n blocks was proposed a long time ago. Don't know how many devs supported it. Since it's not brought up again, I think it was rejected.
August 20, 2015, 12:26:37 PM
Because Core devs don't want to do that...
That's why all the drama, and if you want that use Bitcoin XT client.
That's why all the drama, and if you want that use Bitcoin XT client.
No Bitcoin XT does not have a dynamic blocksize. It just doubles every 2 years.
What OP propose is to adjust the blocksize to the current transaction load every x blocks.
IMO it would be nice to scale the blocksize with every block calculated with a moving average over last x blocks.
Seems like a logical approach with the moving average (simple or exponential) dictating the average block size. Any reasons why this might not work?
August 20, 2015, 12:22:46 PM
Because Core devs don't want to do that...
That's why all the drama, and if you want that use Bitcoin XT client.
That's why all the drama, and if you want that use Bitcoin XT client.
No Bitcoin XT does not have a dynamic blocksize. It just doubles every 2 years.
What OP propose is to adjust the blocksize to the current transaction load every x blocks.
IMO it would be nice to scale the blocksize with every block calculated with a moving average over last x blocks.
August 20, 2015, 12:18:24 PM
Because Core devs don't want to do that...
That's why all the drama, and if you want that use Bitcoin XT client.
That's why all the drama, and if you want that use Bitcoin XT client.
August 20, 2015, 12:13:22 PM
Lol just posted the same idea like you 
https://bitcointalksearch.org/topic/m.12194963
Are we missing somethink ? why not make the size dynamic ?
https://bitcointalksearch.org/topic/m.12194963
Are we missing somethink ? why not make the size dynamic ?
August 20, 2015, 11:54:36 AM
Seems like a better approach than the current 1MB v/ 8MB debate.
Obviously 1 MB is too small and 8 MB is way too large. Rather than have constant code changes, threats of forks, etc... why not just modify the core so that every 100 or so blocks mined the block size increases by a small %?
Obviously 1 MB is too small and 8 MB is way too large. Rather than have constant code changes, threats of forks, etc... why not just modify the core so that every 100 or so blocks mined the block size increases by a small %?
Jump to: