Hard fork voting and counting period clarification and possibility to downgrade the node in case of accidental upgrade.

[ltraveler]

For now the hard fork update process described as:

1. The new node version will support both the current blockchain protocol and the upcoming protocol changes.
2. By running the new version of the node you vote for the upcoming protocol changes. By running the previous version of the node you vote against the protocol changes. To publish your vote you need to keep your Idena node online with the activated mining status during the hard fork voting period.
3. The hard fork voting period starts on December 23th at 8 am UTC. The hard fork will be activated once the voting criteria is met. Otherwise, the hard fork update will be blocked on December 30th.
4. The hard fork update will be activated only when more than 80% of the non-discriminated validators who run their nodes support the upcoming changes
5. Newbie and delegated address votes are discriminated against and not counted. Pool owners are counted once.

During the voting period in case of reaching the majority of the nodes with the newest version, the hard fork would be automatically activated, Which I think could be considered as violation of electoral rights. If we have a clearly set hard fork voting period then the counting process should come into force after the end of voting as it usually happens on any elections.

[spiketrains]

I am slightly inclined to be in favor of having a set date (e.g. 30 Dec. in this case) in which we take a snapshot rather than triggering the update as soon as an upgrading threshold is reached.

My position is based on my belief (I might be wrong, not sure whether we have data here) that a considerable amount of nodes are auto-upgrading via automatic node management solutions. I can imagine there being some edge cases in which this would trigger unintentional activations, as some people running self-upgrading nodes might actually realize to be against the fork after more thoughts/discussions about it.

I understand that the current process has the advantage of potentially faster activations, but I don't think it's worth it unless we are really talking about urgent upgrades.

On the other hand, I wonder if having a snapshot at a specific date could be more easily manipulated by parties withholding their vote until the last moment.

[ltraveler]

My position is based on my belief (I might be wrong, not sure whether we have data here) that a considerable amount of nodes are auto-upgrading via automatic node management solutions. I can imagine there being some edge cases in which this would trigger unintentional activations, as some people running self-upgrading nodes might actually realize to be against the fork after more thoughts/discussions about it.

Exactly. Also there are bunch of identities with voting power who potentially could run the node during to voting period. By accepting immediately the hard fork upgrade before the end of voting period we are essentially disposing their voting rights.

I understand that the current process has the advantage of potentially faster activations, but I don't think it's worth it unless we are really talking about urgent upgrades.

The voting period is set to one week imo there is no practical sense to force activation to the detriment of voting right.

On the other hand, I wonder if having a snapshot at a specific date could be more easily manipulated by parties withholding their vote until the last moment.

Could you explain that please in the frame of possible case?

[spiketrains]

Could you explain that please in the frame of possible case?

DISCLAIMERS

1. I like to talk about governance and voting systems, but I want to make clear that I don’t think we have a big issue right now. Both solutions are viable in my opinion, and in any case we are talking about marginal improvements. I don’t think the attack I describe below is a big deal, as I don’t think “false positives” from auto-upgrades are a big deal. In the worst case, we can always repeat the vote.
2. My arguments below might seem far-fetched in the current environment and I would agree with that as probably there is not enough economic incentive to manipulate voting. However, I prefer being proactive rather than fixing stuff once it becomes urgent.
3. Another reason why the risk is low is that 1 human = 1 vote helps a lot. To pull off the attacks described below you would need a high level of coordination among too many actors. If we had a voting power depending on iDNA holdings it would be much worse.

That being said, my argument is that people against the upgrade might mislead opposition by upgrading during the voting period and downgrading at the last moment.

In this way, it would appear that the upgrade had a very good chance to be activated, disincentivizing people in favor of the upgrade to do extra work to promote it (as we have seen in the past, active campaigns can be useful during the voting period to get extra votes and reach the threshold).

Of course, this “trick” would perhaps work only once or twice, then it would probably be clear and well-known what is going on, and we could say that this drawback is not relevant anymore.

But still, I would argue that the current system would be more transparent on the real intentions of the network and their evolution in real time during the voting period. You could still manage to use this strategy up to a certain extent but it would be more risky if you target a fake baseline near the voting threshold (and it should be there to be effective).

Maybe I could use a similar argument against the current system, saying that people in favor of the upgrade could withdraw their vote, keeping the baseline in favore of the upgrade at a very low level for a few days and coordinate for a “surprise upgrade” voting all at the same time with no possibility for the opposition to react.

But in this case I would argue that this does not really make sense, as in principle the party in favor of the change is the one that needs to put in the work to convince people to upgrade, while the party against the change is “winning by default” (this is not really true in practice, see my comments on the auto-upgrading node managers above, but it is true that in the past we had to put in the work to spread the voice and reach more users to activate and upgrade their nodes).

[ltraveler]

There are some more thoughts that came to my mind:

1. Theoretically it must be a chance for identities who are passing the identity status criteria to join the voting by running the node in any moment during the voting period. But with that immediate activation potentially we are excluding from the voting those kind of swing voters.
2. Why the majority of upgraded client nodes is more important and making hard fork be activated immediately and the majority of old version nodes have to wait until the end of the voting period to block the hard fork activation?

The signs are becoming clear that the vote in favor to accept hard fork changes more privileged in comparison with votes against the changes. I think the rules must be changed to equalize in rights both sides of the election process.

[idena-Egyptian-Pharoh]

Most of people remember the #7 hardfork which is activated 1 hour before the deadline
Link : https://scan.idena.io/hardfork/7
It's always activated once the criteria is met 80%
All nodes that update the node from 16th dec to 23rd before 10:00
Once the voting started means counting votes (old and new) , if the majority is met , if will be activated at once even if in the first 5 minutes of voting counting.

[ltraveler]

Once the voting started means counting votes (old and new) , if the majority is met , if will be activated at once even if in the first 5 minutes of voting counting.

As I mentioned before, during voting period all days should stand equal.
Why the side of accepting a hard fork has more power in comparing to the side of blocking the hard fork update?..
Anyone should have the rights to run the node with the new or with the previous node version during the whole voting period. It should be always a possibility the opposite side to reach the majority during the whole voting period as it usually works in standard elections.

[idena-Egyptian-Pharoh]

Yes they can vote against the hardfork , they have 1 week before voting started since the latest version released.
Once the voting started it counts identities with updated version, once it met criteria it's activated.