mirror of https://github.com/zcash/zips.git
Add rel="bookmark" to permalinks.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
b9f87da380
commit
be9733228f
|
|
@ -35,6 +35,6 @@ fi
|
|||
|
||||
sed -i.sedbak 's|<a href="\([^":]*\).rst">|<a href="\1">|g' "$2"
|
||||
|
||||
perl -i.sedbak -p0e 's|<section id="([^"]*)">\s*.?\s*<h([1-9])>([^<]*(?:<code>[^<]*</code>[^<]*)?)</h([1-9])>|<section id="\1"><h\2><span class="section-heading">\3</span><span class="section-anchor"> <a href="#\1"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h\4>|g' "$2"
|
||||
perl -i.sedbak -p0e 's|<section id="([^"]*)">\s*.?\s*<h([1-9])>([^<]*(?:<code>[^<]*</code>[^<]*)?)</h([1-9])>|<section id="\1"><h\2><span class="section-heading">\3</span><span class="section-anchor"> <a rel="bookmark" href="#\1"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h\4>|g' "$2"
|
||||
|
||||
rm -f *.sedbak
|
||||
|
|
|
|||
10
index.html
10
index.html
|
|
@ -7,7 +7,7 @@
|
|||
<body>
|
||||
<section>
|
||||
<!-- Title: Specifications and Zcash Improvement Proposals -->
|
||||
<section id="what-are-zips"><h2><span class="section-heading">What are ZIPs?</span><span class="section-anchor"> <a href="#what-are-zips"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="what-are-zips"><h2><span class="section-heading">What are ZIPs?</span><span class="section-anchor"> <a rel="bookmark" href="#what-are-zips"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash Improvement Proposals (ZIPs) are the way to:</p>
|
||||
<ul>
|
||||
<li>propose new features for the the <a href="https://z.cash/">Zcash cryptocurrency</a> and their rationale,</li>
|
||||
|
|
@ -16,7 +16,7 @@
|
|||
<li>document design decisions.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="contributing"><h2><span class="section-heading">Contributing</span><span class="section-anchor"> <a href="#contributing"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="contributing"><h2><span class="section-heading">Contributing</span><span class="section-anchor"> <a rel="bookmark" href="#contributing"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The authors of a ZIP are responsible for building consensus within the community and documenting / addressing dissenting opinions.</p>
|
||||
<p>Anyone can write a ZIP! We encourage community contributions and decentralization of work on the Zcash protocol. If you’d like to bounce ideas off people before formally writing a ZIP, we encourage it! Visit the community <a href="https://discord.com/invite/PXHqXV2">Discord</a> channel to talk about your idea.</p>
|
||||
<p>Participation in the Zcash project is subject to a <a href="https://github.com/zcash/zcash/blob/master/code_of_conduct.md">Code of Conduct</a>.</p>
|
||||
|
|
@ -24,17 +24,17 @@
|
|||
<p>To start contributing, first read <a href="zip-0000">ZIP 0</a> which documents the ZIP process. Then clone <a href="https://github.com/zcash/zips">this repo</a> from GitHub, and start adding your draft ZIP, formatted either as reStructuredText or as Markdown.</p>
|
||||
<p>For example, if using reStructuredText, use a filename matching <code>draft-*.rst</code>. Use <code>make</code> to check that you are using correct <a href="https://docutils.sourceforge.io/rst.html">reStructuredText</a> or <a href="https://pandoc.org/MANUAL.html#pandocs-markdown">Markdown</a> syntax, and double-check the generated <code>draft-*.html</code> file before filing a Pull Request.</p>
|
||||
</section>
|
||||
<section id="heartwood-zips"><h2><span class="section-heading">Heartwood ZIPs</span><span class="section-anchor"> <a href="#heartwood-zips"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="heartwood-zips"><h2><span class="section-heading">Heartwood ZIPs</span><span class="section-anchor"> <a rel="bookmark" href="#heartwood-zips"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This is the list of ZIPs included in Heartwood (Network Upgrade 3), due to activate on mainnet in mid-July 2020:</p>
|
||||
<ul>
|
||||
<li><a href="zip-0213">ZIP 213: Shielded Coinbase</a></li>
|
||||
<li><a href="zip-0221">ZIP 221: FlyClient - Consensus-Layer Changes</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="license"><h2><span class="section-heading">License</span><span class="section-anchor"> <a href="#license"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="license"><h2><span class="section-heading">License</span><span class="section-anchor"> <a rel="bookmark" href="#license"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Unless otherwise stated in this repository’s individual files, the contents of this repository are released under the terms of the MIT license. See <a href="COPYING">COPYING</a> for more information or see <a href="https://opensource.org/licenses/MIT">https://opensource.org/licenses/MIT</a> .</p>
|
||||
</section>
|
||||
<section id="index-of-zips"><h2><span class="section-heading">Index of ZIPs</span><span class="section-anchor"> <a href="#index-of-zips"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="index-of-zips"><h2><span class="section-heading">Index of ZIPs</span><span class="section-anchor"> <a rel="bookmark" href="#index-of-zips"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<embed><table>
|
||||
<tr> <th>ZIP</th> <th>Title</th> <th>Status</th> </tr>
|
||||
<tr> <td>0</td> <td class="left"><a href="zip-0000">ZIP Process</a></td> <td>Active</td>
|
||||
|
|
|
|||
|
|
@ -18,17 +18,17 @@ Status: Active
|
|||
Category: Process
|
||||
Created: 2019-02-16
|
||||
License: BSD-2-Clause</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL", and "REQUIRED" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>A Zcash Improvement Proposal (ZIP) is a design document providing information to the Zcash community, or describing a new feature for Zcash or its processes or environment. The ZIP should provide a concise technical specification of the feature and a rationale for the feature.</p>
|
||||
<p>We intend ZIPs to be the primary mechanism for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Zcash. The Owner(s) of the ZIP (usually the authors(s)) are responsible for building consensus within the community and documenting dissenting opinions.</p>
|
||||
<p>Because the ZIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.</p>
|
||||
<p>This document is based partly on the work done by Luke Dashjr with <a href="https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki">BIP 2</a>.</p>
|
||||
</section>
|
||||
<section id="zip-workflow"><h2><span class="section-heading">ZIP Workflow</span><span class="section-anchor"> <a href="#zip-workflow"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="zip-workflow"><h2><span class="section-heading">ZIP Workflow</span><span class="section-anchor"> <a rel="bookmark" href="#zip-workflow"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The ZIP process begins with a new idea for Zcash. Each potential ZIP must have a Owner -- someone who writes the ZIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The ZIP Owner should first attempt to ascertain whether the idea is ZIP-able. Small enhancements or patches to a particular piece of software often don't require standardisation between multiple projects; these don't need a ZIP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker. Additionally, many ideas have been brought forward for changing Zcash that have been rejected for various reasons. The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression. After investigating past work, the best way to proceed is by posting about the new idea to the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum</a>.</p>
|
||||
<p>Vetting an idea publicly before going as far as writing a ZIP is meant to save both the potential Owner and the wider community time. Asking the Zcash community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the Owner. Just because an idea sounds good to the Owner does not mean it will work for most people in most areas where Zcash is used.</p>
|
||||
<p>Once the Owner has asked the Zcash community as to whether an idea has any chance of acceptance, a draft ZIP should be presented to the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum</a>. This gives the Owner a chance to flesh out the draft ZIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be submitted to the <a href="https://github.com/zcash/zips">ZIPs git repository</a> as a pull request. This draft must be written in ZIP style as described below, and named with an alias such as <code>zip-zatoshizakamoto-42millionzec</code> until the ZIP Editors have assigned it a ZIP number (Owners MUST NOT self-assign ZIP numbers).</p>
|
||||
|
|
@ -36,7 +36,7 @@ License: BSD-2-Clause</pre>
|
|||
<p>It is highly recommended that a single ZIP contain a single key proposal or new idea. The more focused the ZIP, the more successful it tends to be. If in doubt, split your ZIP into several well-focused ones.</p>
|
||||
<p>When the ZIP draft is complete, the ZIP Editors will assign the ZIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the ZIPs git repository. The ZIP Editors will not unreasonably reject a ZIP. Reasons for rejecting ZIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or not in keeping with the Zcash philosophy. For a ZIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.</p>
|
||||
<p>The ZIP Owner may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the Owner as pull requests.</p>
|
||||
<section id="zip-numbering-conventions"><h3><span class="section-heading">ZIP Numbering Conventions</span><span class="section-anchor"> <a href="#zip-numbering-conventions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="zip-numbering-conventions"><h3><span class="section-heading">ZIP Numbering Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#zip-numbering-conventions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The ZIP Editors currently use the following conventions when numbering ZIPs:</p>
|
||||
<ul>
|
||||
<li>if a ZIP directly corresponds to a BIP (Bitcoin Improvement Proposal), and the number doesn't clash, assign the same number;</li>
|
||||
|
|
@ -47,15 +47,15 @@ License: BSD-2-Clause</pre>
|
|||
</ul>
|
||||
<p>These conventions are subject to change by consensus of the ZIP Editors.</p>
|
||||
</section>
|
||||
<section id="transferring-zip-ownership"><h3><span class="section-heading">Transferring ZIP Ownership</span><span class="section-anchor"> <a href="#transferring-zip-ownership"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="transferring-zip-ownership"><h3><span class="section-heading">Transferring ZIP Ownership</span><span class="section-anchor"> <a rel="bookmark" href="#transferring-zip-ownership"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>It occasionally becomes necessary to transfer ownership of ZIPs to a new Owner. In general, we'd like to retain the original Owner as a co-Owner of the transferred ZIP, but that's really up to the original Owner. A good reason to transfer ownership is because the original Owner no longer has the time or interest in updating it or following through with the ZIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the ZIP. We try to build consensus around a ZIP, but if that's not possible, you can always submit a competing ZIP.</p>
|
||||
<p>If you are interested in assuming ownership of a ZIP, send a message asking to take over, addressed to both the original Owner and the ZIP Editors. If the original Owner doesn't respond to email in a timely manner, the ZIP Editors will make a unilateral decision (it's not like such decisions can't be reversed :).</p>
|
||||
<p>If an author of a ZIP is no longer an Owner, an Original-Authors field SHOULD be added to the ZIP metadata indicating the original authorship, unless the original author(s) request otherwise.</p>
|
||||
</section>
|
||||
<section id="zip-editors"><h3><span class="section-heading">ZIP Editors</span><span class="section-anchor"> <a href="#zip-editors"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="zip-editors"><h3><span class="section-heading">ZIP Editors</span><span class="section-anchor"> <a rel="bookmark" href="#zip-editors"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The current ZIP Editors are Daira Hopwood, representing the Electric Coin Company, and Deirdre Connolly, representing the Zcash Foundation. Both can be reached at <a href="mailto:zips@z.cash">zips@z.cash</a> . The current design of the ZIP Process dictates that there are always at least two ZIP Editors: one from the Electric Coin Company and one from the Zcash Foundation. Additional Editors may be selected by consensus among the current Editors.</p>
|
||||
</section>
|
||||
<section id="zip-editor-responsibilities-workflow"><h3><span class="section-heading">ZIP Editor Responsibilities & Workflow</span><span class="section-anchor"> <a href="#zip-editor-responsibilities-workflow"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="zip-editor-responsibilities-workflow"><h3><span class="section-heading">ZIP Editor Responsibilities & Workflow</span><span class="section-anchor"> <a rel="bookmark" href="#zip-editor-responsibilities-workflow"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The ZIP Editors subscribe to the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum.</a></p>
|
||||
<p>For each new ZIP that comes in an Editor confirms the following:</p>
|
||||
<ul>
|
||||
|
|
@ -102,7 +102,7 @@ License: BSD-2-Clause</pre>
|
|||
<p>Please send all ZIP-related communications either by email to <<a href="mailto:zips@z.cash">zips@z.cash</a>>, or by opening an issue on the <a href="https://github.com/zcash/zips/issues">ZIPs issue tracker</a>. All communications should abide by the Zcash Code of Conduct <a id="id5" class="footnote_reference" href="#conduct">4</a> and follow <a href="https://www.gnu.org/philosophy/kind-communication.en.html">the GNU Kind Communication Guidelines</a></p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="zip-format-and-structure"><h2><span class="section-heading">ZIP format and structure</span><span class="section-anchor"> <a href="#zip-format-and-structure"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="zip-format-and-structure"><h2><span class="section-heading">ZIP format and structure</span><span class="section-anchor"> <a rel="bookmark" href="#zip-format-and-structure"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>ZIPs SHOULD be written either in reStructuredText <a id="id6" class="footnote_reference" href="#rst">5</a> or LaTeX <a id="id7" class="footnote_reference" href="#latex">6</a>. In the latter case, a <cite>Makefile</cite> MUST be provided to build (at least) a PDF version of the document.</p>
|
||||
<p>Each ZIP SHOULD have the following parts:</p>
|
||||
<ul>
|
||||
|
|
@ -115,7 +115,7 @@ License: BSD-2-Clause</pre>
|
|||
<li>Security and privacy considerations -- If applicable, security and privacy considerations should be explicitly described, particularly if the ZIP makes explicit trade-offs or assumptions. For guidance on this section consider RFC 3552 <a id="id8" class="footnote_reference" href="#rfc3552">2</a> as a starting point.</li>
|
||||
<li>Reference implementation -- Literal code implementing the ZIP's specification, and/or a link to the reference implementation of the ZIP's specification. The reference implementation must be completed before any ZIP is given status “Implemented” or “Final”, but it generally need not be completed before the ZIP is accepted into “Proposed”.</li>
|
||||
</ul>
|
||||
<section id="zip-header-preamble"><h3><span class="section-heading">ZIP header preamble</span><span class="section-anchor"> <a href="#zip-header-preamble"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="zip-header-preamble"><h3><span class="section-heading">ZIP header preamble</span><span class="section-anchor"> <a rel="bookmark" href="#zip-header-preamble"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Each ZIP must begin with an RFC 822-style header preamble. The following header fields are REQUIRED:</p>
|
||||
<pre>ZIP:
|
||||
Title:
|
||||
|
|
@ -140,11 +140,11 @@ Updates:</pre>
|
|||
<p>The Category header specifies the type of ZIP: Consensus, Standards Track, Informational, or Process.</p>
|
||||
<p>The Created header records the date that the ZIP was submitted. Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.</p>
|
||||
</section>
|
||||
<section id="auxiliary-files"><h3><span class="section-heading">Auxiliary Files</span><span class="section-anchor"> <a href="#auxiliary-files"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="auxiliary-files"><h3><span class="section-heading">Auxiliary Files</span><span class="section-anchor"> <a rel="bookmark" href="#auxiliary-files"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>ZIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a subdirectory for that ZIP; that is, for any ZIP that requires more than one file, all of the files SHOULD be in a subdirectory named zip-XXXX.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="zip-categories"><h2><span class="section-heading">ZIP categories</span><span class="section-anchor"> <a href="#zip-categories"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="zip-categories"><h2><span class="section-heading">ZIP categories</span><span class="section-anchor"> <a rel="bookmark" href="#zip-categories"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>There are several kinds of ZIP:</p>
|
||||
<ul>
|
||||
<li>A Consensus ZIP describes a change that affects the consensus protocol followed by all Zcash implementations.</li>
|
||||
|
|
@ -157,7 +157,7 @@ Updates:</pre>
|
|||
</ul>
|
||||
<p>New categories may be added by consensus among the ZIP Editors.</p>
|
||||
</section>
|
||||
<section id="zip-status-field"><h2><span class="section-heading">ZIP Status Field</span><span class="section-anchor"> <a href="#zip-status-field"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="zip-status-field"><h2><span class="section-heading">ZIP Status Field</span><span class="section-anchor"> <a rel="bookmark" href="#zip-status-field"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>Draft: All initial ZIP submissions have this status.</li>
|
||||
<li>Withdrawn: If the Owner decides to remove the ZIP from consideration by the community, they may set the status to Withdrawn.</li>
|
||||
|
|
@ -169,7 +169,7 @@ Updates:</pre>
|
|||
<li>Obsolete: The status when a ZIP is no longer relevant (typically when superseded by another ZIP).</li>
|
||||
</ul>
|
||||
<p>More details on the status workflow in the section below.</p>
|
||||
<section id="specification"><h3><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="specification"><h3><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Owners of a ZIP may decide on their own to change the status between Draft or Withdrawn.</p>
|
||||
<p>A ZIP may only change status from Draft (or Rejected) to Proposed, when the Owner deems it is complete and there is rough consensus on the forums, validated by both the Electric Coin Company and Zcash Foundation Editors. One Editor will not suffice -- there needs to be consensus among the Editors. If it's a Standards Track ZIP, upon changing status to Proposed the Editors will add the optional <code>Network Upgrade</code> header to the preamble, indicating the intent for the ZIP to be implemented in the specified network upgrade. (All <code>Network Upgrade</code> schedules will be distributed via the Zcash Community Forum by the Editors.)</p>
|
||||
<p>A Standards Track ZIP may only change status from Proposed to Implemented once the Owner provides an associated reference implementation, typically in the period after the network upgrade's specification freeze but before the implementation audit. If the Owner misses this deadline, the Editors or Owner(s) may choose to update the <code>Network Upgrade</code> header to target another upgrade, at their discretion.</p>
|
||||
|
|
@ -179,10 +179,10 @@ Updates:</pre>
|
|||
<p>When an Active or Final ZIP is no longer relevant, its status may be changed to Obsolete. This change must also be objectively verifiable and/or discussed. Final ZIPs may be updated; the specification is still in force but modified by another specified ZIP or ZIPs (check the optional Updated-by header).</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="zip-comments"><h2><span class="section-heading">ZIP Comments</span><span class="section-anchor"> <a href="#zip-comments"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="zip-comments"><h2><span class="section-heading">ZIP Comments</span><span class="section-anchor"> <a rel="bookmark" href="#zip-comments"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Comments from the community on the ZIP should occur on the Zcash Community Forum and the comment fields of the pull requests in any open ZIPs. Editors will use these sources to judge rough consensus.</p>
|
||||
</section>
|
||||
<section id="zip-licensing"><h2><span class="section-heading">ZIP Licensing</span><span class="section-anchor"> <a href="#zip-licensing"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="zip-licensing"><h2><span class="section-heading">ZIP Licensing</span><span class="section-anchor"> <a rel="bookmark" href="#zip-licensing"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>New ZIPs may be accepted with the following licenses. Each new ZIP MUST identify at least one acceptable license in its preamble. Each license MUST be referenced by their respective abbreviation given below.</p>
|
||||
<p>For example, a preamble might include the following License header:</p>
|
||||
<pre>License: BSD-2-Clause
|
||||
|
|
@ -191,7 +191,7 @@ Updates:</pre>
|
|||
<p>It is also possible to license source code differently from the ZIP text. This case SHOULD be indicated in the Reference Implementation section of the ZIP. Again, each license MUST be referenced by its respective abbreviation given below.</p>
|
||||
<p>Statements of code licenses in ZIPs are only advisory; anyone intending to use the code should look for license statements in the code itself.</p>
|
||||
<p>ZIPs are not required to be <em>exclusively</em> licensed under approved terms, and MAY also be licensed under unacceptable licenses <em>in addition to</em> at least one acceptable license. In this case, only the acceptable license(s) should be listed in the License header.</p>
|
||||
<section id="recommended-licenses"><h3><span class="section-heading">Recommended licenses</span><span class="section-anchor"> <a href="#recommended-licenses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="recommended-licenses"><h3><span class="section-heading">Recommended licenses</span><span class="section-anchor"> <a rel="bookmark" href="#recommended-licenses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<ul>
|
||||
<li>MIT: <a href="https://opensource.org/licenses/MIT">Expat/MIT/X11 license</a></li>
|
||||
<li>BSD-2-Clause: <a href="https://opensource.org/licenses/BSD-2-Clause">OSI-approved BSD 2-clause license</a></li>
|
||||
|
|
@ -202,7 +202,7 @@ Updates:</pre>
|
|||
</ul>
|
||||
<p>In addition, it is RECOMMENDED that literal code included in the ZIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for zcashd would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the ZIP text.</p>
|
||||
</section>
|
||||
<section id="not-recommended-but-acceptable-licenses"><h3><span class="section-heading">Not recommended, but acceptable licenses</span><span class="section-anchor"> <a href="#not-recommended-but-acceptable-licenses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="not-recommended-but-acceptable-licenses"><h3><span class="section-heading">Not recommended, but acceptable licenses</span><span class="section-anchor"> <a rel="bookmark" href="#not-recommended-but-acceptable-licenses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<ul>
|
||||
<li>BSL-1.0: <a href="http://www.boost.org/LICENSE_1_0.txt">Boost Software License, version 1.0</a></li>
|
||||
<li>CC-BY-4.0: <a href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International</a></li>
|
||||
|
|
@ -213,10 +213,10 @@ Updates:</pre>
|
|||
<li>LGPL-2.1+: <a href="http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html">GNU Lesser General Public License (LGPL), version 2.1 or newer</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="not-acceptable-licenses"><h3><span class="section-heading">Not acceptable licenses</span><span class="section-anchor"> <a href="#not-acceptable-licenses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="not-acceptable-licenses"><h3><span class="section-heading">Not acceptable licenses</span><span class="section-anchor"> <a rel="bookmark" href="#not-acceptable-licenses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>All licenses not explicitly included in the above lists are not acceptable terms for a Zcash Improvement Proposal.</p>
|
||||
</section>
|
||||
<section id="rationale"><h3><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="rationale"><h3><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Bitcoin's BIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient?</p>
|
||||
<ul>
|
||||
<li>The OPL is generally regarded as obsolete, and not a license suitable for new publications.</li>
|
||||
|
|
@ -230,14 +230,14 @@ Updates:</pre>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="see-also"><h2><span class="section-heading">See Also</span><span class="section-anchor"> <a href="#see-also"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="see-also"><h2><span class="section-heading">See Also</span><span class="section-anchor"> <a rel="bookmark" href="#see-also"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li><a href="https://www.gnu.org/philosophy/kind-communication.en.html">The GNU Kind Communication Guidelines</a></li>
|
||||
<li><a href="https://www.rfc-editor.org/rfc/rfc7282.html">RFC 7282: On Consensus and Humming in the IETF</a></li>
|
||||
<li><a href="https://electriccoin.co/blog/the-zcash-network-upgrade-pipeline/">Zcash Network Upgrade Pipeline</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -21,16 +21,16 @@ License: MIT</pre>
|
|||
<p>
|
||||
<span class="math">\(% This ZIP makes heavy use of mathematical markup. If you can see this, you may want to instead view the rendered version at <https://zips.z.cash/zip-0032>.\)</span>
|
||||
</p>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>"Jubjub" refers to the elliptic curve defined in <a id="id2" class="footnote_reference" href="#sapling-jubjub">12</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 <a id="id3" class="footnote_reference" href="#bip-0032">2</a>, to support Zcash's shielded addresses.</p>
|
||||
<p>The specification has three parts. The first part defines a system for deriving a tree of Sapling key components from a single seed. The second part defines an equivalent, but independent, system for Sprout key components (which have a different internal construction). The third part shows how to use these trees in the context of existing BIP 44 <a id="id4" class="footnote_reference" href="#bip-0044">5</a> wallets.</p>
|
||||
<p>This specification complements the existing use by some Zcash wallets of BIP 32 and BIP 44 for transparent Zcash addresses, and is not intended to deprecate that usage (privacy risks of using transparent addresses notwithstanding).</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>BIP 32 <a id="id5" class="footnote_reference" href="#bip-0032">2</a> is the standard mechanism by which wallets for Bitcoin and its derivatives (including Zcash's transparent addresses <a id="id6" class="footnote_reference" href="#slip-0044">6</a>) generate keys and addresses deterministically. This has several advantages over random generation:</p>
|
||||
<ul>
|
||||
<li>Wallets only need to store a single seed (particularly useful for hardware wallets).</li>
|
||||
|
|
@ -40,7 +40,7 @@ License: MIT</pre>
|
|||
</ul>
|
||||
<p>At present, no such equivalent exists for Zcash's shielded addresses. This is of particular concern for hardware wallets; all currently-marketed devices only store a seed internally, and have trained their users to only backup that seed. Given that the Sapling upgrade will make it feasible to use hardware wallets with shielded addresses, it is desirable to have a standard mechanism for deriving them.</p>
|
||||
</section>
|
||||
<section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a href="#conventions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#conventions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Most of the notation and functions used in this ZIP are defined in the Sapling protocol specification <a id="id8" class="footnote_reference" href="#sapling-spec">8</a>. They are reproduced here for convenience:</p>
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -181,8 +181,8 @@ License: MIT</pre>
|
|||
.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="specification-sapling-key-derivation"><h2><span class="section-heading">Specification: Sapling key derivation</span><span class="section-anchor"> <a href="#specification-sapling-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="sapling-extended-keys"><h3><span class="section-heading">Sapling extended keys</span><span class="section-anchor"> <a href="#sapling-extended-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="specification-sapling-key-derivation"><h2><span class="section-heading">Specification: Sapling key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#specification-sapling-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="sapling-extended-keys"><h3><span class="section-heading">Sapling extended keys</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-extended-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>BIP 32 defines a method to derive a number of child keys from a parent key. In order to prevent these from depending solely on the parent key itself, both the private and public keys are extended with a 32-byte chain code. We similarly extend Sapling keys with a chain code here. However, the concepts of "private" and "public" keys in BIP 32 do not map cleanly to Sapling's key components. We take the following approach:</p>
|
||||
<ul>
|
||||
<li>We derive child Sapling expanded spending keys, rather than Sapling spending keys. This enables us to implement both hardened and non-hardened derivation modes (the latter being incompatible with Sapling spending keys).</li>
|
||||
|
|
@ -207,7 +207,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{c}\)</span>
|
||||
is the chain code.</p>
|
||||
</section>
|
||||
<section id="sapling-helper-functions"><h3><span class="section-heading">Sapling helper functions</span><span class="section-anchor"> <a href="#sapling-helper-functions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sapling-helper-functions"><h3><span class="section-heading">Sapling helper functions</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-helper-functions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Define</p>
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -226,7 +226,7 @@ License: MIT</pre>
|
|||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="sapling-master-key-generation"><h3><span class="section-heading">Sapling master key generation</span><span class="section-anchor"> <a href="#sapling-master-key-generation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sapling-master-key-generation"><h3><span class="section-heading">Sapling master key generation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-master-key-generation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Let
|
||||
<span class="math">\(S\)</span>
|
||||
be a seed byte sequence of a chosen length, which MUST be at least 32 bytes.</p>
|
||||
|
|
@ -285,11 +285,11 @@ License: MIT</pre>
|
|||
.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="sapling-child-key-derivation"><h3><span class="section-heading">Sapling child key derivation</span><span class="section-anchor"> <a href="#sapling-child-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sapling-child-key-derivation"><h3><span class="section-heading">Sapling child key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-child-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>As in BIP 32, the method for deriving a child extended key, given a parent extended key and an index
|
||||
<span class="math">\(i\)</span>
|
||||
, depends on the type of key being derived, and whether this is a hardened or non-hardened derivation.</p>
|
||||
<section id="deriving-a-child-extended-spending-key"><h4><span class="section-heading">Deriving a child extended spending key</span><span class="section-anchor"> <a href="#deriving-a-child-extended-spending-key"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="deriving-a-child-extended-spending-key"><h4><span class="section-heading">Deriving a child extended spending key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-child-extended-spending-key"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>
|
||||
<span class="math">\(\mathsf{CDKsk}((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)\)</span>
|
||||
<span class="math">\(\rightarrow (\mathsf{ask}_i, \mathsf{nsk}_i, \mathsf{ovk}_i, \mathsf{dk}_i, \mathsf{c}_i)\)</span>
|
||||
|
|
@ -351,7 +351,7 @@ License: MIT</pre>
|
|||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="deriving-a-child-extended-full-viewing-key"><h4><span class="section-heading">Deriving a child extended full viewing key</span><span class="section-anchor"> <a href="#deriving-a-child-extended-full-viewing-key"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="deriving-a-child-extended-full-viewing-key"><h4><span class="section-heading">Deriving a child extended full viewing key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-child-extended-full-viewing-key"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Let
|
||||
<span class="math">\(\mathcal{G}\)</span>
|
||||
be as defined in <a id="id16" class="footnote_reference" href="#sapling-spendauthsig">11</a> and let
|
||||
|
|
@ -411,7 +411,7 @@ License: MIT</pre>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="diversifier-derivation"><h3><span class="section-heading">Diversifier derivation</span><span class="section-anchor"> <a href="#diversifier-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="diversifier-derivation"><h3><span class="section-heading">Diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#diversifier-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key
|
||||
<span class="math">\(\mathsf{dk}\)</span>
|
||||
. To prevent the diversifier leaking how many diversified addresses have already been generated for an account, we make the sequence of diversifiers pseudorandom and uncorrelated to that of any other account. In order to reach the maximum possible diversifier range without running into repetitions due to the birthday bound, we use FF1-AES256 as a Pseudo-Random Permutation as follows:</p>
|
||||
|
|
@ -441,9 +441,9 @@ License: MIT</pre>
|
|||
is the least nonnegative integer yielding a valid diversifier.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="specification-sprout-key-derivation"><h2><span class="section-heading">Specification: Sprout key derivation</span><span class="section-anchor"> <a href="#specification-sprout-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification-sprout-key-derivation"><h2><span class="section-heading">Specification: Sprout key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#specification-sprout-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>For completeness, we define a system for deriving a tree of Sprout key components. It is unlikely that this will garner much usage once Sapling activates, but is presented for those users who may require it.</p>
|
||||
<section id="sprout-extended-keys"><h3><span class="section-heading">Sprout extended keys</span><span class="section-anchor"> <a href="#sprout-extended-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sprout-extended-keys"><h3><span class="section-heading">Sprout extended keys</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-extended-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Due to the way Sprout keys are constructed and used, it is not possible to derive incoming viewing keys or payment addresses in parallel with spending keys. Nor is it possible to implement non-hardened derivation. We therefore only define and derive Sprout extended spending keys.</p>
|
||||
<p>We represent a Sprout extended spending key as
|
||||
<span class="math">\((\mathsf{a_{sk}, c})\)</span>
|
||||
|
|
@ -453,7 +453,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{c}\)</span>
|
||||
is the chain code.</p>
|
||||
</section>
|
||||
<section id="sprout-helper-functions"><h3><span class="section-heading">Sprout helper functions</span><span class="section-anchor"> <a href="#sprout-helper-functions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sprout-helper-functions"><h3><span class="section-heading">Sprout helper functions</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-helper-functions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Let
|
||||
<span class="math">\(\mathsf{EncodeASK}(\mathsf{a_{sk}})\)</span>
|
||||
be the 32-byte encoding of
|
||||
|
|
@ -467,7 +467,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{EncodeASK}\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
<section id="sprout-master-key-generation"><h3><span class="section-heading">Sprout master key generation</span><span class="section-anchor"> <a href="#sprout-master-key-generation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sprout-master-key-generation"><h3><span class="section-heading">Sprout master key generation</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-master-key-generation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Let
|
||||
<span class="math">\(S\)</span>
|
||||
be a seed byte sequence of a chosen length, which MUST be at least 32 bytes.</p>
|
||||
|
|
@ -494,7 +494,7 @@ License: MIT</pre>
|
|||
.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="sprout-child-key-derivation"><h3><span class="section-heading">Sprout child key derivation</span><span class="section-anchor"> <a href="#sprout-child-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sprout-child-key-derivation"><h3><span class="section-heading">Sprout child key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-child-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>
|
||||
<span class="math">\(\mathsf{CDKsk}((\mathsf{a}_{\mathsf{sk},par}, \mathsf{c}_{par}), i)\)</span>
|
||||
<span class="math">\(\rightarrow (\mathsf{a}_{\mathsf{sk},i}, \mathsf{c}_i)\)</span>
|
||||
|
|
@ -532,9 +532,9 @@ License: MIT</pre>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="specification-wallet-usage"><h2><span class="section-heading">Specification: Wallet usage</span><span class="section-anchor"> <a href="#specification-wallet-usage"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification-wallet-usage"><h2><span class="section-heading">Specification: Wallet usage</span><span class="section-anchor"> <a rel="bookmark" href="#specification-wallet-usage"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id19" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
|
||||
<section id="key-path-levels"><h3><span class="section-heading">Key path levels</span><span class="section-anchor"> <a href="#key-path-levels"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="key-path-levels"><h3><span class="section-heading">Key path levels</span><span class="section-anchor"> <a rel="bookmark" href="#key-path-levels"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Both Sprout and Sapling key paths have the following three path levels at the top, all of which use hardened derivation:</p>
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -561,7 +561,7 @@ License: MIT</pre>
|
|||
<span class="math">\(change\)</span>
|
||||
path level. The use of change addresses in Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by segregating external and internal address usage. Shielded addresses are never publicly visible in transactions, which means that sending change back to the originating address is indistinguishable from using a change address.</p>
|
||||
</section>
|
||||
<section id="sapling-key-path"><h3><span class="section-heading">Sapling key path</span><span class="section-anchor"> <a href="#sapling-key-path"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sapling-key-path"><h3><span class="section-heading">Sapling key path</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-key-path"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Sapling provides a mechanism to allow the efficient creation of diversified payment addresses with the same spending authority. A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.</p>
|
||||
<p>The above key path levels include an account identifier, which in all user interfaces is represented as a "bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Sapling ZIP 32 derivation MUST support the following path for any account in range
|
||||
<span class="math">\(\{ 0\,.\!. 2^{31} - 1 \}\)</span>
|
||||
|
|
@ -584,7 +584,7 @@ License: MIT</pre>
|
|||
.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="sprout-key-path"><h3><span class="section-heading">Sprout key path</span><span class="section-anchor"> <a href="#sprout-key-path"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sprout-key-path"><h3><span class="section-heading">Sprout key path</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-key-path"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Wallets implementing Sprout ZIP 32 derivation MUST support the following path:</p>
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -593,8 +593,8 @@ License: MIT</pre>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="specification-fingerprints-and-tags"><h2><span class="section-heading">Specification: Fingerprints and Tags</span><span class="section-anchor"> <a href="#specification-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="sapling-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Sapling Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a href="#sapling-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="specification-fingerprints-and-tags"><h2><span class="section-heading">Specification: Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#specification-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="sapling-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Sapling Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding
|
||||
<span class="math">\(FVK\)</span>
|
||||
(as specified in <a id="id23" class="footnote_reference" href="#sapling-full-viewing-keys">14</a>) is given by:</p>
|
||||
|
|
@ -606,7 +606,7 @@ License: MIT</pre>
|
|||
<p>It MAY be used to uniquely identify a particular Sapling full viewing key.</p>
|
||||
<p>A "Sapling full viewing key tag" is the first 4 bytes of the corresponding Sapling full viewing key fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to uniquely identify a particular key.</p>
|
||||
</section>
|
||||
<section id="sprout-address-fingerprints-and-tags"><h3><span class="section-heading">Sprout Address Fingerprints and Tags</span><span class="section-anchor"> <a href="#sprout-address-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sprout-address-fingerprints-and-tags"><h3><span class="section-heading">Sprout Address Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-address-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A "Sprout address fingerprint" of a Sprout payment address with raw encoding
|
||||
<span class="math">\(ADDR\)</span>
|
||||
(as specified in <a id="id24" class="footnote_reference" href="#sprout-shielded-addresses">13</a>, including the lead bytes) is given by:</p>
|
||||
|
|
@ -618,7 +618,7 @@ License: MIT</pre>
|
|||
<p>It MAY be used to uniquely identify a particular Sprout payment address.</p>
|
||||
<p>A "Sprout address tag" is the first 4 bytes of the corresponding Sprout address fingerprint. It is intended for optimizing performance of address lookups, and MUST NOT be assumed to uniquely identify a particular address.</p>
|
||||
</section>
|
||||
<section id="seed-fingerprints"><h3><span class="section-heading">Seed Fingerprints</span><span class="section-anchor"> <a href="#seed-fingerprints"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="seed-fingerprints"><h3><span class="section-heading">Seed Fingerprints</span><span class="section-anchor"> <a rel="bookmark" href="#seed-fingerprints"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A "seed fingerprint" for the master seed
|
||||
<span class="math">\(S\)</span>
|
||||
of a hierarchical deterministic wallet is given by:</p>
|
||||
|
|
@ -631,9 +631,9 @@ License: MIT</pre>
|
|||
<p>No corresponding short tag is defined.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="specification-key-encodings"><h2><span class="section-heading">Specification: Key Encodings</span><span class="section-anchor"> <a href="#specification-key-encodings"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification-key-encodings"><h2><span class="section-heading">Specification: Key Encodings</span><span class="section-anchor"> <a rel="bookmark" href="#specification-key-encodings"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The following encodings are analogous to the <code>xprv</code> and <code>xpub</code> encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 <a id="id25" class="footnote_reference" href="#bip-0173">7</a> encoding.</p>
|
||||
<section id="sapling-extended-spending-keys"><h3><span class="section-heading">Sapling extended spending keys</span><span class="section-anchor"> <a href="#sapling-extended-spending-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sapling-extended-spending-keys"><h3><span class="section-heading">Sapling extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-extended-spending-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A Sapling extended spending key
|
||||
<span class="math">\((\mathsf{ask, nsk, ovk, dk, c})\)</span>
|
||||
, at depth
|
||||
|
|
@ -665,7 +665,7 @@ License: MIT</pre>
|
|||
.</p>
|
||||
<p>When encoded as Bech32, the Human-Readable Part is <code>secret-extended-key-main</code> for the production network, or <code>secret-extended-key-test</code> for the test network.</p>
|
||||
</section>
|
||||
<section id="sapling-extended-full-viewing-keys"><h3><span class="section-heading">Sapling extended full viewing keys</span><span class="section-anchor"> <a href="#sapling-extended-full-viewing-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sapling-extended-full-viewing-keys"><h3><span class="section-heading">Sapling extended full viewing keys</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-extended-full-viewing-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A Sapling extended full viewing key
|
||||
<span class="math">\((\mathsf{ak, nk, ovk, dk, c})\)</span>
|
||||
, at depth
|
||||
|
|
@ -697,7 +697,7 @@ License: MIT</pre>
|
|||
.</p>
|
||||
<p>When encoded as Bech32, the Human-Readable Part is <code>zxviews</code> for the production network, or <code>zxviewtestsapling</code> for the test network.</p>
|
||||
</section>
|
||||
<section id="sprout-extended-spending-keys"><h3><span class="section-heading">Sprout extended spending keys</span><span class="section-anchor"> <a href="#sprout-extended-spending-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sprout-extended-spending-keys"><h3><span class="section-heading">Sprout extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-extended-spending-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A Sprout extended spending key
|
||||
<span class="math">\((\mathsf{a_{sk}, c})\)</span>
|
||||
, at depth
|
||||
|
|
@ -730,10 +730,10 @@ License: MIT</pre>
|
|||
<p>When encoded as Bech32, the Human-Readable Part is <code>zxsprout</code> for the production network, or <code>zxtestsprout</code> for the test network. Sprout extended spending keys are encoded using Bech32 even though other Sprout keys and addresses are encoded using Base58Check.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="test-vectors"><h2><span class="section-heading">Test Vectors</span><span class="section-anchor"> <a href="#test-vectors"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="test-vectors"><h2><span class="section-heading">Test Vectors</span><span class="section-anchor"> <a rel="bookmark" href="#test-vectors"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>TBC</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li><a href="https://github.com/zcash-hackworks/zip32">https://github.com/zcash-hackworks/zip32</a></li>
|
||||
<li><a href="https://github.com/zcash/librustzcash/pull/29">https://github.com/zcash/librustzcash/pull/29</a></li>
|
||||
|
|
@ -741,7 +741,7 @@ License: MIT</pre>
|
|||
<li><a href="https://github.com/zcash/zcash/pull/3492">https://github.com/zcash/zcash/pull/3492</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
|
@ -17,15 +17,15 @@ Status: Final
|
|||
Category: Wallet
|
||||
Created: 2018-06-13
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">4</a></p>
|
||||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205. <a id="id3" class="footnote_reference" href="#zip-0205">5</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This document proposes a checksummed base32 format, "Bech32", and a standard for Sapling addresses and keys using it.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Since launch, Zcash has relied on Base58 addresses with a truncated double-SHA256 checksum, inherited from Bitcoin. They were part of the original Bitcoin software and their scope was extended in BIP 13 <a id="id4" class="footnote_reference" href="#bip-0013">6</a> for P2SH (Pay-to-Script-Hash) addresses. However, both the character set and the checksum algorithm have limitations:</p>
|
||||
<ul>
|
||||
<li>Base58 needs a lot of space in QR codes, as it cannot use the ''alphanumeric mode''.</li>
|
||||
|
|
@ -37,7 +37,7 @@ License: MIT</pre>
|
|||
<p>To address these issues, Bitcoin adopted a new encoding called Bech32 <a id="id5" class="footnote_reference" href="#bip-0173">7</a>, for use with address types added by its Segregated Witness proposal. Zcash does not implement Segregated Witness, but it reuses Bech32 with address and key types introduced by the Sapling network upgrade <a id="id6" class="footnote_reference" href="#zip-0205">5</a>.</p>
|
||||
<p>Since the description of Bech32 in <a id="id7" class="footnote_reference" href="#bip-0173">7</a> is partially entangled with Segregated Witness address formats, we have found it clearer to write this ZIP to specify Bech32 separately. This specification should be read in conjunction with section 5.6 ("Encodings of Addresses and Keys") of the Zcash Sapling protocol specification <a id="id8" class="footnote_reference" href="#protocol">2</a>, and with ZIP 32 which specifies additional key types for support of shielded hierarchical deterministic wallets <a id="id9" class="footnote_reference" href="#zip-0032">3</a>.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>We describe the general checksummed base32 format called ''Bech32''. Its use for Sapling payment addresses and keys is defined in the Sapling protocol specification <a id="id10" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
<p>A Bech32 string consists of:</p>
|
||||
<ul>
|
||||
|
|
@ -106,7 +106,7 @@ License: MIT</pre>
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<section id="checksum"><h3><span class="section-heading">Checksum</span><span class="section-anchor"> <a href="#checksum"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="checksum"><h3><span class="section-heading">Checksum</span><span class="section-anchor"> <a rel="bookmark" href="#checksum"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The last six characters of the data part form a checksum and contain no information. Valid strings MUST pass the criteria for validity specified by the Python3 code snippet below. The checksum is defined so that the function <code>bech32_verify_checksum</code> returns true when its arguments are:</p>
|
||||
<ul>
|
||||
<li><code>hrp</code>: the human-readable part as a string;</li>
|
||||
|
|
@ -133,23 +133,23 @@ def bech32_verify_checksum(hrp, data):
|
|||
values = bech32_hrp_expand(hrp) + data
|
||||
polymod = bech32_polymod(values + [0,0,0,0,0,0]) ^ 1
|
||||
return [(polymod >> 5 * (5 - i)) & 31 for i in range(6)]</pre>
|
||||
<section id="error-correction"><h4><span class="section-heading">Error correction</span><span class="section-anchor"> <a href="#error-correction"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="error-correction"><h4><span class="section-heading">Error correction</span><span class="section-anchor"> <a rel="bookmark" href="#error-correction"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>One of the properties of these BCH codes is that they can be used for error correction. An unfortunate side effect of error correction is that it erodes error detection: correction changes invalid inputs into valid inputs, but if more than a few errors were made then the valid input may not be the correct input. Use of an incorrect but valid input can cause funds to be lost irrecoverably. Because of this, implementations SHOULD NOT implement correction beyond potentially suggesting to the user where in the string an error might be found, without suggesting the correction to make.</p>
|
||||
</section>
|
||||
<section id="uppercase-lowercase"><h4><span class="section-heading">Uppercase/lowercase</span><span class="section-anchor"> <a href="#uppercase-lowercase"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="uppercase-lowercase"><h4><span class="section-heading">Uppercase/lowercase</span><span class="section-anchor"> <a rel="bookmark" href="#uppercase-lowercase"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The lowercase form is used when determining a character's value for checksum purposes.</p>
|
||||
<p>Encoders MUST always output an all-lowercase Bech32 string. If an uppercase version of the encoding result is desired (e.g. for presentation purposes, or QR code use), then an uppercasing procedure can be performed external to the encoding process.</p>
|
||||
<p>Decoders MUST NOT accept strings where some characters are uppercase and some are lowercase (such strings are referred to as mixed-case strings).</p>
|
||||
<p>For presentation, lowercase is usually preferable, but inside QR codes uppercase SHOULD be used, as those permit the use of <a href="http://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding">alphanumeric mode</a>, which is 45% more compact than the <a href="http://www.thonky.com/qr-code-tutorial/byte-mode-encoding">byte mode</a> that would otherwise be used.</p>
|
||||
</section>
|
||||
<section id="encoding"><h4><span class="section-heading">Encoding</span><span class="section-anchor"> <a href="#encoding"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="encoding"><h4><span class="section-heading">Encoding</span><span class="section-anchor"> <a rel="bookmark" href="#encoding"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<ul>
|
||||
<li>Start with the bits of the raw encoding of the appropriate address or key type, most significant bit per byte first.</li>
|
||||
<li>Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.</li>
|
||||
<li>Translate those bits, most significant bit first, to characters using the table above.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="decoding"><h4><span class="section-heading">Decoding</span><span class="section-anchor"> <a href="#decoding"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="decoding"><h4><span class="section-heading">Decoding</span><span class="section-anchor"> <a rel="bookmark" href="#decoding"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Software interpreting a Bech32-encoded address MUST first verify that the human-readable part matches that of a specified address type, and similarly for keys.</p>
|
||||
<p>If this check passes, convert the rest of the data to bytes:</p>
|
||||
<ul>
|
||||
|
|
@ -162,31 +162,31 @@ def bech32_verify_checksum(hrp, data):
|
|||
</section>
|
||||
</section>
|
||||
</section>
|
||||
<section id="compatibility"><h2><span class="section-heading">Compatibility</span><span class="section-anchor"> <a href="#compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="compatibility"><h2><span class="section-heading">Compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Only software supporting the Sapling network upgrade is able to use these addresses.</p>
|
||||
<p>There is no effect on support for transparent addresses and keys, or for Sprout z-addresses and keys; these will continue to be encoded using Base58Check, and MUST NOT be encoded using Bech32.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="why-use-base32-at-all"><h3><span class="section-heading">Why use base32 at all?</span><span class="section-anchor"> <a href="#why-use-base32-at-all"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="why-use-base32-at-all"><h3><span class="section-heading">Why use base32 at all?</span><span class="section-anchor"> <a rel="bookmark" href="#why-use-base32-at-all"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The lack of mixed case makes it more efficient to read out loud or to put into QR codes. It does come with a 15% length increase. However, the length of a Bech32-encoded Sapling payment address remains below 80 characters, which reduces the likelihood of line splitting in terminals or email. Thus, cutting-and-pasting of addresses is still reliable.</p>
|
||||
</section>
|
||||
<section id="why-call-it-bech32"><h3><span class="section-heading">Why call it Bech32?</span><span class="section-anchor"> <a href="#why-call-it-bech32"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="why-call-it-bech32"><h3><span class="section-heading">Why call it Bech32?</span><span class="section-anchor"> <a rel="bookmark" href="#why-call-it-bech32"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>"Bech" contains the characters BCH (the error detection algorithm used) and sounds a bit like "base". The term Bech32 is established for Bitcoin and there was no reason to use a different name for it in Zcash Sapling.</p>
|
||||
</section>
|
||||
<section id="why-not-support-bech32-encoding-of-sprout-or-transparent-addresses"><h3><span class="section-heading">Why not support Bech32 encoding of Sprout or transparent addresses?</span><span class="section-anchor"> <a href="#why-not-support-bech32-encoding-of-sprout-or-transparent-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="why-not-support-bech32-encoding-of-sprout-or-transparent-addresses"><h3><span class="section-heading">Why not support Bech32 encoding of Sprout or transparent addresses?</span><span class="section-anchor"> <a rel="bookmark" href="#why-not-support-bech32-encoding-of-sprout-or-transparent-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This was not considered to be sufficiently well-motivated given the compatibility issues that would arise from having two formats for these address types, with pre-Sapling software not supporting the new format.</p>
|
||||
</section>
|
||||
<section id="why-include-a-separator-in-addresses"><h3><span class="section-heading">Why include a separator in addresses?</span><span class="section-anchor"> <a href="#why-include-a-separator-in-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="why-include-a-separator-in-addresses"><h3><span class="section-heading">Why include a separator in addresses?</span><span class="section-anchor"> <a rel="bookmark" href="#why-include-a-separator-in-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>That way the human-readable part is unambiguously separated from the data part, avoiding potential collisions with other human-readable parts that share a prefix. It also allows us to avoid having character-set restrictions on the human-readable part. The separator is ''1'' because using a non-alphanumeric character would complicate copy-pasting of addresses (with no double-click selection in several applications). Therefore an alphanumeric character outside the normal character set was chosen.</p>
|
||||
</section>
|
||||
<section id="why-not-use-an-existing-base32-character-set"><h3><span class="section-heading">Why not use an existing base32 character set?</span><span class="section-anchor"> <a href="#why-not-use-an-existing-base32-character-set"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="why-not-use-an-existing-base32-character-set"><h3><span class="section-heading">Why not use an existing base32 character set?</span><span class="section-anchor"> <a rel="bookmark" href="#why-not-use-an-existing-base32-character-set"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Existing character sets for base-32 encodings include <a href="https://www.rfc-editor.org/rfc/rfc3548.html">RFC 3548</a> and <a href="https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt">z-base-32</a>. The set used for Bech32 was chosen to minimize ambiguity according to <a href="https://hissa.nist.gov/~black/GTLD/">this</a> visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.</p>
|
||||
</section>
|
||||
<section id="why-are-the-high-bits-of-the-human-readable-part-processed-first"><h3><span class="section-heading">Why are the high bits of the human-readable part processed first?</span><span class="section-anchor"> <a href="#why-are-the-high-bits-of-the-human-readable-part-processed-first"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="why-are-the-high-bits-of-the-human-readable-part-processed-first"><h3><span class="section-heading">Why are the high bits of the human-readable part processed first?</span><span class="section-anchor"> <a rel="bookmark" href="#why-are-the-high-bits-of-the-human-readable-part-processed-first"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This design choice had a rationale for Bitcoin Segregated Witness addresses (see <a id="id12" class="footnote_reference" href="#bip-0173">7</a>) that does not apply to Zcash Sapling addresses. It is retained for compatibility with Bech32 encoders/decoders written for Bitcoin.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="reference-implementations"><h2><span class="section-heading">Reference implementations</span><span class="section-anchor"> <a href="#reference-implementations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementations"><h2><span class="section-heading">Reference implementations</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>The encoder/decoder used by <code>zcashd</code>:
|
||||
<ul>
|
||||
|
|
@ -213,10 +213,10 @@ def bech32_verify_checksum(hrp, data):
|
|||
</ul>
|
||||
<p>Note that the encoders written for Bitcoin may make assumptions specific to Segregated Witness address formats that do not apply to Zcash. Only the Python one has been tested with Zcash at the time of writing.</p>
|
||||
</section>
|
||||
<section id="examples"><h2><span class="section-heading">Examples</span><span class="section-anchor"> <a href="#examples"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="examples"><h2><span class="section-heading">Examples</span><span class="section-anchor"> <a rel="bookmark" href="#examples"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>TODO: add valid Sapling payment addresses and keys, and their corresponding raw encodings.</p>
|
||||
</section>
|
||||
<section id="test-vectors"><h2><span class="section-heading">Test vectors</span><span class="section-anchor"> <a href="#test-vectors"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="test-vectors"><h2><span class="section-heading">Test vectors</span><span class="section-anchor"> <a rel="bookmark" href="#test-vectors"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The following strings are valid Bech32:</p>
|
||||
<ul>
|
||||
<li><code>A12UEL5L</code></li>
|
||||
|
|
@ -246,11 +246,11 @@ def bech32_verify_checksum(hrp, data):
|
|||
<li><code>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3pjxtptv</code>: Non-zero padding in 8-to-5 conversion</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="checksum-design"><h2><span class="section-heading">Checksum design</span><span class="section-anchor"> <a href="#checksum-design"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="design-choices"><h3><span class="section-heading">Design choices</span><span class="section-anchor"> <a href="#design-choices"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="checksum-design"><h2><span class="section-heading">Checksum design</span><span class="section-anchor"> <a rel="bookmark" href="#checksum-design"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="design-choices"><h3><span class="section-heading">Design choices</span><span class="section-anchor"> <a rel="bookmark" href="#design-choices"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>BCH codes can be constructed over any prime-power alphabet and can be chosen to have a good trade-off between size and error-detection capabilities. Unlike <a href="https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction">Reed-Solomon codes</a>, they are not restricted in length to one less than the alphabet size. While they also support efficient error correction, the implementation of just error detection is very simple.</p>
|
||||
<p>We pick 6 checksum characters as a trade-off between length of the addresses and the error-detection capabilities, as 6 characters is the lowest number sufficient for a random failure chance below 1 per billion. For the length of data we're most interested in protecting (up to 77 bytes excluding the separator, for a Sapling payment address), BCH codes can be constructed that guarantee detecting up to 4 errors. Longer data is also supported with slightly weaker error detection.</p>
|
||||
<section id="selected-properties"><h4><span class="section-heading">Selected properties</span><span class="section-anchor"> <a href="#selected-properties"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="selected-properties"><h4><span class="section-heading">Selected properties</span><span class="section-anchor"> <a rel="bookmark" href="#selected-properties"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Many of these codes perform badly when dealing with more errors than they are designed to detect, but not all. For that reason, we consider codes that are designed to detect only 3 errors as well as 4 errors, and analyse how well they perform in practice.</p>
|
||||
<p>The specific code chosen here is the result of:</p>
|
||||
<ul>
|
||||
|
|
@ -261,7 +261,7 @@ def bech32_verify_checksum(hrp, data):
|
|||
</ul>
|
||||
<p>As a naive search would require over 6.5 * 10<sup>19</sup> checksum evaluations, a collision-search approach was used for analysis. The code can be found <a href="https://github.com/sipa/ezbase32/">here</a>.</p>
|
||||
</section>
|
||||
<section id="properties"><h4><span class="section-heading">Properties</span><span class="section-anchor"> <a href="#properties"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="properties"><h4><span class="section-heading">Properties</span><span class="section-anchor"> <a rel="bookmark" href="#properties"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The following table summarizes the chances for detection failure (as multiples of 1 in 10<sup>9</sup>).</p>
|
||||
<table>
|
||||
<tbody>
|
||||
|
|
@ -346,10 +346,10 @@ def bech32_verify_checksum(hrp, data):
|
|||
</section>
|
||||
</section>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This document is closely based on BIP 173 written by Pieter Wuille and Greg Maxwell, which was inspired by the <a href="https://rusty.ozlabs.org/?p=578">address proposal</a> by Rusty Russell and the <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-February/004402.html">base32</a> proposal by Mark Friedenbach. BIP 173 also had input from Luke Dashjr, Johnson Lau, Eric Lombrozo, Peter Todd, and various other reviewers.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Status: Final
|
|||
Category: Consensus
|
||||
Created: 2018-01-08
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
|
|
@ -29,10 +29,10 @@ License: MIT</pre>
|
|||
<dd>An intentional consensus rule change undertaken by the community in order to improve the network.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines a mechanism for coordinating upgrades of the Zcash network, in order to remove ambiguity about when network upgrades will activate, provide defined periods in which users should upgrade their local software, and minimize the risks to both the upgrading network and any users opting out of the changes.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash is a <em>consensual currency</em>: nobody is ever going to force someone to use a specific software implementation or a specific consensus branch of Zcash. <a id="id2" class="footnote_reference" href="#consensual-currency">2</a> As such, different sub-communities will always have the freedom to choose different variants or branches which offer different design trade-offs.</p>
|
||||
<p>The current Zcash software includes an <em>End-of-Service halt</em> feature, causing nodes running a particular version to automatically shut down approximately 16 weeks after that version was released (specifically, at the block height <code>DEPRECATION_HEIGHT</code> defined in the source code for that version). This was implemented for several reasons: <a id="id3" class="footnote_reference" href="#release-lifecycle">3</a></p>
|
||||
<ul>
|
||||
|
|
@ -48,7 +48,7 @@ License: MIT</pre>
|
|||
<p>Developers can rely on this cadence for coordinating network upgrades. Once the last pre-upgrade software version has been deprecated, they can reasonably assume that all node operators on the network either support the upgraded rules, or have explicitly chosen not to follow them.</p>
|
||||
<p>However, this behaviour is not sufficient for performing network upgrades. A globally-understood on-chain activation mechanism is necessary so that nodes can unambiguously know at what point the changes from an upgrade come into effect (and can enforce consensus rule changes, for example).</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The following constants are defined for every network upgrade:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
|
|
@ -67,7 +67,7 @@ License: MIT</pre>
|
|||
</dd>
|
||||
</dl>
|
||||
<p>The relationship between <code>CONSENSUS_BRANCH_ID</code> and <code>ACTIVATION_HEIGHT</code> is many-to-one: it is possible for many distinct consensus branches to descend from the same parent block (and thus have the same <code>ACTIVATION_HEIGHT</code>), but a specific consensus branch can only have one parent block. Concretely, this means that if the <code>ACTIVATION_HEIGHT</code> of a network upgrade is changed for any reason (e.g. security vulnerabilities or consensus bugs are discovered), the <code>CONSENSUS_BRANCH_ID</code> MUST also be changed.</p>
|
||||
<section id="activation-mechanism"><h3><span class="section-heading">Activation mechanism</span><span class="section-anchor"> <a href="#activation-mechanism"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="activation-mechanism"><h3><span class="section-heading">Activation mechanism</span><span class="section-anchor"> <a rel="bookmark" href="#activation-mechanism"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The Zcash block chain is broken into "epochs" of block height intervals <code>[ACTIVATION_HEIGHT_N, ACTIVATION_HEIGHT_{N+1})</code> (i.e. including <code>ACTIVATION_HEIGHT_N</code> and excluding <code>ACTIVATION_HEIGHT_{N+1}</code>), on which consensus rule sets are defined.</p>
|
||||
<p>When a consensus rule depends on activation of a particular upgrade, its implementation (and that of any network behavior or surrounding code that depends on it) MUST be gated by a block height check. For example:</p>
|
||||
<pre data-language="cpp"><span class="k">if</span> <span class="p">(</span><span class="n">CurrentEpoch</span><span class="p">(</span><span class="n">chainActive</span><span class="p">.</span><span class="n">Height</span><span class="p">(),</span> <span class="n">Params</span><span class="p">().</span><span class="n">GetConsensus</span><span class="p">())</span> <span class="o">==</span> <span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_OVERWINTER</span><span class="p">)</span> <span class="p">{</span>
|
||||
|
|
@ -83,40 +83,40 @@ License: MIT</pre>
|
|||
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
|
||||
<span class="c1">// Pre-Overwinter consensus rules applied to block</span>
|
||||
<span class="p">}</span></pre>
|
||||
<section id="block-validation"><h4><span class="section-heading">Block validation</span><span class="section-anchor"> <a href="#block-validation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="block-validation"><h4><span class="section-heading">Block validation</span><span class="section-anchor"> <a rel="bookmark" href="#block-validation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Incoming blocks known to have a particular height (due to their parent chain being entirely known) MUST be validated under the consensus rules corresponding to the expected consensus branch ID for that height.</p>
|
||||
<p>Incoming blocks with unknown heights (because at least one block header in their parent chain is unknown) MAY be cached, so that they can be reconsidered in the future after all their parents have been received.</p>
|
||||
</section>
|
||||
<section id="chain-reorganization"><h4><span class="section-heading">Chain reorganization</span><span class="section-anchor"> <a href="#chain-reorganization"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="chain-reorganization"><h4><span class="section-heading">Chain reorganization</span><span class="section-anchor"> <a rel="bookmark" href="#chain-reorganization"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>It is possible for a reorganization to occur that rolls back from after the activation height, to before that height. This can handled in the same way as any regular chain orphaning or reorganization, as long as the new chain is valid.</p>
|
||||
</section>
|
||||
<section id="post-activation-upgrading"><h4><span class="section-heading">Post-activation upgrading</span><span class="section-anchor"> <a href="#post-activation-upgrading"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="post-activation-upgrading"><h4><span class="section-heading">Post-activation upgrading</span><span class="section-anchor"> <a rel="bookmark" href="#post-activation-upgrading"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>If a user does not upgrade their node to a compatible software version before <code>ACTIVATION_HEIGHT</code> is reached, and the node continues running (which could normally only occur if the End-of-Service halt were bypassed), then the node will follow any pre-upgrade consensus branch that persists. In this case it may download blocks that are incompatible with the post-upgrade consensus branch. If the user subsequently upgrades their node to a compatible software version, the node will consider these blocks to be invalid, and if there are a significant number of invalid blocks it SHOULD shut down and alert the user of the issue.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="memory-pool"><h3><span class="section-heading">Memory pool</span><span class="section-anchor"> <a href="#memory-pool"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="memory-pool"><h3><span class="section-heading">Memory pool</span><span class="section-anchor"> <a rel="bookmark" href="#memory-pool"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>While the current chain tip height is below <code>ACTIVATION_HEIGHT</code>, nodes SHOULD NOT accept transactions that will only be valid on the post-upgrade consensus branch.</p>
|
||||
<p>When the current chain tip height reaches <code>ACTIVATION_HEIGHT</code>, the node's local transaction memory pool SHOULD be cleared of transactions that will never be valid on the post-upgrade consensus branch.</p>
|
||||
</section>
|
||||
<section id="two-way-replay-protection"><h3><span class="section-heading">Two-way replay protection</span><span class="section-anchor"> <a href="#two-way-replay-protection"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="two-way-replay-protection"><h3><span class="section-heading">Two-way replay protection</span><span class="section-anchor"> <a rel="bookmark" href="#two-way-replay-protection"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Before the Overwinter network upgrade, two-way replay protection is ensured by enforcing post-upgrade that the most significant bit of the transaction version is set to 1. <a id="id4" class="footnote_reference" href="#zip-0202">6</a> From the perspective of old nodes, the transactions will have a negative version number, which is invalid under the old consensus rules. Enforcing this rule trivially makes old transactions invalid on the Overwinter consensus branch.</p>
|
||||
<p>After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures committing to a specific <code>CONSENSUS_BRANCH_ID</code>. <a id="id5" class="footnote_reference" href="#zip-0143">4</a></p>
|
||||
</section>
|
||||
<section id="wipe-out-protection"><h3><span class="section-heading">Wipe-out protection</span><span class="section-anchor"> <a href="#wipe-out-protection"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="wipe-out-protection"><h3><span class="section-heading">Wipe-out protection</span><span class="section-anchor"> <a rel="bookmark" href="#wipe-out-protection"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Nodes running upgrade-aware software versions will enforce the upgraded consensus rules from <code>ACTIVATION_HEIGHT</code>. The chain from that height will not reorganize to a pre-upgrade consensus branch if any block in that consensus branch would violate the new consensus rules.</p>
|
||||
<p>Care must be taken, however, to account for possible edge cases where the old and new consensus rules do not differ. For example, if the non-upgraded chain only contained empty blocks from <code>ACTIVATION_HEIGHT</code>, and the coinbase transactions were valid under both the old and new consensus rules, a wipe-out could occur. The Overwinter network upgrade is not susceptible to this because all previous transaction versions will become invalid, meaning that the coinbase transactions must use the newer transaction version. More generally, this issue could be addressed in a future network upgrade by modifying the block header to include a commitment to the <code>CONSENSUS_BRANCH_ID</code>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Overwinter network upgrade. <a id="id6" class="footnote_reference" href="#zip-0201">5</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/2898">https://github.com/zcash/zcash/pull/2898</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Status: Final
|
|||
Category: Network
|
||||
Created: 2018-01-15
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in IP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
|
|
@ -23,7 +23,7 @@ License: MIT</pre>
|
|||
<dd>Code-name for the first Zcash network upgrade, also known as Network Upgrade Zero.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines an upgrade to the network handshake and peer management required for network upgrades following the Network Upgrade Activation Mechanism <a id="id3" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>Related to:</p>
|
||||
<ul>
|
||||
|
|
@ -32,10 +32,10 @@ License: MIT</pre>
|
|||
<li>Transaction Expiry <a id="id6" class="footnote_reference" href="#zip-0203">5</a>.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>With scheduled network upgrades, at the activation height, nodes on each consensus branch should disconnect from nodes on other consensus branches and only accept new incoming connections from nodes on the same consensus branch.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>When a new inbound connection is received or an outbound connection created, a CNode object is instantiated with the version field set to INIT_PROTO_VERSION which has a value of 209. This value is not transmitted across the network, but for legacy reasons and technical debt beyond the scope of this ZIP, this value will not be changed.</p>
|
||||
<p>Once the two nodes have connected and started the handshake to negotiate the protocol version, the version field of CNode will be updated. The handshake <a id="id7" class="footnote_reference" href="#bitcoin-version-handshake">8</a> involves "version" and "verack" messages being exchanged.:</p>
|
||||
<pre>L -> R: Send version message with the local peer's version
|
||||
|
|
@ -51,7 +51,7 @@ L: Sets version to the minimum of the 2 versions</pre>
|
|||
...
|
||||
}</pre>
|
||||
<p>where <code>PROTOCOL_VERSION</code> is the highest protocol version supported by the node.</p>
|
||||
<section id="rejecting-pre-overwinter-connections"><h3><span class="section-heading">Rejecting Pre-Overwinter Connections</span><span class="section-anchor"> <a href="#rejecting-pre-overwinter-connections"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="rejecting-pre-overwinter-connections"><h3><span class="section-heading">Rejecting Pre-Overwinter Connections</span><span class="section-anchor"> <a rel="bookmark" href="#rejecting-pre-overwinter-connections"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Currently, nodes will reject connections from peers with an advertised protocol version lower than the other node's minimum supported protocol version.</p>
|
||||
<p>This value is defined as:</p>
|
||||
<pre>//! disconnect from peers older than this proto version
|
||||
|
|
@ -78,7 +78,7 @@ static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
|
|||
<li>disconnect any existing connections to pre-Overwinter nodes.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="network-coalescence"><h3><span class="section-heading">Network Coalescence</span><span class="section-anchor"> <a href="#network-coalescence"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="network-coalescence"><h3><span class="section-heading">Network Coalescence</span><span class="section-anchor"> <a rel="bookmark" href="#network-coalescence"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Prior to the activation of Overwinter, nodes running a pre-Overwinter protocol version (e.g. 170002) and the Overwinter protocol version (170003 for testnet; 170005 for mainnet) remain connected with the same consensus rules, but it is desirable for nodes supporting Overwinter to connect preferentially to other nodes supporting Overwinter.</p>
|
||||
<p>This is intended to help the network partition smoothly, since nodes should already be connected to (a majority of) peers running the same protocol version. Otherwise an Overwinter node may find their connections to Sprout nodes dropped suddenly at the activation height, potentially leaving them isolated and susceptible to eclipse attacks. <a id="id9" class="footnote_reference" href="#eclipse-attack">9</a></p>
|
||||
<p>To assist network coalescence before the activation height, we update the eviction process to place a higher priority on evicting Sprout nodes.</p>
|
||||
|
|
@ -125,7 +125,7 @@ if (nActivationHeight > 0 &&
|
|||
</blockquote>
|
||||
<p>The existing eviction process will classify and divide eviction candidates into buckets called netgroups. If a netgroup only has one peer, it will not be evicted. This means at least one pre-Overwinter node will remain connected upto the activation block height, barring any network issues or a high ban score.</p>
|
||||
</section>
|
||||
<section id="disconnecting-existing-connections"><h3><span class="section-heading">Disconnecting Existing Connections</span><span class="section-anchor"> <a href="#disconnecting-existing-connections"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="disconnecting-existing-connections"><h3><span class="section-heading">Disconnecting Existing Connections</span><span class="section-anchor"> <a rel="bookmark" href="#disconnecting-existing-connections"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>At the activation block height, an Overwinter node may still remain connected to pre-Overwinter nodes. Currently, when connecting, a node can only perform the networking handshake once, where it sends the version message before any other messages are processed. To disconnect existing pre-Overwinter connections, <code>ProcessMessage</code> is modified so that once Overwinter activates, if necessary, the protocol version of an existing peer is validated when inbound messages arrive.</p>
|
||||
<p>Example code:</p>
|
||||
<pre>bool static ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv, int64_t nTimeReceived)
|
||||
|
|
@ -157,7 +157,7 @@ if (nActivationHeight > 0 &&
|
|||
}</pre>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment-of-overwinter"><h2><span class="section-heading">Deployment of Overwinter</span><span class="section-anchor"> <a href="#deployment-of-overwinter"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="deployment-of-overwinter"><h2><span class="section-heading">Deployment of Overwinter</span><span class="section-anchor"> <a rel="bookmark" href="#deployment-of-overwinter"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Overwinter network upgrade defines the following network upgrade constants <a id="id10" class="footnote_reference" href="#zip-0200">3</a>:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
|
|
@ -177,14 +177,14 @@ if (nActivationHeight > 0 &&
|
|||
<li>ZIP 143 <a id="id14" class="footnote_reference" href="#zip-0143">2</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating, Overwinter and pre-Overwinter nodes are compatible and can connect to each other. However, Overwinter nodes will have a preference for connecting to other Overwinter nodes, so pre-Overwinter nodes will gradually be disconnected in the run up to activation.</p>
|
||||
<p>Once the network upgrades, even though pre-Overwinter nodes can still accept the numerically larger protocol version used by Overwinter as being valid, Overwinter nodes will always disconnect peers using lower protocol versions.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/2919">https://github.com/zcash/zcash/pull/2919</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,15 +14,15 @@ Status: Final
|
|||
Category: Consensus
|
||||
Created: 2018-01-10
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch", "network upgrade", and "consensus rule change" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The term "Overwinter" in this document is to be interpreted as described in ZIP 201. <a id="id3" class="footnote_reference" href="#zip-0201">4</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines a new transaction format required for Network Upgrade Activation Mechanism <a id="id4" class="footnote_reference" href="#zip-0200">3</a> and Transaction Expiry <a id="id5" class="footnote_reference" href="#zip-0203">5</a>.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash launched with support for upstream Bitcoin version 1 transactions and defined a new version 2 transaction format which added fields required for shielded transactions.</p>
|
||||
<table>
|
||||
<thead>
|
||||
|
|
@ -106,8 +106,8 @@ License: MIT</pre>
|
|||
<li>support transaction expiry <a id="id7" class="footnote_reference" href="#zip-0203">5</a>.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="transaction-format-version-3"><h3><span class="section-heading">Transaction format version 3</span><span class="section-anchor"> <a href="#transaction-format-version-3"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="transaction-format-version-3"><h3><span class="section-heading">Transaction format version 3</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-format-version-3"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A new version 3 transaction format will be introduced for Overwinter.</p>
|
||||
<p>The version 3 format differs from the version 2 format in the following ways:</p>
|
||||
<ul>
|
||||
|
|
@ -211,7 +211,7 @@ License: MIT</pre>
|
|||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<section id="header-field"><h3><span class="section-heading">Header Field</span><span class="section-anchor"> <a href="#header-field"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="header-field"><h3><span class="section-heading">Header Field</span><span class="section-anchor"> <a rel="bookmark" href="#header-field"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The first four bytes of pre-Overwinter and Overwinter transactions are little-endian encoded.</p>
|
||||
<p>Version 1 transaction (txid 5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061 <a href="https://zcash.blockexplorer.com/tx/5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061">https://zcash.blockexplorer.com/tx/5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061</a>)</p>
|
||||
<ul>
|
||||
|
|
@ -260,18 +260,18 @@ License: MIT</pre>
|
|||
<p>Overwinter parsers will accept the transaction as valid as the most significant bit of the header has been set. By masking off (unsetting) the most significant bit, the parser can retrieve the transaction version number:</p>
|
||||
<pre>0x80000003 & 0x7FFFFFFF = 0x00000003 = 3</pre>
|
||||
</section>
|
||||
<section id="version-group-id"><h3><span class="section-heading">Version Group ID</span><span class="section-anchor"> <a href="#version-group-id"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="version-group-id"><h3><span class="section-heading">Version Group ID</span><span class="section-anchor"> <a rel="bookmark" href="#version-group-id"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The version group ID is a non-zero, random and unique identifier, of type <code>uint32</code>, assigned to a transaction format version, or a group of soft-forking transaction format versions. The version group ID helps nodes disambiguate between consensus branches using the same version number.</p>
|
||||
<p>That is, it prevents a client on one branch of the network from attempting to parse transactions intended for another consensus branch, in the situation where the transactions share the same format version number but are actually specified differently. For example, Zcash and a clone of Zcash might both define their own custom v3 transaction formats, but each will have its own unique version group ID, so that they can reject v3 transactions with unknown version group IDs.</p>
|
||||
<p>The combination of transaction version and version group ID, <code>nVersion || nVersionGroupId</code>, uniquely defines the transaction format, thus enabling parsers to reject transactions from outside the client's chain which cannot be parsed.</p>
|
||||
<p>By convention, it is expected that when introducing a new transaction version requiring a network upgrade, a new unique version group ID will be assigned to that transaction version.</p>
|
||||
<p>However, if a new transaction version can be correctly parsed according to the format of a preceding version (that is, it only restricts the format, or defines fields that were previously reserved and which old parsers can safely ignore), then the same version group ID MAY be re-used.</p>
|
||||
</section>
|
||||
<section id="expiry-height"><h3><span class="section-heading">Expiry Height</span><span class="section-anchor"> <a href="#expiry-height"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="expiry-height"><h3><span class="section-heading">Expiry Height</span><span class="section-anchor"> <a rel="bookmark" href="#expiry-height"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The expiry height field, as defined in the Transaction Expiry ZIP <a id="id8" class="footnote_reference" href="#zip-0203">5</a>, stores the block height after which a transaction can no longer be mined.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="transaction-validation"><h2><span class="section-heading">Transaction Validation</span><span class="section-anchor"> <a href="#transaction-validation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="transaction-validation"><h2><span class="section-heading">Transaction Validation</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-validation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>A valid Overwinter transaction intended for Zcash MUST have:</p>
|
||||
<ul>
|
||||
<li>version number 3; and</li>
|
||||
|
|
@ -286,9 +286,9 @@ License: MIT</pre>
|
|||
</ul>
|
||||
<p>Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id10" class="footnote_reference" href="#zip-0143">2</a>.</p>
|
||||
</section>
|
||||
<section id="implementation"><h2><span class="section-heading">Implementation</span><span class="section-anchor"> <a href="#implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="implementation"><h2><span class="section-heading">Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The comments and code samples in this section apply to the reference C++ implementation of Zcash. Other implementations may vary.</p>
|
||||
<section id="transaction-version"><h3><span class="section-heading">Transaction Version</span><span class="section-anchor"> <a href="#transaction-version"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="transaction-version"><h3><span class="section-heading">Transaction Version</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-version"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Transaction version remains a positive value. The main Zcash chain will follow convention and continue to order transaction versions in an ascending order.</p>
|
||||
<p>Tests can continue to check for the existence of forwards-compatible transaction fields by checking the transaction version using comparison operators:</p>
|
||||
<pre>if (tx.nVersion >= 2) {
|
||||
|
|
@ -303,7 +303,7 @@ License: MIT</pre>
|
|||
<p>Tests can continue to set the version to zero as an error condition:</p>
|
||||
<pre>mtx.nVersion = 0</pre>
|
||||
</section>
|
||||
<section id="overwinter-validation"><h3><span class="section-heading">Overwinter Validation</span><span class="section-anchor"> <a href="#overwinter-validation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="overwinter-validation"><h3><span class="section-heading">Overwinter Validation</span><span class="section-anchor"> <a rel="bookmark" href="#overwinter-validation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>To test if the format of an Overwinter transaction is v3 or not:</p>
|
||||
<pre>if (tx.fOverwintered && tx.nVersion == 3) {
|
||||
// Valid v3 format transaction
|
||||
|
|
@ -320,17 +320,17 @@ License: MIT</pre>
|
|||
<p>Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id11" class="footnote_reference" href="#zip-0143">2</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Overwinter network upgrade. The activation block height proposal is in <a id="id12" class="footnote_reference" href="#zip-0201">4</a>.</p>
|
||||
</section>
|
||||
<section id="backwards-compatibility"><h2><span class="section-heading">Backwards compatibility</span><span class="section-anchor"> <a href="#backwards-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="backwards-compatibility"><h2><span class="section-heading">Backwards compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backwards-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change" <a id="id13" class="footnote_reference" href="#zip-0200">3</a> between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid.</p>
|
||||
<p>Once Overwinter has activated, Overwinter-compatible software will reject version 1 and version 2 transactions, and will only accept transactions based upon supported transaction version numbers and recognized version group IDs.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/2925">https://github.com/zcash/zcash/pull/2925</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,16 +14,16 @@ Status: Final
|
|||
Category: Consensus
|
||||
Created: 2018-01-09
|
||||
License: MIT</pre>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This is a Standards ZIP describing a new consensus rule to set an expiration time after which a transaction cannot be mined. If it is not mined within that time, the transaction will be removed from nodes' mempools.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Transactions that have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing a transaction to set a block height after which it cannot be mined would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent.</p>
|
||||
<p>Advantages include optimizing mempool performance by removing transactions that will not be mined, and potentially simplifying bidirectional payment channels by reducing the need to store and compress revocations for past states, since transactions not committed to the chain could expire and become invalid after a period of time.</p>
|
||||
<p>If the expiry is at block height N, then the transaction must be included in block N or earlier. Block N+1 will be too late, and the transaction will be removed from the mempool.</p>
|
||||
<p>The new consensus rule will enforce that the transaction will not be considered valid if included in block of height greater than N, and blocks that include expired transactions will not be considered valid.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Transactions will have a new field, <code>nExpiryHeight</code>, which will set the block height after which transactions will be removed from the mempool if they have not been mined.</p>
|
||||
<p>The data type for <code>nExpiryHeight</code> will be <code>uint32_t</code>. If used in combination with <code>nLockTime</code>, both <code>nLockTime</code> and <code>nExpiryHeight</code> must be block heights. <code>nExpiryHeight</code> will never be a UNIX timestamp, unlike <code>nLockTime</code> values, and thus the maximum expiry height will be 499999999.</p>
|
||||
<p>For the example below, the last block that the transaction below could possibly be included in is 3539. After that, it will be removed from the mempool.</p>
|
||||
|
|
@ -33,11 +33,11 @@ License: MIT</pre>
|
|||
"expiryheight": 3539,</pre>
|
||||
<p>Default: 20 blocks, or about 1 hour assuming 2.5 minute block times. A configuration option can be used to set the user's default. Minimum: No minimum Maximum: 499999999, about 380 years No limit: To set no limit on transactions (so that they do not expire), <code>nExpiryHeight</code> should be set to 0. Coinbase: <code>nExpiryHeight</code> on coinbase transactions is ignored, and is set to 0 by convention.</p>
|
||||
<p>Every time a transaction expires and should be removed from the mempool, so should all of its dependent transactions.</p>
|
||||
<section id="wallet-behavior-and-ui"><h3><span class="section-heading">Wallet behavior and UI</span><span class="section-anchor"> <a href="#wallet-behavior-and-ui"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="wallet-behavior-and-ui"><h3><span class="section-heading">Wallet behavior and UI</span><span class="section-anchor"> <a rel="bookmark" href="#wallet-behavior-and-ui"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>With the addition of this feature, zero-confirmation transactions with an expiration block height set will have even less guarantee of inclusion. This means that UIs and services must never rely on zero-confirmation transactions in Zcash.</p>
|
||||
<p>Wallet should notify the user of expired transactions that must be re-sent.</p>
|
||||
</section>
|
||||
<section id="rpc"><h3><span class="section-heading">RPC</span><span class="section-anchor"> <a href="#rpc"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="rpc"><h3><span class="section-heading">RPC</span><span class="section-anchor"> <a rel="bookmark" href="#rpc"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>To make changes to the sendtoaddress and z_sendmany commands backwards compatible for future changes, keyword arguments should be accepted by the RPC interface.</p>
|
||||
<p>For Overwinter, tx expiry will be set to a default that can be overridden by a flag <cite>txexpirydelta</cite> set in the config file.</p>
|
||||
<p>-txexpirydelta= set the number of blocks after which a transaction that has not been mined will become invalid</p>
|
||||
|
|
@ -45,18 +45,18 @@ License: MIT</pre>
|
|||
<pre>listtransactions "*" 10 0 "expired"</pre>
|
||||
<p>WalletTxToJSON shows a boolean expired true/false.</p>
|
||||
</section>
|
||||
<section id="config"><h3><span class="section-heading">Config</span><span class="section-anchor"> <a href="#config"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="config"><h3><span class="section-heading">Config</span><span class="section-anchor"> <a rel="bookmark" href="#config"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The default will be user-configurable with the option <cite>txexpirydelta</cite>.</p>
|
||||
<p><cite>--txexpirydelta=100</cite></p>
|
||||
</section>
|
||||
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This feature will be deployed with Overwinter. The activation blockheight proposal is in <a id="id1" class="footnote_reference" href="#zip-0201">1</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/2874">https://github.com/zcash/zcash/pull/2874</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="zip-0201" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Status: Final
|
|||
Category: Consensus
|
||||
Created: 2018-10-08
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">2</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
|
|
@ -23,11 +23,11 @@ License: MIT</pre>
|
|||
<dd>Code-name for the second Zcash network upgrade, also known as Network Upgrade 1.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines the deployment of the Sapling network upgrade. In addition, it describes a hard fork that occurred on testnet to allow "minimum-difficulty" blocks.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="sapling-deployment"><h3><span class="section-heading">Sapling deployment</span><span class="section-anchor"> <a href="#sapling-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="sapling-deployment"><h3><span class="section-heading">Sapling deployment</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary sources of information about Sapling consensus protocol changes are:</p>
|
||||
<ul>
|
||||
<li>The Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol">1</a>.</li>
|
||||
|
|
@ -58,21 +58,21 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
|
|||
<li>disconnect any existing connections to pre-Sapling nodes.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="change-to-difficulty-adjustment-on-testnet"><h3><span class="section-heading">Change to difficulty adjustment on testnet</span><span class="section-anchor"> <a href="#change-to-difficulty-adjustment-on-testnet"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="change-to-difficulty-adjustment-on-testnet"><h3><span class="section-heading">Change to difficulty adjustment on testnet</span><span class="section-anchor"> <a rel="bookmark" href="#change-to-difficulty-adjustment-on-testnet"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Section 7.6.3 of <a id="id9" class="footnote_reference" href="#protocol">1</a> describes the algorithm used to adjust the difficulty of a block (defined in terms of a "target threshold") based on the <code>nTime</code> and <code>nBits</code> fields of preceding blocks.</p>
|
||||
<p>This algorithm changed on testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is at least 15 minutes after that of the preceding block, then the block is a minimum-difficulty block, and its target threshold is set to the value of PoWLimit for testnet (see <a id="id10" class="footnote_reference" href="#protocol">1</a> section 5.3). However, its <code>nBits</code> field is still computed according to the original difficulty adjustment algorithm.</p>
|
||||
<p>This does not affect how the minimum-difficulty block is treated for subsequent difficulty adjustments. In particular, only the <code>nBits</code> field computed by the original algorithm is used for the purpose of computing the MeanTarget values from which subsequent difficulty changes are calculated.</p>
|
||||
<p>This change does not affect mainnet.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating, Sapling and pre-Sapling nodes are compatible and can connect to each other. However, Sapling nodes will have a preference for connecting to other Sapling nodes, so pre-Sapling nodes will gradually be disconnected in the run up to activation.</p>
|
||||
<p>Once the network upgrades, even though pre-Sapling nodes can still accept the numerically larger protocol version used by Sapling as being valid, Sapling nodes will always disconnect peers using lower protocol versions.</p>
|
||||
</section>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Support for Sapling consensus rules was implemented in zcashd version 2.0.0. The majority of support for RPC calls and persistence of Sapling z-addresses was implemented in version 2.0.1. Both of these versions advertise protocol version 170007.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Status: Final
|
|||
Category: Consensus
|
||||
Created: 2019-07-29
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">2</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
|
|
@ -27,11 +27,11 @@ License: MIT</pre>
|
|||
<dd>The Zcash production network, as defined in <a id="id4" class="footnote_reference" href="#protocol">1</a>.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines the deployment of the Blossom network upgrade.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="blossom-deployment"><h3><span class="section-heading">Blossom deployment</span><span class="section-anchor"> <a href="#blossom-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="blossom-deployment"><h3><span class="section-heading">Blossom deployment</span><span class="section-anchor"> <a rel="bookmark" href="#blossom-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary sources of information about Blossom consensus protocol changes are:</p>
|
||||
<ul>
|
||||
<li>The Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol">1</a>.</li>
|
||||
|
|
@ -62,15 +62,15 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating on each network, Blossom and pre-Blossom nodes are compatible and can connect to each other. However, Blossom nodes will have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will gradually be disconnected in the run up to activation.</p>
|
||||
<p>Once the network upgrades, even though pre-Blossom nodes can still accept the numerically larger protocol version used by Blossom as being valid, Blossom nodes will always disconnect peers using lower protocol versions.</p>
|
||||
<p>Unlike Overwinter and Sapling, Blossom does not define a new transaction version. Blossom transactions are therefore in the same v4 format as Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as defined in <a id="id11" class="footnote_reference" href="#protocol">1</a> section 7.1. This does not imply that transactions are valid across the Blossom activation, since signatures MUST use the appropriate consensus branch ID.</p>
|
||||
</section>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Support for Blossom on testnet is implemented in <code>zcashd</code> version 2.0.7, which advertises protocol version 170008. Support for Blossom on mainnet is implemented in <code>zcashd</code> version 2.1.0, which advertises protocol version 170009.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Status: Proposed
|
|||
Category: Consensus
|
||||
Created: 2019-01-04
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="id2" class="footnote_reference" href="#protocol-subsidyconcepts">3</a> <a id="id3" class="footnote_reference" href="#protocol-subsidies">5</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id4" class="footnote_reference" href="#zip-0200">8</a></p>
|
||||
|
|
@ -29,20 +29,20 @@ License: MIT</pre>
|
|||
<dd>The Zcash production network, as defined in the Zcash Protocol Specification. <a id="id6" class="footnote_reference" href="#protocol">2</a></dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal specifies a mechanism to support funding streams, distributed from a portion of the block subsidy for a specified range of block heights.</p>
|
||||
<p>This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 <a id="id7" class="footnote_reference" href="#zip-0214">11</a>. It should be read in conjunction with ZIP 1014 <a id="id8" class="footnote_reference" href="#zip-1014">13</a>, which describes the high-level requirements for that fund.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Motivation for the Zcash Development Fund is considered in ZIP 1014 <a id="id9" class="footnote_reference" href="#zip-1014">13</a>.</p>
|
||||
<p>This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP is being reintroduced for that purpose in order to reuse specification, analysis, and implementation effort.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 <a id="id10" class="footnote_reference" href="#zip-0214">11</a> to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 <a id="id11" class="footnote_reference" href="#zip-1014">13</a>, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.</p>
|
||||
<p>As for the original Founders' Reward, addresses for a given funding stream are changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="definitions"><h3><span class="section-heading">Definitions</span><span class="section-anchor"> <a href="#definitions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="definitions"><h3><span class="section-heading">Definitions</span><span class="section-anchor"> <a rel="bookmark" href="#definitions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>We use the following constants and functions defined in <a id="id12" class="footnote_reference" href="#protocol-constants">4</a>, <a id="id13" class="footnote_reference" href="#protocol-subsidies">5</a>, and <a id="id14" class="footnote_reference" href="#protocol-foundersreward">6</a>:</p>
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -72,7 +72,7 @@ License: MIT</pre>
|
|||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="funding-streams"><h3><span class="section-heading">Funding streams</span><span class="section-anchor"> <a href="#funding-streams"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="funding-streams"><h3><span class="section-heading">Funding streams</span><span class="section-anchor"> <a rel="bookmark" href="#funding-streams"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).</p>
|
||||
<p>By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. <a id="id15" class="footnote_reference" href="#zip-0208">9</a></p>
|
||||
<p>The value of a funding stream at a given block height is defined as:</p>
|
||||
|
|
@ -195,7 +195,7 @@ License: MIT</pre>
|
|||
</blockquote>
|
||||
<p>On Mainnet, Canopy is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to Canopy activation.</p>
|
||||
</section>
|
||||
<section id="consensus-rules"><h3><span class="section-heading">Consensus rules</span><span class="section-anchor"> <a href="#consensus-rules"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="consensus-rules"><h3><span class="section-heading">Consensus rules</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-rules"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. <a id="id16" class="footnote_reference" href="#protocol-foundersreward">6</a></p>
|
||||
<p>Once the Canopy network upgrade activates:</p>
|
||||
<ul>
|
||||
|
|
@ -206,7 +206,7 @@ License: MIT</pre>
|
|||
</ul>
|
||||
<p>For the funding stream definitions to be activated at Canopy, see ZIP 214. <a id="id19" class="footnote_reference" href="#zip-0214">11</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id20" class="footnote_reference" href="#zip-0000">7</a></p>
|
||||
</section>
|
||||
<section id="example-implementation"><h3><span class="section-heading">Example implementation</span><span class="section-anchor"> <a href="#example-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="example-implementation"><h3><span class="section-heading">Example implementation</span><span class="section-anchor"> <a rel="bookmark" href="#example-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<pre data-language="cpp"><span class="k">struct</span> <span class="n">FundingPeriod</span> <span class="p">{</span>
|
||||
<span class="n">std</span><span class="o">::</span><span class="n">vector</span><span class="o"><</span><span class="n">std</span><span class="o">::</span><span class="n">string</span><span class="o">></span> <span class="n">addresses</span><span class="p">,</span>
|
||||
<span class="kt">uint64_t</span> <span class="n">valueNumerator</span><span class="p">,</span>
|
||||
|
|
@ -368,16 +368,16 @@ License: MIT</pre>
|
|||
<span class="p">}</span></pre>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal is intended to be deployed with Canopy. <a id="id21" class="footnote_reference" href="#zip-0251">12</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>TBC</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -15,16 +15,16 @@ Status: Final
|
|||
Category: Consensus
|
||||
Created: 2019-01-10
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">3</a></p>
|
||||
<p>The terms "block chain", "consensus rule change", "consensus branch", and "network upgrade" are to be interpreted as defined in <a id="id2" class="footnote_reference" href="#zip-0200">4</a>.</p>
|
||||
<p>The term "block target spacing" means the time interval between blocks targeted by the difficulty adjustment algorithm in a given consensus branch. It is normally measured in seconds. (This is also sometimes called the "target block time", but "block target spacing" is the term used in <a id="id3" class="footnote_reference" href="#latest-protocol">1</a>.)</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal specifies a change in the block target spacing, to take effect in the Blossom network upgrade <a id="id4" class="footnote_reference" href="#zip-0206">6</a>.</p>
|
||||
<p>The emission schedule of mined ZEC will be approximately the same in terms of time, but this requires the emission per block to be adjusted to take account of the changed block target spacing.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The motivations for decreasing the block target spacing are:</p>
|
||||
<ul>
|
||||
<li>Reduced latency for considering transactions to be sufficiently confirmed;</li>
|
||||
|
|
@ -33,9 +33,9 @@ License: MIT</pre>
|
|||
<p>The latter goal could alternatively be achieved by increasing the block size limit, but that would not also achieve the former goal.</p>
|
||||
<p>Note that, for a given security requirement (in terms of the expected cost distribution of a rollback attack), the number of confirmations needed increases more slowly than the decrease in block time, and so, up to a point, decreasing the block target spacing can provide a better trade-off between latency and security. This argument assumes that the validation and propagation time for a block remain small compared to the block target spacing. See <a id="id5" class="footnote_reference" href="#slowfastblocks">8</a> for further analysis in various attack models.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The changes described in this section are to be made in <a id="id6" class="footnote_reference" href="#latest-protocol">1</a>, relative to the pre-Blossom specification in [#preblossom-protocol].</p>
|
||||
<section id="consensus-changes"><h3><span class="section-heading">Consensus changes</span><span class="section-anchor"> <a href="#consensus-changes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="consensus-changes"><h3><span class="section-heading">Consensus changes</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-changes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Throughout the specification, rename HalvingInterval to PreBlossomHalvingInterval, and rename PoWTargetSpacing to PreBlossomTargetSpacing. These constants retain their values from <a id="id7" class="footnote_reference" href="#preblossom-protocol">2</a> of 840000 (blocks) and 150 (seconds) respectively.</p>
|
||||
<p>In section 2 (Notation), add BlossomActivationHeight and PostBlossomPoWTargetSpacing to the list of integer constants.</p>
|
||||
<p>In section 5.3 (Constants), define PostBlossomPoWTargetSpacing := 75 seconds.</p>
|
||||
|
|
@ -104,30 +104,30 @@ License: MIT</pre>
|
|||
</ul>
|
||||
<p>and in the second note, replace SlowStartShift + PreBlossomHalvingInterval - 1 with FoundersRewardLastBlockHeight.</p>
|
||||
</section>
|
||||
<section id="effect-on-difficulty-adjustment"><h3><span class="section-heading">Effect on difficulty adjustment</span><span class="section-anchor"> <a href="#effect-on-difficulty-adjustment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="effect-on-difficulty-adjustment"><h3><span class="section-heading">Effect on difficulty adjustment</span><span class="section-anchor"> <a rel="bookmark" href="#effect-on-difficulty-adjustment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The difficulty adjustment parameters PoWAveragingWindow and PoWMedianBlockSpan refer to numbers of blocks, but do <em>not</em> change at Blossom activation. This is because the amount of damping/averaging required is expected to be roughly the same, in terms of the number of blocks, after the change in block target spacing.</p>
|
||||
<p>The change in the effective value of PoWTargetSpacing will cause the block spacing to adjust to the new target, at the normal rate for a difficulty adjustment. The results of simulations are consistent with this expected behaviour.</p>
|
||||
<p>Note that the change in AveragingWindowTimespan(height) takes effect immediately when calculating the target difficulty starting from the block at the Blossom activation height, even though the difficulty of the preceding PoWAveragingWindow blocks will have been adjusted using the pre-Blossom target spacing. Therefore it is likely that the difficulty adjustment for the first few blocks after activation will be limited by PoWMaxAdjustDown. This is not anticipated to cause any problem.</p>
|
||||
<section id="minimum-difficulty-blocks-on-the-test-network"><h4><span class="section-heading">Minimum difficulty blocks on the test network</span><span class="section-anchor"> <a href="#minimum-difficulty-blocks-on-the-test-network"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="minimum-difficulty-blocks-on-the-test-network"><h4><span class="section-heading">Minimum difficulty blocks on the test network</span><span class="section-anchor"> <a rel="bookmark" href="#minimum-difficulty-blocks-on-the-test-network"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>On the test network from block height 299188 onward, the difficulty adjustment algorithm allows minimum-difficulty blocks, as described in <a id="id11" class="footnote_reference" href="#zip-0205">5</a>, when the block time exceeds a given threshold. This specification changes this threshold to be proportional to the block target spacing.</p>
|
||||
<p>That is, if the block time of a block at height <em>height</em> ≥ 299188 is at least 6 · PoWTargetSpacing(<em>height</em>) seconds after that of the preceding block, then the block is a minimum-difficulty block, and its target threshold is set to the value of PoWLimit for testnet (see <a id="id12" class="footnote_reference" href="#latest-protocol">1</a> section 5.3).</p>
|
||||
<p>As before, the <code>nBits</code> field of a minimum-difficulty block is still computed according to the original difficulty adjustment algorithm, and only this field is used for the purpose of computing the MeanTarget values from which subsequent difficulty changes are calculated.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="non-consensus-node-behaviour"><h3><span class="section-heading">Non-consensus node behaviour</span><span class="section-anchor"> <a href="#non-consensus-node-behaviour"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="end-of-service-halt"><h4><span class="section-heading">End-of-Service halt</span><span class="section-anchor"> <a href="#end-of-service-halt"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="non-consensus-node-behaviour"><h3><span class="section-heading">Non-consensus node behaviour</span><span class="section-anchor"> <a rel="bookmark" href="#non-consensus-node-behaviour"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="end-of-service-halt"><h4><span class="section-heading">End-of-Service halt</span><span class="section-anchor"> <a rel="bookmark" href="#end-of-service-halt"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p><cite>zcashd</cite> implements an "End-of-Service halt" behaviour that halts the node at a block height that corresponds approximately to a given time after release. This interval SHOULD be adjusted in releases where the End-of-Service halt time will follow Blossom activation.</p>
|
||||
</section>
|
||||
<section id="default-expiry-delta"><h4><span class="section-heading">Default expiry delta</span><span class="section-anchor"> <a href="#default-expiry-delta"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="default-expiry-delta"><h4><span class="section-heading">Default expiry delta</span><span class="section-anchor"> <a rel="bookmark" href="#default-expiry-delta"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>When not overridden by the <cite>-txexpirydelta</cite> option, <cite>zcashd</cite> RPC calls that create transactions use a default value for the number of blocks after which a transaction will expire. The default in recent versions of <cite>zcashd</cite> is 20 blocks, which at the pre-Blossom block target spacing corresponds to roughly 50 minutes.</p>
|
||||
<p>This default SHOULD change to BlossomPoWTargetSpacingRatio · 20 blocks after Blossom activation, to maintain the approximate expiry time of 50 minutes.</p>
|
||||
<p>If the <cite>-txexpirydelta</cite> option is set, then the set value SHOULD be used both before and after Blossom activation.</p>
|
||||
</section>
|
||||
<section id="sprout-to-sapling-migration"><h4><span class="section-heading">Sprout to Sapling migration</span><span class="section-anchor"> <a href="#sprout-to-sapling-migration"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="sprout-to-sapling-migration"><h4><span class="section-heading">Sprout to Sapling migration</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-to-sapling-migration"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>ZIP 308 <a id="id13" class="footnote_reference" href="#zip-0308">7</a> defines a procedure for migrating funds from Sprout to Sapling z-addresses. In that procedure, migration transactions are sent every 500 blocks, which corresponded to roughly 20.83 hours before Blossom.</p>
|
||||
<p>The 500-block constant has not been changed. Therefore, migration transactions are now sent roughly every 10.42 hours after Blossom activation. This has been noted in the ZIP, and a table showing the expected time to complete migration has been updated accordingly.</p>
|
||||
</section>
|
||||
<section id="fingerprinting-mitigation"><h4><span class="section-heading">Fingerprinting mitigation</span><span class="section-anchor"> <a href="#fingerprinting-mitigation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="fingerprinting-mitigation"><h4><span class="section-heading">Fingerprinting mitigation</span><span class="section-anchor"> <a rel="bookmark" href="#fingerprinting-mitigation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>A "fingerprinting attack" is a network analysis technique in which nodes are identified across network sessions, for example using information about which blocks they request or send.</p>
|
||||
<p><code>zcashd</code> inherits from Bitcoin Core the following behaviour, described in a comment in <code>main.cpp</code>, intended as a fingerprinting mitigation:</p>
|
||||
<pre>// To prevent fingerprinting attacks, only send blocks outside of the active
|
||||
|
|
@ -137,13 +137,13 @@ License: MIT</pre>
|
|||
<p>In any case, to estimate the "best equivalent proof of work" of a given block chain (measured in units of time), we take the total work of the chain as defined in <a id="id14" class="footnote_reference" href="#latest-protocol">1</a> section 7.6.5, divide by the work of the block at the active tip, and multiply by the target block spacing of that block.</p>
|
||||
<p>It is not a requirement of the Zcash protocol that this fingerprinting mitigation is used; however, if it is used, then it SHOULD use the target block spacing at the same block height that is used for the current work estimate.</p>
|
||||
</section>
|
||||
<section id="monitoring-for-quicker-or-slower-than-expected-blocks"><h4><span class="section-heading">Monitoring for quicker- or slower-than-expected blocks</span><span class="section-anchor"> <a href="#monitoring-for-quicker-or-slower-than-expected-blocks"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="monitoring-for-quicker-or-slower-than-expected-blocks"><h4><span class="section-heading">Monitoring for quicker- or slower-than-expected blocks</span><span class="section-anchor"> <a rel="bookmark" href="#monitoring-for-quicker-or-slower-than-expected-blocks"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p><cite>zcashd</cite> previously did this monitoring every 150 seconds; it is now done every 60 seconds.</p>
|
||||
</section>
|
||||
<section id="block-timeout"><h4><span class="section-heading">Block timeout</span><span class="section-anchor"> <a href="#block-timeout"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="block-timeout"><h4><span class="section-heading">Block timeout</span><span class="section-anchor"> <a rel="bookmark" href="#block-timeout"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The timeout for a requested block is calculated as the target block time, multiplied by 2 + (the number of queued validated headers)/2.</p>
|
||||
</section>
|
||||
<section id="latency-optimization-when-requesting-blocks"><h4><span class="section-heading">Latency optimization when requesting blocks</span><span class="section-anchor"> <a href="#latency-optimization-when-requesting-blocks"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="latency-optimization-when-requesting-blocks"><h4><span class="section-heading">Latency optimization when requesting blocks</span><span class="section-anchor"> <a rel="bookmark" href="#latency-optimization-when-requesting-blocks"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>When <code>zcashd</code> sees an announced block that chains from headers that it does not already have, it will first ask for the headers, and then the block itself. A latency optimization is performed only if the chain is "nearly synced":</p>
|
||||
<pre>// First request the headers preceding the announced block. In the normal fully-synced
|
||||
// case where a new block is announced that succeeds the current tip (no reorganization),
|
||||
|
|
@ -155,16 +155,16 @@ License: MIT</pre>
|
|||
// not a direct successor.</pre>
|
||||
<p>The heuristic for "nearly synced" is that the timestamp of the block at the active tip is no more than 20 block times before the current "adjusted time". In <code>zcashd</code> this calculation uses the block target spacing as of the best known header. Around Blossom activation when the block target spacing changes, this could cause the heuristic to be based on the pre-Blossom block target spacing until the node has synced headers past the activation block, but this is not anticipated to cause any problem.</p>
|
||||
</section>
|
||||
<section id="response-to-getblocks-message-when-pruning"><h4><span class="section-heading">Response to getblocks message when pruning</span><span class="section-anchor"> <a href="#response-to-getblocks-message-when-pruning"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="response-to-getblocks-message-when-pruning"><h4><span class="section-heading">Response to getblocks message when pruning</span><span class="section-anchor"> <a rel="bookmark" href="#response-to-getblocks-message-when-pruning"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>If pruning is enabled, when <code>zcashd</code> responds to an "getblocks" peer-to-peer message, it will only include blocks that it has on disk, and is likely to still have on disk an hour after responding to the message:</p>
|
||||
<pre>// If pruning, don't inv blocks unless we have on disk and are likely to still have
|
||||
// for some reasonable time window (1 hour) that block relay might require.</pre>
|
||||
<p>For each block, when estimating whether it will still be on disk after an hour, we take MIN_BLOCKS_TO_KEEP = 288 blocks, minus approximately the number of blocks expected in one hour at the target block spacing as of that block. Around Blossom activation, this might underestimate the number of blocks in the next hour, but given the value of MIN_BLOCKS_TO_KEEP, this is not anticipated to cause any problem.</p>
|
||||
</section>
|
||||
<section id="estimation-of-fully-synced-chain-height"><h4><span class="section-heading">Estimation of fully synced chain height</span><span class="section-anchor"> <a href="#estimation-of-fully-synced-chain-height"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="estimation-of-fully-synced-chain-height"><h4><span class="section-heading">Estimation of fully synced chain height</span><span class="section-anchor"> <a rel="bookmark" href="#estimation-of-fully-synced-chain-height"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p><code>zcashd</code> uses the <code>EstimateNetHeight</code> function to estimate the approximate height of the fully synced chain, so that the progress of block download can be displayed to the node operator. This function has been rewritten, simplified, and changed to take account of cases where the time period that needs to be estimated crosses Blossom activation.</p>
|
||||
</section>
|
||||
<section id="other-block-related-constants"><h4><span class="section-heading">Other block-related constants</span><span class="section-anchor"> <a href="#other-block-related-constants"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="other-block-related-constants"><h4><span class="section-heading">Other block-related constants</span><span class="section-anchor"> <a rel="bookmark" href="#other-block-related-constants"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The following constants, measured in number of blocks, were reviewed and a decision was made not to change them:</p>
|
||||
<pre>/** The number of blocks within expiry height when a tx is considered to be expiring soon */
|
||||
TX_EXPIRING_SOON_THRESHOLD = 3
|
||||
|
|
@ -190,16 +190,16 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
</section>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Blossom network upgrade. <a id="id15" class="footnote_reference" href="#zip-0206">6</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/4025">https://github.com/zcash/zcash/pull/4025</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="latest-protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -13,28 +13,28 @@ Status: Final
|
|||
Category: Consensus
|
||||
Created: 2019-02-25
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "block chain" and "network upgrade" are to be interpreted as defined in <a id="id2" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>The "Sprout value pool balance" for a given block chain, as implied by section 4.11 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol">2</a>, is the sum of all <code>vpub_old</code> fields for transactions in the block chain, minus the sum of all <code>vpub_new</code> fields for transactions in the block chain.</p>
|
||||
<p>The "Sapling value pool balance" for a given block chain, as implied by section 4.12 of Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol">2</a>, is the negation of the sum of all <code>valueBalance</code> fields for transactions in the block chain.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines how the consensus rules are altered such that blocks which produce negative shielded value pools are prohibited.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>It is possible for nodes to monitor the total value of notes that are shielded to, or unshielded from, each of the Sprout or Sapling value pools. If the total value that is unshielded exceeds the total value that was shielded for a given pool, a balance violation has occurred in the corresponding shielded transaction protocol.</p>
|
||||
<p>It would be preferable for the network to reject blocks that result in the aforementioned balance violation. However, nodes do not currently react to such an event. Remediation may therefore require chain rollbacks and other disruption.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>If the "Sprout value pool balance" or "Sapling value pool balance" would become negative in the block chain created as a result of accepting a block, then all nodes MUST reject the block as invalid.</p>
|
||||
<p>Nodes MAY relay transactions even if one or more of them cannot be mined due to the aforementioned restriction.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This consensus rule is not deployed as part of a network upgrade as defined in ZIP-200 <a id="id5" class="footnote_reference" href="#zip-0200">3</a> and there is no mechanism by which the network will synchronize to enforce this rule. Rather, all nodes should begin enforcing this consensus rule upon acceptance of this proposal.</p>
|
||||
<p>There is a risk that before all nodes on the network begin enforcing this consensus rule that block(s) will be produced that violate it, potentially leading to network fragmentation. This is considered sufficiently unlikely that the benefits of enforcing this consensus rule sooner are overwhelming.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -13,20 +13,20 @@ Status: Draft
|
|||
Category: Consensus
|
||||
Created: 2019-03-27
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">2</a>.</p>
|
||||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205 <a id="id3" class="footnote_reference" href="#zip-0205">3</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines a modification to the transaction format whereby a single Sapling anchor is used for all Sapling spends. This change removes a potential implementation fingerprint, and reduces the size of Sapling transactions within the block chain.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Sapling network upgrade <a id="id4" class="footnote_reference" href="#zip-0205">3</a> introduced new shielded inputs (spends) and outputs. Each spend proves the existence of the note being spent by including the anchor of a Merkle tree that contains the note's commitment, and proving in zero knowledge the existence of a path from the commitment to the anchor (a witness). Valid anchors correspond to the state of the Sapling commitment tree after each block in the chain.</p>
|
||||
<p>The choice of anchor leaks information about the note being spent, namely that the note was created no later than the anchor's block height. This is an unavoidable outcome of the Zcash design, and the least information it is possible to leak about a note being spent. However, the Sapling v4 transaction format <a id="id5" class="footnote_reference" href="#v4-tx">4</a> includes a separate anchor for each Sapling spend, and thus it is possible to leak additional information by using different anchors for different notes. The anchor selection choices could also be used as a fingerprint to identify transactions created by particular wallet implementations, reducing the privacy set.</p>
|
||||
<p>Modifying the transaction format to have a single Sapling anchor field, instead of one field per Sapling spend, removes the ability (within the new transaction format version) to create transactions with this fingerprint. It also reduces the size of the transaction, costing 32 bytes per transaction instead of 32 bytes per spend.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>A new transaction format is defined, identical to the Sapling v4 transaction format except for two changes:</p>
|
||||
<ul>
|
||||
<li>The <code>anchor</code> field in <code>SpendDescription</code> is removed.</li>
|
||||
|
|
@ -36,17 +36,17 @@ License: MIT</pre>
|
|||
<p>TODO: If this is the only ZIP updating the transaction format in a NU, specify the full transaction format here. Otherwise, reference the new transaction format when specified.</p>
|
||||
<p>Implementations that support older transaction formats MAY copy <code>saplingAnchor</code> into each spend's in-memory representation during parsing to reduce code duplication, and MUST ensure that these per-spend in-memory anchors are all identical prior to serialization.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Placing the <code>saplingAnchor</code> field after <code>vShieldedOutput</code> means that it can be conditionally included (saving space when there are no Sapling spends), while ensuring that the transaction can still be parsed unambiguously.</p>
|
||||
<p>Requiring all Sapling spends to use the same anchor removes a possible performance optimisation in certain classes of (particularly light) wallets, where witnesses for older notes are only updated periodically instead of every block. This optimisation is exactly the kind of behaviour that can be used as a fingerprint in the v4 transaction format, and that we are choosing to prevent with this proposal.</p>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal eliminates a possible avenue for distinguishing transactions based on the client implementation that created them.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>TBD</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,16 +14,16 @@ Status: Proposed
|
|||
Category: Consensus
|
||||
Created: 2019-03-29
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">2</a>.</p>
|
||||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205 <a id="id3" class="footnote_reference" href="#zip-0205">3</a>.</p>
|
||||
<p>The term "Sprout value pool balance" in this document is to be interpreted as described in ZIP 209 <a id="id4" class="footnote_reference" href="#zip-0209">4</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal disables the ability to add new value to the Sprout value pool balance. This takes a step toward being able to remove the Sprout protocol, thus reducing the overall complexity and attack surface of Zcash.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The first iteration of the Zcash network, called Sprout, provided a shielded payment protocol that was relatively closely based on the original Zerocash proposal. <a id="id5" class="footnote_reference" href="#zerocash">7</a></p>
|
||||
<p>The Sapling network upgrade <a id="id6" class="footnote_reference" href="#zip-0205">3</a> introduced significant efficiency and functionality improvements for shielded transactions. It is expected that over time, the use of Sapling shielded transactions will replace the use of Sprout.</p>
|
||||
<p>The Sapling and Sprout shielded protocols employ different cryptographic designs. Since an adversary could potentially exploit any vulnerability in either design, supporting both presents additional risk over supporting only the newer Sapling protocol.</p>
|
||||
|
|
@ -31,12 +31,12 @@ License: MIT</pre>
|
|||
<p>In addition, the Zcash specification and implementation incurs complexity and "technical debt" from the requirement to support and test both shielded transaction protocols.</p>
|
||||
<p>Removing the ability to add to the Sprout shielded value pool balance, is a first step toward reducing this complexity and potential risk. This does not prevent extracting value held in Sprout addresses and sending it to transparent addresses, or to Sapling addresses via the migration tool <a id="id8" class="footnote_reference" href="#zip-0308">6</a>.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>From the relevant activation height, the <code>vpub_old</code> field of each JoinSplit description MUST be zero.</p>
|
||||
<p>When this proposal is activated, nodes and wallets MUST disable any facilities to send to Sprout addresses, and this SHOULD be made clear in user interfaces and API documentation.</p>
|
||||
<p>Note that the facility to send to Sprout addresses, before activation of this proposal, is in any case OPTIONAL for a particular node or wallet implementation.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This design does not require any change to the JoinSplit circuit, thus minimizing the risk of security regressions, and avoiding the need for a new ceremony to generate circuit parameters.</p>
|
||||
<p>The code changes needed are very small and simple, and their security is easy to analyse.</p>
|
||||
<p>During the development of this proposal, alternative designs were considered that would have removed some fields of a JoinSplit description. These alternatives were abandoned for several reasons:</p>
|
||||
|
|
@ -46,17 +46,17 @@ License: MIT</pre>
|
|||
<li>A new transaction version would have been required.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The security motivations for making this change are described in the Motivation section. Privacy concerns that led to the current design are discussed in the Rationale section.</p>
|
||||
<p>Since all clients change their behaviour at the same time from this proposal's activation height, there is no additional client distinguisher.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Canopy network upgrade. <a id="id10" class="footnote_reference" href="#zip-0251">5</a></p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/4489">https://github.com/zcash/zcash/pull/4489</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,16 +14,16 @@ Status: Proposed
|
|||
Category: Consensus
|
||||
Created: 2019-03-31
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The function
|
||||
<span class="math">\(\mathsf{ToScalar}\)</span>
|
||||
is defined as in Section 4.4.2 of the Zcash Protocol Specification. <a id="id2" class="footnote_reference" href="#protocol">2</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP proposes a new note plaintext format for Sapling Outputs in transactions. The new format allows recipients to check the well-formedness of the ephemeral Diffie-Hellman key in the Output to avoid an assumption on zk-SNARK soundness for preventing diversified address linkability.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Sapling payment protocol contains a feature called "diversified addresses" which allows a single incoming viewing key to receive payments on an enormous number of distinct and unlinkable payment addresses. This feature allows users to maintain many payment addresses without paying additional overhead during blockchain scanning.</p>
|
||||
<p>The feature works by allowing payment addresses to become a tuple
|
||||
<span class="math">\((\mathsf{pk_d}, \mathsf{d})\)</span>
|
||||
|
|
@ -82,7 +82,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{rcm}\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#abstractprfs">4</a>. We will be adapting
|
||||
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
|
||||
for the purposes of this ZIP. This function is keyed by a 256-bit key
|
||||
|
|
@ -90,7 +90,7 @@ License: MIT</pre>
|
|||
and takes an arbitrary length byte sequence as input, returning a
|
||||
<span class="math">\(64\)</span>
|
||||
-byte sequence as output.</p>
|
||||
<section id="changes-to-sapling-note-plaintexts"><h3><span class="section-heading">Changes to Sapling Note plaintexts</span><span class="section-anchor"> <a href="#changes-to-sapling-note-plaintexts"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="changes-to-sapling-note-plaintexts"><h3><span class="section-heading">Changes to Sapling Note plaintexts</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-sapling-note-plaintexts"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#notept">5</a>. Currently, the encoding of a Sapling note plaintext requires that the first byte take the form
|
||||
<span class="math">\(\textbf{0x01}\)</span>
|
||||
, indicating the version of the note plaintext. In addition, a
|
||||
|
|
@ -116,7 +116,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{rcm}\)</span>
|
||||
) be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from the decryption of note plaintexts as described in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. <a id="id5" class="footnote_reference" href="#saplingdecryptivk">6</a> <a id="id6" class="footnote_reference" href="#saplingdecryptovk">7</a></p>
|
||||
</section>
|
||||
<section id="changes-to-the-process-of-sending-sapling-notes"><h3><span class="section-heading">Changes to the process of sending Sapling notes</span><span class="section-anchor"> <a href="#changes-to-the-process-of-sending-sapling-notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="changes-to-the-process-of-sending-sapling-notes"><h3><span class="section-heading">Changes to the process of sending Sapling notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-sending-sapling-notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The process of sending notes in Sapling is described in section 4.6.2 of the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#saplingsend">8</a>. During this process, the sender samples
|
||||
<span class="math">\(\mathsf{rcm^{new}}\)</span>
|
||||
uniformly at random. In addition, the process of encrypting a note is described in section 4.17.1 of the Zcash Protocol Specification <a id="id8" class="footnote_reference" href="#saplingencrypt">3</a>. During this process, the sender also samples the ephemeral private key
|
||||
|
|
@ -142,7 +142,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
<section id="changes-to-the-process-of-receiving-sapling-notes"><h3><span class="section-heading">Changes to the process of receiving Sapling notes</span><span class="section-anchor"> <a href="#changes-to-the-process-of-receiving-sapling-notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="changes-to-the-process-of-receiving-sapling-notes"><h3><span class="section-heading">Changes to the process of receiving Sapling notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-receiving-sapling-notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The process of receiving notes in Sapling is described in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. <a id="id9" class="footnote_reference" href="#saplingdecryptivk">6</a> <a id="id10" class="footnote_reference" href="#saplingdecryptovk">7</a></p>
|
||||
<p>After the activation of this ZIP, the note plaintext contains a field
|
||||
<span class="math">\(\mathsf{rseed}\)</span>
|
||||
|
|
@ -163,7 +163,7 @@ License: MIT</pre>
|
|||
and fail decryption if this check is not satisfied.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The attack that this prevents is an interactive attack that requires an adversary to be able to break critical soundness properties of the zk-SNARKs underlying Sapling. It is potentially valid to assume that this cannot occur, due to other damaging effects on the system such as undetectable counterfeiting. However, we have attempted to avoid any instance in the protocol where privacy (even against interactive attacks) depended on strong cryptographic assumptions. Acting differently here would be confusing for users that have previously been told that "privacy does not depend on zk-SNARK soundness" or similar claims.</p>
|
||||
<p>It is possible for us to infringe on the length of the <code>memo</code> field and ask the sender to provide
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
|
|
@ -178,7 +178,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The changes made in this proposal prevent an interactive attack that could link together diversified addresses by only breaking the knowledge soundness assumption of the zk-SNARK. It is already assumed that the adversary cannot defeat the EC-DDH assumption of the Jubjub elliptic curve, for it could perform a linkability attack trivially in that case.</p>
|
||||
<p>In the naive case where the protocol is modified so that
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
|
|
@ -186,13 +186,13 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{rseed}\)</span>
|
||||
) this would lead to an instance of key-dependent encryption, which is difficult or perhaps impossible to prove secure using existing security notions. Our approach of using a key derivation, which ultimately queries an oracle, allows a proof for IND-CCA2 security to be written by reprogramming the oracle to return bogus keys when necessary.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>TBD</p>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The discovery that diversified address unlinkability depended on the zk-SNARK knowledge assumption was made by Sean Bowe and Zooko Wilcox.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -13,21 +13,21 @@ Status: Implemented (zcashd)
|
|||
Category: Consensus
|
||||
Created: 2019-03-30
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">2</a>.</p>
|
||||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205 <a id="id3" class="footnote_reference" href="#zip-0205">3</a>.</p>
|
||||
<p>The terms "Founders' Reward" and "funding stream" in this document are to be interpreted as described in ZIP 207 <a id="id4" class="footnote_reference" href="#zip-0207">4</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines modifications to the Zcash consensus rules that enable coinbase funds to be mined to Sapling addresses. It does not disable the use of transparent addresses in coinbase transactions.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash inherited the concept of "coinbase transactions" from Bitcoin: special transactions inside each block that are allowed to have no inputs. These transactions are created by miners during block creation, and collect the block reward and transaction fees into new transparent outputs that can then be spent. They are also leveraged in Zcash for the Founders' Reward (and potentially for funding streams <a id="id5" class="footnote_reference" href="#zip-0207">4</a>).</p>
|
||||
<p>On the path to deprecating and removing Bitcoin-inherited transparent addresses within the Zcash network, a required step is to be able to create coinbase transactions that have no transparent outputs. However, Zcash was launched with a consensus rule preventing coinbase transactions from containing shielded outputs, instead enforcing that coinbase funds could not be spent in transactions with transparent outputs. This was partly in order to reduce the complexity of the original Zcash modifications to the Bitcoin Core codebase, but also because at the time, shielded transactions required significant memory and CPU resources to create.</p>
|
||||
<p>The Sapling network upgrade <a id="id6" class="footnote_reference" href="#zip-0205">3</a> deployed architectural changes and performance improvements that make shielding funds directly in the coinbase transaction feasible. In order to reduce the complexity of the Sapling network upgrade, the existing consensus rules preventing coinbase transactions from containing shielded outputs were extended to cover Sapling outputs. Therefore, it is now necessary to modify the consensus rules in order to enable miners to start using Sapling addresses.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to activation of the Heartwood network upgrade, this existing consensus rule on coinbase transactions is enforced:</p>
|
||||
<blockquote>
|
||||
<p>A coinbase transaction MUST NOT have any JoinSplit descriptions, Spend descriptions, or Output descriptions.</p>
|
||||
|
|
@ -49,11 +49,11 @@ License: MIT</pre>
|
|||
</li>
|
||||
<li>Full Sapling note decryption MUST succeed using the all-zero outgoing viewing key. More precisely, all Sapling outputs in coinbase transactions MUST have valid note commitments when recovered using a sequence of 32 zero bytes as the outgoing viewing key.</li>
|
||||
</ul>
|
||||
<section id="interaction-with-the-founders-reward"><h3><span class="section-heading">Interaction with the Founders' Reward</span><span class="section-anchor"> <a href="#interaction-with-the-founders-reward"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="interaction-with-the-founders-reward"><h3><span class="section-heading">Interaction with the Founders' Reward</span><span class="section-anchor"> <a rel="bookmark" href="#interaction-with-the-founders-reward"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This ZIP does not alter the existing Founders' Reward addresses.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The ZIP does not require that all coinbase must be shielded immediately from activation of the network upgrade, so that miners and mining pools may gradually migrate from their existing transparent addresses to Sapling addresses. This also simplifies the consensus rules, because the Founders' Reward targets transparent addresses, and thus it remains necessary for the time being to support them. A future ZIP could require all coinbase to be shielded immediately.</p>
|
||||
<p>Enforcing coinbase maturity at the consensus level for Sapling outputs would incur significant complexity in the consensus rules, because it would require special-casing coinbase note commitments in the Sapling commitment tree. The standard recommendation when spending a note is to select an anchor 10 blocks back from the current chain tip, which acts as a de-facto 10-block maturity on all notes, coinbase included. This might be proposed as a consensus rule in future.</p>
|
||||
<p>There is another reason for shielded coinbase maturity being unnecessary: shielded coinbase outputs have the same effect on economic activity as regular shielded outputs. When a transparent address receives a coin in some "parent" transaction and later spends it, a tree of "direct child" transactions is created that all require the original parent transaction to be valid. However, most wallets treat unspent transparent outputs as a single "bucket of money", and select coins to spend without direct user input. This can create a disconnect between the economic activity of users (who might be intending to spend funds that they just received, creating "logical child" transactions), and their on-chain transaction graph.</p>
|
||||
|
|
@ -61,17 +61,17 @@ License: MIT</pre>
|
|||
<p>By contrast, when a reorg or rollback occurs that would cause a shielded coinbase output to disappear, it will also invalidate every shielded transaction that uses an anchor descending from the tree that the shielded coinbase output had been appended to. That is, all shielded economic activity would be rolled back in addition to the shielded coinbase output disappearing, ensuring that all logical child transactions are invalidated, not just direct child transactions. Therefore, there is no reason to make shielded coinbase a special case when the same behaviour already occurs in regular shielded notes.</p>
|
||||
<p>Requiring that note commitments are valid when recovering using a fixed outgoing viewing key implies that target addresses and values for all Sapling outputs within the coinbase are revealed. This would be necessary to correctly enforce shielded Founders' Reward or funding stream outputs, and it is simpler to enforce this on all outputs. Additionally, this maintains the ability for network observers to track miners and mining pools. Meanwhile, the miners and mining pools could put useful or identifying text in the memo fields of the outputs, instead of storing it ad-hoc elsewhere in the coinbase transaction.</p>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Sapling outputs in coinbase transactions are by design publicly viewable, in contrast to Sapling outputs in normal transactions. This does not introduce any privacy regressions relative to existing coinbase transactions, because coinbase output values and recipient addresses have always been public information. However, users with threat models that rely on keeping their Sapling address private (for example, to maintain post-quantum privacy), and who are also miners or mining pools, should use a coinbase-specific address when creating blocks.</p>
|
||||
<p>Revealing the coinbase output notes does not enable anyone else to detect when the note is spent, which removes the need for a separate shielding step like is enforced for transparent coinbase outputs.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Heartwood network upgrade. <a id="id7" class="footnote_reference" href="#zip-0250">5</a></p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/4256">https://github.com/zcash/zcash/pull/4256</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Category: Consensus
|
|||
Created: 2020-02-28
|
||||
License: MIT
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHALL", and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (<a id="id2" class="footnote_reference" href="#trademark">3</a> or successor agreement).</p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id3" class="footnote_reference" href="#zip-0200">5</a> and the Zcash Trademark Donation and License Agreement (<a id="id4" class="footnote_reference" href="#trademark">3</a> or successor agreement).</p>
|
||||
|
|
@ -30,24 +30,24 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<dd>The Zcash production network, as defined in <a id="id8" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP describes consensus rule changes interpreting the proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years.</p>
|
||||
</section>
|
||||
<section id="applicability"><h2><span class="section-heading">Applicability</span><span class="section-anchor"> <a href="#applicability"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="applicability"><h2><span class="section-heading">Applicability</span><span class="section-anchor"> <a rel="bookmark" href="#applicability"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP concerns the Zcash Mainnet and Testnet, and is not intended to be applicable to other block chains using Zcash technology.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Motivation for the Zcash Development Fund itself is considered in ZIP 1014 <a id="id9" class="footnote_reference" href="#zip-1014">9</a>, which gives a high-level description of the intended structure of the fund.</p>
|
||||
<p>An important motivation for describing the consensus rules in a separate ZIP is to avoid making unintended changes to ZIP 1014, which has already been agreed between ECC, ZF, and the Zcash community. This facilitates critically assessing whether the consensus rule changes accurately reflect the intent of ZIP 1014.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The primary requirement of this ZIP is to make changes to consensus rules necessary and sufficient to implement the intent of ZIP 1014.</p>
|
||||
<p>The Zcash Development Fund distributes funding in ZEC obtained from block subsidies on Mainnet. This ZIP should also specify corresponding rules, addresses, and activation height for Testnet, in order to allow testing and auditing of the design and implementation within sufficient lead time before activation on Mainnet.</p>
|
||||
</section>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what is implementable by Zcash consensus rules.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Blossom network upgrade changed the height of the first halving to block height 1046400 <a id="id10" class="footnote_reference" href="#zip-0208">7</a>, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.</p>
|
||||
<p>Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of Canopy on Mainnet therefore SHALL be 1046400.</p>
|
||||
<p>ZIP 207 <a id="id11" class="footnote_reference" href="#zip-0207">6</a> SHALL be activated in Canopy.</p>
|
||||
|
|
@ -91,7 +91,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<p>As specified in <a id="id12" class="footnote_reference" href="#zip-0207">6</a>, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.</p>
|
||||
<p>The funding streams are defined for Testnet are identical except that the start height of each stream is the activation height of Canopy on Testnet, i.e. xxxxxxx.</p>
|
||||
<p>Note: on Testnet, the activation height of Canopy will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1046400) be double the number of currency units as the corresponding initial amount on Mainnet. This reduces to the same number of currency units as on Mainnet, from Testnet block heights 1046400 (inclusive) to 2726400 (exclusive).</p>
|
||||
<section id="dev-fund-recipient-addresses"><h3><span class="section-heading">Dev Fund Recipient Addresses</span><span class="section-anchor"> <a href="#dev-fund-recipient-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="dev-fund-recipient-addresses"><h3><span class="section-heading">Dev Fund Recipient Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#dev-fund-recipient-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC and ZF) SHALL generate sequences of recipient addresses to be used for each stream in each funding period:</p>
|
||||
<ul>
|
||||
<li>ECC SHALL generate the addresses for the <code>FS_ECC</code> funding stream, which on Mainnet corresponds to the <strong>ECC slice</strong>;</li>
|
||||
|
|
@ -100,13 +100,13 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<p>Within each stream, the addresses MAY be independent, or MAY be repeated between funding periods. Each party SHOULD take account of operational security issues associated with potential compromise of the associated spending keys.</p>
|
||||
<p>Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 <a id="id13" class="footnote_reference" href="#zip-1014">9</a>.</p>
|
||||
<p>No requirements are imposed on the use of funds sent to Testnet funding streams.</p>
|
||||
<section id="direct-grant-option"><h4><span class="section-heading">Direct-grant option</span><span class="section-anchor"> <a href="#direct-grant-option"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="direct-grant-option"><h4><span class="section-heading">Direct-grant option</span><span class="section-anchor"> <a rel="bookmark" href="#direct-grant-option"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the <strong>MG slice</strong> may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. <a id="id14" class="footnote_reference" href="#zip-1014">9</a></p>
|
||||
<p>The funding stream mechanism allows for this option by adding a funding stream corresponding to each direct grantee, with addresses generated by ZF. In this case the total amount of funding streams assigned to direct grantees MUST be subtracted from the funding stream for the remaining <strong>MG slice</strong> (or, if all Major Grants are direct, replace the funding stream for the <strong>MG slice</strong>).</p>
|
||||
<p>For each network upgrade after Canopy requiring modifications to the set of direct grantees, a separate ZIP would be published specifying those modifications.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="mainnet-recipient-addresses"><h3><span class="section-heading">Mainnet Recipient Addresses</span><span class="section-anchor"> <a href="#mainnet-recipient-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="mainnet-recipient-addresses"><h3><span class="section-heading">Mainnet Recipient Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#mainnet-recipient-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<blockquote>
|
||||
<dl>
|
||||
<dt>FS_ECC_Addresses[0..47] = [</dt>
|
||||
|
|
@ -118,20 +118,20 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
</dl>
|
||||
</blockquote>
|
||||
</section>
|
||||
<section id="testnet-recipient-addresses"><h3><span class="section-heading">Testnet Recipient Addresses</span><span class="section-anchor"> <a href="#testnet-recipient-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="testnet-recipient-addresses"><h3><span class="section-heading">Testnet Recipient Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#testnet-recipient-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>TODO</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The rationale for ZF generating the addresses for the <code>ZF_MG</code> funding stream is that ZF is the financial recipient of the <strong>MG slice</strong> as specified in ZIP 1014. <a id="id15" class="footnote_reference" href="#zip-1014">9</a></p>
|
||||
<p>Generation of recipient addresses for Testnet is specified to be done by the same parties as on Mainnet, in order to allow practicing each party's security procedures.</p>
|
||||
<p>Since Testnet is ahead of Mainnet in terms of block height (by ~77000 blocks at the time of writing, which is the equivalent of ~67 days at the post-Blossom block target spacing), the activation height and the start heights of the funding streams could have also been set to 1046400 on Testnet. However, 67 days is arguably too short a testing period, and the block rate on Testnet is less predictable than on Mainnet.</p>
|
||||
<p>It was judged to be unnecessary to have a mechanism to update funding stream definitions (in case of security breach or changes to direct grant recipients) other than at network upgrades.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal is intended to be deployed with Canopy. <a id="id16" class="footnote_reference" href="#zip-0251">8</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,17 +14,17 @@ Status: Proposed
|
|||
Category: Consensus
|
||||
Created: 2020-04-27
|
||||
License: BSD-2-Clause</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document is to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash uses Ed25519 signatures as part of Sprout transactions. However, Ed25519 does not clearly define criteria for signature validity, and implementations conformant to RFC 8032 <a id="id2" class="footnote_reference" href="#rfc8032">2</a> need not agree on whether signatures are valid. This is unacceptable for a consensus-critical application like Zcash. Currently, Zcash inherits criteria for signature validity from an obsolete version of <cite>libsodium</cite>. Instead, this ZIP settles the situation by explicitly defining the Ed25519 validity criteria and changing them to be compatible with batch validation.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The lack of clear validity criteria for Ed25519 signatures poses a maintenance burden. The initial implementation of Zcash consensus in <cite>zcashd</cite> inherited validity criteria from a then-current version of <cite>libsodium</cite> (1.0.15). Due to <a href="https://github.com/zcash/zcash/issues/2872#issuecomment-576911471">a bug in libsodium</a>, this was different from the intended criteria documented in the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol">3</a> (before the specification was changed to match <cite>libsodium</cite> 1.0.15 in specification version 2020.1.2). Also, <cite>libsodium</cite> never guaranteed stable validity criteria, and changed behavior in a later point release. This forced <cite>zcashd</cite> to use an older version of the library before eventually patching a newer version to have consistent validity criteria. To be compatible, Zebra had to implement a special library, <cite>ed25519-zebra</cite> to provide Zcash-flavored Ed25519, attempting to match <cite>libsodium</cite> 1.0.15 exactly. And the initial attempt to implement <cite>ed25519-zebra</cite> was also incompatible, because it precisely matched the wrong compile-time configuration of <cite>libsodium</cite>.</p>
|
||||
<p>In addition, the validity criteria used by Zcash preclude the use of batch validation of Ed25519 signatures. While signature validation is not the primary bottleneck for Zcash, it would be nice to be able to batch-validate signatures, as is the case for RedJubjub.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>After activation of this ZIP, the
|
||||
<span class="math">\(\mathsf{JoinSplitSig}\)</span>
|
||||
validation rules in §5.4.5 of the protocol specification <a id="id4" class="footnote_reference" href="#protocol">3</a> are changed to the following:</p>
|
||||
|
|
@ -69,17 +69,17 @@ License: BSD-2-Clause</pre>
|
|||
<span class="math">\([S]B = R + [k]A\)</span>
|
||||
, allowed by RFC 8032, MUST NOT be used.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This change simplifies the Ed25519 validation logic and reduces future maintenance burden. Because multiplication by the cofactor admits more solutions to the validation equation, not fewer, it is compatible with all existing Ed25519 signatures on the chain.</p>
|
||||
<p>It also allows the use of batch validation, which requires multiplication by the cofactor in the validation equation.</p>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This change has no effect on honestly-generated signatures. Unlike the current validation rules, it makes it possible for a user to generate weak signing keys or to generate signing keys with nonzero torsion component and submit them to the blockchain. However, doing so provides them with no advantage, only compromise to their own security. Moreover, these cases are not a failure mode of any deployed implementation.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This is intended to be deployed with the Canopy Network Upgrade, which is scheduled to activate on Mainnet at block height 1046400.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Status: Implemented (zcashd)
|
|||
Category: Consensus
|
||||
Created: 2019-03-30
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">8</a></p>
|
||||
<dl>
|
||||
|
|
@ -39,10 +39,10 @@ License: MIT</pre>
|
|||
<dd>A Merkle mountain range (MMR) is a binary hash tree that allows for efficient appends of new leaves without changing the value of existing nodes.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP specifies modifications to the Zcash block header semantics and consensus rules in order to support the probabilistic verification FlyClient protocol <a id="id3" class="footnote_reference" href="#flyclient">2</a>. The <code>hashFinalSaplingRoot</code> commitment in the block header is replaced with a commitment to the root of a Merkle Mountain Range (MMR), that in turn commits to various features of the chain's history, including the Sapling commitment tree.</p>
|
||||
</section>
|
||||
<section id="background"><h2><span class="section-heading">Background</span><span class="section-anchor"> <a href="#background"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="background"><h2><span class="section-heading">Background</span><span class="section-anchor"> <a rel="bookmark" href="#background"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>An MMR is a Merkle tree which allows for efficient appends, proofs, and verifications. Informally, appending data to an MMR consists of creating a new leaf and then iteratively merging neighboring subtrees with the same size. This takes at most
|
||||
<span class="math">\(\log(n)\)</span>
|
||||
operations and only requires knowledge of the previous subtree roots, of which there are fewer than
|
||||
|
|
@ -150,7 +150,7 @@ License: MIT</pre>
|
|||
0 0 1 3 4 7 8 10 11 15 16 18</pre>
|
||||
<p>MMR trees allow for efficient incremental set update operations (push, pop, prune). In addition, MMR update operations and Merkle proofs for recent additions to the leaf set are more efficient than other incremental Merkle tree implementations (e.g. Bitcoin's padded leafset, sparse Merkle trees, and Zcash's incremental note commitment trees).</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>MMR proofs are used in the FlyClient protocol <a id="id5" class="footnote_reference" href="#flyclient">2</a>, to reduce the proof size needed for light clients to verify:</p>
|
||||
<ul>
|
||||
<li>the validity of a block chain received from a full node, and</li>
|
||||
|
|
@ -174,7 +174,7 @@ License: MIT</pre>
|
|||
<p>FlyClient reduces the number of block headers needed for light client verification of a valid chain, from linear (as in the current reference protocol) to logarithmic in block chain length. This verification is correct with high probability. It also allows creation of subtree proofs, so light clients need only check blocks later than the most recently verified block index. Following that, verification of a transaction inclusion within that block follows the usual reference protocol <a id="id6" class="footnote_reference" href="#zip-0307">11</a>.</p>
|
||||
<p>A smaller proof size could enable the verification of Zcash SPV Proofs in block-chain protocols such as Ethereum, enabling efficient cross-chain communication and pegs. It also reduces bandwidth and storage requirements for resource-limited clients like mobile or IoT devices.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>For a block
|
||||
<span class="math">\(B_n\)</span>
|
||||
at height
|
||||
|
|
@ -195,7 +195,7 @@ License: MIT</pre>
|
|||
, where
|
||||
<span class="math">\(x\)</span>
|
||||
is defined as above. We extend the standard MMR to allow metadata to propagate upwards through the tree by either summing the metadata of both children, or inheriting the metadata of a specific child as necessary. This allows us to create efficient proofs of selected properties of a range of blocks without transmitting the entire range of blocks or headers.</p>
|
||||
<section id="tree-node-specification"><h3><span class="section-heading">Tree Node specification</span><span class="section-anchor"> <a href="#tree-node-specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="tree-node-specification"><h3><span class="section-heading">Tree Node specification</span><span class="section-anchor"> <a rel="bookmark" href="#tree-node-specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Unless otherwise noted, all hashes use BLAKE2b-256 with the personalization field set to <code>'ZcashHistory' || CONSENSUS_BRANCH_ID</code>. <code>CONSENSUS_BRANCH_ID</code> is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the commitment. <a id="id7" class="footnote_reference" href="#zip-0200">8</a> Which is to say, each node in the tree commits to the consensus branch that produced it.</p>
|
||||
<p>Each MMR node is defined as follows:</p>
|
||||
<ol type="1">
|
||||
|
|
@ -333,7 +333,7 @@ License: MIT</pre>
|
|||
<p>Each node, when serialized, is between 147 and 171 bytes long. The canonical serialized representation of a node is used whenever creating child commitments for future nodes. Other than the metadata commitments, the MMR tree's construction is standard.</p>
|
||||
<p>Once the MMR has been generated, we produce <code>hashChainHistoryRoot</code>, which we define as the BLAKE2b-256 digest of the serialization of the root node.</p>
|
||||
</section>
|
||||
<section id="tree-nodes-and-hashing-pseudocode"><h3><span class="section-heading">Tree nodes and hashing (pseudocode)</span><span class="section-anchor"> <a href="#tree-nodes-and-hashing-pseudocode"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="tree-nodes-and-hashing-pseudocode"><h3><span class="section-heading">Tree nodes and hashing (pseudocode)</span><span class="section-anchor"> <a rel="bookmark" href="#tree-nodes-and-hashing-pseudocode"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<pre data-language="python"><span class="k">def</span> <span class="nf">H</span><span class="p">(</span><span class="n">msg</span><span class="p">:</span> <span class="nb">bytes</span><span class="p">,</span> <span class="n">consensusBranchId</span><span class="p">:</span> <span class="nb">bytes</span><span class="p">)</span> <span class="o">-></span> <span class="nb">bytes</span><span class="p">:</span>
|
||||
<span class="k">return</span> <span class="n">blake2b256</span><span class="p">(</span><span class="n">msg</span><span class="p">,</span> <span class="n">personalization</span><span class="o">=</span><span class="n">b</span><span class="s">'ZcashHistory'</span> <span class="o">+</span> <span class="n">consensusBranchId</span><span class="p">)</span>
|
||||
|
||||
|
|
@ -416,7 +416,7 @@ License: MIT</pre>
|
|||
<span class="sd">'''Makes the root commitment for a blockheader'''</span>
|
||||
<span class="k">return</span> <span class="n">H</span><span class="p">(</span><span class="n">root</span><span class="o">.</span><span class="n">serialize</span><span class="p">(),</span> <span class="n">root</span><span class="o">.</span><span class="n">consensusBranchId</span><span class="p">)</span></pre>
|
||||
</section>
|
||||
<section id="incremental-push-and-pop-pseudocode"><h3><span class="section-heading">Incremental push and pop (pseudocode)</span><span class="section-anchor"> <a href="#incremental-push-and-pop-pseudocode"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="incremental-push-and-pop-pseudocode"><h3><span class="section-heading">Incremental push and pop (pseudocode)</span><span class="section-anchor"> <a rel="bookmark" href="#incremental-push-and-pop-pseudocode"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>With each new block
|
||||
<span class="math">\(B_n\)</span>
|
||||
, we append a new MMR leaf node corresponding to block
|
||||
|
|
@ -508,7 +508,7 @@ License: MIT</pre>
|
|||
<span class="n">new_root</span> <span class="o">=</span> <span class="n">bag_peaks</span><span class="p">(</span><span class="n">peaks</span><span class="p">)</span>
|
||||
<span class="k">return</span> <span class="n">new_root</span></pre>
|
||||
</section>
|
||||
<section id="block-header-semantics-and-consensus-rules"><h3><span class="section-heading">Block header semantics and consensus rules</span><span class="section-anchor"> <a href="#block-header-semantics-and-consensus-rules"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="block-header-semantics-and-consensus-rules"><h3><span class="section-heading">Block header semantics and consensus rules</span><span class="section-anchor"> <a rel="bookmark" href="#block-header-semantics-and-consensus-rules"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The <code>hashFinalSaplingRoot</code> block header field (which was named <code>hashReserved</code> prior to the Sapling network upgrade) is renamed to <code>hashLightClientRoot</code>, to reflect its usage by light clients.</p>
|
||||
<p>Prior to activation of the network upgrade that deploys this ZIP, this existing consensus rule on block headers (adjusted for the renamed field) is enforced: <a id="id10" class="footnote_reference" href="#block-header">4</a></p>
|
||||
<blockquote>
|
||||
|
|
@ -523,13 +523,13 @@ License: MIT</pre>
|
|||
<p>The block header byte format and version are not altered by this ZIP.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="tree-nodes"><h3><span class="section-heading">Tree nodes</span><span class="section-anchor"> <a href="#tree-nodes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="tree-nodes"><h3><span class="section-heading">Tree nodes</span><span class="section-anchor"> <a rel="bookmark" href="#tree-nodes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Nodes in the commitment tree are canonical and immutable. They are cheap to generate, as (with the exception of <code>nSaplingTxCount</code>) all metadata is already generated during block construction and/or checked during block validation. Nodes are relatively compact in memory. Approximately 140,000 blocks have elapsed since Sapling activation. Assuming a 164 byte commitment to each of these, we would have generated approximately 24 MB of additional storage cost for the set of leaf nodes (and an additional ~24 MB for storage of intermediate nodes).</p>
|
||||
<p><code>hashSubtreeCommitment</code> forms the strucuture of the commitment tree. Other metadata commitments were chosen to serve specific purposes. Variable-length commitments are placed last, so that most metadata in a node can be directly indexed. We considered using fixed-length commitments here, but opted for variable-length, in order to marginally reduce the memory requirements for managing and updating the commitment trees.</p>
|
||||
<p>In leaf nodes, some information is repeated. We chose to do this so that leaf nodes could be treated identically to internal and root nodes for all algorithms and (de)serializers. Leaf nodes are easily identifiable, as they will show proof of work in the <code>hashSubtreeCommitment</code> field (which commits to the block hash for leaf nodes), and their block range (calculated as <code>nLatestHeight</code> - (<code>nEarliestHeight</code> - 1)) will be precisely 1.</p>
|
||||
<p>Personalized BLAKE2b-256 was selected to match existing Zcash conventions. Adding the consensus branch ID to the hash personalization string ensures that valid nodes from one consensus branch cannot be used to make false statements about parallel consensus branches.</p>
|
||||
<section id="flyclient-requirements-and-recommendations"><h4><span class="section-heading">FlyClient Requirements and Recommendations</span><span class="section-anchor"> <a href="#flyclient-requirements-and-recommendations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="flyclient-requirements-and-recommendations"><h4><span class="section-heading">FlyClient Requirements and Recommendations</span><span class="section-anchor"> <a rel="bookmark" href="#flyclient-requirements-and-recommendations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>These commitments enable FlyClient in the variable-difficulty model. Specifically, they allow light clients to reason about application of the difficulty adjustment algorithm over a range of blocks. They were chosen via discussion with an author of the FlyClient paper.</p>
|
||||
<ul>
|
||||
<li><code>nEarliestTimestamp</code></li>
|
||||
|
|
@ -541,7 +541,7 @@ License: MIT</pre>
|
|||
<li><code>nSubTreeTotalWork</code></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="non-flyclient-commitments"><h4><span class="section-heading">Non-FlyClient Commitments</span><span class="section-anchor"> <a href="#non-flyclient-commitments"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="non-flyclient-commitments"><h4><span class="section-heading">Non-FlyClient Commitments</span><span class="section-anchor"> <a rel="bookmark" href="#non-flyclient-commitments"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Additional metadata commitments were chosen primarily to improve light client security guarantees. We specified commitments where we could see an obvious security benefit, but there may be other useful metadata that we missed. We're interested in feedback and suggestions from the implementers of the current light client.</p>
|
||||
<p>We considered adding a commitment to the nullifier vector at each block. We would appreciate comments from light client teams on the utility of this commitment, as well as the proper serialization and commitment format for the nullifier vector, for possible inclusion in a future upgrade.</p>
|
||||
<ul>
|
||||
|
|
@ -572,7 +572,7 @@ License: MIT</pre>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="header-format-change"><h3><span class="section-heading">Header Format Change</span><span class="section-anchor"> <a href="#header-format-change"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="header-format-change"><h3><span class="section-heading">Header Format Change</span><span class="section-anchor"> <a rel="bookmark" href="#header-format-change"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary goal of the original authors was to minimize header changes; in particular, they preferred not to introduce changes that could affect mining hardware or embedded software. Altering the block header format would require changes throughout the ecosystem, so we decided against adding <code>hashChainHistoryRoot</code> to the header as a new field.</p>
|
||||
<p>ZIP 301 states that "[Miner client software] SHOULD alert the user upon receiving jobs containing block header versions they do not know about or support, and MUST ignore such jobs." <a id="id11" class="footnote_reference" href="#zip-0301">10</a> As the only formally defined block header version is 4, any header version change requires changes to miner client software in order for miners to handle new jobs from mining pools. We therefore do not alter the block version for this semantic change. This does not make block headers ambiguous to interpret, because blocks commit to their block height inside their coinbase transaction, <a id="id12" class="footnote_reference" href="#bip-0034">7</a> and they are never handled in a standalone context (unlike transactions, which exist in the mempool outside of blocks).</p>
|
||||
<p>Replacing <code>hashFinalSaplingRoot</code> with <code>hashChainHistoryRoot</code> does introduce the theoretical possibility of an attack where a miner constructs a Sapling commitment tree update that results in the same 32-byte value as the MMR root. We don't consider this a realistic attack, both because the adversary would need to find a preimage over 32 layers of Pedersen hash, and because light clients already need to update their code to include the consensus branch ID for the Heartwood network upgrade, and can simultaneously make changes to not rely on the value of this header field being the Sapling tree root.</p>
|
||||
|
|
@ -584,7 +584,7 @@ License: MIT</pre>
|
|||
. Also, in the case of chains that activate this ZIP after genesis (including Zcash Mainnet and Testnet), the <code>hashChainHistoryRoot</code> of the activation block would commit to the whole previous epoch if a special case were not made. It would be impractical to calculate this commitment all at once, and so we specify that <code>hashLightClientRoot</code> is set to all zero bytes for that block instead. The hash of the final Sapling note commitment tree root for the activation block will not be encoded in that block, but will be committed to one block later in the <code>hashLatestSaplingRoot</code> field of the MMR root commitment.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP imposes an additional validation cost on new blocks. While this validation cost is small, it may exacerbate any existing DoS opportunities, particularly during abnormal events like long reorgs. Fortunately, these costs are logarithmic in the number of delete and append operations. In the worst case scenario, a well-resourced attacker could maintain 2 chains of approximately equal length, and alternate which chain they extend. This would result in repeated reorgs of increasing length.</p>
|
||||
<p>Given the performance of BLAKE2b, we expect this validation cost to be negligible. However, it seems prudent to benchmark potential MMR implementations during the implementation process. Should the validation cost be higher than expected, there are several potential mitigations, e.g. holding recently seen nodes in memory after a reorg.</p>
|
||||
<p>Generally, header commitments have no impact on privacy. However, FlyClient has additional security and privacy implications. Because FlyClient is a motivating factor for this ZIP, it seems prudent to include a brief overview. A more in-depth security analysis of FlyClient should be performed before designing a FlyClient-based light client ecosystem for Zcash.</p>
|
||||
|
|
@ -592,10 +592,10 @@ License: MIT</pre>
|
|||
<p>FlyClient proofs are probabilistic. When properly constructed, there is negligible probability that a dishonest chain commitment will be accepted by the verifier. The security analysis assumes adversary mining power is bounded by a known fraction of combined mining power of honest nodes, and cannot drop or tamper with messages between client and full nodes. It also assumes the client is connected to at least one full node and knows the genesis block.</p>
|
||||
<p>In addition, <a id="id13" class="footnote_reference" href="#flyclient">2</a> only analyses these security properties in chain models with slowly adjusting difficulty, such as Bitcoin. That paper leaves their analysis in chains with rapidly adjusting difficulty –such as Zcash or Ethereum– as an open problem, and states that the FlyClient protocol provides only heuristic security guarantees in that case. However, as mentioned in <a href="#flyclient-requirements-and-recommendations">FlyClient Requirements and Recommendations</a>, additional commitments allowing light clients to reason about application of the difficulty adjustment algorithm were added in discussion with an author of the FlyClient paper. The use of these fields has not been analysed in the academic security literature. It would be possible to update them in a future network upgrade if further security analysis were to find any deficiencies.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>On the Zcash Mainnet and Testnet, this proposal will be deployed with the Heartwood network upgrade. <a id="id14" class="footnote_reference" href="#zip-0250">9</a></p>
|
||||
</section>
|
||||
<section id="additional-reading"><h2><span class="section-heading">Additional Reading</span><span class="section-anchor"> <a href="#additional-reading"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="additional-reading"><h2><span class="section-heading">Additional Reading</span><span class="section-anchor"> <a rel="bookmark" href="#additional-reading"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li><a href="https://github.com/mahdiz/flyeth">Flyclient enabled geth fork by FlyClient authors</a></li>
|
||||
<li><a href="https://github.com/etclabscore/ECIPs/pull/11/files?short_path=44c106e#diff-44c106ea0ef54fab09596596934d3d15">ECIP-1055: Succinct PoW Using Merkle Mountain Ranges</a></li>
|
||||
|
|
@ -609,7 +609,7 @@ License: MIT</pre>
|
|||
<li><a href="https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md">opentimestamps-server Merkle Mountain Range documentation</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
|
@ -13,7 +13,7 @@ Status: Implemented (zcashd)
|
|||
Category: Consensus
|
||||
Created: 2020-02-28
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
|
|
@ -26,11 +26,11 @@ License: MIT</pre>
|
|||
<dd>The Zcash production network, as defined in <a id="id4" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines the deployment of the Heartwood network upgrade.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="heartwood-deployment"><h3><span class="section-heading">Heartwood deployment</span><span class="section-anchor"> <a href="#heartwood-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="heartwood-deployment"><h3><span class="section-heading">Heartwood deployment</span><span class="section-anchor"> <a rel="bookmark" href="#heartwood-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary sources of information about Heartwood consensus protocol changes are:</p>
|
||||
<ul>
|
||||
<li>The Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol">2</a></li>
|
||||
|
|
@ -65,15 +65,15 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating on each network, Heartwood and pre-Heartwood nodes are compatible and can connect to each other. However, Heartwood nodes will have a preference for connecting to other Heartwood nodes, so pre-Heartwood nodes will gradually be disconnected in the run up to activation.</p>
|
||||
<p>Once the network upgrades, even though pre-Heartwood nodes can still accept the numerically larger protocol version used by Heartwood as being valid, Heartwood nodes will always disconnect peers using lower protocol versions.</p>
|
||||
<p>Unlike Overwinter and Sapling, and like Blossom, Heartwood does not define a new transaction version. Heartwood transactions are therefore in the same v4 format as Sapling transactions, use the same version group ID, i.e. 0x892F2085 as defined in <a id="id12" class="footnote_reference" href="#protocol">2</a> section 7.1, and the same transaction digest algorithm as defined in <a id="id13" class="footnote_reference" href="#zip-0243">7</a>. This does not imply that transactions are valid across the Heartwood activation, since signatures MUST use the appropriate consensus branch ID. <a id="id14" class="footnote_reference" href="#zip-0243">7</a></p>
|
||||
</section>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Support for Heartwood on testnet will be implemented in <code>zcashd</code> version 2.1.2, which will advertise protocol version 170010. Support for Heartwood on mainnet will be implemented in <code>zcashd</code> version 3.0.0, which will advertise protocol version 170011.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Status: Proposed
|
|||
Category: Consensus
|
||||
Created: 2020-02-28
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
|
|
@ -26,11 +26,11 @@ License: MIT</pre>
|
|||
<dd>The Zcash production network, as defined in <a id="id4" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines the deployment of the Canopy network upgrade.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="canopy-deployment"><h3><span class="section-heading">Canopy deployment</span><span class="section-anchor"> <a href="#canopy-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="canopy-deployment"><h3><span class="section-heading">Canopy deployment</span><span class="section-anchor"> <a rel="bookmark" href="#canopy-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary sources of information about Canopy consensus protocol changes are:</p>
|
||||
<ul>
|
||||
<li>The Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol">2</a></li>
|
||||
|
|
@ -69,15 +69,15 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating on each network, Canopy and pre-Canopy nodes are compatible and can connect to each other. However, Canopy nodes will have a preference for connecting to other Canopy nodes, so pre-Canopy nodes will gradually be disconnected in the run up to activation.</p>
|
||||
<p>Once the network upgrades, even though pre-Canopy nodes can still accept the numerically larger protocol version used by Canopy as being valid, Canopy nodes will always disconnect peers using lower protocol versions.</p>
|
||||
<p>Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in <a id="id16" class="footnote_reference" href="#protocol">2</a> section 7.1; and use the same transaction digest algorithm as defined in <a id="id17" class="footnote_reference" href="#zip-0243">10</a>. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. <a id="id18" class="footnote_reference" href="#zip-0243">10</a></p>
|
||||
</section>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Support for Canopy on testnet will be implemented in <code>zcashd</code> version 3.1.0, which will advertise protocol version 170012. Support for Canopy on mainnet will be implemented in <code>zcashd</code> version 4.0.0, which will advertise protocol version 170013.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Status: Final
|
|||
Category: RPC/Wallet
|
||||
Created: 2018-11-27
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">2</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
|
|
@ -25,17 +25,17 @@ License: MIT</pre>
|
|||
<dd>Code-name for the Zcash shielded protocol added by the second Zcash network upgrade, also known as Network Upgrade 1.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal describes privacy-preserving procedures to migrate funds from Sprout to Sapling z-addresses; and supporting RPC operations to enable, disable, and monitor the migration process.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash Sapling <a id="id2" class="footnote_reference" href="#zip-0205">4</a> introduces significant efficiency improvements relative to the previous iteration of the Zcash shielded protocol, Sprout. These improvements will pave the way for broad mobile, exchange and vendor adoption of shielded addresses.</p>
|
||||
<p>Therefore, we anticipate that users will want to migrate all their shielded funds from Sprout to Sapling.</p>
|
||||
<p>The Zcash consensus rules prohibit direct transfers from Sprout to Sapling z-addresses, unless the amount is revealed by sending it through the "transparent value pool" <a id="id3" class="footnote_reference" href="#transparent-value-pool">1</a>. The primary motivation for this is to allow detection of any overall inflation of the Zcash monetary base, due to exploitation of possible vulnerabilities in the shielded protocols or their implementation, or a compromise of the Sprout multi-party computation. (It is not necessary for Sprout -> Sapling transfers to go via a t-address.)</p>
|
||||
<p>Since the exposure of the migrated amount potentially compromises the privacy of users, we wish to define a way to perform the migration that mitigates this privacy leak as far as possible. This can be done by hiding individual migration transactions among those of all users that are doing the migration at around the same time.</p>
|
||||
<p>The security analysis of migration strategies is quite subtle; the more obvious potential strategies can leak a lot of information.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Migration is performed "in the background" by a <code>zcashd</code> (or equivalent) node. It does not significantly interfere with concurrent usage of the node, other than possibly increasing the latency of some other shielded operations.</p>
|
||||
<p>It is possible to enable or disable migration at any time.</p>
|
||||
<p>All shielded funds in Sprout z-addresses will eventually be transferred to Sapling z-addresses, provided the node is working.</p>
|
||||
|
|
@ -51,7 +51,7 @@ License: MIT</pre>
|
|||
<p>The design recovers from failed operations to the extent possible.</p>
|
||||
<p>The total amount sent by each user is obscured, to the extent practical.</p>
|
||||
</section>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>There is no requirement or assumption of network layer anonymity. (Users may, but are not expected to, configure Tor.)</p>
|
||||
<p>The migration procedure does not have to provably leak no information.</p>
|
||||
<p>There is no need to preserve individual note values (i.e. notes can be consolidated).</p>
|
||||
|
|
@ -59,13 +59,13 @@ License: MIT</pre>
|
|||
<p>A small amount (less than 0.01 ZEC) can be left unmigrated if this helps with privacy.</p>
|
||||
<p>It is not required to support the case of single wallet being used by multiple users whose funds should be kept distinct.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>There are two main aspects to a strategy for selecting migration transactions:</p>
|
||||
<ul>
|
||||
<li>how many transactions are sent, and when;</li>
|
||||
<li>the amount sent in each transaction.</li>
|
||||
</ul>
|
||||
<section id="transaction-schedule"><h3><span class="section-heading">Transaction schedule</span><span class="section-anchor"> <a href="#transaction-schedule"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="transaction-schedule"><h3><span class="section-heading">Transaction schedule</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-schedule"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>When migration is enabled, a node will send up to 5 transactions for inclusion in each block with height a multiple of 500 (that is, they are sent immediately after seeing a block with height 499, modulo 500). Up to the limit of 5, as many transactions are sent as are needed to migrate the remaining funds (possibly with a remainder less than 0.01 ZEC left unmigrated).</p>
|
||||
<p>Nodes SHOULD NOT send migration transactions during initial block download, or if the timestamp of the triggering block (with height 499, modulo 500) is more than three hours in the past according to the node's adjusted local clock.</p>
|
||||
<p>Note: the 500-block interval has <em>not</em> been altered as a result of the halving of target block spacing to 75 seconds with the Blossom upgrade. <a id="id4" class="footnote_reference" href="#zip-0208">5</a></p>
|
||||
|
|
@ -75,7 +75,7 @@ License: MIT</pre>
|
|||
<li>does this reliably give sufficient time to generate the transactions?</li>
|
||||
<li>what happens to a batch if the anchor is invalidated -- should it be regenerated, or cancelled?</li>
|
||||
</ul>
|
||||
<section id="rationale-for-transaction-schedule"><h4><span class="section-heading">Rationale for transaction schedule</span><span class="section-anchor"> <a href="#rationale-for-transaction-schedule"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="rationale-for-transaction-schedule"><h4><span class="section-heading">Rationale for transaction schedule</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-transaction-schedule"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Privacy is increased when the times at which to send transactions are coordinated between nodes. We choose to send a batch of transactions at each coordinated time. Sending multiple transactions in each batch ensures that:</p>
|
||||
<ul>
|
||||
<li>less information about balances is leaked;</li>
|
||||
|
|
@ -133,7 +133,7 @@ License: MIT</pre>
|
|||
<p>The code used for this simulation is at <a id="id5" class="footnote_reference" href="#migration-simulator">6</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="how-much-to-send-in-each-transaction"><h3><span class="section-heading">How much to send in each transaction</span><span class="section-anchor"> <a href="#how-much-to-send-in-each-transaction"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="how-much-to-send-in-each-transaction"><h3><span class="section-heading">How much to send in each transaction</span><span class="section-anchor"> <a rel="bookmark" href="#how-much-to-send-in-each-transaction"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>If the remaining amount to be migrated is less than 0.01 ZEC, end the migration.</p>
|
||||
<p>Otherwise, the amount to send in each transaction is chosen according to the following distribution:</p>
|
||||
<ol type="1">
|
||||
|
|
@ -144,12 +144,12 @@ License: MIT</pre>
|
|||
</ol>
|
||||
<p>Implementations MAY optimize this procedure by selecting the exponent and mantissa based on the amount remaining to avoid repetition, but the resulting distribution MUST be identical.</p>
|
||||
<p>The amount chosen <em>includes</em> the 0.0001 ZEC fee for this transaction, i.e. the value of the Sapling output will be 0.0001 ZEC less.</p>
|
||||
<section id="rationale-for-how-much-to-send"><h4><span class="section-heading">Rationale for how much to send</span><span class="section-anchor"> <a href="#rationale-for-how-much-to-send"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="rationale-for-how-much-to-send"><h4><span class="section-heading">Rationale for how much to send</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-how-much-to-send"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Suppose that a user has an amount to migrate that is a round number of ZEC. Then, a potential attack would be to find some subset of all the migration transactions that sum to a round number of ZEC, and infer that all of those transactions are from the same user. If amounts sent were a random multiple of 1 zatoshi, then the resulting knapsack problem would be likely to have a unique solution and be practically solvable for the number of transactions involved. The chosen distribution of transaction amounts mitigates this potential vulnerability by ensuring that there will be many solutions for sets of transactions, including "incorrect" solutions (that is, solutions that mix transactions from different users, contrary to the supposed adversary's inference).</p>
|
||||
<p>Making the chosen amount inclusive of the fee avoids leaving any unmigrated funds at the end, in the case where the original amount to migrate was a multiple of 0.01 ZEC.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="other-design-decisions"><h3><span class="section-heading">Other design decisions</span><span class="section-anchor"> <a href="#other-design-decisions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="other-design-decisions"><h3><span class="section-heading">Other design decisions</span><span class="section-anchor"> <a rel="bookmark" href="#other-design-decisions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>We assume use of the normal wallet note selection algorithm and change handling. Change is sent back to the default address, which is the z-address of the first selected Sprout note. The number of JoinSplits will therefore be the same as for a normal transaction sending the same amount with the same wallet state. Only the <code>vpub_new</code> of the last JoinSplit will be nonzero. There will always be exactly one Sapling Output.</p>
|
||||
<p>The expiry delta for migration transactions MUST be 450 blocks. Since these transactions are sent when the block height is 499 modulo 500, their expiry height will be 451 blocks later, i.e. <code>nExpiryHeight</code> will be 450 modulo 500.</p>
|
||||
<p>The fee for each migration transaction MUST be 0.0001 ZEC. This fee is taken from the funds to be migrated.</p>
|
||||
|
|
@ -159,7 +159,7 @@ License: MIT</pre>
|
|||
<p>When creating Sapling shielded Outputs, the outgoing viewing key <code>ovk</code> SHOULD be chosen in the same way as for a transfer sent from a t-address.</p>
|
||||
<p>A node SHOULD treat migration transactions in the same way as transactions submitted over the RPC interface.</p>
|
||||
</section>
|
||||
<section id="open-questions"><h3><span class="section-heading">Open questions</span><span class="section-anchor"> <a href="#open-questions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="open-questions"><h3><span class="section-heading">Open questions</span><span class="section-anchor"> <a rel="bookmark" href="#open-questions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The above strategy has several "magic number" parameters:</p>
|
||||
<ul>
|
||||
<li>the interval between batches (500 blocks)</li>
|
||||
|
|
@ -173,7 +173,7 @@ License: MIT</pre>
|
|||
<p>In deciding the amount to send in each transaction, the strategy does not take account of the values of individual Sprout notes, only the total amount remaining to migrate. Can a strategy that is sensitive to individual note values improve privacy?</p>
|
||||
<p>An adversary may attempt to interfere with the view of the block chain seen by a subset of nodes that are performing migrations, in order to cause those nodes to send migration batches at a different time, so that they may be distinguished. Is there anything further we can do to mitigate this vulnerability?</p>
|
||||
</section>
|
||||
<section id="rpc-calls"><h3><span class="section-heading">RPC calls</span><span class="section-anchor"> <a href="#rpc-calls"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="rpc-calls"><h3><span class="section-heading">RPC calls</span><span class="section-anchor"> <a rel="bookmark" href="#rpc-calls"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Nodes MUST maintain a boolean state variable during their execution, to determine whether migration is enabled. The default when a node starts, is set by a configuration option:</p>
|
||||
<pre>-migration=0/1</pre>
|
||||
<p>The destination z-address can optionally be set by another option:</p>
|
||||
|
|
@ -209,7 +209,7 @@ License: MIT</pre>
|
|||
<p>A transaction is <code>finalized</code> iff it has at least 10 confirmations. TODO: subject to change, if the recommended number of confirmations changes.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The following PRs implement this specification:</p>
|
||||
<ul>
|
||||
<li><a href="https://github.com/zcash/zcash/pull/3848">https://github.com/zcash/zcash/pull/3848</a> (TransactionBuilder support)</li>
|
||||
|
|
@ -225,7 +225,7 @@ License: MIT</pre>
|
|||
<li><a href="https://github.com/zcash/zcash/pull/4005">https://github.com/zcash/zcash/pull/4005</a> (change expiry for migration transactions)</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="transparent-value-pool" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Status: Draft
|
|||
Category: Informational
|
||||
Created: 2020-03-09
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<dl>
|
||||
<dt>Sapling FVK</dt>
|
||||
<dd>A Sapling full viewing key as described in <a id="id1" class="footnote_reference" href="#protocol">1</a>, or a Sapling extended full viewing key as described in <a id="id2" class="footnote_reference" href="#zip-0032">2</a>.</dd>
|
||||
|
|
@ -28,14 +28,14 @@ License: MIT</pre>
|
|||
<dd>Information that is not revealed as a consequence of holding a Sapling FVK.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP documents what information an entity learns when they are given one or more Sapling viewing keys, and what guarantees they have about this information.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Shielded addresses allow for network participants to send and receive while revealing as little information on the public block chain as possible. However, there are circumstances in which it is desirable to explicitly reveal some of this information to a third party, such as during auditing or for splitting authority between multiple parties or devices.</p>
|
||||
<p>It is important that a party that is relying on the information made visible by a viewing key, understands what that information conveys and what assumptions they can make when relying on it.</p>
|
||||
</section>
|
||||
<section id="security-properties"><h2><span class="section-heading">Security Properties</span><span class="section-anchor"> <a href="#security-properties"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="security-properties"><h2><span class="section-heading">Security Properties</span><span class="section-anchor"> <a rel="bookmark" href="#security-properties"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Alice has a spending key that she has been using for receiving and sending ZEC. She generates a Sapling FVK and gives it to Ian. What can Ian learn with the Sapling FVK, and what guarantees does he have about the things he learns? (Note for below: IVK and OVK are derived from FVK.)</p>
|
||||
<p>If Ian is given some diversified payment address:</p>
|
||||
<ul>
|
||||
|
|
@ -50,7 +50,7 @@ License: MIT</pre>
|
|||
<ul>
|
||||
<li>[GUARANTEED] He can determine whether or not both of these addresses are linked to the given FVK, and if so, that they are linked to each other.</li>
|
||||
</ul>
|
||||
<section id="what-ian-learns-about-a-single-transaction"><h3><span class="section-heading">What Ian learns about a single transaction</span><span class="section-anchor"> <a href="#what-ian-learns-about-a-single-transaction"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="what-ian-learns-about-a-single-transaction"><h3><span class="section-heading">What Ian learns about a single transaction</span><span class="section-anchor"> <a rel="bookmark" href="#what-ian-learns-about-a-single-transaction"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>If Ian detects a new transaction (defined as a transaction that Ian had no prior knowledge about) solely by decrypting one of its Output descriptions with Alice’s IVK, then he learns:</p>
|
||||
<ul>
|
||||
<li>[GUARANTEED] Whether Alice is a recipient of the payment (by verifying the note commitment against the encrypted contents).
|
||||
|
|
@ -109,7 +109,7 @@ License: MIT</pre>
|
|||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="what-ian-learns-about-balances"><h3><span class="section-heading">What Ian learns about balances</span><span class="section-anchor"> <a href="#what-ian-learns-about-balances"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="what-ian-learns-about-balances"><h3><span class="section-heading">What Ian learns about balances</span><span class="section-anchor"> <a rel="bookmark" href="#what-ian-learns-about-balances"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This section concerns what Ian learns contextually across multiple transactions.</p>
|
||||
<p>We define a “tally” to be the abstraction of balance corresponding to an FVK. This corresponds to exactly one expanded spending key. (Balances cannot accurately be modelled as being associated with a diversified address, since there are multiple diversified addresses associated with an FVK.)</p>
|
||||
<p>The balance of a tally after a particular block is defined as the sum of note values that are spendable, according to the Sapling protocol, using the extended spending key associated with the tally, in a block chain that extends from that block.</p>
|
||||
|
|
@ -130,7 +130,7 @@ License: MIT</pre>
|
|||
</ul>
|
||||
<p>It should be noted that since “out-of-band” payments require cooperation between the sender and recipient in not following the Sapling protocol, the sender and recipient could instead have agreed to use a different tally.</p>
|
||||
</section>
|
||||
<section id="what-ian-learns-about-the-ecosystem"><h3><span class="section-heading">What Ian learns about the ecosystem</span><span class="section-anchor"> <a href="#what-ian-learns-about-the-ecosystem"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="what-ian-learns-about-the-ecosystem"><h3><span class="section-heading">What Ian learns about the ecosystem</span><span class="section-anchor"> <a rel="bookmark" href="#what-ian-learns-about-the-ecosystem"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Assume Ian now has access to a set S of FVKs. Without loss of generality we will treat these as belonging to independent entities.</p>
|
||||
<p>Ian runs the transaction and balance scanning protocols described in previous sections, in parallel for all FVKs in S.</p>
|
||||
<p>In addition to information learned from each individual FVK, Ian can infer:</p>
|
||||
|
|
@ -154,7 +154,7 @@ License: MIT</pre>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -13,27 +13,27 @@ Status: Final
|
|||
Category: Network
|
||||
Created: 2019-09-09
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal specifies a change to the behaviour of <code>zcashd</code> nodes intended to mitigate denial-of-service from transaction flooding.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Adoption of this proposal would increase robustness of Zcash nodes against denial-of-service attack, in particular attacks that attempt to exhaust node memory.</p>
|
||||
<p>Bitcoin Core added size limitation for the mempool in version 0.12 <a id="id2" class="footnote_reference" href="#bitcoincore-pr6722">3</a>, defaulting to 300 MB. This was after Zcash forked from Bitcoin Core.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The memory usage of a node’s mempool should be bounded.</p>
|
||||
<p>The eviction policy should as far as possible not be “gameable” by an adversary, i.e. an adversary should not be able to cause legitimate transactions (that do not themselves present any denial-of-service problem) to be preferentially evicted relative to its own transactions.</p>
|
||||
<p>Any configuration options should have reasonable defaults, i.e. without changing relevant configuration, a node should be adequately protected from denial-of-service via mempool memory exhaustion.</p>
|
||||
</section>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The current architecture of Zcash imposes fundamental limits on scaling of transaction throughput. This proposal does not increase the aggregate transaction capacity of the network. (The Blossom upgrade does increase transaction capacity, by a factor of two <a id="id3" class="footnote_reference" href="#zip-0208">2</a>.)</p>
|
||||
<p>Denial-of-service issues in the messaging layer of the peer-to-peer protocol are out of scope for this proposal.</p>
|
||||
<p>This proposal is focused primarily on memory exhaustion attacks. It does not attempt to use fees to make denial-of-service economically prohibitive, since that is unlikely to be feasible while maintaining low fees for legitimate users. It does not preclude changes in fee policy.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This specification describes the intended behaviour of <code>zcashd</code> nodes. Other node implementations MAY implement the same or similar behaviour, but this is not a requirement of the network protocol. Thus, RFC 2119 conformance keywords below are to be interpreted only as placing requirements on the <code>zcashd</code> implementation (and potentially other implementations that have adopted this specification in full).</p>
|
||||
<p>The mempool of a node holds a set of transactions. Each transaction has a <em>cost</em>, which is an integer defined as:</p>
|
||||
<blockquote>
|
||||
|
|
@ -56,7 +56,7 @@ License: MIT</pre>
|
|||
</ul>
|
||||
<p>Nodes SHOULD remove transactions from RecentlyEvicted that were evicted more than <code>mempoolevictionmemoryminutes</code> minutes ago. This MAY be done periodically, and/or just before RecentlyEvicted is accessed when receiving a transaction.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The accounting for transaction size should include some overhead per transaction, to reflect the cost to the network of processing them (proof and signature verification; networking overheads; size of in-memory data structures). The implication of not including overhead is that a denial-of-service attacker would be likely to use minimum-size transactions so that more of them would fit in a block, increasing the unaccounted-for overhead. A possible counterargument would be that the complexity of accounting for this overhead is unwarranted given that the format of a transaction already imposes a minimum size. However, the proposed cost function is almost as simple as using transaction size directly.</p>
|
||||
<p>The threshold 4000 for the cost function is chosen so that the size in bytes of a typical fully shielded Sapling transaction (with, say, 2 shielded outputs and up to 5 shielded inputs) will fall below the threshold. This has the effect of ensuring that such transactions are not evicted preferentially to typical transparent transactions because of their size.</p>
|
||||
<p>The proposed eviction policy differs significantly from that of Bitcoin Core <a id="id4" class="footnote_reference" href="#bitcoincore-pr6722">3</a>, which is primarily fee-based. This reflects differing philosophies about the motivation for fees and the level of fee that legitimate users can reasonably be expected to pay. The proposed eviction weight function does involve a penalty for transactions with a fee lower than the standard (0.0001 ZEC) value, but since there is no further benefit to increasing the fee above the standard value, it creates no pressure toward escalating fees. For transactions up to 4000 bytes, this penalty makes a transaction that pays less than the standard fee value five times as likely to be chosen for eviction (because 4000 + 16000 = 20000 = 4000 * 5).</p>
|
||||
|
|
@ -67,16 +67,16 @@ License: MIT</pre>
|
|||
<p>Note that the RecentlyEvicted queue is intended as a performance optimization under certain conditions, rather than as a DoS-mitigation measure in itself.</p>
|
||||
<p>The default expiry of 40 blocks after Blossom activation represents an expected time of 50 minutes. Therefore (even if some blocks are slow), most legitimate transactions are expected to expire within 60 minutes. Note however that an attacker’s transactions cannot be relied on to expire.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This specification is proposed to be implemented in <code>zcashd</code> v2.1.0. It is independent of the Blossom network upgrade.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li><a href="https://github.com/zcash/zcash/pull/4145">PR 4145: Implementation</a></li>
|
||||
<li><a href="https://github.com/zcash/zcash/pull/4166">PR 4166: macOS compliation fix</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Category: Consensus
|
|||
Created: 2019-08-01
|
||||
License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/>
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-keep-the-block-distribution-as-initaly-defined-90-to-miners/33843></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">2</a></p>
|
||||
<p>For clarity this ZIP defines these terms:</p>
|
||||
<ul>
|
||||
|
|
@ -34,31 +34,31 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-keep-the-blo
|
|||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The spirit of this ZIP is to is to ensure that the Founders’ Reward ends. It is not the intention of this ZIP to stop protocol-based donations.</p>
|
||||
<p>It is a simple short ZIP.</p>
|
||||
<p>Hopefully it will be compatible with a number of other ZIPs and can be worked into them.</p>
|
||||
</section>
|
||||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this Proposal</span><span class="section-anchor"> <a href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this Proposal</span><span class="section-anchor"> <a rel="bookmark" href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>Governance on how decisions are made; this ZIP is not meant to be used as a form of governance.</li>
|
||||
<li>Future funding.</li>
|
||||
<li>It does not cover other donations or revenue streams.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>The Founders’ Reward is set to expire in 2020.</li>
|
||||
<li>To honour the initial promise of giving 90% of total block distribution to miners. Therefore the protocol will give them 100% of the block distribution after the first halving.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>The Founders’ Reward MUST end at the first halving in October 2020.</li>
|
||||
<li>This ZIP does not preclude the Electric Coin Company from sourcing funding elsewhere, or from donations.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>The existing Founders’ Reward consensus rules <a id="id4" class="footnote_reference" href="#spec-subsidies">4</a> <a id="id5" class="footnote_reference" href="#spec-foundersreward">5</a> MUST be preserved.</li>
|
||||
<li>Specifically, <code>FoundersReward(height)</code> MUST equal <code>0</code> if <code>Halving(height) >= 1</code>. (For clarity once the halving happens the Founders’ Reward stops, as per the rules outlined in <a id="id6" class="footnote_reference" href="#spec-subsidies">4</a> and <a id="id7" class="footnote_reference" href="#spec-foundersreward">5</a>.)</li>
|
||||
|
|
@ -66,16 +66,16 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-keep-the-blo
|
|||
<li>Enforcing some kind of mandatory donation via whatever mechanism would be seen as continuation of the Founders’ Reward.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="implications-to-other-users"><h2><span class="section-heading">Implications to other users</span><span class="section-anchor"> <a href="#implications-to-other-users"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="implications-to-other-users"><h2><span class="section-heading">Implications to other users</span><span class="section-anchor"> <a rel="bookmark" href="#implications-to-other-users"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>Block distribution payouts to Founders’ Reward addresses will cease at the first halving.</li>
|
||||
<li>Pools and other software need to take this into account.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="technical-implementation"><h2><span class="section-heading">Technical implementation</span><span class="section-anchor"> <a href="#technical-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="technical-implementation"><h2><span class="section-heading">Technical implementation</span><span class="section-anchor"> <a rel="bookmark" href="#technical-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP requires no changes to current consensus implementations.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Category: Standards Track
|
|||
Created: 2019-07-17
|
||||
License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/>
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-opt-in-protocol-level-development-donation-option/33846></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">3</a></p>
|
||||
<p>This ZIP defines these terms:</p>
|
||||
<ul>
|
||||
|
|
@ -42,23 +42,23 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-op
|
|||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this Proposal</span><span class="section-anchor"> <a href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this Proposal</span><span class="section-anchor"> <a rel="bookmark" href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Governance on how decisions are made. This ZIP is not meant to be used as a form of governance. It is a protocol-level opt-in for supporting the Zcash network development (like the Founders’ Reward, just with opt-out).</p>
|
||||
<p>Signalling. Whilst a lot of the ZIP relies on the ability to signal intent in one way or another, it does not put forward such a mechanism and is designed to work with various form of signalling, or potentially without signalling at all.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The spirit of this ZIP is:</p>
|
||||
<ul>
|
||||
<li>To allow continual funding of the Electric Coin Company, the Zcash Foundation, or some combination of these should a user choose to do so.</li>
|
||||
<li>To add a genuine opt-in feature, which is done at the user's choice.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Technology changes, and it changes fast. What works now, may be easily breakable in 10 years, 20 years and certainly 50 years.</p>
|
||||
<p>To help ensure ZEC can keep up with these changes, now and in 50 or 500 years' time, there needs to be a continual funding for research into new technology and financial stability in order to attract new talent.</p>
|
||||
<p>The only source of indefinite wealth transfer is transaction fees or donations. This ZIP is specifically about voluntary donations (including via mining fees).</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>An additional opt-in mechanism, baked into the protocol. This is a condition of the Zcash Foundation too. <a id="id3" class="footnote_reference" href="#foundation">2</a></li>
|
||||
<li>Give an alterative to redistribution of either the current block distribution structure or the emission curve.</li>
|
||||
|
|
@ -78,7 +78,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-op
|
|||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>This ZIP MUST enforce the initial promise as defined by default.</li>
|
||||
<li>The official client MUST default to be counted as initial promise.</li>
|
||||
|
|
@ -92,7 +92,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-op
|
|||
</ul>
|
||||
<p><span class="editor-note">this proposal is being published as a ZIP for the purpose of discussion and for the Zcash Foundation's sentiment collection process, despite significant issues with lack of clarity in the above specification.</span></p>
|
||||
</section>
|
||||
<section id="raised-objections-and-issues-so-far"><h2><span class="section-heading">Raised objections and issues so far</span><span class="section-anchor"> <a href="#raised-objections-and-issues-so-far"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="raised-objections-and-issues-so-far"><h2><span class="section-heading">Raised objections and issues so far</span><span class="section-anchor"> <a rel="bookmark" href="#raised-objections-and-issues-so-far"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>This adds complexity to the protocol, which is technically not needed and generally a bad idea.</li>
|
||||
<li>This does not add anything that cannot already be done under the current protocol by users manually, although not to the same extent.</li>
|
||||
|
|
@ -104,7 +104,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-op
|
|||
<li>Further note: If burn must be an option I would like to use something like the "rolling burn" option. <span class="editor-note">this is not defined; it was intended that another ZIP be written to define it, but that has not been done.</span></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="implications-to-other-users"><h2><span class="section-heading">Implications to other users</span><span class="section-anchor"> <a href="#implications-to-other-users"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="implications-to-other-users"><h2><span class="section-heading">Implications to other users</span><span class="section-anchor"> <a rel="bookmark" href="#implications-to-other-users"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>Wallet development will need to be considered. Hopefully the requirements will lessen this impact after the first initial change.</li>
|
||||
<li>What happens if the Electric Coin Company and/or the Zcash Foundation close down, will the donations:
|
||||
|
|
@ -117,7 +117,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-op
|
|||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="technical-implementation"><h2><span class="section-heading">Technical implementation</span><span class="section-anchor"> <a href="#technical-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="technical-implementation"><h2><span class="section-heading">Technical implementation</span><span class="section-anchor"> <a rel="bookmark" href="#technical-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Stuff that is already implemented in some form or another:</p>
|
||||
<ul>
|
||||
<li>Optional fees are already implemented in some wallet software.</li>
|
||||
|
|
@ -128,7 +128,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-op
|
|||
<li>Pools already add their own addresses to the coinbase, including donations.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Category: Consensus / Process
|
|||
Created: 2019-06-19
|
||||
License: MIT
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-20-split-between-the-ecc-and-the-foundation/33862></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>For clarity in this ZIP I define these terms:</p>
|
||||
<dl>
|
||||
|
|
@ -26,10 +26,10 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-20-spli
|
|||
<dd>Dev Fund Percentage, the portion of newly minted ZEC in each block reserved for a development fund.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal would allocate a 20% Dev Fund Percentage to be split evenly between the Electric Coin Company (ECC) and the Zcash Foundation during the 2nd Halvening period. This proposal aims to be simple to implement, without a single point of failure, and comes with mandates for transparency, accountability and a mandate to build a development fund voting mechanism to be used during the 3rd Halvening period. This proposal is designed to strike a balance between ensuring that high quality development work can continue uninterrupted, with the need to further decentralize Zcash development funding as soon as possible.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Strengths of this proposal:</p>
|
||||
<ol type="1">
|
||||
<li>Simple to implement. I would rather developers spend time scaling Zcash rather than implementing the development funding mechanism.</li>
|
||||
|
|
@ -38,13 +38,13 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-20-spli
|
|||
<li>With two entities receiving funds there is no single point of failure.</li>
|
||||
</ol>
|
||||
</section>
|
||||
<section id="requirements-and-specification"><h2><span class="section-heading">Requirements and Specification</span><span class="section-anchor"> <a href="#requirements-and-specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements-and-specification"><h2><span class="section-heading">Requirements and Specification</span><span class="section-anchor"> <a rel="bookmark" href="#requirements-and-specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ol type="1">
|
||||
<li>DF% MUST be 20 percent, split evenly between ECC and the Zcash Foundation during the 2nd Halvening period.</li>
|
||||
<li>The Dev Fund MUST only be spent on research, development and adoption of Zcash.</li>
|
||||
<li>A voting system for development funding MUST be built and implemented in order to be used during the 3rd Halvening period.</li>
|
||||
</ol>
|
||||
<section id="voting-system-requirements"><h3><span class="section-heading">Voting System Requirements</span><span class="section-anchor"> <a href="#voting-system-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="voting-system-requirements"><h3><span class="section-heading">Voting System Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#voting-system-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Here are the general properties of the mandated voting mechanism. I don’t want to specify the technical implementation details, since I believe this is a job suited for the engineers building this system.</p>
|
||||
<ol type="1">
|
||||
<li>Voting SHOULD be private.</li>
|
||||
|
|
@ -56,7 +56,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-20-spli
|
|||
<li>The system should be totally open and allow anyone/any organization to compete for funding to develop Zcash.</li>
|
||||
</ol>
|
||||
</section>
|
||||
<section id="transparency-and-accountability-for-the-ecc-and-the-zcash-foundation"><h3><span class="section-heading">Transparency and Accountability for the ECC and the Zcash Foundation</span><span class="section-anchor"> <a href="#transparency-and-accountability-for-the-ecc-and-the-zcash-foundation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="transparency-and-accountability-for-the-ecc-and-the-zcash-foundation"><h3><span class="section-heading">Transparency and Accountability for the ECC and the Zcash Foundation</span><span class="section-anchor"> <a rel="bookmark" href="#transparency-and-accountability-for-the-ecc-and-the-zcash-foundation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>These requirements would apply to both ECC and the Zcash Foundation. The mandate is to adhere to these accountability requirements originally put forward by the Foundation:</p>
|
||||
<ul>
|
||||
<li>Monthly public developer calls, detailing current technical roadmap and updates.</li>
|
||||
|
|
@ -66,7 +66,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-20-spli
|
|||
<li>Yearly reviews of organization performance, along the lines of the State of the Zcash Foundation report <a id="id2" class="footnote_reference" href="#zfnd-state">2</a>.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="requirements-specifically-for-the-ecc"><h3><span class="section-heading">Requirements Specifically for the ECC</span><span class="section-anchor"> <a href="#requirements-specifically-for-the-ecc"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="requirements-specifically-for-the-ecc"><h3><span class="section-heading">Requirements Specifically for the ECC</span><span class="section-anchor"> <a rel="bookmark" href="#requirements-specifically-for-the-ecc"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Motivated by the Zcash Foundation’s proposal that the ECC become a non-profit <a id="id3" class="footnote_reference" href="#zfnd-guidance">3</a>, I am going to list general requirements for the ECC to abide by if they choose to receive funds and work on behalf of ZEC holders.</p>
|
||||
<ol type="1">
|
||||
<li>Because I share the Foundation’s concern that the ECC could be “beholden to its shareholders”, I am mandating that the ECC should be working in the service of the Zcash community and <strong>shall serve no other masters</strong>. The original investors/founders who are not still working in the service of the Zcash community SHOULD NOT have control over the use of the new development funds.</li>
|
||||
|
|
@ -78,7 +78,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-20-spli
|
|||
<p>Finally, in the event that the voting system isn’t implemented by the start of the 3rd Halvening period, the 20% of funds intended to go to the ‘voting development fund’ should instead not be minted.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
@ -104,7 +104,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-20-spli
|
|||
</tbody>
|
||||
</table>
|
||||
<br></section>
|
||||
<section id="change-log"><h2><span class="section-heading">Change Log</span><span class="section-anchor"> <a href="#change-log"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="change-log"><h2><span class="section-heading">Change Log</span><span class="section-anchor"> <a rel="bookmark" href="#change-log"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>2019-06-19 Initial post</li>
|
||||
<li>2019-26-07 Listed three strengths of this proposal</li>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Category: Consensus
|
|||
Created: 2019-06-19
|
||||
License: public domain
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-directed-dev-fund-was-20-to-any-combination-of-ecc-zfnd-parity-or-burn/33864></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>For clarity, this ZIP defines these terms:</p>
|
||||
<dl>
|
||||
|
|
@ -26,33 +26,33 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-d
|
|||
<dd>Miner Reward Percentage, the portion of newly minted ZEC in each block given to miners (so that DF% + MR% = 100%).</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal reserves a portion (20%) of the newly minted coins in each block for the development fund. A fixed set of developer entities would be eligible to receive these funds. The fund would be miner-directed in the sense that the miner of each block can determine how to allocate these funds to eligible developers.</p>
|
||||
</section>
|
||||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this proposal</span><span class="section-anchor"> <a href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this proposal</span><span class="section-anchor"> <a rel="bookmark" href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>This proposal does not (currently) specify any process for reaching agreement on or modifying the fixed set of development entities.</li>
|
||||
<li>This proposal does not specify how miners should reach a decision on how to direct the development fund, or how developers should appeal to miners to do so. Other development fund proposals include specific processes for accountability and to support community decision making, such as monthly developer calls, lists of planned features and goals, etc. Any of these can be compatible with this proposal as well, by providing non-binding advice to miners, by reaching agreement on implementation defaults, by guiding the choice of the fixed set of developers, etc.</li>
|
||||
<li>This proposal only provides a guideline for the 2nd Halvening Period.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Like most development fund proposals, this is motivated by the potential value to the Zcash community of using newly minted coins to hire developers to continue improving Zcash. <a id="id2" class="footnote_reference" href="#amiller-notes">2</a></p>
|
||||
<p>Unlike most other development fund proposals, this proposal is distinct in providing a fine-grained “opt-in” <a id="id3" class="footnote_reference" href="#acityinohio-comment">3</a> feature, since miners have the choice to provide a small amount of development funding or none at all.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>Simplicity: A design goal of this proposal is to be simple to define and implement, without specifying much process for on-chain or off-chain governance.</li>
|
||||
<li>Opt-in: The proposed development fund is not mandatory, since miners can decide not to allocate any funds at all to the developer entities.</li>
|
||||
<li>Incentive-compatible: Miners cannot directly pay the development fund to themselves.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>During the 2nd Halvening Period, a fixed portion (DF% = 20%) of the newly minted coins in each block are reserved for a Miner-Directed Dev Fund (MDDF). A hardcoded set of developer entities (e.g., Electric Coin Company, Zcash Foundation, Parity, or others), represented in the code by their t-address or z-address public keys, are eligible to receive funding from the MDDF. The fund is “miner-directed” in the sense that the miner in each block chooses how to allocate the MDDF coins among the developer entities, simply by creating outputs in the coinbase transaction. The DF% is a maximum — miners can also “opt out” by minting a lower number of coins for the MDDF, or none at all.</p>
|
||||
<p>This proposal is explicitly limited in scope to the 2nd Halvening Period. After the end of this period, the entire block reward in each block is awarded to the miner. The upper bound on the rate of newly minted coins MUST remain the same as before this proposal (i.e., at most 25 ZEC minted per 10 minutes during the 2nd Halvening Period).</p>
|
||||
<p>Implementations MAY define a default opt-in allocation (e.g., DF%/2 to the Electric Coin Company and DF%/2 to the Zcash Foundation).</p>
|
||||
<p>Implementations SHOULD support changing the allocation (overriding any such default) through a configuration option.</p>
|
||||
<section id="examples"><h3><span class="section-heading">Examples</span><span class="section-anchor"> <a href="#examples"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="examples"><h3><span class="section-heading">Examples</span><span class="section-anchor"> <a rel="bookmark" href="#examples"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The following examples illustrate how miners can build the outputs of the coinbase transactions to allocate the MDDF to eligible developers. Assume <code>Dev1</code>, <code>Dev2</code> are the hardcoded addresses of eligible developers, and <code>Miner</code> is the address of the mining pool mining this block. Assume that the total newly minted coins are 3.125 ZEC per block during the 2nd Halvening Period (this takes into account the change to a 75-second block target spacing after the Blossom Network Upgrade <a id="id4" class="footnote_reference" href="#zip-0208">5</a>), and that DF% = 20%, MR% = 80%.</p>
|
||||
<p><strong>Example 1: Split equally between two developers</strong></p>
|
||||
<p>The transaction outputs of the coinbase transaction are as follows:</p>
|
||||
|
|
@ -68,7 +68,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-d
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="issues-and-further-discussion"><h2><span class="section-heading">Issues and Further Discussion</span><span class="section-anchor"> <a href="#issues-and-further-discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="issues-and-further-discussion"><h2><span class="section-heading">Issues and Further Discussion</span><span class="section-anchor"> <a rel="bookmark" href="#issues-and-further-discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Raised objections and issues so far:</p>
|
||||
<ul>
|
||||
<li>Miners may have adverse incentives, such as:
|
||||
|
|
@ -82,7 +82,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-d
|
|||
<li>Several others, notably the Blocktown Capital proposal <a id="id5" class="footnote_reference" href="#blocktown-summary">4</a>, have suggested that a 20% development fund would set a precedent for a perpetual 20% development fund. This proposal is explicitly limited in scope to the 2nd Halvening Period. Thus adopting this proposal on its own, if there are no further updates, would result in the the development fund ending in 2024.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
@ -124,7 +124,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-d
|
|||
</tbody>
|
||||
</table>
|
||||
<br></section>
|
||||
<section id="change-log"><h2><span class="section-heading">Change Log</span><span class="section-anchor"> <a href="#change-log"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="change-log"><h2><span class="section-heading">Change Log</span><span class="section-anchor"> <a rel="bookmark" href="#change-log"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>2019-06-19 Initial post</li>
|
||||
<li>2019-08-28
|
||||
|
|
|
|||
|
|
@ -14,10 +14,10 @@ Category: Consensus
|
|||
Created: 2019-06-23
|
||||
License: MIT
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-zcfs-zcash-community-funding-system/33898></pre>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal introduces a new funding mechanism called the Zcash Community Funding System (ZCFS).</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The motivations for ZCFS are:</p>
|
||||
<ul>
|
||||
<li>The Founders’ Reward is set to expire in 2020.</li>
|
||||
|
|
@ -25,7 +25,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-zcfs-zcash-c
|
|||
<li>There needs to be a more fair and decentralized funding mechanism.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This specification is a modification of the Monero Community Crowdfunding System (CCS) and is defined as follows:</p>
|
||||
<ol type="1">
|
||||
<li>The Founders’ Reward ends in October 2020 as specified by the current consensus rules.</li>
|
||||
|
|
@ -42,9 +42,9 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-zcfs-zcash-c
|
|||
<li>After all milestones are completed, the proposal is locked and all information is retained for posterity.</li>
|
||||
</ol>
|
||||
</section>
|
||||
<section id="rules-and-expectations"><h2><span class="section-heading">Rules and Expectations</span><span class="section-anchor"> <a href="#rules-and-expectations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rules-and-expectations"><h2><span class="section-heading">Rules and Expectations</span><span class="section-anchor"> <a rel="bookmark" href="#rules-and-expectations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The ZCFS is intentionally left as informal as possible. This allows for flexibility of the system, and keeps things from being red-taped into oblivion. However, there are some things you should understand, things that will be expected of you, as either a proposer or a donor, and a recommended way of structuring a proposal for maximum likelihood that your project will be funded.</p>
|
||||
<section id="for-donors"><h3><span class="section-heading">For Donors</span><span class="section-anchor"> <a href="#for-donors"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="for-donors"><h3><span class="section-heading">For Donors</span><span class="section-anchor"> <a rel="bookmark" href="#for-donors"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<ol type="1">
|
||||
<li>The ZCFS is escrowed by the Zcash Foundation (or whoever has ownership of the ZCFS at the time). When you make a donation, you are releasing funds to them to disburse when they deem the community agrees that a milestone is complete. They do not do the work to verify donors, and the final decision for all disputes falls with them, although they do their best to follow community sentiment.</li>
|
||||
<li>In the event that a proposal is overfunded, unable to be completed, or otherwise put in a state where donated money will not be disbursed to the proposer, the default is that the remaining ZEC will be put in the ZF Grants fund.</li>
|
||||
|
|
@ -53,7 +53,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-zcfs-zcash-c
|
|||
<li>Milestone and payout structures vary per proposal based on the proposer’s wishes. It is up to the donor to do their due diligence in whether or not they support the proposal in its entirety.</li>
|
||||
</ol>
|
||||
</section>
|
||||
<section id="for-proposers"><h3><span class="section-heading">For Proposers</span><span class="section-anchor"> <a href="#for-proposers"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="for-proposers"><h3><span class="section-heading">For Proposers</span><span class="section-anchor"> <a rel="bookmark" href="#for-proposers"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<ol type="1">
|
||||
<li>There is no guarantee that your project will get past the community feedback stage, and if it does, there is no guarantee that it will be funded.</li>
|
||||
<li>You have to drum up support for your proposal during the feedback and funding stages. Do not expect others (especially the Zcash Foundation or other trusted members of the community) to do it for you. Others may share and support if they are excited about your project, but ultimately it is nobody’s responsibility but your own.</li>
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Category: Consensus / Process
|
|||
Created: 2019-08-31
|
||||
License: MIT
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/blocktown-development-fund-proposal-10-to-a-2-of-3-multisig-with-community-involved-third-entity/34782></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words “MUST”, “SHOULD”, “SHOULD NOT”, and “MAY” in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The additional terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
|
|
@ -39,11 +39,11 @@ Discussions-To: <https://forum.zcashcommunity.com/t/blocktown-development-fun
|
|||
<dd>Any individual, group, or entity that receives funding from the Zcash Development Fund.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal puts forward the financing mechanism and fundamental rules of governance for the creation of a Zcash Development Fund.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="funding-mechanism-of-the-zcash-development-fund"><h3><span class="section-heading">Funding mechanism of the Zcash Development Fund</span><span class="section-anchor"> <a href="#funding-mechanism-of-the-zcash-development-fund"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="funding-mechanism-of-the-zcash-development-fund"><h3><span class="section-heading">Funding mechanism of the Zcash Development Fund</span><span class="section-anchor"> <a rel="bookmark" href="#funding-mechanism-of-the-zcash-development-fund"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<ul>
|
||||
<li>This funding mechanism MUST be hard-coded so that 10% of newly issued ZEC from block rewards are automatically directed to the transparent address(es) of the Zcash Development Fund.</li>
|
||||
<li>The above requirement MUST be met between the first halving and second halving. Upon the second halving, future governance decisions MAY result in a further decrease of the Zcash Development Fund to 5% of newly issued ZEC from block rewards, or alternatively MAY result in another percent allocation which includes the possibility of a system whereby 100% of block rewards go to miners.</li>
|
||||
|
|
@ -52,7 +52,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/blocktown-development-fun
|
|||
<li>The hard-coded transparent address(es) of the Zcash Development Fund MAY be periodically rotated for operational security purposes to decrease the risk of any potential loss of funds associated with the address(es). The ECC, ZF, and/or “Third Entity” described below SHOULD take any possible precautions within the confines of this Specification section to avoid loss of funds.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="governance-of-the-zcash-development-fund"><h3><span class="section-heading">Governance of the Zcash Development Fund</span><span class="section-anchor"> <a href="#governance-of-the-zcash-development-fund"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="governance-of-the-zcash-development-fund"><h3><span class="section-heading">Governance of the Zcash Development Fund</span><span class="section-anchor"> <a rel="bookmark" href="#governance-of-the-zcash-development-fund"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<ul>
|
||||
<li>Funds allocated to the Zcash Development Fund MUST be used only for their intended purpose as defined in the following Rationale section of this proposal.</li>
|
||||
<li>The transparent address(es) of the Zcash Development Fund MUST be jointly controlled by the ECC, ZF, and Third Entity, and all funds transferred from the Zcash Development Fund MUST be publicly confirmed in an official manner by a majority decision among the ECC, ZF, and Third Entity–commonly referred to as “2-of-3 multisig”. That is, funding decisions MUST be put to an officially documented vote which MUST NOT pass unless at least 2 of the 3 entities above vote approvingly.</li>
|
||||
|
|
@ -82,14 +82,14 @@ Discussions-To: <https://forum.zcashcommunity.com/t/blocktown-development-fun
|
|||
<p>Any decision to alter the governance of the Zcash Development Fund as described in this proposal and in final detail by the ECC, ZF, and Third Entity MUST involve the Zcash community at large, similar to the process outlined in the ZF’s August 6, 2019 statement <a id="id5" class="footnote_reference" href="#zfnd-guidance">2</a>. All transfers from the Zcash Development Fund MUST be in full accordance with the requirements described in this proposal.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="issues-not-addressed-in-this-proposal-out-of-scope"><h2><span class="section-heading">Issues not addressed in this proposal/Out-of-Scope</span><span class="section-anchor"> <a href="#issues-not-addressed-in-this-proposal-out-of-scope"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="issues-not-addressed-in-this-proposal-out-of-scope"><h2><span class="section-heading">Issues not addressed in this proposal/Out-of-Scope</span><span class="section-anchor"> <a rel="bookmark" href="#issues-not-addressed-in-this-proposal-out-of-scope"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>Details of the decision-making process for supporting or rejecting this or other relevant proposals by the ECC, ZF, and/or other Zcash stakeholders. We do maintain, however, that any decision by the ECC and/or the ZF on the issue described in the Motivation section below SHOULD be preceded by the procedures for measuring community sentiment as outlined in the ZF’s August 6, 2019 statement <a id="id6" class="footnote_reference" href="#zfnd-guidance">2</a>.</li>
|
||||
<li>Additional methods for measuring community sentiment MAY include a way for ZEC holders to signal their support of specific proposals.</li>
|
||||
<li>The matter of whether the ECC should reorganize itself into a non-profit or remain for-profit, as addressed by the ZF in their August 6, 2019 statement <a id="id7" class="footnote_reference" href="#zfnd-guidance">2</a>. The current proposal is neutral on this matter, and funding from the Development Fund would be available for non-profit and/or for-profit entities. We consider the governance rules of the Development Fund outlined in this Specification section adequate for transparency and accountability.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Zcash network is scheduled to undergo its first halving in October 2020, per current protocol specifications. At the time of the first halving, the codebase dictates that the Founder’s Reward, which consists of 20% of the ZEC from every block reward, will be terminated. Without codebase modification, for example in the upcoming NU4 Network Upgrade, 100% of block rewards would be claimed by miners after the first halving.</p>
|
||||
<p>The two organizations presently leading development and maintenance of the Zcash network receive funds from the Founder’s Reward. These organizations, the ECC and ZF, have recently requested a source of funding after the first halving in order to continue operations for the foreseeable future. The source of funds could theoretically be from either a modification to the codebase dictating a Zcash Development Fund from block rewards or, alternatively, from external sources. The ECC has indicated though that it would “wind down or pivot” rather than accept funding from any sources that would give “special interests” control over the ECC <a id="id8" class="footnote_reference" href="#ecc-assessment">3</a>.</p>
|
||||
<p>Based on the ECC’s demands, the block reward appears to be the most agreeable source of resources for a Zcash Development Fund.</p>
|
||||
|
|
@ -98,7 +98,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/blocktown-development-fun
|
|||
<p>With a Zcash Development Fund that is only 10% of the block reward, a precedent will be set that a large centralized fund is not indefinite and will decrease faster than simply the rate of block reward halvings. Although this proposal specifically addresses the period between the first and second halving, this proposed feature may set a precedent whereby the percent fee from block rewards allocated to a Zcash Development Fund continually decreases every halving, e.g. 20% (FR) from 2016-2020, 10% from 2020-2024, 5% from 2024-2028, 2.5% from 2028-2032 (effectively quartering the ZEC allocated to a development fund every four years). We believe that this social contract could restore the community’s faith in the decentralization of Zcash as the network incentives align more closely with that of Bitcoin’s over time. Alternatively, it is not unreasonable for the Zcash governance system to elect a 0% allocation for the Zcash Development Fund upon the second halving. For a more detailed exploration regarding the selection of 10%, please review the blog post ‘Proposal for 10% Dev Fund in Zcash 2020 Network Upgrade’ <a id="id11" class="footnote_reference" href="#blocktown-10pc">6</a>.</p>
|
||||
<p>Of note, we are not suggesting or implying that the funding from the Founder’s Reward and a Zcash Development Fund would be managed in a similar way or have similar directives. The Zcash Development Fund feature that we propose for NU4 does not allocate any funds to former angel investors, VCs or vested employees. Furthermore, the Zcash Development Fund would be subject to more explicit and transparent rules of governance, as outlined in the Specification section of this proposal.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The rationale behind this proposal is as follows:</p>
|
||||
<ul>
|
||||
<li>To provide financial resources for research, development, and any other technical work connected to software upgrades/maintenance of the Zcash protocol, as well as non-technical initiatives including marketing, design, events, regulatory outreach, education, governance, and any other form of business that contribute to the success of the Zcash network.</li>
|
||||
|
|
@ -108,7 +108,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/blocktown-development-fun
|
|||
<li>To encourage transparency and cooperation among Zcash stakeholders and strengthen the community’s governance capabilities moving forward.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="discussion"><h2><span class="section-heading">Discussion</span><span class="section-anchor"> <a href="#discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="discussion"><h2><span class="section-heading">Discussion</span><span class="section-anchor"> <a rel="bookmark" href="#discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Recognized objections to this proposal include:</p>
|
||||
<ul>
|
||||
<li>This proposal is not in accordance with the current Zcash protocol, which is programmed to allocate 100% of the coinbase to miners upon the first halving in 2020. However, at least during the next few years of Zcash’s infancy, we believe it is advantageous to have a funded and dedicated development team.</li>
|
||||
|
|
@ -118,10 +118,10 @@ Discussions-To: <https://forum.zcashcommunity.com/t/blocktown-development-fun
|
|||
<li>This proposal does not have a clause dictating that a Recipient must abstain from voting. If a Recipient must abstain from voting in a 2-of-3 multisig governance system, then this could –as in the case of 2-of-2 multisig– result in an entity holding another hostage. For example, if the ECC refuses to fund the ZF until the ZF complies with the ECC’s demands, then the ECC has the power to deadlock any vote to fund the ZF, which requires the ECC and Third Entity to both vote approvingly.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Aspects of this proposal, particularly the Terminology and Specification sections, were adapted and expanded definitions and concepts put forth in Placeholder’s dev fund proposal from August 22, 2019 <a id="id14" class="footnote_reference" href="#placeholder-proposal">8</a>.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -15,24 +15,24 @@ Category: Process
|
|||
Created: 2019-08-24
|
||||
License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/>
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter/34709></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>For clarity this ZIP defines these terms:</p>
|
||||
<ul>
|
||||
<li>Covenant is defined as a legally binding agreement, upon which a specific aspect of development of the Zcash protocol and/or adoption is scheduled and agreed.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>A supplemental proposal to ensure feature selection and work is community-driven.</p>
|
||||
<p>Hopefully it will be compatible with a number of other ZIPs and can be worked into them.</p>
|
||||
</section>
|
||||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this Proposal</span><span class="section-anchor"> <a href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this Proposal</span><span class="section-anchor"> <a rel="bookmark" href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>This proposal does not address the merits, motivations or terms of any particular Development Funding Proposal.</li>
|
||||
<li>Requirements and Implementation.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="motivation-and-requirements"><h2><span class="section-heading">Motivation and Requirements</span><span class="section-anchor"> <a href="#motivation-and-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation-and-requirements"><h2><span class="section-heading">Motivation and Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#motivation-and-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal is supplemental to any Development Funding Proposal that places or purports to place conditions on how the Electric Coin Company (ECC) and the Zcash Foundation (ZF) use development funds, or take other related off-chain actions such as requirements and Covenants.</p>
|
||||
<p>For example, the proposal <a id="id2" class="footnote_reference" href="#zip-1006">2</a> provides that “[f]unds accruing to the Zcash Development Fund MUST be used only for ... technical work directly connected to the various software implementations of the Zcash protocol.” However, once development funding is approved and implemented via a Network Upgrade, there will be no enforcement mechanism to ensure that the ZF and ECC abide by this requirement.</p>
|
||||
<p>This proposal aims to provide such an enforcement mechanism. If this proposal is adopted, then the ECC and/or ZF, as applicable MUST enter into a legal agreement that would entitle ZEC holders to enforce ECC’s/ZF’s performance of any Covenants. For the purposes of this proposal we will refer to the legal agreement as the “DevFund Charter” or “Charter” for short, but it MAY also be styled in other ways – e.g. as a Constitution, Bylaws, Fund Governance Agreement, etc.</p>
|
||||
|
|
@ -42,16 +42,16 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-supplemental-pro
|
|||
<p>It is assumed that the Electric Coin Company, Zcash Foundation, or party with a direct conflict of interest SHOULD identify their vote/signal - which MAY be rejected from the vote.</p>
|
||||
<p>Legal enforcement MAY occur in a court of law, non-binding mediation or binding arbitration. The DevFund Charter MAY also provide rights to other Zcash community constituencies, such as specified miners or the “Third Entity” contemplated by <a id="id3" class="footnote_reference" href="#zip-1006">2</a>.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Because ZEC holders do not have specific legal rights against the ECC or ZF, but MAY wish to condition renewed on-chain development funding on the ECC’s or ZF’s agreement to use the development funds in certain ways, ZEC holders should have the legal right to enforce ECC’s/ZF’s compliance with those agreements.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>If a Development Funding Proposal receives sufficient community support and requires certain Covenants on the part of ECC or ZF, and there is also sufficient community support for using this enforcement mechanism as applied to that proposal, then one or more attorneys MUST be engaged to draft a Charter that reflects those Covenants, and the Charter MUST become legally effective and binding at the same time as the other aspects of the Development Funding Proposal are implemented on-chain (e.g., at the same time as activation of the corresponding Network Upgrade, if a Network Upgrade is is required to implement the Development Funding Proposal).</li>
|
||||
<li>Each pending Development Funding Proposal SHOULD be amended to specifically describe any Covenants that the ECC, ZF or any other relevant person or entity would be required to agree to as part of such Development Funding Proposal.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="open-issues"><h2><span class="section-heading">Open Issues</span><span class="section-anchor"> <a href="#open-issues"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="open-issues"><h2><span class="section-heading">Open Issues</span><span class="section-anchor"> <a rel="bookmark" href="#open-issues"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>Whether a plurality, majority or supermajority of ZEC are required to approve an enforcement action against ECC or ZF;</li>
|
||||
<li>Logistics and technical implementation regarding the Charter, such as on-chain signalling/voting for enforcement;</li>
|
||||
|
|
@ -59,7 +59,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-supplemental-pro
|
|||
<li>Discontinuation or reduction of development funding (which MAY occur by having Covenants that the ZF or ECC will prepare a Network Upgrade that discontinues or reduces development funding if so requested by holders of the requisite plurality, majority or supermajority of ZEC), etc.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="raised-concerns"><h2><span class="section-heading">Raised Concerns</span><span class="section-anchor"> <a href="#raised-concerns"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="raised-concerns"><h2><span class="section-heading">Raised Concerns</span><span class="section-anchor"> <a rel="bookmark" href="#raised-concerns"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>“Code is Law; This is Just Law!”
|
||||
<ul>
|
||||
|
|
@ -81,7 +81,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-supplemental-pro
|
|||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Category: Consensus
|
|||
Created: 2019-09-02
|
||||
License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/>
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/kek-s-proposal-fund-ecc-for-2-more-years/34778></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">2</a></p>
|
||||
<p>For clarity this ZIP defines these terms:</p>
|
||||
<ul>
|
||||
|
|
@ -30,42 +30,42 @@ Discussions-To: <https://forum.zcashcommunity.com/t/kek-s-proposal-fund-ecc-f
|
|||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this Proposal</span><span class="section-anchor"> <a href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this Proposal</span><span class="section-anchor"> <a rel="bookmark" href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Everything except moving the development fund end date.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The spirit of this proposal is to keep to the current structure of the Electric Coin Company (ECC) receiving funding from the block distribution for two years' worth of blocks after the first halving in October 2020.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>To give more time to work out the full ramifications of any potential pivot / slow down, yet keep "all in on ZEC" for two more years with as little disruption as possible.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Nothing about distribution recipients changes.</p>
|
||||
<p><span class="editor-note">The current distribution of the Founders’ Reward is dependent on arrangements between the participants that will, if not explicitly renewed, expire at the first halving. There are currently direct and indirect recipients other than the ECC and Zcash Foundation. It is unclear whether funding of the ECC and Foundation is intended to continue at the current absolute ZEC rate, or at the same rate relative to the block subsidy which halves in October 2020. Further specification would be needed in order to fulfil and clarify the spirit of the proposal.</span></p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>The ECC's portion of block subsidy MUST be 20%, until a block height corresponding to two years after the first halving, i.e. until October 2022.</li>
|
||||
<li>A to-be-specified fraction of ECC's portion SHOULD be used to fund the Zcash Foundation.</li>
|
||||
</ul>
|
||||
<p><span class="editor-note">A previous version of this ZIP stated the following requirements: "The ECC's portion of block subsidy MUST be capped at their projected 1.1m USD costs a month." and "The ECC's portion of block subsidy MUST NOT be greater than 10% of total block subsidy of any one block." These requirements were mistakenly introduced in the process of ZIP editing; they do not reflect the intent of the original author @kek. They are also inconsistent with the summary that was posted in the Community Sentiment Collection Poll blog post at <https://www.zfnd.org/blog/community-sentiment-collection-poll/>, which stated an ECC percentage of 20%. Votes on the Community Sentiment Collection Poll, the Community Advisory Panel Helios poll, and/or the stake-weighted petition reported at <https://forum.zcashcommunity.com/t/staked-poll-on-zcash-dev-fund-debate/34846/71>, should be interpreted with care in light of this ambiguity. Also note that the 1.1m USD cap could not in any case be specified as a consensus rule since there is no on-chain oracle for the USD price.</span></p>
|
||||
<section id="rationale"><h3><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="rationale"><h3><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Provisions that referred to specific block heights have been revised since they were inconsistent with the change in block target spacing <a id="id3" class="footnote_reference" href="#zip-0208">4</a> that will occur with the Blossom Network Upgrade <a id="id4" class="footnote_reference" href="#zip-0206">3</a>; and even if recalculated, fixed block heights would potentially be inconsistent with future changes in target block spacing.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="raised-objections-and-issues-so-far"><h2><span class="section-heading">Raised objections and issues so far</span><span class="section-anchor"> <a href="#raised-objections-and-issues-so-far"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="raised-objections-and-issues-so-far"><h2><span class="section-heading">Raised objections and issues so far</span><span class="section-anchor"> <a rel="bookmark" href="#raised-objections-and-issues-so-far"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>This is just kicking the can down the road.</li>
|
||||
<li>The Zcash Foundation has raised objections to a single point of failure in the ECC.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="implications-to-other-users"><h2><span class="section-heading">Implications to other users</span><span class="section-anchor"> <a href="#implications-to-other-users"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="implications-to-other-users"><h2><span class="section-heading">Implications to other users</span><span class="section-anchor"> <a rel="bookmark" href="#implications-to-other-users"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>The knock-on impact of this ZIP to exchanges and wallet developers may be nontrivial.</li>
|
||||
<li>The economics of doing this have not been calculated.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Category: Process
|
|||
Created: 2019-08-28
|
||||
License: MIT
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entity-strategic-council-approach/34801></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><em>Key terms</em></p>
|
||||
<dl>
|
||||
<dt>Developer Fund</dt>
|
||||
|
|
@ -25,16 +25,16 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entit
|
|||
<dd>An individual, group, company, or other organization that receives funding from the Strategic Council. They are responsible for excellent execution and held accountable by the Strategic Council.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal reserves 20% of newly minted coins in each block for a Developer Fund. A five-person Strategic Council would be elected by the community every two years. The Strategic Council would determine the high level strategy, goals, and metrics to evaluate progress for the ecosystem on a six-month cadence. The Strategic Council would be responsible for allocating funding to Executors for the subsequent six months and summarizing the performance of Executors in the prior six months. Executors would submit proposals to the Strategic Council on a six-month cadence, including project plans, funding plans, and how they will measure success on a scale from 1-10. At the end of six months, Executors will grade themselves and the Strategic Council will summarize what was accomplished with a target of 7/10 in every quarter on a roll-up basis (a simple average of all of the outstanding projects for that six months).</p>
|
||||
</section>
|
||||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this Proposal</span><span class="section-anchor"> <a href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this Proposal</span><span class="section-anchor"> <a rel="bookmark" href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>How to do 1 person = 1 vote (and perhaps we cannot or should not do this).</li>
|
||||
<li>How to structure the Strategic Council legally, i.e. should it be a Swiss Foundation and what sorts of legally binding responsibilities do the Strategic Council members have?</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="motivation-and-requirements"><h2><span class="section-heading">Motivation and Requirements</span><span class="section-anchor"> <a href="#motivation-and-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation-and-requirements"><h2><span class="section-heading">Motivation and Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#motivation-and-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This is an attempt to put on my startup CEO hat and address the strategic and execution challenges I believe have held back Zcash from realizing its full potential.</p>
|
||||
<p><strong>Principles & Observations Based on My Experiences (a.k.a. Biases?)</strong></p>
|
||||
<p>Because layer 1 protocols are network-effect driven, without a quickly growing network-effect in miners, developers, users, and liquidity, a layer 1 protocol will ultimately collapse.</p>
|
||||
|
|
@ -85,7 +85,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entit
|
|||
<li>Execution is best measured by pre-defining success and failure criteria, prior to having been influenced by the challenges of the task at hand.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><em>1. Who determines strategy?</em></p>
|
||||
<ul>
|
||||
<li>A five-person/entity board -- Five people is better than three to minimize collusion.</li>
|
||||
|
|
@ -122,7 +122,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entit
|
|||
<li>Over time the Strategic Council decides who gets funds so under-performers will be culled. Thus Executors are held accountable by the board and the board is held accountable by the community.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="issues-further-discussion"><h2><span class="section-heading">Issues & Further Discussion</span><span class="section-anchor"> <a href="#issues-further-discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="issues-further-discussion"><h2><span class="section-heading">Issues & Further Discussion</span><span class="section-anchor"> <a rel="bookmark" href="#issues-further-discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><em>Raised objections, issues, and open questions:</em></p>
|
||||
<ul>
|
||||
<li>How might we create a process to amending this process? We may want 4/5 of the Strategic Council to approve changes or 2/3 of ZEC holders to be able to amend the Strategic Council’s charter.</li>
|
||||
|
|
@ -130,7 +130,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entit
|
|||
<li>I’m sure there are many other points of ambiguity and improvements we could make. There may even be critical design flaws or failures in this system. Feedback is appreciated.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="references-background"><h2><span class="section-heading">References / Background</span><span class="section-anchor"> <a href="#references-background"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references-background"><h2><span class="section-heading">References / Background</span><span class="section-anchor"> <a rel="bookmark" href="#references-background"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li><a href="https://www.zfnd.org/blog/multisig-governance/">https://www.zfnd.org/blog/multisig-governance/</a></li>
|
||||
<li><a href="https://forum.zcashcommunity.com/t/placeholder-considerations-resources-governance-and-legitimacy-in-nu4/34045">https://forum.zcashcommunity.com/t/placeholder-considerations-resources-governance-and-legitimacy-in-nu4/34045</a></li>
|
||||
|
|
@ -141,7 +141,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entit
|
|||
</ul>
|
||||
<p><span class="editor-note">these should be made into inline references.</span></p>
|
||||
</section>
|
||||
<section id="change-log"><h2><span class="section-heading">Change Log</span><span class="section-anchor"> <a href="#change-log"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="change-log"><h2><span class="section-heading">Change Log</span><span class="section-anchor"> <a rel="bookmark" href="#change-log"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>2019-08-27 Initial draft - thanks to @jubos, @puntium, @zooko, @joshs, and Jack Gavigan for helping me more clearly articulating my ideas and helping get them formatted properly for a ZIP. These ideas are solely mine and were not influenced by any of these individuals.</li>
|
||||
<li>2019-08-28 Updated to be in ZIP format.</li>
|
||||
|
|
|
|||
|
|
@ -20,14 +20,14 @@ Category: Consensus
|
|||
Created: 2019-08-31
|
||||
License: MIT
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812/></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">2</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>I try to put the best pieces of various proposals together. A 20% of the block reward for a 4-year development fund that disburses to a trust controlled by both the Electric Coin Company (ECC) and Zcash Foundation (ZF), but with stringent controls on how funds may be allocated. It sidesteps code complexity in implementation by off-loading disbursements to a legal trust; funds the ECC/ZF; ECC stays a for-profit with restrictions; funds external parties through ZF Grants; all while carving out a limited-scoped opportunity for extending governance to more groups than the ECC/ZF.</p>
|
||||
</section>
|
||||
<section id="motivation-and-requirements"><h2><span class="section-heading">Motivation and Requirements</span><span class="section-anchor"> <a href="#motivation-and-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation-and-requirements"><h2><span class="section-heading">Motivation and Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#motivation-and-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash won't thrive without a dev fund. I wish this wasn't true (I really do), and for the longest time I was against the idea. But I've come to fear the alternative without one; I fear the privacy technology pioneered by Zcash may never reach its true potential — not just for our community, but for others interested in novel approaches to private money.</p>
|
||||
<p>The Foundation, ECC, and broader community has offered many suggestions and guidelines for a potential dev fund, below is my attempt at synthesizing them into a compromise that's greater than the sum of its parts:</p>
|
||||
<ul>
|
||||
|
|
@ -40,7 +40,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/a-grand-compromise-synthe
|
|||
<p><span class="editor-note">for security reasons, it may be useful to refine the "single address" to a list of rolling addresses as described in section 7.8 of the current protocol specification. Other references to a "single address" in this document have not been changed.</span></p>
|
||||
<p><em>Please note: a previous version of this proposal included a portion of the funds being tied to shielded adoption, based on ideas brought forward by Eran Tromer in</em> <a id="id4" class="footnote_reference" href="#tromer-comment">4</a>. <em>After many discussions I came to worry about the gameability of the metric and decided to drop it entirely.</em></p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Upon the NU4 network activation, 20% of the mining reward (post-Blossom / post-halvening = 0.625 ZEC per block) MUST go to a single shielded address with a viewing key widely distributed and known to the community and controlled by a trust established by the ECC and Zcash Foundation. If the trust and associated address aren't established by the NU4 activation deadline, then there MUST NOT be any change to the mining reward. Every quarter-year (105,000 blocks at the post-Blossom rate), until 4 years after NU4 activation (1,680,000 blocks at the post-Blossom rate), the trust SHOULD disburse funds the following way, requiring a public report with every disbursement:</p>
|
||||
<ul>
|
||||
<li>30% of the fund to the ECC, if they meet the accountability requirements set by the trust/described below;</li>
|
||||
|
|
@ -48,7 +48,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/a-grand-compromise-synthe
|
|||
<li>40% of the fund to the Zcash Foundation as a RESTRICTED donation <a id="id5" class="footnote_reference" href="#restricted-funds">5</a> purely for disbursement through ZF Grants <a id="id6" class="footnote_reference" href="#zfnd-grants">6</a>, with additional restrictions and stipulations described below.</li>
|
||||
</ul>
|
||||
<p><span class="editor-note">When this proposal was written it was expected that NU4 activation would correspond exactly to the first (October 2020) halvening. Since that may not be the case, I have resolved a potential ambiguity in the original wording by specifying that the trust disburses funds for 4 years, rather than that it disburses funds until the second (October 2024) halvening.</span></p>
|
||||
<section id="example-disbursements-by-the-trust-for-a-hypothetical-105000-block-period"><h3><span class="section-heading">Example disbursements by the trust for a hypothetical 105000-block period</span><span class="section-anchor"> <a href="#example-disbursements-by-the-trust-for-a-hypothetical-105000-block-period"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="example-disbursements-by-the-trust-for-a-hypothetical-105000-block-period"><h3><span class="section-heading">Example disbursements by the trust for a hypothetical 105000-block period</span><span class="section-anchor"> <a rel="bookmark" href="#example-disbursements-by-the-trust-for-a-hypothetical-105000-block-period"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>0.625 ZEC * 105000 = 65625 ZEC accrued in the trust every quarter. If both the ECC and Zcash Foundation met the accountability requirements set by the trust, then disbursements would look like this:</p>
|
||||
<ul>
|
||||
<li>19687.5 ZEC to the ECC for meeting accountability requirements.</li>
|
||||
|
|
@ -57,7 +57,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/a-grand-compromise-synthe
|
|||
</ul>
|
||||
<p>This example assumes no change to target block spacing.</p>
|
||||
</section>
|
||||
<section id="the-trust-s-accountability-requirements"><h3><span class="section-heading">The trust's accountability requirements</span><span class="section-anchor"> <a href="#the-trust-s-accountability-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="the-trust-s-accountability-requirements"><h3><span class="section-heading">The trust's accountability requirements</span><span class="section-anchor"> <a rel="bookmark" href="#the-trust-s-accountability-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Here I'm borrowing from the Foundation's guidance <a id="id7" class="footnote_reference" href="#zfnd-guidance">3</a> but adding some stipulations to cement the Foundation's independence, prevent the Foundation from hoarding its endowment, and handle the ECC as a for-profit. Before disbursing funds each quarter, the trust MUST validate that both the ECC and Zcash Foundation:</p>
|
||||
<ul>
|
||||
<li>Published quarterly technical roadmap reports and financial reports, detailing spending levels/burn rate and cash/ZEC on hand;</li>
|
||||
|
|
@ -78,10 +78,10 @@ Discussions-To: <https://forum.zcashcommunity.com/t/a-grand-compromise-synthe
|
|||
</ul>
|
||||
<p>The ECC MUST share necessary information with the trust to ascertain no violations of the above, but the information itself (i.e. cap table and detailed financials) SHOULD remain private between the ECC and the trustees unless there is a violation that is not cured.</p>
|
||||
</section>
|
||||
<section id="what-happens-in-the-case-of-a-violation"><h3><span class="section-heading">What happens in the case of a violation</span><span class="section-anchor"> <a href="#what-happens-in-the-case-of-a-violation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="what-happens-in-the-case-of-a-violation"><h3><span class="section-heading">What happens in the case of a violation</span><span class="section-anchor"> <a rel="bookmark" href="#what-happens-in-the-case-of-a-violation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The violating party has 30 days to attempt to cure the violation (if it's possible). If they cannot, future funds MUST be redirected to ZF Grants via a restricted donation to the Zcash Foundation. (That is, not usable by either the Zcash Foundation or ECC, more on that below.)</p>
|
||||
</section>
|
||||
<section id="the-zf-grants-portion"><h3><span class="section-heading">The ZF Grants portion</span><span class="section-anchor"> <a href="#the-zf-grants-portion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="the-zf-grants-portion"><h3><span class="section-heading">The ZF Grants portion</span><span class="section-anchor"> <a rel="bookmark" href="#the-zf-grants-portion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A portion of the dev fund goes to the Foundation but with the express (and restricted) purpose of being distributed via ZF Grants (a restriction that MUST be legally enforced by the trust). The Foundation would continue to administer ZF Grants and distribute funds, but it SHOULD NOT decide where those funds go and would not allowed to be recipients of these funds; instead, the trust MUST demand that the ZF Grants process include broader input in the manner described below. In the discussions around the various "third party" proposals, some have suggested a 3-of-5 approach where the ECC and Zcash Foundation are in the minority; I think that structure would work well for these funds. It's not the full dev fund so we are limiting the downside risk of selecting the "wrong" third parties, which also means we can give those third parties more voice (by making them outnumber the ECC/Zcash Foundation). The Foundation MAY also chose to fund ZF Grants <em>beyond</em> the restricted donations from the trust, but doing so would be at their discretion.</p>
|
||||
<p>Thanks to the discussion on Matt Luongo's proposal there's a good blueprint for how this group would work. I'm borrowing some comments I made on Matt's proposal thread <a id="id9" class="footnote_reference" href="#acityinohio-comment">8</a> and modifying them to apply to a ZF Grants-specific Grant Review Committee, rather than the Foundation's board.</p>
|
||||
<p>The ZF Grant Review Committee would be compromised of five members, voted on in the following manner:</p>
|
||||
|
|
@ -94,9 +94,9 @@ Discussions-To: <https://forum.zcashcommunity.com/t/a-grand-compromise-synthe
|
|||
<p>The group would meet biweekly to make funding decisions, the results of which will be made public on ZF Grants. Taking a note from Eran Tromer's recent proposal, the group would have a goal of making at least two "Large Grants" every year. A "Large Grant" would have an expected scope of six months and 1/4th to 1/3rd of the total ZF Grants yearly budget, with the goal of getting more dedicated external teams involved.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>There are scores of great ideas on the forums, and I took the (subjective, mind you) best parts of each into a proposal that hopefully meets the standards of the ECC, the Zcash Foundation, and the broader community.</p>
|
||||
<section id="a-word-on-the-enigmatic-third-party-floating-around"><h3><span class="section-heading">A word on the enigmatic "third party" floating around</span><span class="section-anchor"> <a href="#a-word-on-the-enigmatic-third-party-floating-around"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="a-word-on-the-enigmatic-third-party-floating-around"><h3><span class="section-heading">A word on the enigmatic "third party" floating around</span><span class="section-anchor"> <a rel="bookmark" href="#a-word-on-the-enigmatic-third-party-floating-around"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>With all due respect to the proposers behind some variant of a "2-of-3 multisig" decision-making process for <em>all</em> disbursement decisions: I think this is a bad idea. To quote a previous forum post of mine:</p>
|
||||
<blockquote>
|
||||
<p>...2-of-3 multisig [is] better if we find the right third party. That in and of itself requires an additional process/mutual agreement between the three parties (which is much more difficult than a bilateral agreement), and as I’ve mentioned before in presentations in the past, 2-of-2 with known entities dedicated to Zcash is better than jumping straight to 2-of-3 with a third party hastily decided or staying with 1-of-1 entity trademarks and software development processes.</p>
|
||||
|
|
@ -105,24 +105,24 @@ Discussions-To: <https://forum.zcashcommunity.com/t/a-grand-compromise-synthe
|
|||
<p>More to the point, I worry that the "third party" in question is being idolized into some Platonic ideal, and in reality either the ECC or the Zcash Foundation would spend a great deal of their time currying favor in either the process or selection of the party in question in the limited time between now and that party's selection. Given that the Zcash Foundation is charged with representing community interests, I'm not sure why another community-focused representative would really make sense from the ECC's perspective — they'd be constantly outvoted if interests clashed, so from a balance of power perspective I'm not sure why the ECC would find that tenable. And I'm not sure the community would want the "third party" to be another profit-generating enterprise, like a VC or another startup, which would tip power another way.</p>
|
||||
<p>The crux of this proposal still centers around the idea that the Zcash Foundation and ECC share responsibility for protocol development, which is now bolstered by the 2-of-2 agreement on the trademark. It assumes and expects that both continue developing consensus-compatible node software that interacts with the Zcash network. But it mandates accountability for disbursement of funds to the ECC/Zcash Foundation, and expands outside stakeholder input on funds that <em>wouldn't</em> be earmarked for the ECC/Zcash Foundation (similar to Placeholder's earlier version of their proposal and Matt Luongo's current proposal), while it doesn’t preclude the possibility of migrating to broader "2-of-3" later on future governance decisions.</p>
|
||||
</section>
|
||||
<section id="why-a-trust"><h3><span class="section-heading">Why a trust?</span><span class="section-anchor"> <a href="#why-a-trust"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="why-a-trust"><h3><span class="section-heading">Why a trust?</span><span class="section-anchor"> <a rel="bookmark" href="#why-a-trust"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The main reason: reducing complexity creep in consensus code. Rather than try to incorporate some complex mechanism for dev fund disbursements on-chain, we can meet the NU4 with the simplest possible code-change and spend more time ironing out the details of the trust "off-chain." Since both the ECC and the Zcash Foundation are based in the US, using a trust with well-specified criteria for disbursements is a reasonable path. This also fits in nicely with lex-node's proposal <a id="id10" class="footnote_reference" href="#zip-1007">9</a> for legal covenants on funding.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The biggest issue is custody of the funds under the trust's control, but I suspect this can be managed with a partnership with a custody partner. There's also the issue that non-public information would need to be verified and validated by the trust, but I view this as a net positive for the community ("transparency for organizations, privacy for individuals").</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>TBD, but it should be relatively simple to code in both zebra and zcashd.</p>
|
||||
</section>
|
||||
<section id="issues-and-further-discussion"><h2><span class="section-heading">Issues and further discussion</span><span class="section-anchor"> <a href="#issues-and-further-discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="issues-and-further-discussion"><h2><span class="section-heading">Issues and further discussion</span><span class="section-anchor"> <a rel="bookmark" href="#issues-and-further-discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>What are the tax implications for setting up the trust?</li>
|
||||
<li>Are the amounts reasonable? Should the dev fund be less than 20% in aggregate?</li>
|
||||
<li>Should this or other proposals seek to change the ECC and Zcash Foundation's board/makeup, or should we keep those organizations running as they are and sandbox a new process to a specific disbursement of the dev fund? (This proposal assumes the latter via ZF Grants.)</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -15,29 +15,29 @@ Category: Process
|
|||
Created: 2019-09-27
|
||||
License: MIT
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252></pre>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal describes a structure for Zcash governance, including funding and managing new Zcash development, decentralizing those development efforts, and resolving governance hangups between the Zcash Foundation and the Electric Coin Company.</p>
|
||||
<p>These goals are accomplished via a 20% dev fee, enacted in NU4 and continuing for one halving period. This fee will fund a diverse group of development teams to ensure Zcash maintains best-in-class research and engineering talent while growing a robust ecosystem, funding the Zcash Foundation with 25% of the dev fee, and a newly established principal developer role with 35% of the dev fee.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="who-am-i"><h3><span class="section-heading">Who am I?</span><span class="section-anchor"> <a href="#who-am-i"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="who-am-i"><h3><span class="section-heading">Who am I?</span><span class="section-anchor"> <a rel="bookmark" href="#who-am-i"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>My name is Matt Luongo. I'm an entrepreneur who's been full-time in the crypto space since 2014, co-founding Fold, a Bitcoin payments company, and more recently Keep, a private computation startup built on Ethereum. At Keep, we've done some <a href="https://github.com/ethereum/EIPs/pull/2129">work around Zcash</a>, and our parent company, <a href="https://thesis.co">Thesis</a>, is considering investing more heavily in Zcash development for our latest project.</p>
|
||||
<p>I'm deeply interested in privacy tech. For me, privacy is about consent –consent to share my habits, beliefs, and preferences– and I see privacy as the inevitable next frontier in our pursuit of an economy that respects individual choice.</p>
|
||||
<p>My perspective is as the founder of a for-profit company focused on building self-sovereign technology who wants to develop on Zcash. We work in this space ideologically, but our work isn't free; attracting and growing talent requires funding.</p>
|
||||
<p>If you're interested in more on my background, I've introduced myself more <a href="https://forum.zcashcommunity.com/t/introducing-matt-luongo-from-keep/34947">properly on the forum</a>.</p>
|
||||
</section>
|
||||
<section id="what-s-this-about"><h3><span class="section-heading">What's this about?</span><span class="section-anchor"> <a href="#what-s-this-about"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="what-s-this-about"><h3><span class="section-heading">What's this about?</span><span class="section-anchor"> <a rel="bookmark" href="#what-s-this-about"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Since Zcon1, I've been looking to fund work to build an Ethereum / Zcash bridge. I've spoken to the ECC, the Zcash Foundation, and a number of early Zcash community members on how best to move forward with this project, and in the process I've learned a lot about how the community works and dev governance has been structured thus far.</p>
|
||||
<p>Inevitably, I've become interested in the community's proposals for a new dev fee, and thought about how the right structure might support work like ours.</p>
|
||||
<p>I believe the Zcash community has an opportunity to deploy a new incentive structure that will attract companies like ours to build and improve Zcash, leading to a more resilient network, stronger technology, and wider usage.</p>
|
||||
</section>
|
||||
<section id="the-zcash-narrative"><h3><span class="section-heading">The Zcash narrative</span><span class="section-anchor"> <a href="#the-zcash-narrative"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="the-zcash-narrative"><h3><span class="section-heading">The Zcash narrative</span><span class="section-anchor"> <a rel="bookmark" href="#the-zcash-narrative"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>We're all here to build a robust, private, decentralized currency. But in the dev fee proposals I've seen so far, the idea of a Zcash narrative that distinguishes it from the competition is absent.</p>
|
||||
<p>Of the slew of ZIPs addressing Zcash's future, there's only been one strong narrative case — the idea that Zcash exists purely as a hedge against Bitcoin's long-term privacy failure. Put simply, Zcash is "Bitcoin, but private".</p>
|
||||
<p>Zcash should aim higher. Bitcoin is the only coin that has successfully made a store of value argument, which I like to call "worse is better". Don't upgrade the network –the argument goes– stability is more important than solving today's problems. Bitcoin is chasing the <a href="https://en.wikipedia.org/wiki/Lindy_effect">Lindy effect</a>, where worse is better, and the network becomes stronger every day it survives. That's great for Bitcoin. For the rest of us, though, better is better. Zcash <em>should be better</em>.</p>
|
||||
<p>Zcash is known for having the best tech in the space, built by one of the best teams in the space. We should lean in to that reputation, nurturing the best research and engineering talent to take Zcash to the next level, and leveraging a Zcash dev fee as a differentiator to build the world's best private medium of exchange.</p>
|
||||
</section>
|
||||
<section id="principles-of-cryptocurrency-governance"><h3><span class="section-heading">Principles of cryptocurrency governance</span><span class="section-anchor"> <a href="#principles-of-cryptocurrency-governance"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="principles-of-cryptocurrency-governance"><h3><span class="section-heading">Principles of cryptocurrency governance</span><span class="section-anchor"> <a rel="bookmark" href="#principles-of-cryptocurrency-governance"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>To understand Zcash governance, it's worth reviewing "default" cryptocurrency governance. Most proof-of-work chains today have three major governing roles:</p>
|
||||
<ol type="1">
|
||||
<li>Miners validate and secure the chain. They do some work to earn a reward. Miners are the first owners of newly minted coins, and are an integral part of network upgrades.</li>
|
||||
|
|
@ -52,7 +52,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fe
|
|||
</ol>
|
||||
<p>These roles together form a balance of power that makes contentious forks difficult — any change that a large swath of users disapproves of could split the chain.</p>
|
||||
</section>
|
||||
<section id="the-state-of-play"><h3><span class="section-heading">The state of play</span><span class="section-anchor"> <a href="#the-state-of-play"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="the-state-of-play"><h3><span class="section-heading">The state of play</span><span class="section-anchor"> <a rel="bookmark" href="#the-state-of-play"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>In Zcash, the addition of the Electric Coin Company (ECC) and the Zcash Foundation skew this balance.</p>
|
||||
<p>Both organizations are comprised of Zcash founders, developers, researchers, and privacy proponents who have driven this ecosystem forward and represent its values. Nevertheless, their mode of operation today skews a healthy balance of power in Zcash governance.</p>
|
||||
<p>The mechanisms of that skew are the Zcash trademark, held jointly by the Foundation and the ECC, and primary client software development, now split between the ECC and the Foundation.</p>
|
||||
|
|
@ -65,7 +65,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fe
|
|||
<li>The ECC and Foundation are both put at legal risk. As entangled entities, they're remarkably similar to a single entity when trying to minimize regulatory risk.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="the-crowding-out-problem"><h3><span class="section-heading">The "crowding out" problem</span><span class="section-anchor"> <a href="#the-crowding-out-problem"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="the-crowding-out-problem"><h3><span class="section-heading">The "crowding out" problem</span><span class="section-anchor"> <a rel="bookmark" href="#the-crowding-out-problem"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The Zcash ecosystem, as it exists today, leaves little incentive for outside developers to participate.</p>
|
||||
<p>Zcash development has a high learning curve.</p>
|
||||
<ul>
|
||||
|
|
@ -78,7 +78,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fe
|
|||
<p>Sustainably attracting talent to Zcash is critical to maintain innovation and build resilience.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The first requirement is a balanced governance structure. Developers should be rewarded, without rewarding governance capture. What's best for the chain and ZEC holders should always come before commercial interests.</p>
|
||||
<p>The second, and secondary, requirement is funding Zcash development. While the chain shouldn't be run by a commercial entity, it will need to be supported by them.</p>
|
||||
<p>The third requirement is the support of a more resilient ecosystem by:</p>
|
||||
|
|
@ -89,11 +89,11 @@ Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fe
|
|||
</ol>
|
||||
<p>Finally, avoid introducing unnecessary additional entities into the governance process.</p>
|
||||
</section>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>General on-chain governance is outside the scope of this proposal. On-chain governance is an exciting idea -- what if we had an impartial arbiter funding development? My experience with on-chain governance to date, however, leads me to believe it's still a risky direction. Zcash should focus on what it's good at –privacy– and leave proving on-chain governance models to other projects.</p>
|
||||
<p>While this proposal attempts to outline a long-term structure for Zcash funding and governance, specifying the structure beyond the next 4 years is out of scope. Much will have changed in 4 years. Perhaps this structure will be sufficient; perhaps we'll be battling the Third Crypto War, and need to go back to the drawing table.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The below proposal is an effort to cleanly resolve the problems with Zcash's current governance, while</p>
|
||||
<ul>
|
||||
<li>maintaining a balance of power between stakeholders;</li>
|
||||
|
|
@ -101,7 +101,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fe
|
|||
<li>growing development and usage of Zcash;</li>
|
||||
<li>and supporting the best interests of miners, users, and developers <em>today</em>.</li>
|
||||
</ul>
|
||||
<section id="decentralizing-development"><h3><span class="section-heading">Decentralizing development</span><span class="section-anchor"> <a href="#decentralizing-development"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="decentralizing-development"><h3><span class="section-heading">Decentralizing development</span><span class="section-anchor"> <a rel="bookmark" href="#decentralizing-development"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A few proposals have suggested the introduction of a mysterious "third entity" to resolve disagreements between the Foundation and the ECC.</p>
|
||||
<p>I prefer a different approach, refocusing the role of the Foundation and making room for the ECC to work with a robust developer ecosystem.</p>
|
||||
<p>In this proposal, the Foundation shall support community development through running the forum and events, gathering community sentiment, managing short-term development grants, research and development, and conducting the diligence behind the assignment and disbursement of a development fee. This development fee shall be funded by 20% of the block reward, with as much as half of the fee burned in case of extraordinary growth in the price of ZEC.</p>
|
||||
|
|
@ -116,7 +116,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fe
|
|||
</ul>
|
||||
<p>Prior to each network upgrade, the Foundation shall recommend a list of addresses and a total number of ZEC per block each address is meant to receive from the dev fee. The recommendation will be "ratified" by the miners as the network upgrade activates.</p>
|
||||
</section>
|
||||
<section id="the-role-of-dev-fee-recipients"><h3><span class="section-heading">The role of dev fee recipients</span><span class="section-anchor"> <a href="#the-role-of-dev-fee-recipients"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="the-role-of-dev-fee-recipients"><h3><span class="section-heading">The role of dev fee recipients</span><span class="section-anchor"> <a rel="bookmark" href="#the-role-of-dev-fee-recipients"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Dev fee recipients are distinguished from grant recipients in the scope and timelines of their work, as well as the specificity of direction. The intent is to allow teams to focus on a core competency, while encouraging research and adjacent work.</p>
|
||||
<p>Dev fee recipients are chosen semi-annually by the Foundation based on their ability to move Zcash forward. Recipients will typically be development teams, though "full stack" teams that can communicate well with the community, expand Zcash usage, and widely share their work should be advantaged.</p>
|
||||
<p>Recipients shall submit quarterly plans to the community for their efforts, as well as monthly progress updates.</p>
|
||||
|
|
@ -124,7 +124,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fe
|
|||
<p>Though the Foundation shall periodically judge the efficacy of dev fee recipients, deciding on and driving roadmaps for Zcash is the role of dev fee recipients, in partnership with the community. This role is neatly balanced by users running full nodes and miners, either of which can veto a network upgrade.</p>
|
||||
<p>While dev fee recipients are not required to work exclusively on Zcash, considering the nature of their work, recipients must guarantee they aren't obliged to the interests of competing projects.</p>
|
||||
</section>
|
||||
<section id="the-role-of-the-principal-developer"><h3><span class="section-heading">The role of the principal developer</span><span class="section-anchor"> <a href="#the-role-of-the-principal-developer"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="the-role-of-the-principal-developer"><h3><span class="section-heading">The role of the principal developer</span><span class="section-anchor"> <a rel="bookmark" href="#the-role-of-the-principal-developer"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The role of the principal developer is as a "first among equals" amongst the dev fee recipients.</p>
|
||||
<p>The principal developer shall make a number of guarantees.</p>
|
||||
<ol type="1">
|
||||
|
|
@ -135,7 +135,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fe
|
|||
<p>In exchange, the principal developer is granted an indefinite minimum dev fee allocation of 20%, with a maximum allocation of 35% of the total fee, as recommended annually by the Foundation.</p>
|
||||
<p>The principal developer will have a wide remit to pursue longer-term research relevant to Zcash, though it will submit the same plans required of other recipients. The principal developer will only be recommended for removal by the Foundation in extraordinary circumstances, including reneging on the above guarantees or extreme negligence.</p>
|
||||
</section>
|
||||
<section id="minimum-viable-foundation"><h3><span class="section-heading">Minimum viable Foundation</span><span class="section-anchor"> <a href="#minimum-viable-foundation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="minimum-viable-foundation"><h3><span class="section-heading">Minimum viable Foundation</span><span class="section-anchor"> <a rel="bookmark" href="#minimum-viable-foundation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>To manage the dev fee and fulfill its community and diligence duties, the Foundation shall maintain a board of 5 independent members. Rather than the structure in the current bylaws, the board will consist of</p>
|
||||
<ul>
|
||||
<li>1 seat voted on periodically by ZEC holders directly.</li>
|
||||
|
|
@ -149,25 +149,25 @@ Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fe
|
|||
<p>No board members shall have an ongoing commercial interest in any recipients of the dev fee.</p>
|
||||
<p>Considering their expertise, the Foundation shall deliver a transition plan, including a board election schedule and report on the feasibility of a future coin vote process to determine a board seat.</p>
|
||||
</section>
|
||||
<section id="the-ecc-as-the-principal-developer"><h3><span class="section-heading">The ECC as the principal developer</span><span class="section-anchor"> <a href="#the-ecc-as-the-principal-developer"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="the-ecc-as-the-principal-developer"><h3><span class="section-heading">The ECC as the principal developer</span><span class="section-anchor"> <a rel="bookmark" href="#the-ecc-as-the-principal-developer"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>I propose that the ECC be considered as the initial principal developer, receiving an indefinite dev fee allocation in exchange for their exclusive focus on Zcash research and development, and assigning all patents and marks relevant to Zcash to the Foundation.</p>
|
||||
<p>I believe this arrangement is best for the Zcash ecosystem, and with proper management of funds, should satisfy the ongoing needs of the ECC.</p>
|
||||
</section>
|
||||
<section id="the-dev-call"><h3><span class="section-heading">The dev call</span><span class="section-anchor"> <a href="#the-dev-call"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="the-dev-call"><h3><span class="section-heading">The dev call</span><span class="section-anchor"> <a rel="bookmark" href="#the-dev-call"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The Foundation shall organize a bi-weekly call for all dev fee recipients and other third party developers. The call will be live-streamed for community participation, though the speaking participants will be invite only. At a minimum, a single representative from each dev fee recipient should attend.</p>
|
||||
<p>The Foundation shall also maintain a simple chat solution for development of the protocol. While the chat logs should be publicly viewable, it need not be open to public participation.</p>
|
||||
</section>
|
||||
<section id="moving-forward"><h3><span class="section-heading">Moving forward</span><span class="section-anchor"> <a href="#moving-forward"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="moving-forward"><h3><span class="section-heading">Moving forward</span><span class="section-anchor"> <a rel="bookmark" href="#moving-forward"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>I believe this proposal can form the basis for a new way forward for Zcash — a robust, decentralized ecosystem with fair governance. I also hope it can bring together the stakeholders in this discussion, and allow us to get back to why we're all here — to protect the world's financial privacy.</p>
|
||||
<p>I look forward to feedback on GitHub and the Zcash forum.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="disclosures"><h2><span class="section-heading">Disclosures</span><span class="section-anchor"> <a href="#disclosures"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="disclosures"><h2><span class="section-heading">Disclosures</span><span class="section-anchor"> <a rel="bookmark" href="#disclosures"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>In the interest of transparency, I'd like to make a few professional disclosures.</p>
|
||||
<p>I'm the largest shareholder of <a href="https://thesis.co">Thesis</a>, the parent company and studio behind <a href="https://foldapp.com">Fold</a> and <a href="https://keep.network">Keep</a>. Thesis is a for-profit company that might benefit from this proposal as a dev fee recipient. While today I maintain exclusive control of Thesis, the company has taken outside investment in the past.</p>
|
||||
<p>As far as my financial interest in Zcash, I've held a small amount of ZEC since shortly after launch. I'm in the process of building my personal ZEC position, as well as a position at Thesis.</p>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Thanks to my friends and colleagues <a href="https://twitter.com/CReckhow">Carolyn</a>, <a href="https://twitter.com/LauraWallendal">Laura</a>, <a href="https://twitter.com/JoshSRosenblatt">Josh</a>, <a href="https://twitter.com/_prestwich">James</a>, <a href="https://twitter.com/CorbinPon">Corbin</a>, and <a href="https://github.com/shadowfiend">Antonio</a> for early review of the text this proposal.</p>
|
||||
<p>Thanks to my fellow dev fund ZIP authors, <a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entity-strategic-council-approach/34801">Avichal Garg</a> at Electric Capital, <a href="https://forum.zcashcommunity.com/t/zcash-dev-fund-results-based-financing-equity-proposal-amendment/35052/31">Antoinette Marie</a>, <a href="https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812">Josh Cincinnati, ED</a> at the Zcash Foundation, <a href="https://forum.zcashcommunity.com/t/asp-founders-reward-positioning-support-for-avichal-garg-s-proposal-with-amendments/35184">Jacob Phillips</a> at Autonomous Partners, <a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-directed-dev-fund-was-20-to-any-combination-of-ecc-zfnd-parity-or-burn/33864">Andrew Miller</a>, <a href="https://twitter.com/cburniske">Chris Burniske</a>, <a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fund-to-ecc-zfnd-major-grants/35364/15">Eran Tromer</a>, and the fellows at <a href="https://forum.zcashcommunity.com/t/blocktown-development-fund-proposal-10-to-a-2-of-3-multisig-with-community-involved-third-entity/34782">Blocktown</a>, each of whose ideas influenced this proposal. And of course, thanks to <a href="https://github.com/sonyamann">Sonya Mann</a> and the Foundation for coordinating discussions around these different proposals.</p>
|
||||
<p>Outside ongoing discussions in the forum and with other ZIP authors, I've spoken with a number of prominent community members while developing this proposal, though none were provided early access to the text of the proposal. I appreciated the thoughtful discussions with <a href="https://twitter.com/acityinohio">Josh Cincinnati</a>, <a href="https://twitter.com/zooko">Zooko Wilcox</a>, <a href="https://twitter.com/jswihart">Josh Swihart</a>, <a href="https://twitter.com/secparam">Ian Miers</a>, and others.</p>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Category: Consensus / Process
|
|||
Created: 2019-11-10
|
||||
License: MIT
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fund-to-ecc-zfnd-major-grants/35364></pre>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal describes a structure for a the Zcash Development Fund, to be enacted in Network Upgrade 4 and last for 4 years. This Dev Fund would consist of 20% of the block rewards, split into 3 slices:</p>
|
||||
<ul>
|
||||
<li>35% for the Electric Coin Company;</li>
|
||||
|
|
@ -23,11 +23,11 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fun
|
|||
</ul>
|
||||
<p>Funding is capped at $700k/month per slice. Governance and accountability are based on existing entities and legal mechanisms, and increasingly decentralized governance is encouraged.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Starting at Zcash's first halving in October 2020, by default 100% of the block rewards will be allocated to miners, and no further funds will be automatically allocated to research, development and outreach. Consequently, no substantial new funding may be available to existing teams dedicated to Zcash: the Electric Coin Company (ECC), the Zcash Foundation (ZF), and the many entities funded by the ZF grant program.</p>
|
||||
<p>There is a need to strike a balance between incentivizing the security of the consensus protocol (i.e., mining) versus other crucial aspects of the Zcash security and functionality, such as development and outreach.</p>
|
||||
<p>Furthermore, there is a need to balance the sustenance of ongoing work by the current teams dedicated to Zcash, with encouraging decentralization and growth of independent development teams.</p>
|
||||
<section id="difference-from-matt-luongo-s-proposal"><h3><span class="section-heading">Difference from Matt Luongo's proposal</span><span class="section-anchor"> <a href="#difference-from-matt-luongo-s-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="difference-from-matt-luongo-s-proposal"><h3><span class="section-heading">Difference from Matt Luongo's proposal</span><span class="section-anchor"> <a rel="bookmark" href="#difference-from-matt-luongo-s-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This proposal is based on Matt Luongo's <a href="https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252">Decentralizing the Dev Fee</a> proposal, which has similar motivations. The major changes are as follows:</p>
|
||||
<ul>
|
||||
<li>The Dev Fund slice intended for external recipients (beyond ECC, ZF and existing ZF grants) may be used to fund ECC if no competitive alternatives present themselves, to mitigate unwarranted loss of existing capabilities.</li>
|
||||
|
|
@ -41,7 +41,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fun
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Dev Fund should encourage decentralization of the work and funding, by supporting new teams dedicated to Zcash.</p>
|
||||
<p>The Dev Fund should maintain the existing teams and capabilities in the Zcash ecosystem, unless and until concrete opportunities arise to create even greater value for the Zcash ecosystem.</p>
|
||||
<p>There should not be any single entity which is a single point of failure, i.e., whose capture or failure will effectively prevent effective use of the funds.</p>
|
||||
|
|
@ -52,12 +52,12 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fun
|
|||
<p>The new Dev Fund system should be simple to understand and realistic to implement. In particular, it should not assume the creation of new mechanisms (e.g., election systems) or entities (for governance or development) for its execution; but it should strive to support and use these once they are built.</p>
|
||||
<p>Comply with legal, regulatory and taxation constraints in pertinent jurisdictions.</p>
|
||||
</section>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>General on-chain governance is outside the scope of this proposal.</p>
|
||||
<p>Rigorous voting mechanism (whether coin-weighted, holding-time-weighted or one-person-one-vote) are outside the scope of this proposal, though there is prescribed room for integrating them once available.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="dev-fund-allocation"><h3><span class="section-heading">Dev Fund allocation</span><span class="section-anchor"> <a href="#dev-fund-allocation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="dev-fund-allocation"><h3><span class="section-heading">Dev Fund allocation</span><span class="section-anchor"> <a rel="bookmark" href="#dev-fund-allocation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Starting at the first Zcash halving in 2020, until the second halving in 2024, 20% of the block rewards will be allocated to a "Dev Fund" that consists of the following three slices:</p>
|
||||
<ul>
|
||||
<li>35% for the Electric Coin Company (denoted <strong>ECC slice</strong>);</li>
|
||||
|
|
@ -65,7 +65,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fun
|
|||
<li>40% for additional "Major Grants" for large-scale long-term projects (denoted <strong>ZF-MG slice</strong>).</li>
|
||||
</ul>
|
||||
<p>Details below. The fund flow will be implemented at the consensus-rule layer, by sending the corresponding ZEC to the designated address in each block. This Dev Fund will end at the second halving (unless extended/modified by a future ZIP).</p>
|
||||
<section id="ecc-slice-electric-coin-company"><h4><span class="section-heading">ECC slice (Electric Coin Company)</span><span class="section-anchor"> <a href="#ecc-slice-electric-coin-company"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="ecc-slice-electric-coin-company"><h4><span class="section-heading">ECC slice (Electric Coin Company)</span><span class="section-anchor"> <a rel="bookmark" href="#ecc-slice-electric-coin-company"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>This slice of the Dev Fund will flow to ECC.</p>
|
||||
<p>ECC must undertake a firm obligation to use the Dev Fund only in support of the Zcash cryptocurrency and its community.</p>
|
||||
<p>In particular, ECC must commit to not distribute the Dev Fund proceeds to its partners ("shareholders"), other than:</p>
|
||||
|
|
@ -76,11 +76,11 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fun
|
|||
<p>(ECC is encouraged to transition to a corporate structure that would avoid the latter taxes.)</p>
|
||||
<p>This obligation must be made irrevocable, e.g., within ECC's corporate governance structure (i.e., its Operating Agreement) or contractual obligations.</p>
|
||||
</section>
|
||||
<section id="zf-gu-slice-zcash-foundation-for-general-use"><h4><span class="section-heading">ZF-GU slice (Zcash Foundation, for general use)</span><span class="section-anchor"> <a href="#zf-gu-slice-zcash-foundation-for-general-use"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="zf-gu-slice-zcash-foundation-for-general-use"><h4><span class="section-heading">ZF-GU slice (Zcash Foundation, for general use)</span><span class="section-anchor"> <a rel="bookmark" href="#zf-gu-slice-zcash-foundation-for-general-use"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>This slice of the Dev Fund will flow to ZF, to be used at its discretion for any purpose within its mandate to support Zcash and financial privacy, including: development, education, support community communication on-line and via events, gathering community sentiment, and external awarding grants for all of the above.</p>
|
||||
<p>ZF may award grants as profit-sharing contracts, in which case any resulting profits will be added to the ZF-GU slice (to fund its ongoing operations and any future grants).</p>
|
||||
</section>
|
||||
<section id="zf-mg-slice-zcash-foundation-for-major-grants"><h4><span class="section-heading">ZF-MG slice (Zcash Foundation, for major grants)</span><span class="section-anchor"> <a href="#zf-mg-slice-zcash-foundation-for-major-grants"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="zf-mg-slice-zcash-foundation-for-major-grants"><h4><span class="section-heading">ZF-MG slice (Zcash Foundation, for major grants)</span><span class="section-anchor"> <a rel="bookmark" href="#zf-mg-slice-zcash-foundation-for-major-grants"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>This slice of the Dev Fund is intended to fund independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) for the public good of Zcash ecosystem, to the extent that such teams are available and effective.</p>
|
||||
<p>The funds will be received and administered by ZF. ZF will disburse them as "Major Grants", within the framework of ZF's grant program but subject to the following additional constraints:</p>
|
||||
<ol type="1">
|
||||
|
|
@ -96,12 +96,12 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fun
|
|||
<p>ZF shall recognize the ZF-MG slice of the Dev Fund as a Restricted Fund donation under the above constraints (suitably formalized), and keep separate accounting of its balance and usage under its Transparency and Accountability obligations defined below.</p>
|
||||
<p>From grant proposers' side, proposals for such grants will be submitted through ZF usual grant process, allowing for public discussion and public funding. It is intended that small one-time grants will be funded by drawing on the ZF-GU slice (where they also compete with other ZF activities), whereas large long-duration will be funded from the dedicated ZF-MG slice; though this is at ZF's discretion.</p>
|
||||
<p>ZF shall strive to define target metrics and key performance indicators, and utilize these in its funding decisions.</p>
|
||||
<section id="direct-grant-option"><h5><span class="section-heading">Direct-grant option</span><span class="section-anchor"> <a href="#direct-grant-option"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
|
||||
<section id="direct-grant-option"><h5><span class="section-heading">Direct-grant option</span><span class="section-anchor"> <a rel="bookmark" href="#direct-grant-option"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
|
||||
<p>It may be deemed better, operationally or legally, if the Major Grant funds are not accepted and disbursed by ZF, but rather directly assigned to the grantees. Thus, the following mechanism may be used in perpetuity, if agreed upon by both ECC and ZF before NU4 activation:</p>
|
||||
<p>Prior to each Network Upgrade, the Foundation shall publish a list of grantees' addresses and the total number of Dev Fund ZEC per block they should receive. ECC and ZF shall implement this list in any implementations of the Zcash consensus rules they maintain. This decision will then be, effectively, ratified by the miners as the network upgrade activates.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="funding-target-and-volatility-reserve"><h4><span class="section-heading">Funding Target and Volatility Reserve</span><span class="section-anchor"> <a href="#funding-target-and-volatility-reserve"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="funding-target-and-volatility-reserve"><h4><span class="section-heading">Funding Target and Volatility Reserve</span><span class="section-anchor"> <a rel="bookmark" href="#funding-target-and-volatility-reserve"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Each Dev Fund slice has a Funding Target, initially US $700,000 for each slice. At the end of each calendar month, the fair market value of the Dev Fund ZEC received during that month will be computed, and the excess over the Funding Target will be put into a dedicated Volatility Reserve account by the funds' recipient.</p>
|
||||
<p>Funds may be withdrawn from the Volatility Reserve account only by that same party, in months where the aforementioned monthly ZEC value falls short of the Funding Target, and only to the extent needed to cover that shortfall.</p>
|
||||
<p>The Volatility Reserve may be kept as ZEC, or sold and held as fiat currency or investments (whose profits will remain in the Volatility Reserve).</p>
|
||||
|
|
@ -110,8 +110,8 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fun
|
|||
<p>Irrevocable obligations to the above must be made by the recipients (e.g., using their Operating Agreements or by receiving the slice as Restricted Funds).</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="transparency-and-accountability"><h3><span class="section-heading">Transparency and Accountability</span><span class="section-anchor"> <a href="#transparency-and-accountability"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="obligations"><h4><span class="section-heading">Obligations</span><span class="section-anchor"> <a href="#obligations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="transparency-and-accountability"><h3><span class="section-heading">Transparency and Accountability</span><span class="section-anchor"> <a rel="bookmark" href="#transparency-and-accountability"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="obligations"><h4><span class="section-heading">Obligations</span><span class="section-anchor"> <a rel="bookmark" href="#obligations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>ECC, ZF and Major Grant recipients (during and leading to their award period) shall all accept the following obligations:</p>
|
||||
<p>Ongoing public reporting requirements:</p>
|
||||
<ul>
|
||||
|
|
@ -130,12 +130,12 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fun
|
|||
<p>ECC's reports, and ZF's annual report on its non-grant operations, should be at least as detailed as grant proposals/reports submitted by other funded parties, and satisfy similar levels of public scrutiny.</p>
|
||||
<p>All substantial software whose development was funded by the Dev Fund should be released under an Open Source license (as defined by the Open Source Initiative), preferably the MIT license.</p>
|
||||
</section>
|
||||
<section id="enforcement"><h4><span class="section-heading">Enforcement</span><span class="section-anchor"> <a href="#enforcement"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="enforcement"><h4><span class="section-heading">Enforcement</span><span class="section-anchor"> <a rel="bookmark" href="#enforcement"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>For grant recipients, these conditions should be included in their contract with ZF, such that substantial violation, not promptly remedied, will cause forfeiture of their grant funds and their return to ZF.</p>
|
||||
<p>ECC and ZF will contractually commit to each other to fulfill these conditions, and the prescribed use of funds, such that substantial violation, not promptly remedied, will permit the other party to issue a modified version of Zcash node software that removes the violating party's Dev Fund slice, and use the Zcash trademark for this modified version. The slice's funds will be reassigned to ZF-MG (whose integrity is legally protected by the Restricted Fund treatment).</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="future-community-governance"><h3><span class="section-heading">Future Community Governance</span><span class="section-anchor"> <a href="#future-community-governance"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="future-community-governance"><h3><span class="section-heading">Future Community Governance</span><span class="section-anchor"> <a rel="bookmark" href="#future-community-governance"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Decentralized community governance is used in this proposal in the following places:</p>
|
||||
<ol type="1">
|
||||
<li>As advisory input to the <a href="#zf-mg-slice-zcash-foundation-for-major-grants">ZF-MG slice (Zcash Foundation, for major grants)</a>.</li>
|
||||
|
|
@ -144,13 +144,13 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fun
|
|||
</ol>
|
||||
<p>It is highly desirable to develop robust means of decentralized community voting and governance, and to integrate them into all of the above processes, by the end of 2021. ECC and ZF should place high priority on such development and its deployment, in their activities and grant selection.</p>
|
||||
</section>
|
||||
<section id="zf-board-composition"><h3><span class="section-heading">ZF Board Composition</span><span class="section-anchor"> <a href="#zf-board-composition"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="zf-board-composition"><h3><span class="section-heading">ZF Board Composition</span><span class="section-anchor"> <a rel="bookmark" href="#zf-board-composition"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>ZF should formally integrate robust means of decentralized community voting into its Board of Director elections, in a way that is consistent with ZF's mission and values. ZF should lead the process for determining and implementing this, legally and technically, by the end of 2021.</p>
|
||||
<p>Members of ZF's Board of Directors must not hold equity in ECC or have current business or employment relationships with ECC.</p>
|
||||
<p>Grace period: members of the board who hold ECC equity (but do not have other current relationships to ECC) may dispose of their equity, or quit the Board, by 1 March 2021. (The grace period is to allow for orderly replacement, and also to allow time for ECC corporate reorganization related to Dev Fund receipt, which may affect how disposition of equity would be executed.)</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="disclosures"><h2><span class="section-heading">Disclosures</span><span class="section-anchor"> <a href="#disclosures"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="disclosures"><h2><span class="section-heading">Disclosures</span><span class="section-anchor"> <a rel="bookmark" href="#disclosures"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The author is</p>
|
||||
<ul>
|
||||
<li>a coauthor of the <a href="https://eprint.iacr.org/2014/349">Zerocash</a> academic paper underlying Zcash;</li>
|
||||
|
|
@ -160,7 +160,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fun
|
|||
</ul>
|
||||
<p>This proposal is his private opinion and does not represent any of the above.</p>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposed is most closely based on the Matt Luongo <a href="https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252">Decentralizing the Dev Fee</a> proposal, with substantial changes and mixing in elements from <em>@aristarchus</em>'s <a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-20-split-between-the-ecc-and-the-foundation/33862">20% split between the ECC and the Foundation</a> proposal, Josh Cincinnati's <a href="https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812">A Grand Compromise/Synthesis ZIP Proposal</a> proposal and extensive discussions in the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum</a>. The author is grateful to all of the above for their excellent ideas and many insightful discussions, and to Howard Loo and forum users <em>@aristarchus</em> and <em>@dontbeevil</em> for valuable initial comments on this proposal.</p>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Category: Consensus / Process
|
|||
Created: 2019-11-14
|
||||
License: Public Domain
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/zip-keep-it-simple-zcashers-kisz-10-to-ecc-10-to-zfnd/35425></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
|
|
@ -26,12 +26,12 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-keep-it-simple-zcashe
|
|||
<dd>a regularly-scheduled discontinuity where the rate of ZEC issuance halves, expected first in roughly October 2020 then next in roughly October 2024.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP proposes:</p>
|
||||
<p>After the 1st Zcash Halvening, when the "Founders’ Reward" system- bootstrapping protocol-based development funding expires, continue to direct 20% of new ZEC issuance to development-related activities for ongoing research, development, innovation, and maintenance of Zcash.</p>
|
||||
<p>Assign half of such funds to the ECC, and half to the ZF. Continue this allocation until the 2nd Halvening.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>There have been many proposals for potential allocations of Zcash block rewards (ZEC inflation) after the 1st Halvening. Many cluster around similar broad parameters:</p>
|
||||
<ul>
|
||||
<li>20% of block rewards for continuing development efforts;</li>
|
||||
|
|
@ -40,13 +40,13 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-keep-it-simple-zcashe
|
|||
</ul>
|
||||
<p>However, no existing ZIPs explicitly propose the most simple variation on this theme - one that maintains maximal continuity with prior practice. This 'Keep It Simple, Zcashers' ZIP aims to fill that gap.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intends to be easy to describe, understand, and implement.</p>
|
||||
</section>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal does not seek to propose any particular course of action past the 2nd Halvening.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>To implement this ZIP, the Zcash protocol and compatible software MUST:</p>
|
||||
<ul>
|
||||
<li>maintain a 20% allotment of new ZEC issuance to development activities through to the 2nd Halvening event (expected around October 2024);</li>
|
||||
|
|
@ -56,7 +56,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-keep-it-simple-zcashe
|
|||
<p>This proposal specifically refrains from adding any new conditions or procedural formalities, technical or legal, on the delivery of development funds.</p>
|
||||
<p>There is only the expectation that these recipients SHOULD continue the stated missions, practices of transparency, and responsiveness to community input that they have demonstrated thus far.</p>
|
||||
</section>
|
||||
<section id="discussion"><h2><span class="section-heading">Discussion</span><span class="section-anchor"> <a href="#discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="discussion"><h2><span class="section-heading">Discussion</span><span class="section-anchor"> <a rel="bookmark" href="#discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal primarily differs from similar proposals in two ways: (1) it places no new comditions/processes on the disbursement of ZEC development funds; (2) it specifies a fixed, 50-50 division-of-funds between the ECC and ZF.</p>
|
||||
<p>These differences are motivated by a desire for simplicity and continuity. This allocation can be implemented technically without novel institutions, processes, or legal agreements.</p>
|
||||
<p>Rather than relying on lists-of-conditions with underspecified enforcement or dispute-resolution mechanisms, the adequate performance of fund recipients is expected due to:</p>
|
||||
|
|
@ -66,7 +66,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/zip-keep-it-simple-zcashe
|
|||
</ul>
|
||||
<p>From original "Founders’ Reward"-era development-funds, roughly 15% has been directed to the ZF. (Or, about 3 points of the full 20 points of bootstrap- funds.) However, from its later start, the ZF has recently grown its technical, grantmaking, and organizational capabilities, and wide sentiment in the Zcash community, ECC, and ZF desires the ZF grow to a role of equivalent or greater importance as the ECC for long-term Zcash evolution. Thus this proposal specifies a 50:50 split of future development funds, rather than continuing any prior proportions.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -22,14 +22,14 @@ Category: Consensus / Process
|
|||
Created: 2019-11-10
|
||||
License: MIT
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">5</a> and the Zcash Trademark Donation and License Agreement (<a id="id3" class="footnote_reference" href="#trademark">3</a> or successor agreement).</p>
|
||||
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="id4" class="footnote_reference" href="#protocol">2</a></p>
|
||||
<p>"Electric Coin Company", also called "ECC", refers to the Zerocoin Electric Coin Company, LLC.</p>
|
||||
<p>"Zcash Foundation", also called "ZF", refers to the 501(c)(3) nonprofit corporation of that name.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal describes a structure for the Zcash Development Fund, to be enacted in Network Upgrade 4 and last for 4 years. This Dev Fund would consist of 20% of the block subsidies, split into 3 slices:</p>
|
||||
<ul>
|
||||
<li>35% for the Electric Coin Company;</li>
|
||||
|
|
@ -38,12 +38,12 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
</ul>
|
||||
<p>Governance and accountability are based on existing entities and legal mechanisms, and increasingly decentralized governance is encouraged.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Starting at Zcash's first halving in October 2020, by default 100% of the block subsidies will be allocated to miners, and no further funds will be automatically allocated to research, development, and outreach. Consequently, no substantial new funding may be available to existing teams dedicated to Zcash: the Electric Coin Company (ECC), the Zcash Foundation (ZF), and the many entities funded by the ZF grant program.</p>
|
||||
<p>There is a need to strike a balance between incentivizing the security of the consensus protocol (i.e., mining) versus other crucial aspects of the Zcash security and functionality, such as development and outreach.</p>
|
||||
<p>Furthermore, there is a need to balance the sustenance of ongoing work by the current teams dedicated to Zcash, with encouraging decentralization and growth of independent development teams.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Dev Fund should encourage decentralization of the work and funding, by supporting new teams dedicated to Zcash.</p>
|
||||
<p>The Dev Fund should maintain the existing teams and capabilities in the Zcash ecosystem, unless and until concrete opportunities arise to create even greater value for the Zcash ecosystem.</p>
|
||||
<p>There should not be any single entity which is a single point of failure, i.e., whose capture or failure will effectively prevent effective use of the funds.</p>
|
||||
|
|
@ -54,12 +54,12 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<p>The new Dev Fund system should be simple to understand and realistic to implement. In particular, it should not assume the creation of new mechanisms (e.g., election systems) or entities (for governance or development) for its execution; but it should strive to support and use these once they are built.</p>
|
||||
<p>Comply with legal, regulatory, and taxation constraints in pertinent jurisdictions.</p>
|
||||
</section>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>General on-chain governance is outside the scope of this proposal.</p>
|
||||
<p>Rigorous voting mechanisms (whether coin-weighted, holding-time-weighted or one-person-one-vote) are outside the scope of this proposal, though there is prescribed room for integrating them once available.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="dev-fund-allocation"><h3><span class="section-heading">Dev Fund allocation</span><span class="section-anchor"> <a href="#dev-fund-allocation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="dev-fund-allocation"><h3><span class="section-heading">Dev Fund allocation</span><span class="section-anchor"> <a rel="bookmark" href="#dev-fund-allocation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Starting at the first Zcash halving in 2020, until the second halving in 2024, 20% of the block subsidy of each block SHALL be allocated to a "Dev Fund" that consists of the following three slices:</p>
|
||||
<ul>
|
||||
<li>35% for the Electric Coin Company (denoted <strong>ECC slice</strong>);</li>
|
||||
|
|
@ -67,7 +67,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<li>40% for additional "Major Grants" for large-scale long-term projects (denoted <strong>MG slice</strong>).</li>
|
||||
</ul>
|
||||
<p>The slices are described in more detail below. The fund flow will be implemented at the consensus-rule layer, by sending the corresponding ZEC to the designated address(es) for each block. This Dev Fund will end at the second halving (unless extended/modified by a future ZIP).</p>
|
||||
<section id="ecc-slice-electric-coin-company"><h4><span class="section-heading">ECC slice (Electric Coin Company)</span><span class="section-anchor"> <a href="#ecc-slice-electric-coin-company"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="ecc-slice-electric-coin-company"><h4><span class="section-heading">ECC slice (Electric Coin Company)</span><span class="section-anchor"> <a rel="bookmark" href="#ecc-slice-electric-coin-company"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>This slice of the Dev Fund will flow to ECC.</p>
|
||||
<p>ECC MUST undertake a firm obligation to use the Dev Fund only in support of the Zcash cryptocurrency and its community.</p>
|
||||
<p>In particular, ECC MUST commit to not distribute the Dev Fund proceeds to its partners ("shareholders"), other than:</p>
|
||||
|
|
@ -78,10 +78,10 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<p>(ECC is encouraged to transition to a corporate structure that would avoid the latter taxes.)</p>
|
||||
<p>This obligation MUST be made irrevocable, e.g., within ECC's corporate governance structure (i.e., its Operating Agreement) or contractual obligations.</p>
|
||||
</section>
|
||||
<section id="zf-slice-zcash-foundation-s-general-use"><h4><span class="section-heading">ZF slice (Zcash Foundation's general use)</span><span class="section-anchor"> <a href="#zf-slice-zcash-foundation-s-general-use"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="zf-slice-zcash-foundation-s-general-use"><h4><span class="section-heading">ZF slice (Zcash Foundation's general use)</span><span class="section-anchor"> <a rel="bookmark" href="#zf-slice-zcash-foundation-s-general-use"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>This slice of the Dev Fund will flow to ZF, to be used at its discretion for any purpose within its mandate to support Zcash and financial privacy, including: development, education, supporting community communication online and via events, gathering community sentiment, and awarding external grants for all of the above.</p>
|
||||
</section>
|
||||
<section id="mg-slice-major-grants"><h4><span class="section-heading">MG slice (Major Grants)</span><span class="section-anchor"> <a href="#mg-slice-major-grants"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="mg-slice-major-grants"><h4><span class="section-heading">MG slice (Major Grants)</span><span class="section-anchor"> <a rel="bookmark" href="#mg-slice-major-grants"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>This slice of the Dev Fund is intended to fund independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) for the public good of the Zcash ecosystem, to the extent that such teams are available and effective.</p>
|
||||
<p>The funds SHALL be received and administered by ZF. ZF MUST disburse them as "Major Grants", but subject to the following additional constraints:</p>
|
||||
<ol type="1">
|
||||
|
|
@ -95,14 +95,14 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
</ol>
|
||||
<p>ZF SHALL recognize the MG slice of the Dev Fund as a Restricted Fund donation under the above constraints (suitably formalized), and keep separate accounting of its balance and usage under its <a href="#transparency-and-accountability">Transparency and Accountability</a> obligations defined below.</p>
|
||||
<p>ZF SHALL strive to define target metrics and key performance indicators, and the Major Grant Review Committee SHOULD utilize these in its funding decisions.</p>
|
||||
<section id="direct-grant-option"><h5><span class="section-heading">Direct-grant option</span><span class="section-anchor"> <a href="#direct-grant-option"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
|
||||
<section id="direct-grant-option"><h5><span class="section-heading">Direct-grant option</span><span class="section-anchor"> <a rel="bookmark" href="#direct-grant-option"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
|
||||
<p>It may be deemed better, operationally or legally, if the Major Grant funds are not accepted and disbursed by ZF, but rather directly assigned to the grantees. Thus, the following mechanism MAY be used in perpetuity for some or all grantees, if agreed upon by both ECC and ZF before Network Upgrade 4 (Canopy) activation:</p>
|
||||
<p>Prior to each network upgrade, the Foundation SHALL publish a list of grantees' addresses and the total number of Dev Fund ZEC per block they should receive. ECC and ZF SHALL implement this list in any implementations of the Zcash consensus rules they maintain. This decision will then be, effectively, ratified by the miners as the network upgrade activates.</p>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
<section id="transparency-and-accountability"><h3><span class="section-heading">Transparency and Accountability</span><span class="section-anchor"> <a href="#transparency-and-accountability"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="obligations"><h4><span class="section-heading">Obligations</span><span class="section-anchor"> <a href="#obligations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="transparency-and-accountability"><h3><span class="section-heading">Transparency and Accountability</span><span class="section-anchor"> <a rel="bookmark" href="#transparency-and-accountability"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="obligations"><h4><span class="section-heading">Obligations</span><span class="section-anchor"> <a rel="bookmark" href="#obligations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>ECC, ZF, and Major Grant recipients (during and leading to their award period) SHALL all accept the obligations in this section.</p>
|
||||
<p>Ongoing public reporting requirements:</p>
|
||||
<ul>
|
||||
|
|
@ -121,27 +121,27 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<p>ECC's reports, and ZF's annual report on its non-grant operations, SHOULD be at least as detailed as grant proposals/reports submitted by other funded parties, and satisfy similar levels of public scrutiny.</p>
|
||||
<p>All substantial software whose development was funded by the Dev Fund SHOULD be released under an Open Source license (as defined by the Open Source Initiative <a id="id6" class="footnote_reference" href="#osd">4</a>), preferably the MIT license.</p>
|
||||
</section>
|
||||
<section id="enforcement"><h4><span class="section-heading">Enforcement</span><span class="section-anchor"> <a href="#enforcement"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="enforcement"><h4><span class="section-heading">Enforcement</span><span class="section-anchor"> <a rel="bookmark" href="#enforcement"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>For grant recipients, these conditions SHOULD be included in their contract with ZF, such that substantial violation, not promptly remedied, will cause forfeiture of their grant funds and their return to ZF.</p>
|
||||
<p>ECC and ZF MUST contractually commit to each other to fulfill these conditions, and the prescribed use of funds, such that substantial violation, not promptly remedied, will permit the other party to issue a modified version of Zcash node software that removes the violating party's Dev Fund slice, and use the Zcash trademark for this modified version. The slice's funds will be reassigned to MG (whose integrity is legally protected by the Restricted Fund treatment).</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="future-community-governance"><h3><span class="section-heading">Future Community Governance</span><span class="section-anchor"> <a href="#future-community-governance"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="future-community-governance"><h3><span class="section-heading">Future Community Governance</span><span class="section-anchor"> <a rel="bookmark" href="#future-community-governance"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Decentralized community governance is used in this proposal via the Community Panel as input into the Major Grant Review Committee which governs the <a href="#mg-slice-major-grants">MG slice (Major Grants)</a>.</p>
|
||||
<p>It is highly desirable to develop robust means of decentralized community voting and governance –either by expanding the Community Panel or a successor mechanism– and to integrate them into this process by the end of 2021. ECC and ZF SHOULD place high priority on such development and its deployment, in their activities and grant selection.</p>
|
||||
</section>
|
||||
<section id="zf-board-composition"><h3><span class="section-heading">ZF Board Composition</span><span class="section-anchor"> <a href="#zf-board-composition"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="zf-board-composition"><h3><span class="section-heading">ZF Board Composition</span><span class="section-anchor"> <a rel="bookmark" href="#zf-board-composition"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Members of ZF's Board of Directors MUST NOT hold equity in ECC or have current business or employment relationships with ECC, except as provided for by the grace period described below.</p>
|
||||
<p>Grace period: members of the board who hold ECC equity (but do not have other current relationships to ECC) may dispose of their equity, or quit the Board, by 1 November 2021. (The grace period is to allow for orderly replacement, and also to allow time for ECC corporate reorganization related to Dev Fund receipt, which may affect how disposition of equity would be executed.)</p>
|
||||
<p>The Foundation SHOULD endeavor to use the Community Panel (or successor mechanism) as advisory input for future board elections.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal is a limited modification of Eran Tromer's ZIP 1012 <a id="id7" class="footnote_reference" href="#zip-1012">9</a> by the Zcash Foundation, the ECC, further modified by feedback from the community and the results of the <a href="https://vote.heliosvoting.org/helios/elections/43b9bec8-39a1-11ea-914c-b6e34ffa859a/view">latest Helios poll</a>.</p>
|
||||
<p>Eran's proposal is most closely based on the Matt Luongo 'Decentralize the Dev Fee' proposal (ZIP 1011) <a id="id8" class="footnote_reference" href="#zip-1011">8</a>. Relative to ZIP 1011 there are substantial changes and mixing in of elements from <em>@aristarchus</em>'s '20% Split Evenly Between the ECC and the Zcash Foundation' (ZIP 1003) <a id="id9" class="footnote_reference" href="#zip-1003">6</a>, Josh Cincinnati's 'Compromise Dev Fund Proposal With Diverse Funding Streams' (ZIP 1010) <a id="id10" class="footnote_reference" href="#zip-1010">7</a>, and extensive discussions in the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum</a>.</p>
|
||||
<p>The authors are grateful to all of the above for their excellent ideas and any insightful discussions, and to Howard Loo and forum users <em>@aristarchus</em> and <em>@dontbeevil</em> for valuable initial comments on ZIP 1012.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -16,11 +16,11 @@ Status: Draft
|
|||
Category: {Consensus | Standards Track | Network | RPC | Wallet | Informational | Process}
|
||||
Created: yyyy-mm-dd
|
||||
License: {usually MIT}</pre>
|
||||
<section id="don-t-panic"><h2><span class="section-heading">Don't Panic</span><span class="section-anchor"> <a href="#don-t-panic"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="don-t-panic"><h2><span class="section-heading">Don't Panic</span><span class="section-anchor"> <a rel="bookmark" href="#don-t-panic"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>If this is your first time writing a ZIP, the structure and format may look intimidating. But really, it's just meant to reflect common-sense practice and some technical conventions. Feel free to start with a simple initial draft that gets ideas across, even if it doesn't quite follow this format. The community and ZIP editors will help you figure things out and get it into shape later.</p>
|
||||
<p>{Delete this section.}</p>
|
||||
</section>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>{Edit this to reflect the key words that are actually used.} The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
|
|
@ -30,29 +30,29 @@ License: {usually MIT}</pre>
|
|||
<dd>{Definition.}</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>{Describe what this proposal does, typically in a few paragraphs.</p>
|
||||
<p>The Abstract should only provide a summary of the ZIP; the ZIP should remain complete without the Abstract.</p>
|
||||
<p>Use links where applicable, e.g. <a id="id2" class="footnote_reference" href="#protocol">2</a>.}</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>{Why is this proposal needed?</p>
|
||||
<p>This is one of the most important sections of the ZIP, and should be detailed and comprehensive. It shouldn't include any of the actual specification -- don't put conformance requirements in this section.</p>
|
||||
<p>Explain the status quo, why the status quo is in need of improvement, and if applicable, the history of how this area has changed. Then describe <em>at a high level</em> why this proposed solution addresses the perceived issues. It is ok if this is somewhat redundant with the abstract, but here you can go into a lot more detail.}</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>{Describe design constraints on, or goals for the solution -- typically one paragraph for each constraint or goal. Again, don't actually specify anything here; this section is primarily for use as a consistency check that what is specified meets the requirements.}</p>
|
||||
</section>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>{This section is entirely optional. If it is present, it describes issues that the proposal is <em>not</em> attempting to address, that someone might otherwise think it does or should.}</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>{This section describes what should change, using precise language and conformance key words. Anything that is <em>required in order to implement the ZIP</em> (or follow its process, in the case of a Process ZIP) should be in this section.</p>
|
||||
<p>Avoid overspecification! Also avoid underspecification. Specification is hard. Don't be afraid to ask for help.</p>
|
||||
<p>Unless the specification is particularly simple, you will need to organise it under subheadings.}</p>
|
||||
<section id="example-subheading"><h3><span class="section-heading">Example subheading</span><span class="section-anchor"> <a href="#example-subheading"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="example-subheading"><h3><span class="section-heading">Example subheading</span><span class="section-anchor"> <a rel="bookmark" href="#example-subheading"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>{At least while the ZIP is in Draft, we encourage writing open questions and TODOs.}</p>
|
||||
<section id="open-questions"><h4><span class="section-heading">Open questions</span><span class="section-anchor"> <a href="#open-questions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="open-questions"><h4><span class="section-heading">Open questions</span><span class="section-anchor"> <a rel="bookmark" href="#open-questions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<ul>
|
||||
<li>What happens if a full node can't parse the fandangle as a doohicky?</li>
|
||||
</ul>
|
||||
|
|
@ -60,7 +60,7 @@ License: {usually MIT}</pre>
|
|||
<p>{Feel free to copy from other ZIPs doing similar things, e.g. defining RPC calls, consensus rules, etc.}</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="valid-restructuredtext"><h3><span class="section-heading">Valid reStructuredText</span><span class="section-anchor"> <a href="#valid-restructuredtext"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="valid-restructuredtext"><h3><span class="section-heading">Valid reStructuredText</span><span class="section-anchor"> <a rel="bookmark" href="#valid-restructuredtext"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This is optional before publishing a PR, but to check whether a document is valid reStructuredText, first install rst2html5:</p>
|
||||
<pre>sudo apt-get install python-pip
|
||||
sudo pip install rst2html5</pre>
|
||||
|
|
@ -69,10 +69,10 @@ sudo pip install rst2html5</pre>
|
|||
<p>and view <code>zip-xxxx.html</code> in a web browser.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>{This section is entirely optional; if present, it usually gives links to zcashd or zebrad PRs.}</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
|
|||
Loading…
Reference in New Issue