Just do stake weighted voting
The problem with stake weighted voting, if you’re trying to incentivize participation by smaller players, is that its tilted towards whales. You also lose the powerful “contribute 0.1 ZEC, get matched 5 ZEC” psychology that QF provides.
The proposal is to have an anti-sybil mechanism. Did you see post above on how we do anti sybil in Gitcoin Grants now? Do you think that approach would not work on Gitcoin Grants for Zcash?
they are complimentary, not competitive. you can participate in both.
Nathan, I’m waiting until the end, which as you suggested, will be easier to track.
@owocki We appear to be talking past each other.
I’m aware of the problems with stake weighted voting and what quadratic voting wants to solve.
The issue is I don’t think you are going to find a sybil protection mechanism that is compatible with an anonymous cryptocurrency. The entire thing that makes zcash special is its about privacy. Don’t get me wrong, I’m all for trying to figure one out and totally willing to help. But IMHO, that’s harder than designing zcash itself.
Suppose you had an anti sybil mechanism that worked well: why not just let people vote with that instead of money? There are two answers. One is you like voting with money provided you avoid the whale problem. The second answer is because none of the mechanisms actually work well enough to trust alone. So you’re relying on money + the specific sms/KYC/w/e as the anti sybil mechanism Maybe in a transparent system, they work well enough and you can detect failures. It doesn’t in zcash.
It is possible not to completely solve the problem with whale voices, but to minimize it as much as possible without violating anonymity, it is enough to make a vote with the greatest complication to repeat the vote, for example, during the voting process, you need to fill out a form manually, if you exclude the automation option, then the threat of voice repetition through the separation of funds will be reduced to a minimum, add blocking of funds or lifting the balance at the time of voting and get a minimum of double vote violations.
By increasing the threshold for voting by the number of votes (for example, 1,500 instead of any), this gives an additional reduction in the influence of a double vote on the overall picture. A set of measures will give a working system.
Python scripts are pretty easy to write. You can of course throw captcha’s up, but I can just answer those myself or pay people to do it on mturk. Ok, so now you start doing KYC or SMS auth. First, thats a major privacy issue. Second, its a trusted party, third it’s also readily gmeable with money. Phone numbers cost like 10 cents to get. You really cannot readily stop automated vote submission. And indeed, this was precisely why you vote with money: it makes there be some cost to spamming votes.
Disagree with you 1) The filling form can go in free order every time, you can automatically fill it out, but writing a recognition for the answers and the answers themselves are not so difficult, I would even make the field fit after entering the site to get the code (anonymous but by ip) in which you can see the region, which will further limit the possibility of obtaining votes from one place. At the same time, by setting the threshold for voting as well as the percentage for the voting thresholds, you can minimize double votes so much that they will not play any role, make a voting period, for example, 1 day. If you need 5 minutes to get a vote (timer to get the code from the website)
As a result, we get a system that can be circumvented, but it is so difficult and without any guarantee that animating with this does not make sense.
I only understand this concern if we were talking about some change to Zcash base layer or core governance/funding. In that case I would definitely share those concerns.
My expectation for this experiment is to see pragmatic iteration and experimentation, and it doesn’t alter Zcash protocol, governance, or core funding structure. If Gitcoin QF grew to a massive scale, for example proportional to the Major Grants funding, then those concerns should grow proportionally, and even then only if the matching pools are coming from a community Dev Fund (such as MG grants).
It’s always been the Zcash approach to use a bunch of pragmatic, best effort ways to address the same underlying problem in different contexts: the community governance panel, US Corporations with employees+boards, and so on.
None of those are perfect by a long shot. They exclude pseudonymous contributors. They limit who can receive dev funding due to constraints on the legal entities, etc… But, they work well enough for Zcash today. So long as we keep iterating to make them more robust that’s good enough.
We haven’t adopted PoS yet or implemented on-chain governance precisely because we protect the base layer while we experiment on other layers (like the human layer).
Down the road, if we find better on-chain governance or funding that allows participants to retain privacy and do not compromise permissionlessness, then let’s start up those experiments, too, and if they demonstrate success, we may adopt them into the core of Zcash governance or prototocol.
Quadratic voting is the opposite of this approach. Suppose we had a sybil prevention mechanism. For this to work, it would have to reliably detect multiple voter registrations by the same person. But if we had that, why not do normal voting?
An accurate summary of quadratic voting:
Problem: we can’t find out who is a real person to do voting.
Solution: vote with money.
Problem: Well that’s a plutocracy and looks bad.
Solution: “find out who is a real person”
How is there a middle ground where 1) we have enough KYC to prevent quadratic voting ballot stuffing 2) it isn’t good enough for actual voting?
Because by requiring donations from the participants we measure how much it matters to them with skin in the game. That feels quite different from voting on how to allocate someone else’s money. A cleverness of QF is by providing a middle ground between “just vote how to spend someone else’s money” versus “pure individual donations”.
BTW, I’m not convinced QF is the best middle ground. I have two big concerns:
First, Sybil vulnerability, under-the-table-kickbacks, and all of that kind of gaming.
But second, imagine all such gaming is perfectly protected against. From what I hear QF is a solution to “funding public goods”. My second issue is: how do you know if any given proposal is a ‘public good’ or not. Maybe most proposals are a mixture. Or maybe we should be funding non ‘public goods’ too.
In any case, I’m totally comfortable experimenting through iterations with Gitcoin QF and learning from it, especially in a way that’s totally opt-in and isn’t part of Zcash protocol or governance. If anything we should be doing dozens of funding experiments even if they have various flaws to be learning as quickly as possible.
BTW- check out this twitter thread were I’m speculating that Rational Street Performers protocol might be a good way to do crowd-funding that may work well without Sybil vulnerability: x.com 
I’m worried about a bigger risk: mission creep. Or actually figleaf creep
Your point about skin in the game is good and for a way of allocating a small amount of funds, the risk of being manipulated by big pocketed interests is maybe acceptable. But why would it stop at small amounts?
We both agree quadratic voting has a sybil problem.
We both agree if you could fix it well, you could just do normal voting using the sybil prevention.
The “quadratic” part of quadratic voting is a fig leaf over these issues which lets people not grapple with them. This sets it up to be used with more and more important things in zcash. And because people forgot it was a figleaf covering up how manipulatable it is, they won’t grapple with the problems.
Hence my point, we should ditch the quadratic part and be open about the faults.
Huh? No.
I probably would not support ‘normal voting’ on other peoples funds over the long term / big picture.
I would support donation matching where the weight of contributions depends on how much skin in the game someone is bringing to the table.
I’m not super confident in this kind of ranking, but here’s my preference for how to allocate funds in the long term:
Best: some kind of skin-in-the-game w/ game-theoretic matching benefits with very low Sybil attack vulnerability. (If the game-theoretic aspects were convincing enough.)
Second: some kind of skin-in-the-game w/ game-theoretic matching benefits with more Sybil vulerability (ie: maybe Gitcoin QF)
Tie for Second: multiple independent centralized orgs allocating funds by decision of small expert boards that are elected by “some good election mechanism” (<- Note Sybil vulnerability!)
Third: ‘Classic’ crowdfunding.
Last: A large group of ‘users’ (somehow coherently defined) voting how to allocate a single pot of funds.
Tied for Last: No dev funding.
In the short term I think having 2 orgs centrally handing out funding, with adequate accountability, set up in a best effort at governance that attempts to capture most “stake-holder segments” is good enough.
Finally, I don’t feel super confident about any particular “solution” so I prefer to have multiple independent approaches. The issue there is that it can be difficult to know how to assess their relative performance, since Zcash itself provides a diffuse network effect to all participants. That’s yet another big problem to tackle.
How many non-matched ZEC have you received?
I heard through the grapevine that with matching we may be past the ~$15k USD threshold. I’m going to wait to the 16th then do one lump-sum matching donation.
So what should we do if we get more donations up through the 15th?
0 voters
Edit: Eh, this is my first poll and I may have screwed it up with this “trust level” thing. Ping @shawn or other moderators, any advice here? I’d like ‘everyone except trolls’ to be able to vote. (Also this is hilarious, given the discussion about QF, voting, and Sybil attacks elsewhere in this thread.)
So far we’ve raised ZEC 233.93703287 USD 12434.08. I’m told that DC has put in his matching funds, but I dont know if you have yet @nathan-at-least. So there should be at least 7k in funds that didnt come from DC/Nathan.
So what should we do if we get more donations up through the 15th?
Do 2 or more pilot iterations with equal proportions of the donations split among their matching pools.
Note that we’ve found in the Ethereum space that, the higher the average funds available per project (total funds/number projects), the more people take the fundraising seriously. One metric we have in the ETH space is “lives changed”, basically how many people can quit their day jobs and just work on public goods. Given a monthly
I dont want to put my thumb on the scale for this poll too much, but I’d just like voters who are participating to know this information.
The only way to limit a poll (via the forum software) is to restrict the trust level of who can vote, since that’s really the only confidence system that Discourse uses.
However, I can manually go into the SQL database and run queries about who voted in a certain poll with parameters. Similar to how when we did the forum poll about the development fund and did not count votes belonging to new (less than X months old) accounts to prevent ballot stuffing by users registering new accounts just to vote.
Not too sure how serious about polling you want to get and what you are trying to accomplish.
In terms of decentralization, quadratic voting comes between voting with stake and one person one vote system.
So what’s the current balance?
Has @nathan-at-least contributed his share yet? I think I recall he’s going to send it on the 15th?
If there’s already enough ZEC to max his match, is there a reason to not send it now?
It seems like sending it sooner (thereby upping the public balance) signals robustness.
Howdy folks. I sent the remainder of my pledged funds last week.
"outputs": [
{
"type": "sapling",
"output": 0,
"outgoing": true,
"address": "zs17lcwdj7qlqs9wt04akhs4ytm7k8r65pns6jghh5cdp09qeem5wclvhxpy08ylrwq9ggw50rtkzl",
"value": 100.00000000,
"valueZat": 10000000000,
"memo": "40616c6368656d7964632066756c66696c6c696e67206d7920706c6564676520746f2074686520636f6d6d756e69747920746f206d6174636820646f6e6174696f6e7320696e20737570706f7274206f662074686520476974636f696e207175616472617469632066756e64696e672070696c6f7420666f72205a636173682e0a5265706c792d546f3a0a7a7331356b733574706172367238656a65356874326b6a72666e7277376b327038323471786b7275777478777868667130716e387875777565616374646b303236396a6564306e3779327138706600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"memoStr": "@alchemydc fulfilling my pledge to the community to match donations in support of the Gitcoin quadratic funding pilot for Zcash.\nReply-To:\nzs15ks5tpar6r8eje5ht2kjrfnrw7k2p824qxkruwtxwxhfq0qn8xuwueactdk0269jed0n7y2q8pf"
}
Anybody who imports the viewing key I posted can cryptographically verify that I have fulfilled my promise to the community in support of this pilot.
@nathan-at-least are you ready to send the rest of your pledge also?
I’m very excited to see what Gitcoin and quadratic funding can do for the Zcash community.
the current amount is ZEC 233.94703287 USD 12026.11 - ill let @nathan-at-least comment about whats going on with his pledge.