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.
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.
This sounds like a good idea. More certainty is always good. Also the upgrade warning is a great way to handle it without having to use a centralized message.
Couldn’t this be abused if the only requirement is one block? Couldn’t anyone rewrite the client to have a higher protocol version vote, and then mint. It may be more of a nuisance than an actual risk, but putting some percentage of blocks as a threshold before the message occurs prevents it. “10% of the last 100 blocks reported a higher protocol version of X. Consider upgrading your client”
That or just displaying a percentage in the status bar until the protocol vote passes.
“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.
Bitcoin and Peercoin have alerts that can be issued by trusted people in possession of an alert private key, such as Gavin Andresen and Sunny King. I was determined to make Nu completely decentralised, so it has always been my plan to use data feeds to issue alerts and software updates (which wouldn’t be completely automatic). It just hasn’t been prioritised yet. It’s probably the highest priority feature that hasn’t been scheduled for release yet. We are being extraordinarily careful about holding down costs for the network right now and we are busy with B&C Exchange. Honestly, a year ago I thought we would have it implemented by now. It is probably fair to say the exchange losses in February are the reason it hasn’t been done yet.
