Staked Poll on Zcash Dev Fund Debate

[sonya]

EDIT on 11/25/2019: This is not a Zcash Foundation thing. This is a thing that I, a person who works at ZF, proposed independently.

I am against plutocracy, so I think staked votes are generally a terrible way to make binding decisions. But they’re a great source of information. As far as I know, nobody else plans to hold a staked poll. I might as well do it, and @boxalex volunteered to help!

The poll will be open to anyone with ZEC.

ZF’s guidance noted that the Foundation “is happy to consider other forms of community feedback collected by other parties” between September 3 and September 17. (See the section “How the Foundation will select a particular proposal.”) So I’m going to use the same time period for this poll.

Why

Staked polls have the unique advantage: They can be both anonymous and sybil-resistant. Since votes are weighted by stake, splitting up ZEC to vote doesn’t change anything but appearances. You can’t change the outcome of a staked poll through sybil attacks. Instead, your only option is to use more ZEC to vote.

But we know that, so we know that we can only draw tentative conclusions from the distribution of vote stakes. (In other words, we cannot conclude that the number of votes = the number of people who voted.)

What

I’ll ask the same questions that ZF asks the Community Advisory Panel (still TBD), and a couple of additional ones. @boxalex had good suggestions.

How

This part is tricky. What do y’all think of this setup?

1. Between September 3 and September 15 (UTC), send your stake of ZEC to a t-address. (For optimal privacy, generate a new t-address and never use it again. Also, send your stake from a shielded address, then withdraw it back into the shielded pool after the poll is over.)

2. No later than September 15 (still UTC), send a shielded memo with your vote to [address redacted for now] from the t-address containing your stake.

3. Don’t move the ZEC until September 18.

I plan to use the same address as z2z Public Messages, since @amiller already generated a viewing key.

[amiller]

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

[sonya]

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.

[amiller]

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

[somedude]

@sonya

I am against plutocracy, so I think staked votes are generally a terrible way to make binding decisions.

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.)

[ChileBob]

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.

[amiller]

OK so… here’s a prototype:

• Stake Poll Z-Address:
  zs1ud5cyusgfsqgkfqlxery0ttyvuvj66wztlqgv8tc4qaukaeaejxj7u70j0qgcctjfvzuzadejxd
  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: https://docs.google.com/spreadsheets/d/e/2PACX-1vSGWZ7kk5-hl81-kpKLd_O1TNmW9LQvT2M-rpCr7ifCzBH9Aw8vuMC16M0Cdqa7S2xyQVtbNjnD3KJG/pubhtml
• Incoming viewing key:
  zivks1299ck2xdp6uh6uer8tfmp0a8q5fcsz4e4fmx5a6gtmr8a7trugqstarajr
  Anyone can follow along with the voting process, but you’d need to run the work-in-progress code on sapling viewing keys here: https://github.com/zcash/zcash/pull/3822
• 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:

[str4d]

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.

[amiller]

@str4d

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).

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

[amiller]

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.

[sonya]

@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?

[garethtdavies]

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.

[str4d]

Yep, what I described should be doable through ZecWallet.

@amiller

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

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.

[daira]

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.

[mistfpga]

@daira

2. Keep the viewing key secret and then reveal it at the end of the poll. That would have privacy implications for the voters

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.

[ChileBob]

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.

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

[daira]

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.

[str4d]

@amiller

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

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.

[str4d]

@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.

[daira]

@str4d

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.

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.