Welcome to the forum!
Yeah I didn’t say it was coming anytime soon, I’ve thought about it a lot and haven’t drawn much but blanks
Welcome to the forum!
If you are who we think you are the mods will prob bump your account to allow edits
Pre-emptive answer to security question: I most recently saw Zooko at a dinner in SF (Presidio) at the end of October, and there was a slightly awkward moment where he popped by beside me at exactly the time I was finishing the sentence (roughly) “meals with zero vegetable content literally make my stomach sick”. We were later all asked for a book that had an influence on us, and I replied The Elephant In The Brain.
What a an excellent post! I agree, and for the simple special case of coin-weighted voting, I recently likewise pointed out that it degenerates to pay-to-vote in the presence of lending markets. (Appended this link above, now.)
With Zcash governance, we’ve painted ourselves into a particularly difficult corner:
- The ethos of privacy/anonymity makes identity-based and permissioned approaches unsavory to this community.
- A big goal of the current Dev Fund discussion is to transcend the dependence on the established governance players (ECC and Zfnd). We can’t do governance by permissionless voting, for all of the above reasons, and we can’t use permissioned voting, because (by definition) the existing governance is not supposed to make the requisite discretionary calls. So there are many proposals that instead prescribe the creation of independent new governance committees to preside on or along the existing ones. But how shall those be populated? Well, you guessed it, election by coin-weighted voting is a popular suggestion…
Thus far, things have gravitated towards non-binding “sentiment collection”, which is interpreted by human beings (the Zcash Foundation and ECC) at their best discretion and under the watchful eyes of the community.
Welcome to the forums Vitalik
I have bumped your trust level to Member so you can edit your posts
Hey, V! Welcome to our forum!
Moderators: I can confirm that his story about the most recent time we saw each other checks out. (Also that this post is totally his style.)
Vitalik, you can vote in Community sentiment collection: Poll on NU4 dev fund ZIPs!, and I hope you do — just to increase the signal available to the community — even though only the votes of people who had an account more than six months ago are going to be counted by the Foundation (as an effective Sybil-resistance technique).
As to your post, I agree with Tromer that it is excellent, and I agree with you that there are promising ideas under development for identity systems that are “open” in some sense and censorship-resistant, but I also think that identity is overrated. We can do a lot of things just using public keys/addresses and local names—in which case we don’t need global names—and we can avoid a lot of the collective action problems that your post is about by minimizing the need for collective action.
Not that I think you yourself are mistakenly overrating the need for collective action, and therefore the need for identity, but I think most people are.
Anyway, there is a collective decision process going on here and now which, despite the daunting theoretical impossibilities is going very well. So go vote (in a non-binding signaling-only vote since you are too new to the forum to be automatically identified as a probable non-Sybil) if you want.
Oh, also you can vote in the coin-holders poll, which is also theoretically impossible to secure, but which I also expect is going to work fine in practice.
Random thought… (just throwing this out there for smarter minds than mine to play with)
How about combining signing an account/balance with a captcha?
Could a captcha validate you’re a ‘random human’ and not a ‘random human its already validated’, then produce a code to include in a signed message. Klunky, but interesting, depends on some central infrastructure run by someone so there’s that…
What is your definition of “collective action” here?
That is interesting, perhaps could be tied to the device more safely but even then it’s different versions of the same issues, hmmm
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 )
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!
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.
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.
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.
- 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
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.
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)
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 “disgusting privacy mess” 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.
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.