How voting the numbers could solve the stucked fork

[vazaki3]

We are all waiting for a fork to happen when 80% of the masternodes will be updated to v18. But we have a problem here, two masternodes megawhale operators (weejohnny and august) refuse to update to v18. Thus we are currently stucked. The situation is 78% already updated to v18 and 22% remain in the old version. How this can be solved?

80% is the number that is required for a fork to happen, and it is an arbitrary number. Nobody knows why someone decided this number and not another. Numbers without a theory behind, are wrong numbers. In that case, lets vote the numbers.

• 77% vote that the fork should happen when 50% is reached (thats the smart vote in terms of games theory, and common logic says that a fork should not happen when less than 50% demands it, so the possible votes are bounded between 50% and 100%).
• 22% vote that the fork should happen when 100% is reached.

Assuming that the method required to extract the result is voted to be the mean average method, we do the calculation. (22X100+78X50)/100=61%

So the fork happens when 61%% of the masternodes update to v18. Thus the fork occurs now, yesterday I would say.

Voting the numbers helps the community to solve and bypass such deadend issues.

 

[thephez]

Actually this fork (as well as the previous 1 or 2) does not require 80% of masternodes to update. The fork occurs as soon as the mining threshold (which diminishes from 80% to 60% over time) is reached irrespective of masternodes. Which could create some issues if enough masternodes didn't upgrade fast enough (e.g. inability to form quorums), but has not.

Also, as I understand it, the 80% you reference in regard to masternodes is not arbitrary, but is the value at which proof of service can effectively operate well. Finally, it's worth noting that this has been the fastest activation of a hard fork within the last 4+ years (possibly ever).

 

[vazaki3]

Actually this fork (as well as the previous 1 or 2) does not require 80% of masternodes to update. The fork occurs as soon as the mining threshold (which diminishes from 80% to 60% over time) is reached irrespective of masternodes. Which could create some issues if enough masternodes didn't upgrade fast enough (e.g. inability to form quorums), but has not.

So lets vote the numbers for the mining threshold, which also seems arbitrary to me.

Also, as I understand it, the 80% you reference in regard to masternodes is not arbitrary, but is the value at which proof of service can effectively operate well. Finally, it's worth noting that this has been the fastest activation of a hard fork within the last 4+ years (possibly ever).

Why the proof of service can effectively operate at 80%, and not at 79% or at 81%?
Do you have a proof or a theory explaining why 80% is the golden number? If not, then lets vote the numbers about it.