Adjustments to protocol voting

Issue #21 new
Jordan Lee
repo owner created an issue

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)

  1. Jordan Lee reporter

    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.

  2. Log in to comment