[PASSED] Finalized motion for protocol "voting"

JordanLee 2014-11-17 20:42:06 UTC #1

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*

Release plan

masterOfDisaster 2014-11-17 21:17:18 UTC #2

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.

Chronos 2014-11-17 21:40:48 UTC #3

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%?

pennybreaker 2014-11-17 21:44:44 UTC #4

This is a good point. What do we do in the event of an emergency release like the one we had last week?

desrever 2014-11-17 22:40:21 UTC #5

Good points pg and chronos : what if we classify upgrades ( regular, urgent, emergency ) with different thresholds for each type (90,75,10)?

mhps 2014-11-18 01:23:04 UTC #6

Isn’t choosing a client to run is already voting for the protocol that the client supoort? What am I missing?

JordanLee 2014-11-18 01:48:37 UTC #7

I understand the 2000 blocks as a rolling window like for other votes. Is that right?

Yes.

Though the voting period is 2000 blocks, normally the client update would be made available weeks ahead of the switch time.

masterOfDisaster 2014-11-18 05:50:42 UTC #8

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?

Cybnate 2014-11-18 07:35:49 UTC #9

Why wouldn’t we just go for 50%? Otherwise you might get subject to the tyranny of a minority group.

GreatScott 2014-11-18 20:08:58 UTC #10

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.

mhps 2014-11-19 00:10:24 UTC #11

Broadcasting is already implemented in bitcoin-qt hence peercoin wallet.

Cybnate 2014-11-19 18:31:26 UTC #12

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

JordanLee 2014-11-19 19:39:14 UTC #13

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.

JordanLee 2014-11-19 19:47:07 UTC #14

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.

woolly_sammoth 2014-11-20 08:47:59 UTC #15

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.

Cybnate 2014-11-20 09:01:18 UTC #16

Continuing the discussion from Draft motion for protocol “voting”:

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?

JordanLee 2014-11-23 19:27:42 UTC #17

I determine whether a release is deemed an emergency release not subject to this provision. If I am unavailable, sigmike will make the decision.

Unfortunately, the code of the reference client represents an element of centralization in all blockchain technologies. I see no alternative.

JordanLee 2014-11-23 19:37:30 UTC #18

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.

JordanLee 2014-11-23 23:51:40 UTC #19

Agreed.

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.

Cybnate 2014-11-24 08:06:43 UTC #20

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.