BIP proposal: Increase block size limit to 2 megabytes



Summary:

In the context provided, it is mentioned that if everyone upgrades there will be no veto power and the waiting period of 95% block version signaling for deployment coordination should be chosen using bip9. However, the grace period to give time to all users to upgrade should be before and not after miner's final confirmation. Assuming an adequate grace period, nearly 100% of miners will have upgraded long before everyone else. Bip9 can be used after the grace period to activate hardfork only if 95% of miners have upgraded. Some people have suggested a year-long grace period for simple hardforks like this one.Gavin Andresen wrote a blog post on the constants chosen, which included information about signature operations in un-executed branches of a script not being counted, and the amount of data hashed to compute signature hashes being limited to 1,300,000,000 bytes per block. Luke Dashjr expressed concerns about these changes breaking static analysis and suggested requiring scripts to commit to the total accurate-sigop count to fix this issue.Dashjr also questioned how miners express their support for the BIP since they do not get to decide hardforks and suggested rephrasing the section to indicate that miners should only enable the bit when they have independently confirmed economic support. He also recommended that any hardfork should address at least the simple tasks on the hardfork wishlist and be deployed as a soft-hardfork so as not to leave old nodes entirely insecure.Finally, it was pointed out that SPV wallets are not compatible with a hardfork and that "Light clients" would be a better term to use. The draft's controversial sentence regarding the need for an increase to continue current economic policies with regards to fees and block space was also discussed, and it was suggested that it be removed or made more subjective.


Updated on: 2023-06-11T03:45:06.886808+00:00