Voting Update

Discussion in 'Announcements' started by moo1337, Jan 13, 2017.

  1. 2017/12/15 - Decred v1.1.2 released! → Release Notes  → Downloads
  1. moo1337

    moo1337 Moderator

    Jul 25, 2016
    80
    121
    Male
    Texas
    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?
     
    Tivra, drunkenmugsy, Dyrk and 3 others like this.
  2. sambiohazard

    sambiohazard Sr. Member

    Jan 21, 2016
    844
    372
    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

    1. allow voting on more than one proposal with a single command e.g.
      Code:
      $ dcrctl --wallet vote proposal1 yes, proposal2 no, ...
    2. 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.
     
    drunkenmugsy, adam2312 and jy-p like this.
  3. davecgh

    davecgh Hero Member
    Developer Organizer

    Dec 31, 2015
    642
    788
    Male
    United States
    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
    ...
    
     
    drunkenmugsy, adam2312 and 418Sec like this.
  4. davecgh

    davecgh Hero Member
    Developer Organizer

    Dec 31, 2015
    642
    788
    Male
    United States
    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.
     
    drunkenmugsy and sambiohazard like this.
  5. sambiohazard

    sambiohazard Sr. Member

    Jan 21, 2016
    844
    372
    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.
     
  6. adam2312

    adam2312 Jr. Member

    Jan 11, 2016
    118
    43
    Male
    Looks easy to me. Agreed with Sam would like to set multiple votes on one command.
     
  7. karamble

    karamble Member
    Developer

    Feb 19, 2016
    57
    71
    #7 karamble, Jan 13, 2017
    Last edited: Jan 16, 2017
    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' :D ?

    ----

    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!
     
    drunkenmugsy and jy-p like this.
  8. Shadowlance

    Shadowlance Full Member

    Jan 9, 2016
    219
    155
    Male
    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 :)
     
    jy-p and jinlei like this.
  9. davecgh

    davecgh Hero Member
    Developer Organizer

    Dec 31, 2015
    642
    788
    Male
    United States

    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.
     
    drunkenmugsy and jy-p like this.
  10. Alexoz

    Alexoz Member

    Thanks guys making it easy for lambda users!
     
  11. jy-p

    jy-p Sr. Member
    Organizer

    Jan 2, 2016
    133
    340
    Male
    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.
     
  12. drunkenmugsy

    drunkenmugsy Sr. Member
    Advocate (Reddit)

    Dec 28, 2015
    405
    218
    Male
    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?!?
     
  13. karamble

    karamble Member
    Developer

    Feb 19, 2016
    57
    71
    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?)
     
  14. jy-p

    jy-p Sr. Member
    Organizer

    Jan 2, 2016
    133
    340
    Male
    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."
     
    drunkenmugsy and Tivra like this.

Share This Page