Staked Poll on Zcash Dev Fund Debate

That is interesting, perhaps could be tied to the device more safely but even then it’s different versions of the same issues, hmmm :thinking:

1 Like

Heres a thought on incentivizing minimum stake, the whats and hows idk its late im going to bed soon
The stake for a vote is
A. timelocked a long time
B. has a high liklihood of not being returned in its entirety
C. in jeopardy of being lost entirely
D. by the collective actions of the voting body and not just the individual voter

For example let’s say there’s a hundred voters and they all have to stake at least one zcash for 4 years in an address perhaps to defined in the protocol that no one person really controls ya know
Let’s say one of your fellow voters gets antsy and the best they can do is request a reduction in the time lock which also reduces the amount of stake returned to everybody in the end including yourself
It introduces accountability and commitment, if you’re serious about it then you’re serious about it and what’s the difference if you don’t get any of it back, however if you’re not then it really doesn’t make any sense at all to participate
( I don’t like the idea of this, it seems like a pay to vote thing but thinking about the future, outside the box :grimacing:)
Perhaps in the spirit of things each request for timelock reduction halves the pot
Without identity its almost gotta be like seriously play-for-keeps, its all so flawed!

1 Like

Returning to the utility of zcash as a way and not just coins, I’ll say my suggestion: Create a website on which registration takes place through a wallet, with a certain number of coins per voice blocked for a specified period. Next, we make a vote either open or closed with its advantages and disadvantages, I am for closed and blocking coins by default. How to get rid of the situation when one user has several wallets and therefore he can vote several times, but no way, more votes, more coins in the block.Yes, whales can vote for so many users, but how to put it into practice is by no means very difficult, well, no one will create 100 copies of wallets for voting, it’s difficult just technically, so if the community has many members, this method will have a small general error, ideally this method can be implemented through a wallet, without registering on the site, but then it is difficult to convey information on the vote.

Timelocks make it interesting, especially long ones, say 6 months or maybe synced to the NU cycles.

4 Likes

I prefer the name “petition”, because that evokes the permissionless or self-initiated quality of it. This encourages experimenting with the format and policy, rather than it needing to come from an authority. So I hope we keep these qualities whatever we try.

I agree with @tromer’s trilemma. Although this thread is about coin-weighted and permissionless petitions, I don’t think this has to be plutocratic, especially if it’s just one signal in the overall decision input. With some kind of stake polling mechanism, we’d have some input mechanism from roughly all three corners.

Those users just passing through ZEC to make transactions may not be affected much by price. But those who are “long zec” are affected by each other in the market. So, as with miners, it makes sense to provide them some voice mechanism. Maybe it should only be weighted heavily if the turnout represents a significant fraction of the overall supply of coins.

We should make this voice mechanism iteratively better, turnout% being an important metric. It would be nice to take a gradual path towards a futarchy mechanism like in Vitalik’s post collusion.html, but I think that would ultimately need a defi science project. The use of futarchy or coin petitions here is not so much like the counterexample in Vitalik’s post, where it’s overextended for automatic curation of permissionlessly-created proposals, so I think we should keep some experiment open.

Another shortish term, less sciencey, but still difficult step is to ask exchanges or custodians to participate in some such mechanism and ideally extend the option of choosing or delegating to their users. These are whales and yet also likely to comprise a large number of users.

3 Likes

In the spirit of moonshot design, here’s a question about the desired functionality of coin-holding-time-weighted voting (critique aside).

The straightforward way to measure coin holding time is: how long have the coins been untouched as of the cutoff time. Or more technically: how long ago has each (unspent) note been created.

(I’ll be talking about Zcash notes. This is all true for Bitcoin-style UTOXs too, but we want privacy, so let’s focus on a shielded design.)

The problem is that measured this way, holding time is reset when funds are moved within a user’s wallet or between their self-owned wallets. For example, all of the following may reset the user’s holding period:

  • making a payment, even a tiny one (that spends the note, even if sends most of the funds back to the same address)
  • moving funds from a wallet app to a better one
  • moving some funds from a hardware/cold wallet to phone app wallet, or vice versa
  • moving funds to a fresh wallet because the old one (or its backup) was compromised
  • merging notes for efficiency

This means that in order to achieve a large voting weight, voters needs need to be not merely “long ZEC” in their financial exposure (as proponents desire), but also effectively need to avoid using and securing their ZEC funds. That’s bad.

There is a mechanism that addresses this, by making it possible to move funds while annotating the transaction as sending-to-myself, meaning it does not reset the holding period. This can be done on-chain by privacy-preserving consensus rules. (I can elaborate, but let’s first see if want it.)

So when your wallet software sends change to itself, or when you make a transfer and check the box saying “sending to myself”, your holding period will be maintained. When you later cast a vote using these coins, its weight will be automatically computed according to the holding period going back to the last transfer that wasn’t marked as sending-to-myself.

Conversely, when you send funds to someone else, you leave the “sending to myself” box unchecked, and this causes the holding period to be reset, so the recipient doesn’t enjoy an extra weight to their future votes just because you happened to hold your coins for a long time.

Drawbacks:

  • This weakens fungibility. Coins are worth more, because of increased voting power, if they already have a long holding period and their owner is willing to mark them as “sending to myself” when selling them.
  • UX complexity: it’s another decision to make when sending funds, which complicates the UI and requires users’ attention and education.

