MIP3, "longblocks", was recently activated via BIP9. The outcome was in question only because of two sha256d pools that have not updated their core software for several releases now. Activation was something of a close thing, requiring a lot of attention to notifying every pool that could be found of the new update. Activation margin was very narrow, even though no one known to us was actually opposed. Those same non-updated pools regularly capture more than 25% of many 2016-block windows to this day.
We now consider activating, probably, two or more other protocol changes. As anticipated by comments on #132, these will likely fail to activate by BIP9 process: A "partner" pool to one of the pools above was offline during longblocks signaling because it had failed to update at an even earlier time and had been forked off. It's now back, and I assume we still cannot successfully inform any of these operators about updates. Very roughly 30% of blocks are involved altogether.
I propose changing consensus signaling so that both an "approve" and "disapprove" bit are offered. To succeed, a proposal would need the designated percentage of approval when only the yes/no signals are counted, leaving blocks from non-participating -- probably unaware -- miners out of the count. To prevent creating a minority fork in the real sense, there should be a floor percentage for change approval to succeed when all blocks are counted, participating or not, maybe in the 60% neighborhood.
If the consensus mechanism is to be changed, perhaps a distinction can be made between protocol changes that impact everyone more or less equally, and those that tend to affect the miners of a certain algorithm more. With a change like this, we may be able to regularly meet 95% acceptance (for example) for most items, though the present 75% (or 95% of active algorithms, less one of them) would sometimes make more sense.
Notification of updates can be somewhat provided for by implementing a minimum time or block count between first signalling of a proposal and its activation (not necessarily the same as its first real use). Unaware miners would have the opportunity to see warnings such as are already issued about "unknown block version being mined", to investigate, and to update their node as they may wish.
I suggest activation of changes like the above by BIP9, version bit 2. Yes, that's the old "legbit retention" bit left set by the still non-updated nodes. Although using this already-signaled bit to implement one of the other proposed changes might be considered unfair, I think the sensibility of doing so here is easily seen.
Further protocol changes could be activated by this new process.
MIP3, "longblocks", was recently activated via BIP9. The outcome was in question only because of two sha256d pools that have not updated their core software for several releases now. Activation was something of a close thing, requiring a lot of attention to notifying every pool that could be found of the new update. Activation margin was very narrow, even though no one known to us was actually opposed. Those same non-updated pools regularly capture more than 25% of many 2016-block windows to this day.
We now consider activating, probably, two or more other protocol changes. As anticipated by comments on #132, these will likely fail to activate by BIP9 process: A "partner" pool to one of the pools above was offline during longblocks signaling because it had failed to update at an even earlier time and had been forked off. It's now back, and I assume we still cannot successfully inform any of these operators about updates. Very roughly 30% of blocks are involved altogether.
I propose changing consensus signaling so that both an "approve" and "disapprove" bit are offered. To succeed, a proposal would need the designated percentage of approval when only the yes/no signals are counted, leaving blocks from non-participating -- probably unaware -- miners out of the count. To prevent creating a minority fork in the real sense, there should be a floor percentage for change approval to succeed when all blocks are counted, participating or not, maybe in the 60% neighborhood.
If the consensus mechanism is to be changed, perhaps a distinction can be made between protocol changes that impact everyone more or less equally, and those that tend to affect the miners of a certain algorithm more. With a change like this, we may be able to regularly meet 95% acceptance (for example) for most items, though the present 75% (or 95% of active algorithms, less one of them) would sometimes make more sense.
Notification of updates can be somewhat provided for by implementing a minimum time or block count between first signalling of a proposal and its activation (not necessarily the same as its first real use). Unaware miners would have the opportunity to see warnings such as are already issued about "unknown block version being mined", to investigate, and to update their node as they may wish.
I suggest activation of changes like the above by BIP9, version bit 2. Yes, that's the old "legbit retention" bit left set by the still non-updated nodes. Although using this already-signaled bit to implement one of the other proposed changes might be considered unfair, I think the sensibility of doing so here is easily seen.
Further protocol changes could be activated by this new process.