questions about bitcoin-XT code fork & non-consensus hard-fork



Summary:

In this email thread, Aaron Voisine suggests that major changes to the non-consensus code should be made to handle situations in which blocks fill up. He believes that this must eventually be done if the block size limit is to be kept from rising indefinitely. Voisine argues that hardfork deployment should be discussed more often and that non-emergency hardforks should have been deployed long ago to fix known bugs like the timetravel attack. He plans to propose a fork himself, as he believes that "hardforks aren't possible" is not an acceptable answer. He thinks that he has proposed more hardforks than Gavin, all of which were rejected, but hopes that some will eventually be adopted by Bitcoin main. If not, he believes that creating an altcoin may be the only option.In response to Voisine's email, Mike Hearn explains that an alternative to the XT hard fork would be a modified version of Gavin's proposal that increases the block size limit to 8MB instead of 20MB, or BIP100, which seems to be gaining momentum toward consensus. Bryan Bishop warns that evaluating consensus changes requires extreme care, especially in the world of Bitcoin, and urges everyone to evaluate messages and source code more carefully. Faiz Khan expresses concern that proposing a hard fork is counterproductive and that it is not within a single developer's talents to manage the process start-to-finish.


Updated on: 2023-06-09T23:16:51.901986+00:00