Staked Poll on Zcash Dev Fund Debate

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

2 Likes

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

3 Likes

I still don’t fully understand the UTXO approach, and now I’m not clear on whether it’s better or not?

The poll schedule will shift to match ZF’s delay (announced today).

I’ll write a blog post with step-by-step instructions once the unknowns are worked out.

7 Likes

I think you should use the original protocol you proposed. It’s secure enough for this purpose and it doesn’t involve any operations that are not supported by commonly used wallets.

1 Like

I’m very uncomfortable with telling people to compromise their privacy in order to exercise their voting rights.

Requiring people to unshield funds is exactly that, especially given the lack of tooling to prevent trivial linkability by amount. Made worse by the above concerns about IP address linkability.

I also worry about the security-of-funds aspect. People using cold wallets would need to either move funds out of their cold wallet (taking a risk), fiddle with their cold wallet private key (taking a risk and lacking tooling), or forego voting using their full holding.

The conjunction of the two of pretty bad. I conjecture that many “serious” ZEC holders use cold wallets or shielded funds, for good reasons. If these are effectively excluded from the vote, it’s unclear what sample we’re getting.

This might still be acceptable as a one-time temporarily solution for an advisory vote, but it must not become a recurring or binding mechanism.

4 Likes

Let’s revisit the topic of stakeholder voting, now that several feedback mechanisms are under way for NU4. So far, we’re actively collecting inputs from a forum poll, a helios vote among the Community Advisory Panel, and even instructions to miners , all about approval voting over 13 zip proposals about a dev fund. Unfortunately so far, there’s been no instructions about how to vote if you’re a coinholder.

The good news is: the stakeholder polling mechanism initiated in this thread can be still be used to vote in the ongoing Q32019 community sentiment collection.

The instructions are simple enough:
To vote for NU4 dev fund proposals, put your stake in a t-address, and send a memo from that t-address to the stake polling address:
zs1ud5cyusgfsqgkfqlxery0ttyvuvj66wztlqgv8tc4qaukaeaejxj7u70j0qgcctjfvzuzadejxd

Encoding your vote: Follow the same convention as in the instructions to miners.
For each of the 13 proposals, give the number followed by the vote, Y/N/A (Yes/No/Abstain).
An example encoding is:
1Y2Y3N4N5Y6A7A8N9Y10N11N12Y13Y
which would be interpreted as "1 Yes, 2 Yes, 3 No, …7 Abstain,… 13 Yes’. So it’s approval voting on the 13 proposals.

Keep your coins in the same t-address. Your vote is weighted based on the amount of ZEC held in the t-address at the time we declare a cut-off time and count the votes. This can be fiddly, since by default Zecwallet sends change away from your original t-address and back to some different change address. If this happens, you can just send the balance back again to your original t-address.

Checking up on the votes: The original post includes an incoming view key, so that anyone running the viewing-key development branch of zcashd can follow along with the memos that have been sent.
I’m also providing a best-effort view of the current voting memos and current t-balances.

Privacy / unshielding concerns. Ideally this would be secret ballot, but the need to use t-addresses makes this tricky. If you just use an existing t-address, you should expect that your vote will be publicly linked to that t-address. If you are using a shielded address and want to participate, this is at your own risk, since it’s generally recommended for privacy your keep coins in the unshielded address. You could send ZEC from a z-address to a t-address, unshielding them just to vote, and send them back after the polling period ends.

6 Likes

I have some (additional) concerns here:

That’s enough information to make some votes unique. So if your vote becomes known elsewhere (e.g. because you publishes your preferences, or you only support your own proposal, or you voted on the forum and that gets compromised), then you’ve effectively broadcast how much ZEC you hold (or at least a lower bound on that).

Also, there are ZEC lending markets, meaning this balance-snapshot vote can be grossly manipulated very cheaply.

2 Likes

Super cool! Any idea when the cutoff and count-the-votes date will be?

Are the results weighted (i.e. there’s 65 ZEC behind proposal x) , or is it based on the number of votes (i.e. proposal x was voted for 23 times)?

:man_shrugging: no idea

IMO weighted by ZEC is the only interpretation that makes sense here, because it’s pretty trivial to split into multiple t-addresses and vote multiple times

4 Likes

How a sudden, 5 days bevor the official voting ends, another mechanism is added?

I can’t find anything about this mechanism in the community sentiment collection ZF announcement:

