You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a new major version of decrediton is released, typically there are new consensus agendas that are available to vote on. These vote preferences are saved at the dcrwallet level and when updated they are sent to vsps for any unspent/unexpired tickets.
In a perfect world the VSPs would all update to the new version immediately and when these vote choices were sent to the vsps from dcrwallet, they would set all the pending tickets to the proper choices. But in practice, the vspd update doesn't happen for a few weeks after major releases, and some vsps are slow to update their infrastructure as well.
This situation leads to the following situation: New release 1.X.X comes out and a decrediton user has Y tickets unspent/unexpired at N vsps. They immediately open decrediton and update their vote preferences. These vote preferences are updated in dcrwallet and preserved for their local set up. They are also sent to any used vsps, but the vsps aren't updated so the vote preferences are lost. Then if the user never does anything else the unspent tickets will end up being voted with abstained choices.
I propose we track the following information:
the current minimum vsp version,
the current version of all vsps,
the last time vote preferences were updated,
how many tickets each used vsp currently has.
This information should allow us to track whether or not a user needs to update their vote preferences.
If any un-upgraded used vsp that has > 0 unspent tickets the user should be alerted to this situation on the governance page. (still need to figure out ideal UI/UX for that alert). "You have unspent tickets at a VSP that has not upgraded to the minimum version. While your confirmed/paid for tickets will be voted, your vote preferences will not be used. Please contact <vsp.host> to ask them to upgrade."
If any recently-upgraded vsp has > 0 unspent tickets and the most recent vote preference update was prior to them upgrading, we should alert the user and automatically do a set vote preference request modal.
The text was updated successfully, but these errors were encountered:
alexlyp
changed the title
[vsps] Track used VSPs last voting preference update
[vsp] Track used VSPs last voting preference update
Mar 17, 2022
When a new major version of decrediton is released, typically there are new consensus agendas that are available to vote on. These vote preferences are saved at the dcrwallet level and when updated they are sent to vsps for any unspent/unexpired tickets.
In a perfect world the VSPs would all update to the new version immediately and when these vote choices were sent to the vsps from dcrwallet, they would set all the pending tickets to the proper choices. But in practice, the vspd update doesn't happen for a few weeks after major releases, and some vsps are slow to update their infrastructure as well.
This situation leads to the following situation: New release 1.X.X comes out and a decrediton user has Y tickets unspent/unexpired at N vsps. They immediately open decrediton and update their vote preferences. These vote preferences are updated in dcrwallet and preserved for their local set up. They are also sent to any used vsps, but the vsps aren't updated so the vote preferences are lost. Then if the user never does anything else the unspent tickets will end up being voted with abstained choices.
I propose we track the following information:
This information should allow us to track whether or not a user needs to update their vote preferences.
If any un-upgraded used vsp that has > 0 unspent tickets the user should be alerted to this situation on the governance page. (still need to figure out ideal UI/UX for that alert). "You have unspent tickets at a VSP that has not upgraded to the minimum version. While your confirmed/paid for tickets will be voted, your vote preferences will not be used. Please contact <vsp.host> to ask them to upgrade."
If any recently-upgraded vsp has > 0 unspent tickets and the most recent vote preference update was prior to them upgrading, we should alert the user and automatically do a set vote preference request modal.
The text was updated successfully, but these errors were encountered: