|
Title: Why not scale up the block size automatically after every N blocks mined? Post by: fenican on August 20, 2015, 04:54:36 PM 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 %? Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: doc12 on August 20, 2015, 05:13:22 PM Lol just posted the same idea like you :)
https://bitcointalk.org/index.php?topic=1157838.msg12194963#msg12194963 (https://bitcointalk.org/index.php?topic=1157838.msg12194963#msg12194963) Are we missing somethink ? why not make the size dynamic ? Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: pedrog on August 20, 2015, 05: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. Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: doc12 on August 20, 2015, 05: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. 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. Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: bassclef on August 20, 2015, 05: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. 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? Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: PolarPoint on August 20, 2015, 05: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.
Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: pedrog on August 20, 2015, 05: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. 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%... Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: doc12 on August 20, 2015, 05: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. 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. Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: pedrog on August 21, 2015, 09: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. 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... Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: LiQio on August 21, 2015, 10: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/ Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: Laila10 on August 21, 2015, 10:10:35 AM I feel disgusted with every drama made caused by XT ;D
Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: ZephramC on August 21, 2015, 12:07:05 PM 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).
Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: PolarPoint on August 21, 2015, 08:16:46 PM I feel disgusted with every drama made caused by XT ;D 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. Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: MoorChael on August 21, 2015, 08:52:09 PM I feel disgusted with every drama made caused by XT ;D 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. Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: jonald_fyookball on August 21, 2015, 08:58:05 PM I feel disgusted with every drama made caused by fixed that for you. Title: Re: Why not scale up the block size automatically after every N blocks mined? Post by: Klestin on August 21, 2015, 08:59:12 PM 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. |