There’s a compromise option, which automatically considers funds to be “sent to myself” if, and only if, they are sent and received by the same address. This covers the most common case: keeping the holding period of change (from a payment or fund transfer) that’s sent back to the original wallet. It doesn’t cover the other cases, involving multiple addresses owned by the same user.

What do you think? Which would you choose? Do you have a better idea?

Let me even make a straw poll:

How should coin-holding-time-weighted voting compute the holding period?

  • Reset the holding period whenever the wallet is used
         (more precisely: when a note is spent; see above)
  • Sending back change does not reset the holding period; anything else does
  • Allow manual “send-to-myself” which does not reset the holding period
  • I have an even better idea, and will post it below
  • Abstain/unsure

0 voters

3 Likes

The idea was written by me above.
In the wallet, select the number of coins for voting and force block them for transfer. While there is a blocking voice counted. Set a threshold for voice on the number of coins.

Coin-holding-time-weighted voting mechanisms are a bad design that is far too easy to manipulate. By making different coins have different amounts of voting weight, you’re creating the incentive for relatively simple types of collusion attack in which parties collude to make it appear that coins are not being spent, while actually spending them amongst each other.

Since there’s no technical mechanism that can completely prevent this form of attack, you’re basically stuck with it — and it becomes inevitable in the event that a specific election matters enough. On top of that you’re creating a whole batch of security issues and perverse incentives, as you mention in your post.

If we must do coin-stake-weighted voting, all coins should count equally. This isn’t perfect either, but eliminates a huge class of opportunities to game the system.

12 Likes

Like I said I’m just tossing ideas around here, shrug
Perhaps what I’m getting at is if the problem appears largely impossible then perhaps the solution is just crazy (kinda like the once only theorized zero knowledge proof, crazy)

1 Like

Happy Thanksgiving to US-oriented folks, and happy thursday in fall to everyone else. This post is an update on the unofficial, badly designed, thoroughly disavowed, and universally panned “Staked Poll on Zcash Dev Fund debate”.

As of this morning, the votes collected so far (subject to change) are:

  • 3278.492433 (t1RiPMkD…) (t1M69j4…) 1N2N3N4N5N6N7N8N9N10Y11N12N13N (tx1) (tx2)
    Yes on 10: Grand Compromise synthesis proposal, no to all else
  • 26.9998 t1HtjB8… 1N2N3A4N5N6N7N8Y9N10A11N12Y13Y (tx)
    That’s Yes on 8 fund ECC for 2 more years, 12 ecc/zfnd/grants, 13 keep it simple,
    Abstain on 3 20% spit, and 10,
    No on everything else
  • 0.15319907 t1J13Pa… 1n2n3n4n5n6n7n8n9n10n11n12n13Y
    “In other words, yes for Proposal 13: Keep It Simple, Zcashers (KISZ)”, no on everything else

Warning: anyone who participates in this cursed poll is actively contributing to a :warning::rotating_light: “disgusting privacy mess” :warning::rotating_light: If you too wish to participate and send your soul to privacy coin purgatory, you could always follow the instructions above, and put a ZEC balance on a t-address and send a t->z to the stake poll address with your vote in the memo field.

Since t-addresses are subject to on-chain analysis, and to make the privacy risks even more explicit here, we can scrutinize these just a bit. The t1J13Pa… address looks like it unshielded just to vote. On the other hand, both of these addresses t1RiPMkD… t1M69j4… look to me like they’re direct recipients of mining pool payouts. The t1HtjB8… is a few transactions away from mining pool payouts. I think this is interesting because it suggests that this stake polling mechanism may be used by miners to voice their inputs, even if the mining pools they join do not support it! Of course, the turnout so far is about %0.04 of the coins in circulation, so it’s impossible to draw any conclusion about this as a representative sample.

Disclaimer: Zcash Foundation has clearly indicated that this poll is not official, and although it could be considered as “other sentiment collection,” given the myriad problems with this form of poll discussed above, it should be interpreted with due skepticism. I’m the sole promoter of this poll survey, acting in my free time and not in any capacity related to Zcash Foundation. Stay tuned for the technical analysis and weather forecast.
Always blockchain responsibly.
~=z2z me=~

14 Likes

To the person who posted the 6000 Zec and the, as such, oxymoronically contrived religious quote

WTF is this supposed to mean? Hmm?

It means that you should try and be good because the real reward is not in this material world but in heaven above. It wasnt me LoL I have nowhere near that amount of ZEC.

1 Like

Well if that’s the point they’re trying to convey they kind of undermined it by staking $180,000 by today’s value worth of zcash
They obviously don’t really believe it

Thats the meaning of the quote from the Bible I didnt go into motivations why someone would post it.

1 Like

They could be rich but they could also sincerely believe in that Bible quote.

5 Likes

They could also have a lot more ZEC because the amount was obviously chosen to represent the verse.

1 Like

I just wish they’d also told us what ZIPs they’d support.

4 Likes

Well the only obvious number that stands out is 6 so proposal 6? And we dont have proposals 19 and 21.

I suppose you’re right but the message that comes across certainly isn’t supportive of it
Sending a message that they know is purposely disavowed by the foundation, backed by a fortune that literally says money isn’t everything in the form of a religious archetype? Uh uh sry

This whole thing is right out

I dont get any hostility from the message… Explain your thinking? I mean perhaps somebody just wanted to vote in a quirky way? Is there any other significance in the numbers?