|
fenican (OP)
|
 |
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 %?
|
|
|
|
|
|
|
|
|
|
"You Asked For Change, We Gave You Coins" -- casascius
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
pedrog
Legendary
 Offline
Activity: 2786
Merit: 1031
|
|
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.
|
|
|
|
doc12
Legendary
Offline
Activity: 1284
Merit: 1042
|
|
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. |
|
|
|
|
|
bassclef
|
|
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? |
|
|
|
|
|
PolarPoint
|
|
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.
|
|
|
|
|
pedrog
Legendary
Offline
Activity: 2786
Merit: 1031
|
|
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%... |
|
|
|
doc12
Legendary
Offline
Activity: 1284
Merit: 1042
|
|
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. |
|
|
|
|
pedrog
Legendary
Offline
Activity: 2786
Merit: 1031
|
|
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... |
|
|
|
LiQio
Legendary
Offline
Activity: 1181
Merit: 1002
|
|
August 21, 2015, 10:04:45 AM |
|
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/ |
|
|
|
|
|
Laila10
|
|
August 21, 2015, 10:10:35 AM |
|
I feel disgusted with every drama made caused by XT  |
|
|
|
|
|
ZephramC
|
|
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).
|
|
|
|
|
|
PolarPoint
|
|
August 21, 2015, 08: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. |
|
|
|
|
MoorChael
Newbie
Offline
Activity: 56
Merit: 0
|
|
August 21, 2015, 08: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. |
|
|
|
|
jonald_fyookball
Legendary
Offline
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
|
|
August 21, 2015, 08: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. |
|
|
|
|
Klestin
|
|
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.
|
|
|
|
|
|
