Published on: 2015-08-19T03:45:47+00:00
A recent release by XT author(s) has not shown any sign of moving towards an "increasing consensus" version. However, the BIP authors are working together to create something meaningful and useful. Visualizations or graphs of miner votes on BIP 100 and BIP 101 are expected. Tier Nolan suggests making available a version of XT with only block size changes to address mining pools' concerns about its experimental nature. Additionally, there is discussion about combining BIP 100 and BIP 101 to increase consensus.In an email conversation, Tier Nolan suggested that miners vote to decide the soft limit for block size. However, one member argued against it, stating that it may lead to an anti-miner hardfork instead of a softfork. The discussion also referenced BIP99 and potential scenarios for reducing the supply.A suggestion was made to create a fourth test network with large blocks from the genesis onwards instead of replacing most of Testnet with a specialized test chain. Multiple test networks using the same code were also suggested.In a discussion on the Bitcoin-dev mailing list, Ross Nicoll suggested using a minimum height as a solution for activating hardforks. However, BIP99 recommended a minimum height plus 95% mining upgrade confirmation for uncontroversial hardforks. The activation discussion for general hardforks was inconclusive.Tier Nolan proposed making a version of Bitcoin XT with only blocksize changes available to address mining pools' concerns. The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip changes, and the consensus measuring code could be removed. Satoshi Nakamoto's original proposal for a block height comparison could be used, and the state storing code could be eliminated by using the standard "counting" upgrade system.There is discussion about combining BIP 100 and BIP 101 to increase consensus. The proposed combined version includes a miner vote threshold, a notice period or earliest start time, a block size default target set to 1 MB, a soft limit set to 1MB, and a hard limit set to 8MB with doubling every two years. Miners could leave the 1MB limit initially, but the vote is to get the option to increase the block size. Legacy clients would remain until >80% of miners vote to raise the limit and a miner produces a >1MB block.The dismissal of a formal process in Bitcoin is criticized for not properly evaluating proposed changes. Some developers believe their knowledge makes them superior to outside experts. However, this attitude can be detrimental to Bitcoin's progress. It is suggested that a well-defined and well-documented evaluation process should be introduced to ensure the safety of proposed changes.In an email exchange, Peter Todd and Gavin Andresen discuss the impact of larger blocks on miners with poor connectivity. The suggestion to rent a server on the other side of the bottleneck is countered by concerns about insecure infrastructure. The discussion also highlights the centralizing effect of mining control and the need for proposals to counter it.Gavin Andresen promised to write a BIP after implementing the increase-the-maximum-block-size code. The discussion mentions updating contact information and upcoming events.In an email conversation, Gavin Andresen discusses the analogy of a suspension bridge with limited traffic capacity and tolls increasing as demand rises. The proposed change is to expand the bridge, but careful analysis is needed. Civil engineering teaches us not to give in to political pressure until consequences are well understood.The discussion on the Bitcoin-dev mailing list focuses on the centralizing effect of miner connectivity and its impact on block propagation. Simulations show that miners with poor connectivity are negatively affected. Suggestions to work around this include renting a server on the other side of the bottleneck, but concerns about insecure infrastructure are raised. The discussion also addresses the need for proposals to counter mining centralization.Moving averages are compared to fixed growth, but they have limitations. Gavin Andresen suggests changing the default 'target' block size to the average of the last N blocks to create healthy "fee pressure" in the system.In an email conversation, Gavin Andresen and Will discuss block size. The suggestion is made to make the lazy miners' default choice grow at a slower rate than the average, which would encourage more fee pressure in the system.In 2017, Gavin Andresen put forward a Bitcoin Improvement Proposal (BIP) to increase the maximum block size from one megabyte to 8,000,000 bytes. The proposal suggests doubling the block size every two years until it reaches 8,192,000,000 bytes. To activate this change, a hash-power supermajority vote is required. This proposal allows miners, merchants, and users running full-nodes ample time to upgrade their software to support larger blocks.It's important to note that this proposed change is a hard-forking modification to the Bitcoin protocol. Therefore, anyone running code that fully validates blocks must upgrade their software before the activation time.
Updated on: 2023-08-01T13:34:19.646161+00:00