Closed dckc closed 3 years ago
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.
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}}}
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
wrong button :-/
@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: https://github.com/zsluedem/transaction-server/pull/3 https://github.com/rchain-community/transaction-server/tree/api-doc
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
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
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
I started sketching test cases in a shared spreadsheet:
@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.
The tallying doesn't (yet) check that the deployer / signer = the voter, does it?
ah... if the transaction succeeded, then the RevVault contract guarantees that the sender was the signer.
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.
LGM prefers SQL to js for 2nd impl
sketch...
fetch transactions from index server (unfortunately trusted)
SQL
fetch, put on chain
rholang
wish: index server that stuffs into sql
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 https://github.com/rchain/rvote/issues/8 .
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?