tallying votes - members, secretary, board

[dckc]

The secretary counts the votes (section II. 6 Voting) and majority rule etc. determines the outcome of each question.

How does this work? On chain in rholang? Off-chain? Is there a process for amendment?

How are the results communicated to the membership? Is there a process for appeal?

• index transactions
  • given a ballot, find all transactions to the addresses it contains
    • write transaction set to JSON file for use in various implementations tally in sql; start generative testing #101
    • send transaction set to RChain for use in rholang implementation postponed as tally in rholang #105
• initial prototype bash script
  • handle list of voters in bash
  • limit timestamp for valid votes in bash
• multiple implementations: port to js / py / sql
  • handle list of voters in sql
  • limit timestamp for valid votes - partly done; for follow-up, see start time limit for tally rchain/rvote#8
• port to rholang postponed as tally in rholang #105
• handle change from yes/no to abstain
• tally only the most recent yes/no/abstain vote in tally.sh
  • tally only the most recent yes/no/abstain vote in a second implementation (tally.sql)

[dckc]

I suppose this issue shouldn't presume zulip. We also have the "send dust to an address representing your choice" design (#29 from @leithaus).

In that design, votes are counted by an off-chain script, though I'm not aware that anyone has written such a script.

[dckc]

I worked out a detailed design at the ocap level, independent of zulip:
https://github.com/rchain-community/community/blob/ocap-review/Ballot.rho 9b29d4f

It supports multiple questions, each with a set of possible answers.

It doesn't compute winners, but it does "count the votes cast" in the sense of the Voting section of the bylaws.

{"votes" : {"President" : {"Douglas" : 1, "Lincoln" : 3}}}

[dckc]

In that ["send dust ..." (#29)] design, votes are counted by an off-chain script, though I'm not aware that anyone has written such a script.

The recent work by @zsluedem to show account histories in https://revdefine.io should help a lot.

@jimscarver took the ball on indexing testnet transactions with https://github.com/zsluedem/transaction-server

[dckc]

@jimscarver is working on a transaction service at http://rhobot.net:7070/api/total-supply
I started one at http://kc-strip.madmode.com:7070/docs

I started a couple PRs: zsluedem/transaction-server#3
https://github.com/rchain-community/transaction-server/tree/api-doc

[dckc]

An #rchat message at 2:51pm CT Sat 5 Sep 2020 tells us we can start our testnet scans at block 372418.

That's the block containing deploy with signature c4acf82c128361fbe7df590284034ec2a3f5696ced540b7d6493395a1acc6e7340c668fcbc44d18252cc22707ecc8149b8b4a8fee7cc0639e23608b2996e4e6d1b

[jimscarver]

I started a bash script to tally vote results. The yes votes are zero :(

#!/bin/bash
#usage: ./tally.sh [ballotfile] [transaction-server:port]
# https://github.com/rchain-community/rv2020/issues/35
# an account can vote only once for a choice.
# The case of a person voting for multiple choices is not handled.
# the check for the account being allowed to vote is not handled.
ballot=${1-ballotexample}
server=${2-kc-strip.madmode.com:7070}
 cat $ballot|jq -r '.|.[].shortDesc' >/tmp/shortDesc
 cat $ballot|jq -r '.|.[].yesAddr' >/tmp/yesAddr
 cat $ballot|jq -r '.|.[].noAddr' >/tmp/noAddr
lastblock=???????
 for n in $(seq $(wc -l </tmp/shortDesc)); do
         desc=$(sed -n ${n}p /tmp/shortDesc)
         yesAddr=$(sed -n ${n}p /tmp/yesAddr)
         noAddr=$(sed -n ${n}p /tmp/noAddr)
         echo  "$desc"
         yes=$(curl -s http://$server/api/transfer/$yesAddr|
                 jq '.[].fromAddr'|uniq|tee /tmp/yesVotes|wc -l)
         no=$(curl -s http://$server/api/transfer/$noAddr|
                jq '.[].fromAddr'|uniq|tee /tmp/noVotes|wc -l)
         echo  "  $yes yes votes $yesAddr";echo "  $no no votes $noAddr"
         double=$(cat /tmp/yesVotes /tmp/noVotes|sort|uniq -d)
         if [ "$double" != "" ]; then
                 echo ALERT: $double voted both yes and no.
         fi
done
rm /tmp/shortDesc /tmp/yesAddr /tmp/noAddr /tmp/yesVotes /tmp/noVotes

[dckc]

Can we have the list of voter rev addresses on chain, please? I'm interested to do tallying in rholang.

Rao asks about two different methods and cross-checking.

Do the transparency benefits outweigh the privacy risks? gov cttee seems supportive...

list should not go out until voting is closed, else people can do tallying while voting is open

[dckc]

I started sketching test cases in a shared spreadsheet:

• rv2020 tally test cases

@leithaus suggested "generative tests" for volume. That sounds like property testing, to me; in general that's an excellent approach, but I haven't given much thought to what the properties should be. @leithaus said generative testing is also useful just for volume of tests, even if they don't exercise special cases.

[dckc]

The tallying doesn't (yet) check that the deployer / signer = the voter, does it?

[dckc]

ah... if the transaction succeeded, then the RevVault contract guarantees that the sender was the signer.

[dckc]

I'm inclined to implement tallying in SQL. should take just a few lines.

Should make for a good rholang prototype, too.

Tallying in rholang requires copying the indexed transactions into the RhoVM. That's more motivation to separate gathering the transactions from the tallying algorithm.

[dckc]

LGM prefers SQL to js for 2nd impl

sketch...

1. fetch transactions from index server (unfortunately trusted)

2. SQL

3. fetch, put on chain

4. rholang

wish: index server that stuffs into sql

[dckc]

In today's meeting, we observed we have two implementations (tally.sh and tally.sql) with no outstanding critical issues.

Generative testing (#104) is still useful in due course. Rank order questions (#59 ) will involve a change to the tallying algorithm, but that's not in the near-term critical path.

@jimscarver noted tally.sh doesn't exclude votes before a start time (e.g. as part of a mock election) . The staff seem to be in position to manage that risk; see rchain#8 .