Published on: 2015-06-28T20:56:20+00:00
In a discussion on the Bitcoin-dev mailing list, members expressed concerns about the decision-making process for controversial changes to Bitcoin. They debated whether it was appropriate to rely on a single person to determine what is considered controversial, as this could be influenced by a vocal minority. It was suggested that proposals should be made after things have "cooled down" to avoid unnecessary controversy. The conversation referenced the phrase "I know it when I see it," which originated from a US Supreme Court ruling and has since been used to describe subjective judgments.Some members discussed the risks of both "doing nothing" and increasing the block size limit. They noted that gauging the majority's preference is difficult before something actually happens. There were varying perceptions of the risks, but it was suggested that conducting a "software fork" would be the only way to determine how many people are in favor of bigger blocks. The question of whether the majority has the right to dictate to the minority was deemed complex and advised to be left out of the discussion.The debate over increasing the block size limit highlighted a contradiction between the economic policy of avoiding fee pressure and the consensus status quo of not having a hard fork. Some argued that maintaining the status quo without changing either the policy or consensus rules is not possible. It was suggested that making changes to the policy code of different implementations would be closer to "maintaining the status quo" than a hard fork. However, increasing the block size without addressing underlying problems was considered a "lazy option" that could leave implementations unprepared for new rules.There were discussions on the possibility of uncontroversial hardforks and the need to propose them to see if they are viable. It was mentioned that minor issues planned for the long term or non-politically loaded features could be considered for hardforks. Additionally, major emergencies that exploit coin holders or miners could warrant a hard fork. Non-critical and non-controversial hardforks could even be planned and time-locked up to five years ahead, eliminating the need for quick client upgrades.The issue of whether Bitcoin needs to scale to business or vice versa was debated. The writer argued that Bitcoin already has utility and that increased adoption does not necessarily increase its value. They cautioned against sacrificing decentralization to big business and advocated for holding steady while doing necessary research. It was suggested that Bitcoin should be seen as a solution when things go wrong for ordinary users, rather than fitting into existing business models.In an email exchange, Wladimir J. van der Laan expressed hostility towards hardforks after recent stressful conditions. He suggested that hardforks must be possible if they are uncontroversial and give enough time for users and alternative software to upgrade. However, politically loaded changes were advised to be avoided. The article also compared the debate over block size to limiting planes' wingspan to old hangar doors, which caused controversy as modern planes may not fit. The writer argued for facing reality instead of creating false expectations.In discussions on blockchains, it was suggested that they can go beyond value tokens to determine consensus among users. The role of developers in making economic decisions for Bitcoin's growth was emphasized. The question of whether Bitcoin should compete with existing payment networks or define its own network was raised. It was argued that developers have a crucial role in implementing economic policy and that multinational or government-sponsored entities dominating the blockchain do not mean that Bitcoin has been surrendered to the "free market. "In an email conversation, Pieter Wuille and Wladimir J. van der Laan expressed their views on larger blocks in Bitcoin's blockchain. They disagreed on the necessity of larger blocks due to fear of changes in economics. They found political pressure tactics used to change the consensus system concerning and stressed that developers work on technical improvements, not governing the system. They expressed hostility towards hardforks that make politically loaded changes and emphasized the importance of resiliency and decentralization.In discussions on the Bitcoin-dev mailing list, ideas were proposed to create websites displaying current mempool backlogs and fees needed to prioritize transactions. Standardizing reporting "delay alerts" in wallets was also suggested to inform users about potential issues during periods of increased transaction volume. The importance of communication between senders and receivers regarding transaction delays and confirmations was highlighted.Overall, the context highlights the ongoing debate about increasing the block size in Bitcoin. Different perspectives are presented, with some arguing for larger blocks to increase utility and accommodate growing usage, while others emphasize the importance of careful consideration, decentralization, and understanding the risks involved. The need for a clear path and schedule to accomplish changes is also mentioned, as well as concerns about centralization risk and the impact on the blockchain network.In the context provided, there is a disagreement between Gavin and Pieter regarding the idea of increasing block sizes in Bitcoin. Gavin argues that a fear of change does not necessitate larger blocks, as it could lead to an unlimited growth similar to infinite copyright terms.
Updated on: 2023-08-01T14:00:18.445572+00:00