Author: Jorge Timón 2015-07-29 20:27:29
Published on: 2015-07-29T20:27:29+00:00
The author discusses the challenges of defining thresholds for consensus fork activation. They explain that there are three options available, each with its own disadvantage. The options are block.nTime, median time and block.nHeight. The author suggests that nHeight's disadvantage is the least worse but others may disagree. They argue that a solid criteria needs to be established to decide on which option to use.The author goes on to discuss combining the threshold with a miner's "voting" on top of it, and the problems this can present when not being monotonic. They provide examples for using height and median time to address this issue. They also discuss the example of an emergency consensus fork where the previous block index may not be available. The author then provides an example hardfork scenario where miners are allowed to create bigger blocks if the transactions help reducing the size of the utxo. They explain that while block.nTime is available at the block validation level, checking an unconfirmed transaction would require the block.nTime of the next block, which is unpredictable. In conclusion, the author suggests that a uniform threshold mechanism needs to be established instead of using the three options depending on the fork. They express a desire for a more generic solution that can be used for any type of consensus fork.
Updated on: 2023-06-10T04:20:19.727089+00:00