Published on: 2015-08-05T19:29:41+00:00
In a discussion on the security of bip102, Jorge Timón raises the question of whether miners' upgrade confirmation is necessary for uncontroversial hard forks. He suggests that without a strong supermajority of miner support, the fork risks attack and proposes requiring 95% approval as a minimum safety requirement. However, there is disagreement on this point. Peter Todd clarifies that a strong supermajority of miner support is needed to prevent attacks and highlights the option for miners to defeat forks without their approval, such as creating their own fork with a new consensus algorithm or attacking the unwanted chain. In August 2015, Jorge Timón sends a message to the bitcoin-dev mailing list discussing the issue of miners' upgrade confirmation for uncontroversial hard forks. The message emphasizes the need for a strong supermajority of miner support to prevent attacks and suggests requiring 95% approval as a minimum safety requirement. It also mentions Hearn's proposal of using centralized checkpoints to override PoW consensus but raises legal concerns about this option. The message suggests that miners have various options to defeat forks without their approval, including creating their own fork with a new consensus algorithm that requires them to prove they're attacking the unwanted chain. The message cites Garzik's recent 2MB blocks proposal as an example of such a design.In an email conversation, Gavin Andresen proposes using the version and timestamp fields in the block header as the simplest and best option for validating blocks. He explains that this option has advantages such as being available to SPV nodes with no change to the network protocol and allowing parallel and independent block validation. However, it has the disadvantage of not being monotonically increasing. Andresen dismisses discussions about transactions in the memory pool as a distraction and points out that blockchain reorganizations can affect the validity of transactions in the memory pool. He suggests that either median time or block timestamp can be used, but he dislikes using block height due to the uncertainty of knowing the next block time.The author discusses the challenges of defining thresholds for consensus fork activation and presents three options: block.nTime, median time, and block.nHeight. The author argues that block.nHeight's disadvantage is the least problematic but acknowledges that others may disagree. They emphasize the need for a solid criteria to decide which option to use. The author also discusses the combination of a threshold with miners' "voting" and the issues this can create when not being monotonic. Examples are provided for using height and median time to address this problem. The author further explains the example of an emergency consensus fork where the previous block index may not be available. Additionally, they present a scenario of a hardfork allowing miners to create bigger blocks based on transactions reducing the size of the UTXO. The author concludes by suggesting the establishment of a uniform threshold mechanism rather than relying on the three options depending on the fork type, advocating for a more generic solution applicable to any consensus fork.
Updated on: 2023-08-01T14:42:12.987100+00:00