Staked Poll on Zcash Dev Fund Debate

Awesome idea. Stake voting using signatures was possible from the command line but inconvenient every other way, and left open how to post the signed messages anyway… But this process works the same way and can be done entirely through zecwallet today.

We can give some examples later of how to format them unambiguously, like to vote for/against as many zips as possible in a single memo.

I’d suggest using a different key from the z2z one. It wasn’t hard to generate/use the incoming view key w/ the _bmlis zcashd code, we could just do it again for here


Andrew, so that we don’t have to transfer keys around, would you be willing to host the z-address for this poll? (If you’re too busy, I get it.)

And if so, would you be able to do programming magic to put all the results in a spreadsheet? That would make tabulating the votes much easier.

Agree re: voting syntax, I’ll follow ZF’s lead there. Single memo is definitely ideal and I think eminently doable.


Sure. I can set something up pretty easily that should get us far enough. I may DM you to iterate a bit.


in a perfect world.

in a real world this could generate an additional explicit signal what significant money, parked in zcash think about zips without/prior to price movements. i think opinion of top10 zec richlist has… at least non less impact on zcash future, then all current debates of vocal part of community.)


It’ll be an interesting signal, thats for sure.

Worth doing just to see how it compares, big holders have had hard times & thats a real test of loyalty.


OK so… here’s a prototype:

  • Stake Poll Z-Address:
    To vote, send a T->Z transaction to the Stake Poll Z-Address from your own fresh T address, with a memo containing your “Vote” message. Since you need to keep the balance on the T-address at the time the poll closes, you can’t just let it send change to a fresh address - you need to actually add multiple recipients, one of which is back to the same T-address. Illustrated example below: [1]
  • Hourly-updated view of the votes received so far, as well as the current balance of each t-address:
  • Incoming viewing key:
    Anyone can follow along with the voting process, but you’d need to run the work-in-progress code on sapling viewing keys here:
  • TODO: Lots of caveats: Later on we’ll have to write some guidance on how to format your vote memo so we can automatically parse it. As long as there aren’t too many votes, we can look over them manually to try to interpret them the best way we can. The view right now doesn’t make it clear how to interpret “multiple” votes from the same T-addr. I’m sure you can find edge cases, like sending a voting transaction from Z-addr or multiple T-addrs etc. Since the google spreadsheets view above isn’t curated, I’ll probably have to turn it off as soon as someone griefs it / files an abuse complaint, who knows.

Basically this is a lot like the t2z version of the z2z message board, but automated, with no curation, and a current balance summary.

[1] Screenshot of how to vote with Z-wallet by sending a “max available” change back to your T address, and a 0-value transaction with memo to the Stake Poll address:


AFAICT the only parts of the above mechanism that matter from a polling perspective are:

  • The voting transaction MUST contain a zero-value shielded output to the poll z-address.
  • The voting transaction MUST be mined between September 3 and September 15 (UTC).
  • The voting transaction MUST contain at least one transparent output.
  • The stake of the voting transaction is the sum of the voting transaction’s transparent outputs that remain unspent by the end of September 18 (UTC).

Thus it seems that a simpler polling mechanism would be:

  1. Create a new transparent address with getnewaddress
  2. Create a transaction with two outputs:
    • A zero-value shielded output to the poll address, with a memo containing the vote.
    • An transparent output to the transparent address created in (1), with value equal to the desired stake.
  3. Do not spend from the transparent address created in (1) until after September 18 (UTC).

This avoids the need for two transactions (doing Z->T and then T->(Z, T) provides no additional benefit to the poll over Z->(Z, T) AFAICT), and allows improved privacy by enabling respondents to vote from a shielded address.


Interesting. This approach is more UTXO-based than address based, since it’s just the utxo of the vote transaction that must be unspent, not the overall balance of the address. If you indeed generate a fresh address for this vote then it is just as good.
But the original way gives some more flexibility:

  • If you choose, you could use an existing t address
  • you could vote first with a small amount, and then add more stake by sending more coins to your address
  • you can keep using / spending from your t address if you need to without revoting, just make sure to keep the balance at the T-address as high as you can before the poll closes

Edit: thinking more… I can imagine scenarios where this UTXO version this lets you vote on behalf of someone else, e.g. an exchange, by basically sending coins to their T-address, hoping they credit your account and letting you withdraw from some other UTXO. Fundamentally the problem is, the vote wouldn’t have been authorized by the recipient of the UTXO