If these votes would be accepted this would raise a lot of other questions as well:

  • Is the ECC, ZF using their funds for voting with a staked poll?
  • Are others that are on the forum and advisory panel voting eligable to vote with the stake poll as well?
  • Miners are unable to vote because there is no mining poolo participating, but a sudden stake holders are able to vote instead, seriously?

There are a lot more concerns and honestly, this sudden adding of a staked poll some days bevor voting end is of highest concern in my opinion.

2 Likes

This thread is from August ^. The point is that miners and stakeholders both have ways they could signal their support for/against any proposals, without requiring any support or invitation from Zfnd or anyone else.

This is up for each org to answer, my guess is “No”, but clearly nothing about the stake poll itself would indicate clearly where the un-attributed votes came from

We couldn’t stop them if we wanted so I think yes.

I think miners and stakeholders are in the same boat here. You could vote if you do it yourself, but if you’re delegating to pools/exchanges to mine/stake for you, it’s up to what they support.

4 Likes

Excellent !!! More polling signal :slight_smile:

Its going to be interesting to see results from different groups.

3 Likes

I’d love to see some kind of on-chain voting incorporated as an extra signal. I even included it in my proposal as something to be developed. However, this needs to be done properly. The details need to be worked out, the risks addressed, the parameters nailed down, and the instructions properly announced. Maybe even requisite technology developed to solve problems.

This isn’t the case here yet, so I strongly advise against giving any weight to this on-chain polling as a signal, for now. The results will be completely dominated by whether potential participants even hear of this just-now-suggested vote, their risk tolerance for the privacy risks, and their access to their wallets on the yet-to-be-determined-but-probably-short schedule.

Put otherwise: the results may be easily dominated by one or two ZEC holders, who happen to read this thread, and don’t appreciate the risks to funds or privacy. In my estimate this is fairly likely to happen, and even in hindsight we won’t even be able to tell whether this was the case.

Worse yet, any attempt to judge the validity of the poll after it concludes may be seen as picking and choosing signals to support an agenda. So it’s important for Zfnd to pre-commit to what polling signals are valid before their results are known.

Indeed, this thread has been open for 3 months. Thanks, @amiller, for proactively raising the possibility of coin-weighted voting! Unfortunately, the details have not been finalized in time (e.g., the voting format was suggested just today, and no one knows the dates when the staking balance needs to be maintained). Also and crucially, it’s not on the Zcash Dev Fund Community Sentiment Collection Poll announcement.

7 Likes

Why all this? Who will be and most importantly how to deal with the calculation of mood if through the different voting systems one and the same people can vote. It seems that any vote has no effect on the final decision. It was much simpler just to accept what you want yourself, without pseudo-democratic voting, especially since 100 people who voted can not be called a community in any case.

1 Like

This stakeholder poll was not announced, not confirmed, not worked out, not anything. I had concerns allready with miner signalling that someone can rent hashpower just for voting but with a staked poll i have way more concerns including that someone can just buy/loan temporary ZEC and vote.

This is another concern. On the advisory panel and forum we have named voting, everybody stands with his name behind his vote which ensures even avoiding double voting. For both, advisory panel and forum members, there have been several restrictions, but for a stake holder poll there are literally none. No registration, no name, no anything needed.

This alone should be a concern but it’s of course not the biggest one.

Totally agree with this. It will raise a shitstorm and i admit i’am a bit shocked that this idea which sounds allready like a finished fact comes from a ZF board member.

Again, totally agree, there a 5-6 days left only for signalling and the staked polling was NOT announced so far. It would take even some days to announce it additionally leaving it just with 2-3 days for signalling and it would still mean that stake holders may not be aware of it until the end of voting. Having a different time or end line for signalling should be another No-Go anyway as this could easyly be seen as a try to manipulate the outcome of the other poll options in my opinion.

I would even add that the reputation of the ZF is in danger and could be questioned if the staked polling a sudden is added out of nothing.

1 Like

Nice, Zooko and the ECC allready animate their followers to stake vote on twitter, he is not wasting any time, lol.

You guys are really good in taking away the last faith someone can have into Zcash governance, transparency, community participation and fairness, amazing.

Edit: amiller and Sonya as well spreading it for the ZF as it seems, nice:

This voting mechanism seems like a very unsafe idea with many of the same problems and risks that the earlier transparent migration process had. Hoping that users understand the risks associated with interacting with the transparent pool, and correctly apply mitigations appropriate to them, is not a good idea. It wasn’t a good idea during the transparent migration (when safe standardized tools were not made widely available), and it seems an equally not-good idea now.

2 Likes