Please review my proposal at Project Proposal - Coin Voting
Coin Voting using Orchard funds for Governance, Airdrops, and Proofs of Balance
The proposal is quite long, so it’s best reviewed on GitHub pages.
Exciting!!
fyi: links are pointing to localhost:3000 (ie http://localhost:3000/implementation/index.html).
Thanks! The links should be fixed now.
yes, this must be made!
Instead of just the Orchard circuit, I think it would be appropriate for the deliverables for this to include an MIT/Apache-licensed Rust crate based upon zcash_primitives and zcash_keys that makes it simple for other wallets to integrate voting functionality. This functionality will be most useful when it is available to all participants in the ecosystem.
Additionally, I think that both the client and server should be subjected to third-party audits, the same as we require for other components that have implications for user privacy or touch user keys.
@hanh one question: how large (in terms of bytes) is a vote in your coin voting protocol? Is it feasible to combine the voting protocol with the extended-memos proposal such that the ballots can be collected over the Zcash network, and thereby obtain true secret balloting via sender privacy? See ZIP 231: Memo Bundles by str4d · Pull Request #824 · zcash/zips · GitHub
Yes, absolutely. The license will be MIT, and I’ll work with other ecosystem members. I didn’t explicitly mention an audit because it is not the norm. I searched the different projects, and they don’t say it even when they are related to zebrad/zcashd.
AFAICR, the ballot size is ~10K, taken mainly by the ZKP.
your GitHub proposal has taken grant proposals to another level. Congratulations on that!
I have a suggestion for the case @ZcashGrants decides going forward and approving this grant
Deliverable 1.2
Prototype Vote Server
Deliverable 1.3
Vote client integrated with Ywallet
Deliverable 1.4
Multiple Devfund pools
I think this is missing a deliverable that release a framework that allows integration of coin voting to wallets and clients and that a subsequent deliverable is the Ywallet integration that it’s both a functionality and an example of how to integrate coin voting to shielded wallets
Ywallet’s contributions to Zcash are proven to be great but they could have been game changers for ZEC if those innovations could have been implemented in other wallets. For example, warp-sync on Zingo, ECC SDKs, etc instead of having 4 different sync algorithms (vanilla, blaze, warp, non-linear SBS)
This is a great opportunity to learn from our past and continue to build a great future
My modest suggestion
Deliverable 1.2
Prototype Vote Server
Deliverable 1.3
vote framework/sdk and tests
Deliverable 1.4
Vote framework/sdk integrated with Ywallet and documentation on how integrators should implement this in their Zcash clients
Deliverable 1.5
Multiple Devfund pools
Sure, the source code for Coin Voting 1.0 will be released and placed under MIT in milestone 1.
I am sorry but I need to point out that the code for warp-sync is under MIT and documented.
Whether other wallets use it or roll their own is not in my control, but their algorithm is also under MIT, so I don’t think availability has anything to do with it.
I’m not referring to that. availability and licensing are legal requirements 
In order for code to be adopted it has to be structured and thought to be used by others.
Another example is librustzcash and all of its forks. Anyone that had to do something meaningful has to fork the crates and it was hard for them to actually contribute upstream. Aditya from zecwallet had this problem, you (Ywallet), Zingo, eZcash and more recently Chainsafe.
Zcash has not been the greatest development experience out there. We are all survivors here. We’ve made advances. Yes. Yet we need to keep going that route and focusing on building tools for others to use. The original developers already have the advantage of being the creators of the thing. Integrating first and generalizing later generates unfriendly development tools. We need to work differently if we want to be competitive.
WebZ.js is a tool that works for everyone and that the snap team will use in their own development. I believe that’s the paradigm that will bring better results. It is more work. Yes. But it’s Zec better spent
And you are a great developer and I’m sure the tooling you make will be awesome.
Is it possible to get a more precise estimate here of exactly how much space you need? The reason that I ask is that I think it would be good for a memo to have space for both a coin vote and the proof associated with an authenticated reply-to address. If there’s space for both, then voters have the option of either casting a fully secret ballot, or a pseudonymous ballot, and I think having that flexibility is valuable, but we still want to keep a cap on the memo size.
One can imagine that in the future, an election could be announced by posting an IVK and a “blank ballot” of some sort to ZecPages; voters using pseudonymous ballots could then post both their votes and their campaign arguments to an address controlled by that IVK using the same arta (Authenticated Reply-To Address), with a dedicated ZIP 302 memo format for the vote and an ordinary authenticated ZIP 302 memo with text supporting their opinion, such that that opinion is linked to proof of voting with a given amount.