Adjustments to protocol voting
We learned something from the Nu 2.0 protocol switch. It is desirable to have a protocol switch date known with certainty well in advance of the switch. Though we had assigned and published August 25 14:00 UTC as that date, it was contingent on getting a 90% consensus on the new protocol. The 90% threshold was not met at the switch date, which meant the actual protocol switch time became unpredictable, as no one could be certain when the 90% threshold would be met.
To avoid an uncertain switch date in the future, we plan to make 90% consensus the sole criteria, with the actual switch date occurring two weeks after 90% consensus is reached to provide a two week window of certainty regarding the switch date. We intend to use this approach for all subsequent Nu and B&C protocol changes. A switch time of 14:00 UTC is preferable, so the switch date should be at the first 14:00 UTC that is two weeks or more from the time 90% threshold is reached.
We will also display a warning in the status bar when the client receives a block with a protocol vote for a version exceeding its own. This means that 4.0 users will receive a warning when others begin to upgrade to 5.0. This will also be employed in the Nu client in 2.1.
Comments (3)
-
Jordan Lee reporter
-
Michael Witrant
I implemented the protocol switch (without the warning) in pull request #24.
-
Michael Witrant
The warning is implemented in pull request #25.
- Log in to comment
From CoinGame:
"X percent of the last N blocks have a higher protocol version of L" where X is an ever increasing value based on the last N blocks. Setting the percentage to display at 20%-30% would probably also prevent it.
This is an improvement. Let's do it using a 20% threshold for displaying the message. Let's make N a constant 2000 blocks.