Block size: It's economics & user preparation & moral hazard [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2015-12-27T00:33:58+00:00


Summary:

Email exchanges and discussions on the bitcoin-dev mailing list are focused on hard forks and increasing the block size of Bitcoin. Bryan Bishop denies claims of stalling in deploying a hard fork and emphasizes extensive discussion about different block size proposals. However, he is accused of being condescending and banning someone from the mailing list to prevent uncomfortable questions. The other person raises concerns about stonewalling, deception, conflicts of interest, and crimes.Pieter Wuille proposes a timeframe of 6 to 12 months for an uncontroversial hard fork and suggests involving miners as an extra layer of safety. He also mentions using the Alert System and creating an "Upgrade now!" message to encourage node upgrades. Jonathan Toomim agrees that user and miner adoption for a hard fork will not be difficult but argues against giving miners the power to trigger the fork. He believes consensus should be hard to change and that visible full nodes' upgrade percentage should be considered.Discussions highlight the importance of planning ahead to avoid forced upgrades during capacity emergencies. Pieter Wuille notes that even non-controversial proposals have taken longer than expected for full node adoption. He suggests incentivizing full node upgrades when a hard fork is implemented. In another discussion, Wuille expresses concern that setting the switchover point for a hard fork at 75% consensus would result in a temporary forked off chain. A grace period of 4000 to 8000 blocks (1 to 2 months) is suggested, but slow adoption rates for uncontroversial changes are acknowledged.The role of Bitcoin Core maintainers in judging consensus for a hard fork is discussed, emphasizing the need for widespread agreement. Soft forks are seen as a viable alternative to hard forks in the short-term. The discussion also touches on the concept of the bitcoin-core release as a Schelling point in the consensus game.One email offers a Bitcoin reward for those affected by a hard fork to 2MB blocks and proposes incentivizing miners by pledging a portion of a fund. Risks and alternative methods are discussed. Another conversation focuses on math equations, the benefits and drawbacks of hard forks and soft forks, and the ongoing decision-making process to improve Bitcoin's scalability and efficiency.Jeff Garzik expresses concern about the power of the Bitcoin Core development team in deciding network consensus rules. Pieter Wuille argues for continuing what is known to work and emphasizes the need for an expected upgrade at a predictable date in the future.In discussions around Segregated Witness (SegWit), Pieter Wuille argues that robust adoption rates by up-layer ecosystem software are not required for its success. He highlights the benefits of SegWit, such as increased capacity and better security models, independent of others' adoption.The decentralization of Bitcoin gives miners the power to veto any block size increases. Users also have some power, but imposing costs on others harms themselves. Various groups like Core Devs, miners, exchanges, merchants, and customers each have their own interests and potential for influence. Changes can be made without complete agreement, but if merchants and customers switch to different software, it can have a significant impact.Pieter Wuille emphasizes that no one group is in charge of making decisions regarding Bitcoin. Consensus is important, but not always necessary. The core dev team has been given authority by the most powerful groups but can be checked if necessary. Communication about protocol changes is important to avoid confusion.The main objective in maintaining the Service is to ensure its vitality, security, decentralization, and resistance to censorship for as many Users as possible. Block size functions as a limited resource, becoming available every 10 minutes with some variability. Users, block size, and the bidding process are intertwined, with hashpower assessing block inclusion based on transaction fees. Recent changes in the mempool have introduced a floating relay fee, enhancing responsiveness to rapidly changing markets and Denial-of-Service attacks. Efforts are focused on maintaining a thriving, secure, decentralized, and censorship-resistant Service for all Users.


Updated on: 2023-08-01T17:10:34.372179+00:00