Afaik viewing keys aren’t supported in ZecWallet yet - and again, even by command line, for now it’s only available from some unreviewed/unmerged rpc calls. But I wouldn’t be surprised if this experiment spurs on some support for developing viewing keys.


@str4d, am I correct in assuming that there’s no way we can enable people to do what you describe through ZecWallet soon enough for this poll?


Unless I am misunderstanding something this is already possible with ZecWallet. What would be helpful is a way to format the memo with some sort of UI to indicate preferences.

1 Like

Yep, what I described should be doable through ZecWallet.

This isn’t how I read your post (you referred to a “fresh t-address”). But if you want this kind of flexibility then sure, you could define poll stake as being tied to the addresses defined by the transparent outputs in the voting transaction.

1 Like

Concept ACK to this (@sonya’s original suggestion) being a reasonably secure way to do voting using existing protocol mechanisms.

There are three options for what to do with the viewing key.

  1. Keep the viewing key secret. Note that the poll is then not end-to-end verifiable. We would be trusting the holder of the viewing key for the poll address to correctly tally results.

  2. Keep the viewing key secret and then reveal it at the end of the poll. That would have privacy implications for the voters (even if they used shielding as recommended, it links the vote to the IP address that submits the voting transaction). We are trusting the holder of that viewing key not to make adverse use of early results. They could also choose not to reveal the viewing key based on the results (at the cost of some reputational damage).

  3. Make the viewing key public from the start. Same IP address linking consequence for voters, and anyone can see early results (which is usually considered undesirable in election protocols).

I’m not sure precisely which of these was intended; maybe 3?

Arguably these issues are not be too much of a problem for this particular poll, but that’s a matter of opinion. I can’t immediately think of a better approach that is practical in the relevant timescale.


Seeing as this option provides the same security concerns as option 3 - couldn’t you publish the sha256sum of the view key with a short message, then pgp sign the hashed value message and publish it. then release the actual plain text of the message the end of the vote so we can verify it is the correct view key. This would mitigate the results being seen as the vote takes place. (the problem with option 3.)

It enforces legitimacy with option 2. although it does not stop the owner making use of the key. but it will highlight that they did this when the key is released. - because they pgp signed the message so they are the only person who knows the plaintext.

How about the view key is shared with ZFnd & ECC only instead of being published?

You could then don your respective zip editor hats, tabulate results, validate & publish together.

We would obviously need a photo posted of our editors wearing those hats :wink:


Note that it’s possible to reliably tell whether a viewing key corresponds to a given address, so there’s no risk that the viewing key holder could release the wrong one without detection.


The entity making the vote is by definition the sender, not the recipient. It is the sender that authorizes the vote by moving their funds into a transparent UTXO. The owner of the recipient address should not be assumed to be the voter (per the above design, it is supposed to be a transient address anyway).

If the sender attempts to make a vote in the same transaction as they send funds to another entity’s t-address, then the recipient either 1) does not move the funds within the window, in which case the sender’s vote stands, or 2) does move the funds, in which case they have invalidated the sender’s vote. In either case, by moving funds to another entity in their voting transaction, in such a way as it is indistinguishable from the staking operation, the sender is giving up the ability for their vote to be guaranteed.


@amiller explained what he was trying to get at with my proposal: it doesn’t prove that the sender has knowledge of the private key for the recipient t-address. This is a valid problem, and it’s one that was being addressed in the original proposal indirectly, as a side-effect of creating two transactions.

The way I would address this in my proposal, is to sign the vote message with the newly-generated t-address, and then place the vote + signature into the memo field. This retains the single-transaction property, while sufficiently binding the recipient address to the vote.

1 Like

In the case where the recipient does not move the funds, the sender gains an advantage relative to every honest voter, because it has the thing that the funds paid for. For example, it could in principle send the funds to an exchange (decentralized or not), in exchange for another token which it exchanges for ZEC, and then vote again with essentially the same money (minus exchange fees / inefficiency).

The original protocol by @sonya doesn’t have this problem, and IMHO should be used in preference.


Yep, this is a completely valid point, and what @amiller was getting at. I was thrown off by “the vote wouldn’t have been authorized by the recipient of the UTXO”, which I read as meaning that the recipient address couldn’t control whether it receives funds. This is obviously impossible to control for any address that has been made public, and my point was that it shouldn’t ever be assumed that a recipient agrees with a transaction that it is an output of. But this was beside the point of the actual adversarial condition, which is essentially a cross-protocol attack (between the voting protocol and the exchange redemption process).