There are a variety of ways of getting community input on decisions to support off-chain or on-chain governance. Miner signals are often used in Bitcoin for example to reach agreement on soft-fork upgrades. Stakeholder votes are used in Tezos for analogous upgrades. The Zcash Foundation used a “community governance panel” election using Helios e-voting in 2018. There are several posts discussing ideas for how to adopt coinholder votes to Zcash 1112 219 that ideally allow voting directly from the Sapling shielded pool.
The point of this post is to discuss a more lightweight alternative that could potentially be used in the very near future with minimal coordination and additional software. Just use the signmessage and verifymessage feature which is already present in zcash-cli (carried over from bitcoin).
As an example:
- The address
t1Yvv2zdNdgyzy9v6a74SDNBToqEv9c4hDdcurrently has a balance of 1.0 ZEC - I signed a message
"VOTE https://forum.zcashcommunity.com/t/33864 YES"which indicates that the balance of this address casts a vote in favor of the miner-directed dev fund proposal described in the OP of that post - You can check the above with
./zcash-cli verifymessage t1Yvv2zdNdgyzy9v6a74SDNBToqEv9c4hDd HxwWO5iUPgFjt7neuFRwuEM7M/pS75TND4tVwNrpauNpfFQBC433ftdPMP13/aGT+Nhu429kGR9i5/gQs1KCUl4= "VOTE https://forum.zcashcommunity.com/t/33864 YES"
Petition vs Election
This approach is called a “petition” because it’s informal. Votes can be added gradually, and anyone can propose one, without much coordination needed up front. To make a conclusive statement about how many votes are for or against a given proposal at a given time, the main technical constraint is to make sure that coins aren’t double counted. You can change your vote at any time by moving your coins out of that address and into a different one. A petition that becomes popular could be upgraded to an “election” by taking a snapshot at a given blockheight. But, and this is a key difference to more sophisticated proposals, the snapshot doesn’t have to be determined in advance at all.
Collecting votes
In principle petition votes could be collected on-chain by building them into OP_RETURN or some other transaction metadata. An even lighter weight alternative would be just to post them to the forum, mailing list, or some other public space, and only use OP_RETURN as a censorship resistant alternative if necessary.
Encoding votes
There’s flexibility in how you encode the vote string, and this doesn’t need to be agreed on up front. This suggested template “VOTE [ZIP 1004] Dev fund proposal: Miner Directed Dev Fund (was: 20% to any combination of ECC, Zfnd, Parity, or "burn") YES” is meant to resemble http/url ideas, with VOTE being an action, a URL being self describing and hopefully unmabiguous (a hash would be better of course, posts can be edited), and YES/NO being clear binary choice.
If conflicting votes for the same topic and address are present, they should just be discarded.
Coinholder petitions support delegative democracy right out of the box, e.g. DELEGATE https://forum.zcashcommunity.com/t/33864 ZFND could indicate that you want to delegate your voice on this topic to whatever position the Zcash Foundation takes.
Downsides
There are tons of downsides of this kind of idea. One is that we’re trying to encourage more use of the shielded pool, so isn’t it counter productive to give people a reason to put more coins in t-addresses? A coinholder petition would be impactful the more ZEC gets behind it, but presumably the majority of the supply is in cold storage and wouldn’t want to casually access key material for this sort of thing.