As I am working through the hard fork code I have been thinking about how to present this to the user. Currently, the interface is a binary field and super hard to use. The alternative I came up with is to provide two new commands votelist and vote. The votelist command should display the current ballot and the options. For example: Code: $ dcrctl --wallet votelist blockchain "Change block height from in64 to uint64" Yes "Vote for block height type change" No "Vote against block height type change" Abstain "Don't vote for block height type change" blocksize "Change block size to a new value" 1M "Change block size to 1MB" 10M "Change block size to 10MB" 100M "Change block size to 100MB" The vote command allows the user to cast his vote. For example: Code: $ dcrctl --wallet vote blockchain yes What do you guys think? Good or bad idea? Got any suggestions?
So if i am understanding this correctly above command shows that there are 2 votes ongoing, one is normal vote on the current block and 2nd is for blocksize. if that is the case than i think this works very well, just need to make sure that description are good. I have 2 suggestions allow voting on more than one proposal with a single command e.g. Code: $ dcrctl --wallet vote proposal1 yes, proposal2 no, ... Maybe give proposal an ID or abbreviation when its announced e.g. BLOCKSIZE, SUBSIDY etc and use it in command to recognize it. I hope these suggestions make sense.
I would also suggest the casing be consistent. The listed options show them capitalized, whereas the vote command shows it lowercase. Ideally the options should be shown in lowercase, and the vote command would lowercase whatever the user supplies to avoid any case-related issues. EDIT: That way these would all be equivalent: Code: $ dcrctl --wallet vote <agendaid> yes $ dcrctl --wallet vote <agendaid> YES $ dcrctl --wallet vote <agendaid> Yes ...
The other thing I'd like to point out is that the dcrctl approach is fine (and necessary) for being able to change the vote at runtime, however, there also must be a way to specify them at startup so the desired options can be set when starting the wallet. In my opinion, it would not be acceptable to only have the option to change the settings after starting the wallet. EDIT: Upon reflecting on it, I would also say that perhaps the settings should be saved into the wallet database and loaded at startup so the most recent settings are retained between restarts. Losing the settings when restarting is not ideal.
i like the idea of saving the vote settings at shutdown rather than creating new flags for setting votes at runtime, especially when new proposals are added you have to change whole RPC flag code everytime. Although i think this can be shown in very easy way in GUI via checkboxes/radio buttons, which can make it very easy for beginners to choose their vote. We can even add a little tooltip explaining the proposal. I am not sure if it is a good idea to embed link in the wallet but we can show proposal id and tell them to search for it on forum/github.
I like the solution. There also should be an option to get the current vote statistics parsed from the last blocks. You should be able to give the block-height as a parameter to get the vote counts. something like Code: dcrctl --wallet votecount <agendaid> <blockheight.start> <blockheight.end> With this the user is able to specify a timeframe which he want's to analyze / can see how opinions shift over time caused of 'FUD' ? ---- When a User wants to register with stakepool via the gui.wallet he should be able to register on various stakepools and decide when purchasing tickets for which stakepool he buys his tix. Fair share and not carved in stone!
How will this work for people who are allergic to the CLI? Will there be a GUI based vote option? Also how does the voting work? Is the vote open for a period of time and all votes are tallied during that period? What about the default when a new vote is opened? Can you change the vote for tickets that have already been purchased? More questions to come I'm sure
Yes, the idea is definitely to have check boxes and/or radio buttons (as necessary) in the wallet GUI to be able to choose the votes. However, @moo1337 was specifically just asking about the CLI side here. The first part of the voting process, which has to do with PoW and PoS upgrading is explained in detail at https://blog.decred.org/2016/11/16/Upgrading-Consensus/. I would expect there to be another detailed blog post that explains further details when 0.8.0 is released. However, I'll provide short version answers to your questions here. Voting is open starting from the first block that falls on a voting interval after the voting agenda start time has been reached and both the majority of PoW and PoS miners have upgraded as described in the aforementioned blog until there is either a super majority yes, a super majority no, or the expiration time has been reached (this will be variable per voting agenda, but is likely to be an extended period such as a year). The default is "abstain" which is effectively an "I don't know enough about this to intelligently vote one way or the other or I don't care" and means your vote does not influence the result. This is to prevent bias that would result from having a default of yes or no. Obviously all stakeholders are encouraged to vote, but just like not everyone votes in elections, it isn't very likely everyone will vote on every agenda in Decred either. Without an abstain mechanism, those non-voters would unfairly influence the results in one way or another depending on the default. Votes are not cast until a ticket wins. This is already the case today where the software is voting on the validity of the previous block when your ticket wins. It is the vote that is earning the reward, not the ticket. That is why you don't get a reward if you miss your winning ticket notification and fail to vote. Also, there is no way to predict what voting agendas will be active when a ticket wins at the time of a ticket purchase, so it wouldn't be reasonable to include a vote at that time.
Good question, we've already given this some consideration. We will have hard fork voting working for the 0.8.0 release, but that will not include a nice GUI or a list of issues to vote on. There will be a working demo configuration for this on simnet and we will begin publicly test hard fork voting on testnet immediately after the 0.8.0 release. Between 0.8.0 and the next release, we will add GUIs for setting votebits in Paymetheus, decrediton and stake pools, in addition to putting several changes up for vote for the next stake version. This way, even GUI-only users will be able to set their voting preferences with ease.
Are the pools going to be updated with controls to allow this? I dont recall seeing how you vote from the pool. Only the solo PoS has been discussed?!?
Yes, there have to be some additions to be done in stakepool, too! There will be a new api added to the stakepool with which paymatheus can communicate with the stakepool. This feature will enable the user to automatically register and activate stakepool from the gui.wallet with a few clicks. Also the process of voting will be configurable trough the gui.wallet and communicate this trough the api. Of course there have to be new functions in the user-frontend on the stakepool web.page. We can expect those additions when votebits will be implemented to the daemons and gui.wallets (?v0.9 / v1.0?)
From my earlier post: "Between 0.8.0 and the next release, we will add GUIs for setting votebits in Paymetheus, decrediton *and stake pools*, in addition to putting several changes up for vote for the next stake version."