Developing a better voting procedure for personnel votes

Do you think votes should be secret for staff roles?

  • yes

    Votes: 6 75.0%
  • no

    Votes: 1 12.5%
  • undecided

    Votes: 1 12.5%

  • Total voters
    8

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
As we go into our first elections for a new Secretary for BU, I long for a voting system which would allow members to vote privately.

Voting for/against people filling certain roles is a different matter than voting on technical issues.
No-one wants to damage relationships, nor have their votes held against them later in personal matters.

To avoid all that, I'd be very happy if we could come up with a design (to be proposed as a BUIP) which would enable us to hold such personnel-related elections in a more privacy-preserving manner, i.e. secret votes.

I still have to think about how without making it terribly complex, but I think there's a lot smarter folks than me around here who may have some ideas.

My requirements shortlist for such an adequate voting system:
  • no-one else (except perhaps the Secretary) can tell who you voted for (better of course if no-one else can at all)
  • the tally is public and unforgeable
  • everyone can verify their own votes have been processed correctly
  • fraud proof without revealing one's actual vote
Of course this should all base on our BU signing keys plus perhaps some additional tokens.
I'll put some design ideas in here once I've wrapped my head around them (too busy with other things at the moment).

But I'm interested to hear your thoughts on this!

---
Related reading:

http://www.instore.gr/evote/evote_end/htm/3public/doc3/public/aegean/paper4.pdf
http://www.cs.jhu.edu/~rubin/courses/sp03/group-reports/group4/group4_requirements.pdf
https://en.wikipedia.org/wiki/Electronic_voting
 

digitsu

Member
Jan 5, 2016
63
149
I think much of the requirements you listed are already there with voting tokens over Counterparty (or presumably any other colored coin implementation, but CP happens to be one with many tools already developed for this purpose)

see
https://blockscan.com/vote/XCPELECTION2016
https://blockscan.com/vote/PJMJS48M4F

and
http://counterparty.io/docs/voting_with_tokens/

We can make it so that the secretary is in charge of issuing the tokens for each BUIP, distributing out to the members accounts. Then members can vote by sending their token vote to the publicy announced addresses for each voting outcome (which is also broadcast via the blockchain). The only work to make it completely 'seamless' for BU members is to bake counterwallet.io into our BU website (simple given APIs are available) or just provide a link to that on the BU site itself. As you can see in the links blockscan.com already provides a real-time voting results interface. CP votes can be time limited by stating until which block the votes are valid. (we can therefore implement the 5 day limit on voting subject to the accuracy of the blocks /day produced.)

This is something that doesn't require too much dev commitment, and takes a lot of admin out of the job of running the voting system.

BTW creating a counterparty wallet takes practically _no time_ at all. just go to https://wallet.counterwallet.io/ and click "create new wallet". Write down your 12 word passphrase. save it! then in any wallet implementation you can just enter this phrase to access your address.

As we already have members submitting their own Membership addresses, we would need to have people create a 'voting account' once and let the Voting Administrator know the address to member mapping. Conversely this new address can be used as the new signing key for all BUIPs going forward. (though extracting the private key from the passphrase may require some wizardry)

An additional plus is that alphanumeric token IDs are free to issue in CP. So we can adopt a naming convention that makes it easy for people to know what voting for, ex BUVOTEBUIPXXX token.
 
Last edited:

digitsu

Member
Jan 5, 2016
63
149
The issue with the current voting for office is that a ballot (assuming 3 candidates) for VOTE, yes, yes is pretty much the same as just 1 vote for candidate A, and a ballot of yes, yes, yes is the same as ABSTAIN. (counts for quorum, and not really a vote). In a public ballot nobody would ever vote a 'no' for fear of repercussions, and also a ballot by the President or other elected official will be seen as an unofficial endorsement, which is also unfair and would bias the voters.
 
  • Like
Reactions: freetrader

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
I'm not familiar enough with Counterparty, but it sounds intriguing. Thanks for the suggestion!
I'm assuming the votes do somehow end up registered on the Bitcoin blockchain that way?
 

digitsu

Member
Jan 5, 2016
63
149
yes, all votes are actually just tokens sent to a vote "outcome" address (normally a burn address so that it cannot be fugmangled by evil gremlins). That way the whole voting process is transparent, the number of votes provably countable, and (blockchainers fav buzzword) IMMUTABLE!

It would be really cool if our own governance process was dependant on the Bitcoin blockchain itself.
That way if the webpage is ever down or the forums wiped clean by men in black, the BU bylaws are still there.
 
Last edited:

digitsu

Member
Jan 5, 2016
63
149
ptschip
i'm also onboard for a private voting system. I think we should also at some point re-visit the idea of what a quorum means, or how we calculate that value. Should we only include members that have been active for the last year (or some amount of time)? Not sure how we would figure that out but I can see in the future where we lose members, they move on to something else, pass away, or for whatever reason are no longer involved. Then , over time, we will have a harder and harder time reaching our quorums. There needs to be a weeding out process at some point.

if we do votes by way of tokens, then we can simply send voting tokens to user who have voted in previous BUIPs. if you have not voted on a BUIP within a year, then don’t send new voting tokens to them for future unless manually reset. all this is easy when all past elections and votes are on blockchain
if we do votes by way of tokens, then we can simply send voting tokens to user who have voted in previous BUIPs. if you have not voted on a BUIP within a year, then don’t send new voting tokens to them for future unless manually reset. all this is easy when all past elections and votes are on blockchain

[2:41]
this can be scripted and automated.