This is a good point. What do we do in the event of an emergency release like the one we had last week?
Good points pg and chronos : what if we classify upgrades ( regular, urgent, emergency ) with different thresholds for each type (90,75,10)?
Isn’t choosing a client to run is already voting for the protocol that the client supoort? What am I missing?
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.
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?
Why wouldn’t we just go for 50%? Otherwise you might get subject to the tyranny of a minority group.
1 Like
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.
Broadcasting is already implemented in bitcoin-qt hence peercoin wallet.
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.
1 Like
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.
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?
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.
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.
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.
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.
Any protocol change will need to be approved via motion. Any such motion can specify a different adoption threshold if the author sees a reason to do so. No extra motion is needed.
This motion has passed.
excellent