Published on: 2015-10-02T01:22:14+00:00
Gregory Maxwell and Rusty Russell had a discussion about the possibility of requiring a bit to be set during the soft fork activation period. This would allow thin clients to reject blocks from non-upgraded miners. However, they decided against this proposal as it would cause warnings on older clients. Instead, they focused on upgrading versionbits and opened a PullReq for the "keep setting bit until activation" proposal.The conversation also explored the idea of making a BIP deployment optional but recommended for the first time. This would help collect valuable data to identify faulty implementations and bugs. It was suggested that a more sophisticated signaling mechanism could be introduced in the future to provide informative messages to end-users regarding changes and direct them to resources for learning about new features.There was a suggestion to require setting the bit for a period of time after rule enforcement begins, without actually enforcing the bit. This would allow thin clients to approach these blocks with skepticism. However, implementing this later would trigger warnings on older clients who would see the bit as representing a new soft fork. The simplest solution proposed was to have miners continue setting the bit for another 2016 blocks, which could potentially become a consensus rule if necessary.Gregory Maxwell argued that the bit can be easily checked by thin clients to reject blocks from non-upgraded miners post-switch. A middle ground solution was proposed to require setting the bit for a period of time after rule enforcement begins, but only enforce the validity of the block under new rules. However, this would add another state and trigger warnings on older clients if implemented later. Miners would need to keep setting the bit for another 2016 blocks to implement this solution, which could become a consensus rule if needed. Rusty concluded the discussion with a humorous quote.The context also discusses the challenge of determining whether miners are enforcing new rules without relying on someone mining a block that breaks the rule. Hard forks come with greater risks and disruptions, so the author suggests that an awareness campaign can help address concerns about older clients. The Version Bits mechanism is not a 'voting' system but a deployment mechanism for uncontroversial changes, measuring adoption before activation. It is most useful for adding default settings in product releases. The author emphasizes the importance of smooth transitions and acknowledges the reality that explicit acknowledgment of enforcement may not be possible.Rusty Russell raised the issue that the current BIP has miners turning off the bit as soon as it's locked in, making network adoption less visible. He suggested that miners should keep setting the bit for another 2016 blocks after activation and have a consensus rule that rejects blocks without the bit. This would "force" upgrades on the last remaining miners. However, this immediate bit forcing was seen as an advantage of versionbits over prior work.In another discussion, Pieter and Eric noted that miners turn off the bit as soon as it's locked in, which reduces network adoption visibility. Rusty did not propose an alternative suggestion but mentioned that miners should keep setting the bit for 2016 blocks after activation. If this idea proves successful, they can proceed with it. According to BIP-0009, software should begin by setting the bit in all mined blocks until it is resolved. If the bit is set in 1916 or more of the 2016 blocks within a retarget period, it becomes 'locked-in,' and miners should continue setting the bit for visibility. The consensus rules related to the locked-in soft fork will be enforced in the second retarget period, allowing the remaining 5% to upgrade. At the activation block and after, miners should stop setting the bit, which can potentially be reused for a different soft fork.
Updated on: 2023-08-01T16:26:12.381254+00:00