As usual, this motion is presented is for discussion, after which a finalized version of the motion will be presented for shareholder voting
Protocol changes are typically implemented using a hard coded date the change takes effect. If the vast majority of the network has not upgraded their client by that date serious problems can result. Therefore, protocol changes would be lower risk if they didn’t take effect unless the vast majority of the network has adopted the new protocol. By lowering the risk of protocol changes, we can be more bold in updating and evolving the protocol.
To vote for this motion, enter the following motion hash in your Nu client:
b3772ae165320bcc08297dd338e82dd91cd01a56
Begin motion
A client should vote for its protocol version. Each version of the reference client has a protocol version number hard coded in it. This number should be placed on the blockchain in the coinstake transaction when a block is minted, similar to how other votes are cast. This vote is not user configurable, so it has no user interface components. When 90% of the last 2000 blocks have voted to increment the protocol version AND any applicable date criteria for the protocol change is met, the protocol will change. If the percentage of the last 2000 blocks voting for a protocol version falls back below 90% threshold, no action will be taken. The protocol version in effect cannot be decremented. End motion*
I understand the 2000 blocks as a rolling window like for other votes. Is that right? I’m asking because the passage that deals with the vote falling below 90%. This sounds a bit confusing.
If my understanding is right, I can’t find obvious drawbacks.
2000 blocks should equal roughly 33 hours or one and a third day.
The update time frame is only that short, if the majority of the minters is quickly updating and voting for the change. It might often take way more time than 33 hours from the release until the 90% are reached. I expect that users of NBT need to follow.
But even it goes that fast; it’s in my opinion enough time for both the remaining minters to follow the minting majority as well as the exchanges (and soon the merchants and other users ot NBT - hopefully!) to update their wallets.
Admittedly I’m not involved in running an exchange (nor a business), but I guess that more than a day (“worst case”; read: shortest time frame) should be enough - maybe I should say that I hope it…
Once the adoption is far beyond a bunch of users and some exchanges (ok, this one’s a little bit tongue-in-cheek) it might be appropriate to have another vote to expand the minimum time frame from making the new client version available until switching to the new protocol version.
This might become necessary because the number of NBT users (people, merchants, exchanges, etc.) will grow quicker than the number of NSR holders (possible minters) and the number of minting NSR.
This seems like a great way to roll out updates. The only drawback I detect is that 90% might be too high. If this motion had been in place for the previous version updates, would it have significantly delayed their distribution? What downsides do you foresee if the number were 75% instead of 90%?
This way you can run a client that supports the new protocol version and postpone the protocol switch to a later point of time or did I get this wrong?
Thinking twice makes me believe that you are actually right. Who would stop minting just to postpone the protocol switch?
It would be really cool if the client had an automatic way to let you know of an up and coming protocol change. It could display a message in the bottom left corner of the client indicating something like: “x% of peers have changed to protocol v0.5.2”
I actually didn’t realize 0.5.1 had come out until a transaction of mine never showed up and I did some quick checking around on here to get the news.
Slightly off-topic, but can’t we just have a kind of custodial grant for broadcasting a message. That way we can get rid of the central messaging aspect and bring the communication to end-users in the hands of the shareholders. Would be interesting to hear what such a development would cost.
Edit: just an example we would vote for message "xyz’ to be displayed for x amount of time starting from block xxx. When the proposal is granted by having more than 50% of Shareholders voting for it the client would automatically display the message for that timeframe
The biggest risk is that an exchange would be on the old fork, accept a deposit that wasn’t accepted in the main chain, the user would exchange it for another asset and withdraw. It is likely the deposit would be recorded in the main chain as well, but with nodes using the new protocol banning old protocol nodes, it may not be propagated in both forks. Due to the seriousness of such an outcome, a very high degree of consensus is appropriate. 85% might be a reasonable figure, but 75% is clearly dangerous. We can get the consensus as people eventually upgrade. Automated upgrading based on a signed instruction from a data feed you choose to subscribe to is planned as a medium high priority. This will make protocol consensus even easier. I believe we can make data feed subscription the default behavior for new client installs in a way that doesn’t favour any particular data feed, but just mirrors their popularity in the wild.
Emergency protocol changes don’t need to have any acceptance threshold. The way a protocol change will typically be implemented is to have it inside an ‘if’ block that tests for the date and whether the vote for the protocol has passed. In the case of a protocol change like what was included in version 0.5.1, both these tests would be omitted. This proposal doesn’t compromise our ability to make rapid protocol changes with less consensus when needed.
I like this idea. Anything that improves the robustness of the network, especially at a potentially fragile moment like a protocol change, is a good idea in my book.
Would it be worth having the percentage of the network that needs to agree for the change to take effect as a component of the vote that gets tested in the ‘if block’ rather than a hard coded number. My gut feel is that deciding a percentage now may lead to issues when the changes hit the real world. Better to have the ability to change the percentage with little to no effort.
So it is more a guideline than something enforceable by the network as I understand it. The developers can always override in case of emergency. The question becomes what is an emergency and who determines that?
I just edited the original post to transform it from a draft motion to a finalized motion ready for voting. The only change to the original draft motion content was the correcting of a grammatical error.
Let’s make 90% the default, but if the author of a motion changing the protocol would like a different percentage to be the threshold for the switch, they may specify it and we will use it in the code.
I’m not reading that statement in the motion in the OP. With this motion I don’t think an author has choice other than to raise a motion to override the 90%. Not very practicable.