Published on: 2015-09-09T13:10:43+00:00
The proposal suggests setting a "triggering level" for an increase in block size, indicating an increase in transaction volume that would fill up blocks. The appropriate triggering level is difficult to determine and consists of three parameters: evaluation period, capacity, and threshold. A period of 4032 blocks was selected for the evaluation period, a capacity level of 60% was chosen, and a threshold of 2000 blocks or ~50% was selected. If 2000+ nodes have a block size >= 60%, this indicates a real increase in transaction volume, and a block size increase of 10% is triggered.The author of this proposal suggests a trigger level for an increase in the block size. This level is set at 60% full to reflect an underlying trend towards filling blocks. Determining the appropriate triggering level is difficult and consists of three parameters: evaluation period, capacity, and threshold. The author selected a period of 4032 blocks, a capacity level of 60%, and a threshold of 2000 blocks or ~50%. If 2000+ nodes have a block size >= 60%, this is an indication that real transaction volume has increased and we're approaching a time where block could be filled to capacity without an increase. The block size increase, 10%, is triggered.In a discussion around the proposal of a dynamic limit on the block size, Gavin Andresen and another individual's favorable stance was revealed. However, Corey Fields, a Bitcoin Core developer, stated that he was unclear on what problem(s) this proposal was trying to solve. Fields suggested implementing simple rules such as specifying a maximum block size based on the average block size over the last N blocks or implementing an absolute maximum block size that increases by a maximum of 3.45 times every year. He questioned the need for centralized decision-making in determining how full blocks "should" be and justifying why these specific growth limits were chosen.The author expresses their support for a technical approach to block scaling rather than a political one. They criticize BIP100 for giving too much power to miners and consider BIP101's attempt to predict technological progression in the future as flawed. The author suggests that a dynamic limit on block size would be favorable, but worries about the potential need for a hard fork in the future and the difficulty of upgrading embedded firmware. They propose a plan where the maximum block size decreases by 10% every 4032 blocks if a minimum of 2500 blocks has a size greater than the previous maximum block size. The author also identifies the risks of a selfish mining attack and suggests that unbounded growth is undesirable.The conversation is about the possibility of a selfish mining attack on the Bitcoin network. It is mentioned that such an attack would be possible but unlikely due to economic disincentives. However, one concern raised is the lack of a mechanism to lower the block size, which could make the network vulnerable to this type of attack. The proposal for a dynamic limit on the block size is discussed, with questions about what variables should be adjusted to make it more acceptable to Core developers like Gavin and Adam Back. In response, Adam Back clarifies that he was referring to the risk that excess block size could be used to amplify selfish mining instead of collecting transaction fees.According to Adam Back, a selfish mining attack could potentially be used to amplify the impact of excess block-size in a system that has no means to reduce it. In this scenario, an attacker with enough hashrate could take advantage of the free transaction space created by excess block-size and use it to perform a selfish mining attack. However, such an attack would have to be sustained for at least 2000 blocks over a period of 4 weeks in order to achieve a mere 10% increase in the block size.The maximum block size is one that can be filled at zero-cost by miners, which allows for some selfish-mining related attacks. A selfish mining attack would have to be performed for at least 2000 blocks over a period of 4 weeks to achieve a meager 10% increase in the block size. If the goal is to increase block size to push out smaller miners, they will have to perform this attack over the course of years and destroy any economic incentives they have for mining in the first place. However, if the goal is to simply drive up fees to gain acceptance into the block, nothing stops a miner from doing so. Developers cannot predict the appropriate block size for the next 20 years just as it is impossible to predict the appropriate hash rate to secure the network. Both need to adjust dynamically to the scale/adoption of the network. Miners already control block size through soft caps. The only reason for reducing the max block limit other than technology availability is if it is believed that this will produce the fee market, which is more of an economic discussion than a technology scaling discussion.
Updated on: 2023-08-01T16:03:07.802781+00:00