Create draft-coinholder-directed-grants.md #1112
Conversation
|
|
||
| The Administrator MUST collect and publish finalized tallies. | ||
|
|
||
| TBD: specify how shielded voting is counted. |
|
|
||
| Independent auditors MAY verify the results using the published election data. | ||
|
|
||
| TBD: specify how shielded voting is audited. |
| TBD: finish the specification, including but not limited to: | ||
| - The signing protocol (just specifying a signature algorithm is insufficient). | ||
| - The address derivation to be used. | ||
| - The structure of transaction to be created (what kinds of outputs, how many, to what recipients, with what values). |
There was a problem hiding this comment.
Fill out this TBD. By "the signing" protocol, this needs to describe how signatures are constructed and the relationship between the transparent address and the signing key. In particular, it should not be possible to replay signatures to spend funds. Is this intended to use the signmessage and verifymessage RPC APIs provided by zcashd? Alternately, should BIP 340 be used as the basis for this instead of ECDSA?
|
|
||
| #### Counting Votes | ||
|
|
||
| TBD: specify how transparent votes are counted. |
There was a problem hiding this comment.
Is this sufficient: "For shielded voting, tallying is performed using the Coin Voting 2.0 Audit Tool [^zcash-vote-audit] to aggregate verified ballots submitted to the voting chain. For transparent voting, tallying is performed by verifying signed messages and corresponding transparent payments received at the published Orchard address using the IVK. Shielded and transparent results are combined into a unified tally prior to publication. "
There was a problem hiding this comment.
Shielded and transparent tallying should be specified in their respective sections, but that aside what you've written here is a high-level overview of the process. Some points that are missing (for the transparent side):
- What is the format of vote messages, and how are the signatures attached to the body of the vote message?
- How are malformed vote messages to be interpreted?
- How is the coin weight for a transparent vote calculated?
- How are signatures verified?
| - with payments below 1 ZEC. | ||
| - where the Voter moves the submitted funds before voting concludes, as specified in the Quarterly Timeline below. | ||
|
|
||
| TBD: clarify specification of "voting concludes"; if you mean "at the end of the Coinholder Vote on Proposals phase" then say this instead of relying on the indirect definition. |
|
|
||
| The Administrator MUST publish IVK-based audit data and all received vote messages in order to allow verification. | ||
|
|
||
| TBD: specify how transparent votes are verified. |
There was a problem hiding this comment.
Fill out this TBD. This may refer to the vote counting specification.
There was a problem hiding this comment.
Is this sufficient? "For transparent voting, tallying is performed by verifying signed messages and corresponding transparent payments received at the published Orchard address using the IVK. Shielded and transparent results are combined into a unified tally prior to publication. "
|
|
||
| The Administrator MUST publish relevant parameters for each voting method for each cycle, and provide sufficient information for independent auditing. | ||
|
|
||
| TBD: specify the rest of the overall voting process. |
There was a problem hiding this comment.
Fill out this TBD. This should include:
- How to choose the parameters for each voting method
- How the set of validators whose responses will be considered authoritative for determining the outcome of the vote is chosen
- Some of the timeline should probably be in this section - this should direct the administrator with respect to how to set the registration window, etc.
- Anything else that requires a choice by the administrator resulting from the completed specifications of the individual shielded and transparent voting mechanism sections.
- How the set of grants being voted on is translated into a set of individual elections.
| | Review and Discussion Period | ≥ 30 days | Proposals are publicly discussed and evaluated. The Administrator or its delegate reviews submissions for eligibility and publishes a final list of qualified proposals. | | ||
| | Registration Period | ≥ 10 days | Coinholders register their balances for voting by creating eligible Orchard notes within a defined block range (as described in Section 4.1). | | ||
| | Coinholder Vote on Proposals | ~ 2 weeks | Coinholders vote on eligible proposals using the process defined in Section 4. The Administrator or its delegate verifies and tallies the results. | | ||
| | Vote Tallying | After voting concludes | The Administrator or its delegate tallies all votes. For shielded voting, tallying is performed using the Coin Voting 2.0 Audit Tool [^zcash-vote-audit] to aggregate verified ballots submitted to the voting chain. For transparent voting, tallying is performed by verifying signed messages and corresponding transparent payments received at the published Orchard address using the IVK. Shielded and transparent results are combined into a unified tally prior to publication. | |
There was a problem hiding this comment.
Most of the content here should probably not be in this table, but should instead be in the relevant specification sections instead.
The first sentence can stay here, the second sentence belongs in the shielded voting method section, the third in the transparent voting method section, and the final sentence belongs in Voting Process.
| TBD: add missing rationale for: | ||
| - Why the transparent voting FVK must not be published. | ||
| - The requirement for, and bound on, the payment amount for transparent voting. | ||
| - The requirement that transparent voters not move their funds until voting concludes. |
This PR adds a draft process ZIP for the Coinholder-Directed Retroactive Grants Program
Co-authored-by: Daira-Emma Hopwood <[email protected]> Co-authored-by: Kris Nuttycombe <[email protected]>
Co-authored-by: Daira-Emma Hopwood <[email protected]> Co-authored-by: Kris Nuttycombe <[email protected]>
Co-authored-by: Daira-Emma Hopwood <[email protected]> Co-authored-by: Kris Nuttycombe <[email protected]>
Co-authored-by: Kris Nuttycombe <[email protected]>
Co-authored-by: Kris Nuttycombe <[email protected]>
Co-authored-by: Kris Nuttycombe <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
…rmat. Signed-off-by: Daira-Emma Hopwood <[email protected]>
…arent voting process was run in the last vote. Signed-off-by: Daira-Emma Hopwood <[email protected]>
…r-directed-grants.md Signed-off-by: Daira-Emma Hopwood <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
daira
force-pushed
the
aquietinvestor-coinholder-grant-program
branch
from
16d84d9 to
f795d42
Compare
5 participants
This PR adds a draft process ZIP for the Coinholder-Directed Retroactive Grants Program