zecfoundation
/
zips
mirror of https://github.com/ZcashFoundation/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

[Dark mode] Fix the background colour of the section anchor image. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2022-01-11 13:19:12 +00:00
parent 3ba7b5f246
commit 0ada3050af
62 changed files with 837 additions and 834 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
css/style.css
View File

@ -28,6 +28,9 @@
img {
background: #bbbbbb;
}
img.section-anchor {
background: #111111 !important;
}
span.reserved {
color: #a0a0a0;
}

2
edithtml.sh
View File

@ -36,6 +36,6 @@ fi
sed -i.sedbak 's|<a \(class=[^ ]* \)*href="\([^":]*\)\.rst\(\#[^"]*\)*">|<a \1href="\2\3">|g' "$2"
sed -i.sedbak 's|&lt;\(https:[^&]*\)&gt;|\&lt;<a href="\1">\1</a>\&gt;|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"
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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h\4>|g' "$2"
rm -f *.sedbak

10
index.html
View File

@ -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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 <a href="https://discord.gg/kdjfvps">ZcashCommunity Discord chat</a> 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,7 +24,7 @@
<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="nu5-zips"><h2><span class="section-heading">NU5 ZIPs</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-zips"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="nu5-zips"><h2><span class="section-heading">NU5 ZIPs</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-zips"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This is the list of ZIPs relevant to the proposed NU5 Upgrade, which is planned to activate on Mainnet in January 2022:</p>
<ul>
<li><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a> (updated)</li>
@ -43,10 +43,10 @@
<li><a href="zip-0401">ZIP 401: Addressing Mempool Denial-of-Service</a> (clarified)</li>
</ul>
</section>
<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>
<section id="license"><h2><span class="section-heading">License</span><span class="section-anchor"> <a rel="bookmark" href="#license"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>

42
zip-0000.html
View File

@ -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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 Owners — one or more people who write the ZIP using the style and format described below, shepherd the discussions in the appropriate forums, and attempt to build community consensus around the idea. The ZIP Owners 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 Owners 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 Owners. Just because an idea sounds good to the Owners does not mean it will work for most people in most areas where Zcash is used.</p>
<p>Once the Owners have 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 Owners 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 (if that has not already been done) and one or more Categories, 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 Owners may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the Owners as pull requests.</p>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 &amp; 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>
<section id="zip-editor-responsibilities-workflow"><h3><span class="section-heading">ZIP Editor Responsibilities &amp; Workflow</span><span class="section-anchor"> <a rel="bookmark" href="#zip-editor-responsibilities-workflow"><img width="24" height="24" class="section-anchor" 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 &lt;<a href="mailto:zips@z.cash">zips@z.cash</a>&gt;, 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>ZIPs SHOULD be written in reStructuredText <a id="id6" class="footnote_reference" href="#rst">5</a>, Markdown <a id="id7" class="footnote_reference" href="#markdown">6</a>, or LaTeX <a id="id8" class="footnote_reference" href="#latex">7</a>. For ZIPs written in LaTeX, a <code>Makefile</code> 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="id9" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Each ZIP MUST begin with a RFC 822-style header preamble. For ZIPs written in reStructuredText, this is represented as <code>::</code> on the first line, followed by a blank line, then the preamble indented by 2 spaces.</p>
<p>The following header fields are REQUIRED:</p>
<pre>ZIP:
@ -144,11 +144,11 @@ Updates:</pre>
<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>
<p>For ZIPs written in reStructuredText, URLs in header fields SHOULD be surrounded by <code>&lt;</code> <code>&gt;</code>; this ensures that the link is rendered correctly.</p>
</section>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Each ZIP is in one or more of the following categories, as specified in the Category header:</p>
<dl>
<dt>Consensus</dt>
@ -174,7 +174,7 @@ Updates:</pre>
<p>Consensus and Standards ZIPs SHOULD have a Reference Implementation section, which includes or (more often) links to an implementation.</p>
<p>Consensus ZIPs SHOULD have a Deployment section, describing how and when the consensus change is planned to be deployed (for example, in a particular network upgrade).</p>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>Reserved: The ZIP Editors have reserved this ZIP number, and there MAY be a Pull Request for it, but no ZIP has been published. The ZIP Editors SHOULD publish a stub header so that the reservation appears in the <a href="https://zips.z.cash#index-of-zips">ZIP index</a>.</li>
<li>Draft: All initial ZIP submissions have this status.</li>
@ -187,7 +187,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 are given in the section below.</p>
<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>
<section id="specification"><h3><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" 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 Consensus ZIP, a Deployment section MUST be present in order for the ZIP to change status to Proposed. Typically, although not necessarily, this will specify a network upgrade in which the consensus change is to activate.</p>
<p>A Standards ZIP may only change status from Proposed to Implemented once the Owners provide an associated reference implementation, typically in the period after the network upgrade's specification freeze but before the implementation audit. If the Owners miss this deadline, the Editors or Owners MAY choose to update the Deployment section of the ZIP to target another upgrade, at their discretion.</p>
@ -197,10 +197,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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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
@ -209,7 +209,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 rel="bookmark" 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" class="section-anchor" 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>
@ -220,7 +220,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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<ul>
<li>BSL-1.0: <a href="https://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>
@ -231,10 +231,10 @@ Updates:</pre>
<li>LGPL-2.1+: <a href="https://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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -248,13 +248,13 @@ Updates:</pre>
</ul>
</section>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

80
zip-0032.html
View File

@ -21,13 +21,13 @@ 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 rel="bookmark" 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" class="section-anchor" 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="#protocol-jubjub">13</a>.</p>
<p>A "chain code" is a cryptovalue that is needed, in addition to a spending key, in order to derive descendant keys and addresses of that key.</p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">9</a>.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" 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="id4" class="footnote_reference" href="#bip-0032">2</a>, to support Zcash's shielded addresses.</p>
<p>The initial parts of the specification define (mostly) equivalent, but independent, systems for deriving a tree of key components from a single seed, for the following shielded pools (which have different internal key structures):</p>
<ul>
@ -38,7 +38,7 @@ License: MIT</pre>
<p>The last part shows how to use these trees in the context of existing BIP 44 <a id="id5" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>BIP 32 <a id="id6" 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="id7" 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>
@ -48,7 +48,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 rel="bookmark" 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" class="section-anchor" 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 Zcash protocol specification <a id="id9" class="footnote_reference" href="#protocol">8</a>. They are reproduced here for convenience:</p>
<ul>
<li>
@ -189,8 +189,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 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>
<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" class="section-anchor" 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" class="section-anchor" 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>
@ -215,7 +215,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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Define</p>
<ul>
<li>
@ -234,7 +234,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 rel="bookmark" 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" class="section-anchor" 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 and at most 252 bytes.</p>
@ -293,11 +293,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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -359,7 +359,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 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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Let
<span class="math">\(\mathcal{G}\)</span>
be as defined in <a id="id17" class="footnote_reference" href="#protocol-concretespendauthsig">12</a> and let
@ -419,7 +419,7 @@ License: MIT</pre>
</ul>
</section>
</section>
<section id="sapling-diversifier-derivation"><h3><span class="section-heading">Sapling diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-diversifier-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="sapling-diversifier-derivation"><h3><span class="section-heading">Sapling diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-diversifier-derivation"><img width="24" height="24" class="section-anchor" 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>
@ -449,9 +449,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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -461,7 +461,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 rel="bookmark" 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" class="section-anchor" 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
@ -475,7 +475,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 rel="bookmark" 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" class="section-anchor" 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 and at most 252 bytes.</p>
@ -502,7 +502,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 rel="bookmark" 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" class="section-anchor" 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>
@ -540,9 +540,9 @@ License: MIT</pre>
</ul>
</section>
</section>
<section id="specification-orchard-key-derivation"><h2><span class="section-heading">Specification: Orchard key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#specification-orchard-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="specification-orchard-key-derivation"><h2><span class="section-heading">Specification: Orchard key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#specification-orchard-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The derivation mechanism for Sapling addresses specified above incurs significant complexity to support non-hardened derivation. In the several years since Sapling was deployed, we have seen no use cases for non-hardened derivation appear. With that in mind, we define Orchard key derivation very similarly to Sprout above: only hardened derivation is supported.</p>
<section id="orchard-extended-keys"><h3><span class="section-heading">Orchard extended keys</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-extended-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="orchard-extended-keys"><h3><span class="section-heading">Orchard extended keys</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-extended-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>We represent an Orchard extended spending key as
<span class="math">\((\mathsf{sk, c}),\)</span>
where
@ -551,7 +551,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{c}\)</span>
is the chain code.</p>
</section>
<section id="orchard-master-key-generation"><h3><span class="section-heading">Orchard master key generation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-master-key-generation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="orchard-master-key-generation"><h3><span class="section-heading">Orchard master key generation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-master-key-generation"><img width="24" height="24" class="section-anchor" 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 and at most 252 bytes.</p>
@ -583,7 +583,7 @@ License: MIT</pre>
.</li>
</ul>
</section>
<section id="orchard-child-key-derivation"><h3><span class="section-heading">Orchard child key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-child-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="orchard-child-key-derivation"><h3><span class="section-heading">Orchard child key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-child-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>
<span class="math">\(\mathsf{CDKsk}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\)</span>
<span class="math">\(\rightarrow (\mathsf{sk}_{i}, \mathsf{c}_i)\)</span>
@ -618,7 +618,7 @@ License: MIT</pre>
.</li>
</ul>
</section>
<section id="orchard-diversifier-derivation"><h3><span class="section-heading">Orchard diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-diversifier-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="orchard-diversifier-derivation"><h3><span class="section-heading">Orchard diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-diversifier-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As with Sapling, we define a mechanism for deterministically deriving a sequence of diversifiers, without leaking how many diversified addresses have already been generated for an account. Unlike Sapling, we do so by deriving a diversifier key directly from the full viewing key, instead of as part of the extended spending key. This means that the full viewing key provides the capability to determine the position of a diversifier within the sequence, which matches the capabilities of a Sapling extended full viewing key but simplifies the key structure.</p>
<p>Given an Orchard extended spending key
<span class="math">\((\mathsf{sk}_i, \mathsf{c}_i)\)</span>
@ -656,9 +656,9 @@ License: MIT</pre>
</p>
</section>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id20" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Sprout, Sapling, and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:</p>
<ul>
<li>
@ -685,7 +685,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 rel="bookmark" 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" class="section-anchor" 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>
@ -713,7 +713,7 @@ License: MIT</pre>
<span class="math">\(address\_index\)</span>
.</p>
</section>
<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>
<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" class="section-anchor" 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>
@ -721,7 +721,7 @@ License: MIT</pre>
.</li>
</ul>
</section>
<section id="orchard-key-path"><h3><span class="section-heading">Orchard key path</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-key-path"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="orchard-key-path"><h3><span class="section-heading">Orchard key path</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-key-path"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard supports diversified addresses with the same spending authority (like Sapling). 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 Orchard ZIP 32 derivation MUST support the following path for any account in range
<span class="math">\(\{ 0\,.\!. 2^{31} - 1 \}\)</span>
@ -737,8 +737,8 @@ License: MIT</pre>
payment addresses (unlike Sapling, all Orchard diversifiers are valid).</p>
</section>
</section>
<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>
<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" class="section-anchor" 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" class="section-anchor" 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">\(\mathit{FVK}\)</span>
(as specified in <a id="id24" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">16</a>) is given by:</p>
@ -750,7 +750,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 rel="bookmark" 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" class="section-anchor" 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">\(\mathit{ADDR}\)</span>
(as specified in <a id="id25" class="footnote_reference" href="#protocol-sproutpaymentaddrencoding">14</a>, including the lead bytes) is given by:</p>
@ -762,7 +762,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="orchard-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Orchard Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="orchard-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Orchard Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding
<span class="math">\(\mathit{FVK}\)</span>
(as specified in <a id="id26" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">18</a>) is given by:</p>
@ -774,7 +774,7 @@ License: MIT</pre>
<p>It MAY be used to uniquely identify a particular Orchard full viewing key.</p>
<p>An "Orchard full viewing key tag" is the first 4 bytes of the corresponding Orchard 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="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>
<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" class="section-anchor" 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>
@ -789,9 +789,9 @@ License: MIT</pre>
<p>Note: a previous version of this specification did not have the length byte prefixing the seed. The current specification reflects the implementation in <cite>zcashd</cite>.</p>
</section>
</section>
<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>
<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" class="section-anchor" 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="id27" 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 rel="bookmark" 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" class="section-anchor" 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
@ -823,7 +823,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 rel="bookmark" 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" class="section-anchor" 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
@ -855,7 +855,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 rel="bookmark" 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" class="section-anchor" 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
@ -887,7 +887,7 @@ License: MIT</pre>
.</p>
<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 id="orchard-extended-spending-keys"><h3><span class="section-heading">Orchard extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-extended-spending-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="orchard-extended-spending-keys"><h3><span class="section-heading">Orchard extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-extended-spending-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>An Orchard extended spending key
<span class="math">\((\mathsf{sk, c})\)</span>
, at depth
@ -917,10 +917,10 @@ License: MIT</pre>
<p>We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users <a id="id28" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">19</a>.</p>
</section>
</section>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -928,7 +928,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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

44
zip-0143.html
View File

File diff suppressed because one or more lines are too long

26
zip-0155.html
View File

@ -17,21 +17,21 @@ Created: 2021-08-13
License: BSD-2-Clause
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/542">https://github.com/zcash/zips/issues/542</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/543">https://github.com/zcash/zips/pull/543</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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>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 terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
<p>"P2P network" means the Zcash peer-to-peer network.</p>
<p><code>uint8</code>, <code>uint16</code>, and <code>uint32</code> denote unsigned integer data types of the corresponding length (8, 16, or 32 bits respectively).</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This document proposes a new P2P message to gossip longer node addresses over the P2P network. This is required to support new-generation onion addresses, I2P, and potentially other networks that have longer endpoint addresses than fit in the 128 bits of the current <code>addr</code> message.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Tor v3 onion services are part of the stable release of Tor since version 0.3.2.9. They have various advantages compared to the old v2 onion services, among which better encryption and privacy <a id="id4" class="footnote_reference" href="#tor-rendezvous-v3">9</a>. These services have 256-bit addresses and thus do not fit in the existing <code>addr</code> message (unchanged from Bitcoin <a id="id5" class="footnote_reference" href="#bitcoin-addr-message">7</a>), which encapsulates onion addresses in OnionCat IPv6 addresses.</p>
<p>Other transport-layer protocols such as I2P have always used longer addresses. This change would make it possible to gossip such addresses over the P2P network, so that other peers can connect to them.</p>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The <code>addrv2</code> message is defined as a message where the <code>command</code> field is (NUL-padded) <code>"addrv2"</code>. It is serialized in the standard encoding for P2P messages. Its format is similar to the current <code>addr</code> message format described in <a id="id6" class="footnote_reference" href="#bitcoin-addr-message">7</a>, with the difference that the fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to <a id="id7" class="footnote_reference" href="#bitcoin-compactsize">8</a>.</p>
<p>This means that the message contains a serialized vector of the following structure:</p>
<blockquote>
@ -131,9 +131,9 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/543">https://githu
<p>Clients SHOULD gossip valid, potentially routable addresses from all known networks, even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to.</p>
<p>Clients MUST NOT gossip addresses from unknown networks, because they have no means to validate those addresses and so can be tricked to gossip invalid addresses.</p>
<p>Clients MUST reject messages that contain addresses that have a different length than specified in this table for a specific network ID, as these are meaningless.</p>
<section id="network-address-encodings"><h3><span class="section-heading">Network address encodings</span><span class="section-anchor"> <a rel="bookmark" href="#network-address-encodings"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="network-address-encodings"><h3><span class="section-heading">Network address encodings</span><span class="section-anchor"> <a rel="bookmark" href="#network-address-encodings"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The <code>IPV4</code> and <code>IPV6</code> network IDs use addresses encoded in the usual way for binary IPv4 and IPv6 addresses in network byte order (big endian).</p>
<section id="tor-v3-address-encoding"><h4><span class="section-heading">Tor v3 address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#tor-v3-address-encoding"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="tor-v3-address-encoding"><h4><span class="section-heading">Tor v3 address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#tor-v3-address-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>According to the spec <a id="id9" class="footnote_reference" href="#tor-rendezvous-v3">9</a>, version 3 <code>.onion</code> addresses are encoded as follows:</p>
<pre>onion_address = base32(PUBKEY || CHECKSUM || VERSION) + ".onion"
CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
@ -147,22 +147,22 @@ CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
</ul>
<p>Tor v3 addresses MUST be sent with the <code>TORV3</code> network ID, with the 32-byte <code>PUBKEY</code> part in the <code>addr</code> field. As <code>VERSION</code> will always be 0x03 in the case of v3 addresses, this is enough to reconstruct the onion address.</p>
</section>
<section id="i2p-address-encoding"><h4><span class="section-heading">I2P address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#i2p-address-encoding"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="i2p-address-encoding"><h4><span class="section-heading">I2P address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#i2p-address-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Like Tor, I2P naming uses a base32-encoded address format <a id="id11" class="footnote_reference" href="#i2p-naming">11</a>.</p>
<p>I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by <code>.b32.i2p</code>. The base32 encoding does not include <code>"="</code> padding characters.</p>
<p>I2P addresses MUST be sent with the <code>I2P</code> network ID, with the decoded SHA-256 hash as address field.</p>
</section>
<section id="cjdns-address-encoding"><h4><span class="section-heading">Cjdns address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#cjdns-address-encoding"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="cjdns-address-encoding"><h4><span class="section-heading">Cjdns address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#cjdns-address-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Cjdns addresses are simply IPv6 addresses in the <code>fc00::/8</code> range <a id="id12" class="footnote_reference" href="#cjdns-whitepaper">12</a>. They MUST be sent with the <code>CJDNS</code> network ID. They are encoded in network byte order (big endian) as for the <code>IPV6</code> network ID.</p>
</section>
</section>
<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>
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Support for this specification is signalled by peer protocol version 170017 (on both Testnet and Mainnet). Note that this is the same peer protocol version that signals support for NU5 on Mainnet <a id="id13" class="footnote_reference" href="#zip-0252">6</a>.</p>
<p>Nodes that have not negotiated peer protocol version 170017 or higher on a given connection, MUST NOT send <code>addrv2</code> messages on that connection.</p>
<p>A node that has negotiated peer protocol version 170017 or higher on a given connection, MAY still send <code>addr</code> messages on the connection, and MUST handle received <code>addr</code> messages as it would have done prior to this ZIP.</p>
</section>
</section>
<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="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP is closely based on BIP 155 <a id="id14" class="footnote_reference" href="#bip-0155">3</a>, with the following changes:</p>
<ul>
<li>Deployment: support for the <code>addrv2</code> message is signalled by advertising a peer protocol version of 170017 or higher, not by sending a <code>sendaddrv2</code> message. This is motivated by a desire to avoid an exponential explosion in the space of possible feature configurations in a given peer-to-peer connection. In Zcash, unlike Bitcoin, the space of such configurations is effectively constant no matter how many peer-to-peer protocol changes are made, because nodes that do not support a given peer protocol version will drop off the network over time if they do not support the latest Network Upgrade. The feature configuration for a given connection is also established at version negotiation, and cannot change after that point without reconnecting. Other peer-to-peer protocol changes ported from the Bitcoin peer-to-peer protocol, for example the <code>MSG_WTX</code> inv type defined in ZIP 239 <a id="id15" class="footnote_reference" href="#zip-0239">5</a>, have taken the same approach to signalling.</li>
@ -172,10 +172,10 @@ CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
<li>Clients MUST, rather than SHOULD, reject messages that contain addresses that have a different length than specified for a known network ID, or a length greater than the 512-byte maximum for an unknown network ID.</li>
</ul>
</section>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP is closely based on BIP 155 <a id="id16" class="footnote_reference" href="#bip-0155">3</a>, written by Wladimir J. van der Laan. Zancas Wilcox ported the implementation for Zcashd.</p>
<p>Acknowledgements for BIP 155:</p>
<ul>
@ -183,7 +183,7 @@ CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
<li>Gregory Maxwell: various suggestions regarding extensibility.</li>
</ul>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

52
zip-0173.html
View File

@ -17,15 +17,15 @@ Status: Final
Category: Standards / Wallet
Created: 2018-06-13
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 &gt;&gt; 5 * (5 - i)) &amp; 31 for i in range(6)]</pre>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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="https://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding">alphanumeric mode</a>, which is 45% more compact than the <a href="https://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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 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>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 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>
<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" class="section-anchor" 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 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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 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>
<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" class="section-anchor" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

30
zip-0200.html
View File

@ -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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 be 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

22
zip-0201.html
View File

@ -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 rel="bookmark" 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" class="section-anchor" 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 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,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 rel="bookmark" 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" class="section-anchor" 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 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 -&gt; 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 &gt; 0 &amp;&amp;
</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 rel="bookmark" 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" class="section-anchor" 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&amp; vRecv, int64_t nTimeReceived)
@ -157,7 +157,7 @@ if (nActivationHeight &gt; 0 &amp;&amp;
}</pre>
</section>
</section>
<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>
<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" class="section-anchor" 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 &gt; 0 &amp;&amp;
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

32
zip-0202.html
View File

@ -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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a new transaction format required for Network Upgrade 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 rel="bookmark" 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" class="section-anchor" 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 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>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 <a href="https://blockchair.com/zcash/transaction/5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061">5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061</a>)</p>
<ul>
@ -260,17 +260,17 @@ 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 &amp; 0x7FFFFFFF = 0x00000003 = 3</pre>
</section>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 id="transaction-validation"><h3><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></h3>
<section id="transaction-validation"><h3><span class="section-heading">Transaction Validation</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-validation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<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>
<p>Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id9" class="footnote_reference" href="#zip-0143">2</a>.</p>
</section>
</section>
<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>
<section id="implementation"><h2><span class="section-heading">Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#implementation"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 &gt;= 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 rel="bookmark" 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" class="section-anchor" 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 &amp;&amp; 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="id10" 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 rel="bookmark" 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" class="section-anchor" 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="id11" 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 rel="bookmark" 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" class="section-anchor" 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="id12" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

22
zip-0203.html
View File

@ -15,10 +15,10 @@ 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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
@ -32,7 +32,7 @@ License: MIT</pre>
<span class="math">\(N\)</span>
, 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 rel="bookmark" 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" class="section-anchor" 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 (but see the exception for coinbase transactions described in <a href="#changes-for-nu5">Changes for NU5</a>).</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>
@ -46,35 +46,35 @@ License: MIT</pre>
<p>No limit: To set no limit on transactions (so that they do not expire), <code>nExpiryHeight</code> should be set to 0.</p>
<p>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="changes-for-blossom"><h3><span class="section-heading">Changes for Blossom</span><span class="section-anchor"> <a rel="bookmark" href="#changes-for-blossom"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="changes-for-blossom"><h3><span class="section-heading">Changes for Blossom</span><span class="section-anchor"> <a rel="bookmark" href="#changes-for-blossom"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>On Blossom activation <a id="id1" class="footnote_reference" href="#zip-0206">2</a>, the default changes to 40 blocks from the current height, which still represents about 50 minutes at the revised 75-second target block spacing.</p>
</section>
<section id="changes-for-nu5"><h3><span class="section-heading">Changes for NU5</span><span class="section-anchor"> <a rel="bookmark" href="#changes-for-nu5"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="changes-for-nu5"><h3><span class="section-heading">Changes for NU5</span><span class="section-anchor"> <a rel="bookmark" href="#changes-for-nu5"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As mentioned above, <code>nExpiryHeight</code> is ignored for coinbase transactions. However, from NU5 activation <a id="id2" class="footnote_reference" href="#zip-0252">3</a>, the <code>nExpiryHeight</code> field of a coinbase transaction MUST be set equal to the block height. Also, for coinbase transactions only, the bound of 499999999 on <code>nExpiryHeight</code> is removed. The motivation is to ensure that transaction IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol specification <a id="id3" class="footnote_reference" href="#protocol-txnencoding">4</a>.</p>
</section>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>For Overwinter, transaction expiry will be set to a default that can be overridden by a flag <cite>txexpirydelta</cite> set in the config file.</p>
<p><code>-txexpirydelta=</code> set the number of blocks after which a transaction that has not been mined will become invalid</p>
<p>To view: <cite>listtransactions</cite> has a new filter attribute, showing expired transactions only:</p>
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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="id4" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="zip-0201" class="footnote">
<tbody>
<tr>

16
zip-0205.html
View File

@ -14,7 +14,7 @@ Status: Final
Category: Consensus / Network
Created: 2018-10-08
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 "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">7</a></p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
@ -24,11 +24,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 rel="bookmark" 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" class="section-anchor" 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 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>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" 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" class="section-anchor" 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="id4" class="footnote_reference" href="#protocol">2</a>.</li>
@ -59,21 +59,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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Section 7.6.3 of the Zcash Protocol Specification <a id="id10" class="footnote_reference" href="#protocol-diffadjustment">5</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 greater than 15 minutes after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="id11" class="footnote_reference" href="#protocol-constants">4</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="id12" class="footnote_reference" href="#protocol-nbits">6</a>.</p>
<p>Note: a previous revision of this ZIP incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the <code>nBits</code> field is modified as well, and this affects difficulty adjustment for subsequent blocks.</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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

14
zip-0206.html
View File

@ -14,7 +14,7 @@ Status: Final
Category: Consensus / Network
Created: 2019-07-29
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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>
@ -27,11 +27,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 rel="bookmark" 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" class="section-anchor" 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 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>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" 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" class="section-anchor" 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">2</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 rel="bookmark" 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" class="section-anchor" 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">2</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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

24
zip-0207.html
View File

@ -15,7 +15,7 @@ Status: Implemented (zcashd)
Category: Consensus
Created: 2019-01-04
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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">7</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">10</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-networks">4</a></dd>
</dl>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" 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">14</a>. It should be read in conjunction with ZIP 1014 <a id="id8" class="footnote_reference" href="#zip-1014">16</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 rel="bookmark" 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" class="section-anchor" 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">16</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 rel="bookmark" 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" class="section-anchor" 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">14</a> to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (BP, ZF, and MG) defined in ZIP 1014 <a id="id11" class="footnote_reference" href="#zip-1014">16</a>, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.</p>
<p>As for the original Founders' Reward, a mechanism is provided to allow addresses for a given funding stream to be 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 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>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" 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" class="section-anchor" 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">5</a>, <a id="id13" class="footnote_reference" href="#protocol-diffadjustment">6</a>, <a id="id14" class="footnote_reference" href="#protocol-subsidies">7</a>, and <a id="id15" class="footnote_reference" href="#protocol-foundersreward">8</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 rel="bookmark" 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" class="section-anchor" 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="id16" class="footnote_reference" href="#zip-0208">11</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 rel="bookmark" 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" class="section-anchor" 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="id17" class="footnote_reference" href="#protocol-foundersreward">8</a></p>
<p>Once the Canopy network upgrade activates:</p>
<ul>
@ -209,20 +209,20 @@ License: MIT</pre>
<p>For the funding stream definitions to be activated at Canopy, see ZIP 214. <a id="id21" class="footnote_reference" href="#zip-0214">14</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id22" class="footnote_reference" href="#zip-0000">9</a></p>
</section>
</section>
<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>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal is intended to be deployed with Canopy. <a id="id23" class="footnote_reference" href="#zip-0251">15</a></p>
</section>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li><a href="https://github.com/zcash/zcash/pull/4560">https://github.com/zcash/zcash/pull/4560</a></li>
<li><a href="https://github.com/zcash/zcash/pull/4675">https://github.com/zcash/zcash/pull/4675</a></li>
<li><a href="https://github.com/zcash/zcash/pull/4830">https://github.com/zcash/zcash/pull/4830</a></li>
</ul>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

44
zip-0208.html
View File

@ -16,17 +16,17 @@ Category: Consensus
Created: 2019-01-10
License: MIT
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://github.com/zcash/zips/pull/237</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 "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">9</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 the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-diffadjustment">6</a>.)</p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol-networks">4</a>.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" 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="id5" class="footnote_reference" href="#zip-0206">11</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 rel="bookmark" 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" class="section-anchor" 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>
@ -35,9 +35,9 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<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="id6" class="footnote_reference" href="#slowfastblocks">13</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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The changes described in this section are to be made in the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#protocol">3</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 rel="bookmark" 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" class="section-anchor" 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="id8" 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>
@ -106,31 +106,31 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
</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 rel="bookmark" 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" class="section-anchor" 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-testnet"><h4><span class="section-heading">Minimum difficulty blocks on Testnet</span><span class="section-anchor"> <a rel="bookmark" href="#minimum-difficulty-blocks-on-testnet"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="minimum-difficulty-blocks-on-testnet"><h4><span class="section-heading">Minimum difficulty blocks on Testnet</span><span class="section-anchor"> <a rel="bookmark" href="#minimum-difficulty-blocks-on-testnet"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>On Testnet from block height 299188 onward, the difficulty adjustment algorithm <a id="id10" class="footnote_reference" href="#protocol-diffadjustment">6</a> allows minimum-difficulty blocks, as described in <a id="id11" class="footnote_reference" href="#zip-0205">10</a>, when the block time is greater than 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 greater than 6 · PoWTargetSpacing(<em>height</em>) seconds after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="id12" class="footnote_reference" href="#protocol-constants">5</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="id13" class="footnote_reference" href="#protocol-nbits">7</a>.</p>
<p>Note: a previous revision of this ZIP (and <a id="id14" class="footnote_reference" href="#zip-0205">10</a>) incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the <code>nBits</code> field is modified as well, and this affects difficulty adjustment for subsequent blocks.</p>
<p>This change does not affect Mainnet.</p>
</section>
</section>
<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>
<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" class="section-anchor" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>When not overridden by the <code>-txexpirydelta</code> 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 <code>-txexpirydelta</code> 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>ZIP 308 <a id="id15" class="footnote_reference" href="#zip-0308">12</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 rel="bookmark" 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" class="section-anchor" 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><cite>zcashd</cite> 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
@ -140,13 +140,13 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<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 section 7.7.5 of the Zcash Protocol Specification <a id="id16" class="footnote_reference" href="#protocol-workdef">8</a>, 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 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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>When <cite>zcashd</cite> 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),
@ -158,16 +158,16 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
// 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 <cite>zcashd</cite> 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>If pruning is enabled, when <cite>zcashd</cite> 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p><cite>zcashd</cite> 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 rel="bookmark" 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" class="section-anchor" 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
@ -193,16 +193,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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal will be deployed with the Blossom network upgrade. <a id="id17" class="footnote_reference" href="#zip-0206">11</a></p>
</section>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

12
zip-0209.html
View File

@ -14,7 +14,7 @@ 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 rel="bookmark" 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" class="section-anchor" 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>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 chain value pool balance" for a given block chain 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>
@ -22,23 +22,23 @@ License: MIT</pre>
<p>The "Orchard chain value pool balance" for a given block chain is the negation of the sum of all <code>valueBalanceOrchard</code> fields for transactions in the block chain. (Before NU5 has activated, the Orchard chain value pool balance is zero.)</p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines how the consensus rules are altered such that blocks that produce negative shielded chain value pool balances are prohibited.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" 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, Sapling, and Orchard 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>If any of the "Sprout chain value pool balance", "Sapling chain value pool balance", or "Orchard chain 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 rel="bookmark" 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" class="section-anchor" 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="id4" 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>
<p>This specification was deployed in zcashd v2.0.4 for Testnet, and in zcashd v2.0.5 for Mainnet. The application to the Orchard chain value pool balance will be deployed from NU5 activation <a id="id5" class="footnote_reference" href="#zip-0252">4</a>.</p>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

18
zip-0210.html
View File

@ -13,23 +13,23 @@ Status: Withdrawn
Category: Consensus
Created: 2019-03-27
License: MIT</pre>
<section id="status"><h2><span class="section-heading">Status</span><span class="section-anchor"> <a rel="bookmark" href="#status"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="status"><h2><span class="section-heading">Status</span><span class="section-anchor"> <a rel="bookmark" href="#status"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP has been withdrawn because a similar change has been incorporated into the ZIP 225 proposal for a version 5 transaction format. <a id="id1" class="footnote_reference" href="#zip-0225">5</a></p>
</section>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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="id2" 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="id3" class="footnote_reference" href="#zip-0200">3</a>.</p>
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205 <a id="id4" class="footnote_reference" href="#zip-0205">4</a>.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The Sapling network upgrade <a id="id5" class="footnote_reference" href="#zip-0205">4</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="id6" class="footnote_reference" href="#protocol-txnencoding">2</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 rel="bookmark" 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" class="section-anchor" 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>
@ -39,17 +39,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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

18
zip-0211.html
View File

@ -14,17 +14,17 @@ Status: Implemented (zcashd)
Category: Consensus
Created: 2019-03-29
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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">3</a>.</p>
<p>The term "Sprout shielded protocol" in this document refers to the shielded payment protocol defined at the launch of the Zcash network.</p>
<p>The term "Sapling shielded protocol" in this document refers to the shielded payment protocol introduced in the Sapling network upgrade <a id="id3" class="footnote_reference" href="#zip-0205">4</a> <a id="id4" class="footnote_reference" href="#protocol">2</a>.</p>
<p>The term "Sprout chain value pool balance" in this document is to be interpreted as described in ZIP 209 <a id="id5" class="footnote_reference" href="#zip-0209">5</a>.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal disables the ability to add new value to the Sprout chain value pool balance. This takes a step toward being able to remove the Sprout shielded 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 rel="bookmark" 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" class="section-anchor" 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="id6" class="footnote_reference" href="#zerocash">8</a></p>
<p>The Sapling network upgrade <a id="id7" class="footnote_reference" href="#zip-0205">4</a> introduced significant efficiency and functionality improvements for shielded transactions. It is expected that over time, the use of Sapling will replace the use of Sprout in shielded transactions.</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 shielded protocol.</p>
@ -32,7 +32,7 @@ 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 payment protocols.</p>
<p>Removing the ability to add to the Sprout chain 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="id9" class="footnote_reference" href="#zip-0308">7</a>.</p>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Consensus rule: 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 create transactions that have both one or more outputs to Sprout addresses, and one or more inputs from non-Sprout addresses. This SHOULD be made clear in user interfaces and API documentation.</p>
<p>Notes:</p>
@ -41,7 +41,7 @@ License: MIT</pre>
<li>The facility to send to Sprout addresses, even before activation of this proposal, is OPTIONAL for a particular node or wallet implementation.</li>
</ul>
</section>
<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="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" 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>
@ -51,17 +51,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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal will be deployed with the Canopy network upgrade. <a id="id11" class="footnote_reference" href="#zip-0251">6</a></p>
</section>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

28
zip-0212.html
View File

@ -14,7 +14,7 @@ Status: Implemented (zcashd)
Category: Consensus
Created: 2019-03-31
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "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 following functions are defined in the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol">2</a> according to the type (Sapling or Orchard) of note plaintext being processed:</p>
<ul>
@ -48,10 +48,10 @@ License: MIT</pre>
defined in section 4.1.8 <a id="id8" class="footnote_reference" href="#protocol-abstractcommit">4</a>.</li>
</ul>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP proposes a new note plaintext format for Sapling Outputs (later extended to include Orchard Actions) in transactions. The new format allows recipients to verify that the sender of an Output or Action knows the private key corresponding to the ephemeral Diffie-Hellman key, in order 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The Sapling and Orchard payment protocols have 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>
@ -112,7 +112,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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The specification in this ZIP is intended to be aligned with version 2021.2.16 or later of the Zcash Protocol Specification <a id="id9" class="footnote_reference" href="#protocol">2</a>.</p>
<p>Pseudo random functions (PRFs) are defined in section 4.1.2 of the Zcash Protocol Specification <a id="id10" class="footnote_reference" href="#protocol-abstractprfs">3</a>. We will be adapting
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
@ -121,7 +121,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-and-orchard-note-plaintexts"><h3><span class="section-heading">Changes to Sapling and Orchard Note plaintexts</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-sapling-and-orchard-note-plaintexts"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="changes-to-sapling-and-orchard-note-plaintexts"><h3><span class="section-heading">Changes to Sapling and Orchard Note plaintexts</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-sapling-and-orchard-note-plaintexts"><img width="24" height="24" class="section-anchor" 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="id11" class="footnote_reference" href="#protocol-notept">15</a>. Before activation of this ZIP, the encoding of a Sapling note plaintext required that the first byte take the form
<span class="math">\(\mathtt{0x01}\)</span>
, indicating the version of the note plaintext. In addition, a
@ -150,7 +150,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{rcm}\)</span>
field be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from descriptions of note plaintexts in the Zcash Protocol Specification.</p>
</section>
<section id="changes-to-the-process-of-sending-sapling-or-orchard-notes"><h3><span class="section-heading">Changes to the process of sending Sapling or Orchard notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-sending-sapling-or-orchard-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-or-orchard-notes"><h3><span class="section-heading">Changes to the process of sending Sapling or Orchard notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-sending-sapling-or-orchard-notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The process of sending notes is described in section 4.7.2 of the Zcash Protocol Specification for Sapling <a id="id12" class="footnote_reference" href="#protocol-saplingsend">7</a> and section 4.7.3 for Orchard <a id="id13" class="footnote_reference" href="#protocol-orchardsend">8</a>. In addition, the process of encrypting a note is described (currently) in section 4.19.1 of the Zcash Protocol Specification <a id="id14" class="footnote_reference" href="#protocol-saplingandorchardencrypt">9</a>. Prior to activation of this ZIP, the sender sampled
<span class="math">\(\mathsf{rcm^{new}}\)</span>
and the ephemeral private key
@ -180,7 +180,7 @@ License: MIT</pre>
</ul>
<p>For Orchard, an encoding of ρ is appended to these PRF inputs, as specified in section 4.7.3 of the Zcash Protocol Specification <a id="id15" class="footnote_reference" href="#protocol-orchardsend">8</a>.</p>
</section>
<section id="changes-to-the-process-of-receiving-sapling-or-orchard-notes"><h3><span class="section-heading">Changes to the process of receiving Sapling or Orchard notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-receiving-sapling-or-orchard-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-or-orchard-notes"><h3><span class="section-heading">Changes to the process of receiving Sapling or Orchard notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-receiving-sapling-or-orchard-notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The process of receiving notes in Sapling is described in sections 4.19.2 and 4.19.3 of the Zcash Protocol Specification. <a id="id16" class="footnote_reference" href="#protocol-decryptivk">10</a> <a id="id17" class="footnote_reference" href="#protocol-decryptovk">11</a></p>
<p>There is a "grace period" of 32256 blocks starting from the block at which this ZIP activates, during which note plaintexts with lead byte
<span class="math">\(\mathtt{0x01}\)</span>
@ -222,7 +222,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\)</span>
, failing decryption if this check is not satisfied. For Orchard, an encoding of ρ is appended to the PRF inputs, as for encryption.</p>
</section>
<section id="consensus-rule-change-for-coinbase-transactions"><h3><span class="section-heading">Consensus rule change for coinbase transactions</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-rule-change-for-coinbase-transactions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="consensus-rule-change-for-coinbase-transactions"><h3><span class="section-heading">Consensus rule change for coinbase transactions</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-rule-change-for-coinbase-transactions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>After the activation of this ZIP, any Sapling output of a coinbase transaction that is decrypted to a note plaintext as specified in <a id="id18" class="footnote_reference" href="#zip-0213">17</a>, MUST have note plaintext lead byte equal to
<span class="math">\(\mathtt{0x02}\)</span>
.</p>
@ -232,7 +232,7 @@ License: MIT</pre>
.</p>
</section>
</section>
<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="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" 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>
@ -255,7 +255,7 @@ License: MIT</pre>
<span class="math">\(\mathtt{0x01}\)</span>
were non-conformantly sent even after the end of the specified grace period. ZecWallet extended its implementation of the grace period by a further 161280 blocks (approximately 20 weeks) in order to allow for recovery of these funds <a id="id21" class="footnote_reference" href="#zecwallet-grace-extension">20</a>.</p>
</section>
<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>
<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" class="section-anchor" 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 (or Pallas) elliptic curve, for it could perform a linkability attack trivially in that case.</p>
<p>In the naïve case where the protocol is modified so that
<span class="math">\(\mathsf{esk}\)</span>
@ -263,10 +263,10 @@ 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="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>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal will be deployed with the Canopy network upgrade. <a id="id22" class="footnote_reference" href="#zip-0251">18</a></p>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>In zcashd:</p>
<ul>
<li><a href="https://github.com/zcash/zcash/pull/4578">https://github.com/zcash/zcash/pull/4578</a></li>
@ -276,10 +276,10 @@ License: MIT</pre>
<li><a href="https://github.com/zcash/librustzcash/pull/258">https://github.com/zcash/librustzcash/pull/258</a></li>
</ul>
</section>
<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>
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

20
zip-0213.html
View File

@ -13,21 +13,21 @@ Status: Final
Category: Consensus
Created: 2019-03-30
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 (and later Orchard) 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 rel="bookmark" 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" class="section-anchor" 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. It will also be possible for miners to use Orchard addresses starting from activation of the NU5 upgrade <a id="id7" class="footnote_reference" href="#zip-0252">6</a>.</p>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" 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>
@ -54,11 +54,11 @@ License: MIT</pre>
<li>Coinbase transactions MAY contain Sapling and/or Orchard outputs.</li>
</ul>
<p>This does not require any change to the consensus rule given above; it is a consequence of other rules as of NU5 activation.</p>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -66,17 +66,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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal will be deployed with the Heartwood network upgrade. <a id="id8" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

28
zip-0214.html
View File

@ -14,7 +14,7 @@ Category: Consensus
Created: 2020-02-28
License: MIT
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560">https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "SHALL", "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 "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">6</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">8</a> and the Zcash Trademark Donation and License Agreement (<a id="id4" class="footnote_reference" href="#trademark">6</a> or successor agreement).</p>
@ -24,24 +24,24 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/community-sentim
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id8" class="footnote_reference" href="#protocol-networks">4</a>.</p>
<p>"Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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">12</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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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">10</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">9</a> SHALL be activated in Canopy.</p>
@ -125,7 +125,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/community-sentim
<li>The block heights of halvings are different between Testnet and Mainnet, as a result of different activation heights for the Blossom network upgrade (which changed the block target spacing). The end height of these funding streams corresponds to the second halving on each network.</li>
<li>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 1116000) 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 1116000 (inclusive) to 2796000 (exclusive).</li>
</ul>
<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>
<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" class="section-anchor" 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 on behalf of BP; 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_ZIP214_BP</code> funding stream, which on Mainnet corresponds to the <strong>BP slice</strong>;</li>
@ -134,13 +134,13 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/community-sentim
<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">12</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 rel="bookmark" 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" class="section-anchor" 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">12</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 value of funding streams assigned to direct grantees MUST be subtracted from the value of 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 SHOULD 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<pre>FS_ZIP214_BP.AddressList[0..47] = [
"t3LmX1cxWPPPqL4TZHx42HU3U5ghbFjRiif",
"t3Toxk1vJQ6UjWQ42tUJz2rV2feUWkpbTDs",
@ -197,7 +197,7 @@ FS_ZIP214_ZF.AddressList[0..47] = ["t3dvVE3SQEi7kqNzwrfNePxZ1d4hUyztBA1"] * 48
FS_ZIP214_MG.AddressList[0..47] = ["t3XyYW8yBFRuMnfvm5KLGFbEVz25kckZXym"] * 48</pre>
<p>(i.e. <code>FS_ZIP214_ZF.AddressList</code> and <code>FS_ZIP214_MG.AddressList</code> for Mainnet each consist of 48 repetitions of the same address).</p>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<pre>FS_ZIP214_BP.AddressList[0..50] = [
"t26ovBdKAJLtrvBsE2QGF4nqBkEuptuPFZz",
"t26ovBdKAJLtrvBsE2QGF4nqBkEuptuPFZz",
@ -258,15 +258,15 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
<p>(i.e. <code>FS_ZIP214_ZF.AddressList</code> and <code>FS_ZIP214_MG.AddressList</code> for Testnet each consist of 51 repetitions of the same address).</p>
</section>
</section>
<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="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The rationale for ZF generating the addresses for the <code>FS_ZIP214_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">12</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>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 rel="bookmark" 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" class="section-anchor" 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">11</a></p>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

16
zip-0215.html
View File

@ -14,17 +14,17 @@ Status: Implemented (zcashd)
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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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-2020-1-1">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 rel="bookmark" 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" class="section-anchor" 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 <a id="id4" class="footnote_reference" href="#protocol-concreteed25519">5</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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This is intended to be deployed with the Canopy Network Upgrade <a id="id7" class="footnote_reference" href="#zip-0251">6</a>, which is scheduled to activate on Mainnet <a id="id8" class="footnote_reference" href="#protocol-networks">4</a> at block height 1046400.</p>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

16
zip-0216.html
View File

@ -16,14 +16,14 @@ Category: Consensus
Created: 2021-02-11
License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://github.com/zcash/zips/issues/400</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key word "MUST" in this document is 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">12</a></p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP fixes an oversight in the implementation of the Sapling consensus rules, by rejecting all non-canonical representations of Jubjub points.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The Sapling specification was originally written with the intent that all values, including Jubjub points, are strongly typed with canonical representations. <a id="id3" class="footnote_reference" href="#protocol-jubjub">6</a> This has significant advantages for security analysis, because it allows the protocol to be modelled with just the abstract types.</p>
<p>The intention of the Jubjub implementation (both in the <cite>jubjub</cite> crate <a id="id4" class="footnote_reference" href="#jubjub-crate">15</a> and its prior implementations) was to ensure that only canonical point encodings would be accepted by the decoding logic. However, an oversight in the implementation allowed an edge case to slip through: for each point on the curve where the
<span class="math">\(u\!\)</span>
@ -51,7 +51,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<p>This issue is not known to cause any security vulnerability, beyond the risk of consensus incompatibility. In fact, for some of the fields that would otherwise be affected, the issue does not occur because there are already consensus rules that prohibit small-order points, and this incidentally prohibits non-canonical encodings.</p>
<p>Adjustments to the protocol specification were made in versions 2020.1.8, 2020.1.9, 2020.1.15, and 2021.1.17 to match the <cite>zcashd</cite> implementation. (The fact that this required 4 specification revisions to get right, conclusively demonstrates the problem.)</p>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Let
<span class="math">\(\mathsf{abst}_{\mathbb{J}}\)</span>
,
@ -168,7 +168,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
.)</p>
<p>The above is intended to be a complete list of the places where compressed encodings of Jubjub points occur in the Zcash consensus protocol and in plaintext, address, or key formats.</p>
</section>
<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="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Zcash previously had a similar issue with non-canonical representations of points in Ed25519 public keys and signatures. In that case, given the prevalence of Ed25519 signatures in the wider ecosystem, the decision was made in ZIP 215 <a id="id14" class="footnote_reference" href="#zip-0215">13</a> (which activated with the Canopy network upgrade <a id="id15" class="footnote_reference" href="#zip-0251">14</a>) to allow non-canonical representations of points.</p>
<p>In Sapling, we are motivated instead to reject these non-canonical points:</p>
<ul>
@ -199,13 +199,13 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
are not affected.</p>
<p>Encodings of elliptic curve points on the Pallas and Vesta curves in the NU5 proposal <a id="id16" class="footnote_reference" href="#protocol-pallasandvesta">7</a> are also not affected.</p>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP eliminates a potential source of consensus divergence between differing full node implementations. At the time of writing (February 2021), no such divergence exists for any production implementation of Zcash, but the alpha-stage <cite>zebrad</cite> node implementation would be susceptible to this issue.</p>
</section>
<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>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP is proposed to activate with Network Upgrade 5. Requirements on points encoded in payment addresses and full viewing keys MAY be enforced in advance of NU5 activation.</p>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

36
zip-0221.html
View File

@ -17,7 +17,7 @@ Status: Final
Category: Consensus
Created: 2019-03-30
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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">13</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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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">
@ -361,7 +361,7 @@ License: MIT</pre>
<p>Each node, when serialized, is between 147 and 171 bytes long (between 212 and 244 bytes after NU5 activation). 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 rel="bookmark" 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" class="section-anchor" 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">-&gt;</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="sa">b</span><span class="s1">&#39;ZcashHistory&#39;</span> <span class="o">+</span> <span class="n">consensusBranchId</span><span class="p">)</span>
@ -460,7 +460,7 @@ License: MIT</pre>
<span class="sd">&#39;&#39;&#39;Makes the root commitment for a blockheader&#39;&#39;&#39;</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 rel="bookmark" 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" class="section-anchor" 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
@ -552,7 +552,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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The following specification is accurate before NU5 activation. See <a id="id11" class="footnote_reference" href="#zip-0244">9</a> for header field changes in NU5.</p>
<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. (In NU5, this field is renamed again to <code>hashBlockCommitments</code> as specified in <a id="id12" class="footnote_reference" href="#zip-0244">9</a>.)</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="id13" class="footnote_reference" href="#protocol-blockheader">3</a></p>
@ -568,14 +568,14 @@ 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 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>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" 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" class="section-anchor" 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> and <code>nOrchardTxCount</code>) all metadata is already generated during block construction and/or checked during block validation. Nodes are relatively compact in memory. As of the original publication of this ZIP, approximately 140,000 blocks had 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 structure of the commitment tree. Other metadata commitments were chosen to serve specific purposes. Originally variable-length commitments were placed last, so that most metadata in a node could 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>Orchard fields are placed last, in order to avoid complicating existing uses of the other fields.</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 rel="bookmark" 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" class="section-anchor" 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>
@ -587,7 +587,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 rel="bookmark" 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" class="section-anchor" 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>
@ -623,7 +623,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 rel="bookmark" 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" class="section-anchor" 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="id14" class="footnote_reference" href="#zip-0301">12</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="id15" 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>
@ -635,7 +635,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 rel="bookmark" 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" class="section-anchor" 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>
@ -643,11 +643,11 @@ 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="id16" 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 rel="bookmark" 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" class="section-anchor" 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="id17" class="footnote_reference" href="#zip-0250">10</a></p>
<p>Additional fields are added on activation of the NU5 network upgrade <a id="id18" class="footnote_reference" href="#zip-0252">11</a>, to support the new Orchard shielded protocol.</p>
</section>
<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>
<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" class="section-anchor" 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/blob/f37acdbb392e18a61c8a6600ca1c4a2edee5813d/ECLIPs/ECIP-draft_succinct-proofs.md">Draft ECIP-1055: Succinct PoW Using Merkle Mountain Ranges</a></li>
@ -660,7 +660,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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

28
zip-0222.html
View File

@ -17,21 +17,21 @@ Status: Draft
Category: Consensus
Created: 2019-07-01
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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">6</a>.</p>
<p>The term "prefix-free" in this document is to be interpreted as to mean that no valid encoding of a value may have the same binary representation as any prefix of the binary encoding of another value of the same type.</p>
<p>The term "non-malleable" in this document is to be interpreted as described in ZIP 244 <a id="id3" class="footnote_reference" href="#zip-0244">7</a>.</p>
<p>The value <code>MAX_MONEY</code> is as defined in section 5.3 of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol-constants">3</a>.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a modification to the consensus rules that enables complex forms of transparent output preconditions to be deployed in network upgrades. This in turn enables the creation of "transparent Zcash extensions" that augment the network's functionality in a carefully-defined and auditable fashion.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Zcash supports a limited set of preconditions that may be imposed upon how funds, both transparent and shielded, may be spent. Spending limitations on transparent funds are defined by what may be encoded in Bitcoin script, and spending of shielded funds is even more restricted. As such, some use cases (for example, integration of BOLT support <a id="id5" class="footnote_reference" href="#zip-draft-bolt">9</a>) are not yet supportable.</p>
<p>Transparent Zcash Extensions are intended to make it possible to incrementally add new functionality without modifying interpretation of the existing Bitcoin script, which is complex and potentially error-prone. Extensions may also serve as laboratories for evaluating demand for functionality which may eventually be candidates for inclusion in the consensus rules for shielded transactions.</p>
</section>
<section id="definitions"><h2><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></h2>
<section id="definitions"><h2><span class="section-heading">Definitions</span><span class="section-anchor"> <a rel="bookmark" href="#definitions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<dl>
<dt>encumber</dt>
<dd>To set conditions that must be satisfied in order to spend some or all of a transaction's outputs.</dd>
@ -41,8 +41,8 @@ License: MIT</pre>
<dd>Evidence to be evaluated against the challenge encoded by a precondition.</dd>
</dl>
</section>
<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="transparent-extensions"><h3><span class="section-heading">Transparent Extensions</span><span class="section-anchor"> <a rel="bookmark" href="#transparent-extensions"><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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="transparent-extensions"><h3><span class="section-heading">Transparent Extensions</span><span class="section-anchor"> <a rel="bookmark" href="#transparent-extensions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Transparent Extensions are modular software components that are distributed as part of the code of consensus implementations. An extension defines interpretation rules for several new pieces of data that are included as part of a transaction.</p>
<p>A Transparent Extension is identified by a numeric <code>type</code>. A Transparent Extension may also have several modes of operation, corresponding to different kinds of encumbrance within the extension's overall protocol.</p>
<p>The following three values are made available to the extension (in addition to <code>type</code>):</p>
@ -57,7 +57,7 @@ License: MIT</pre>
<p>The encoded forms of <code>precondition</code> and <code>witness</code> are not required to be constant-length, but SHOULD be solely determined by the pair <code>(type, mode)</code>.</p>
<p>The introduction of TZEs by this ZIP produces a new transparent unspent outpoint set, distinct from the UTXO set, such that indices into this set of outpoints may be referred to by TZE inputs in spending transactions.</p>
</section>
<section id="encoding-in-transactions"><h3><span class="section-heading">Encoding in transactions</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-in-transactions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="encoding-in-transactions"><h3><span class="section-heading">Encoding in transactions</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-in-transactions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>We define a new transaction format that contains two new fields:</p>
<ul>
<li><code>tze_outputs</code>: A list of pairs of:
@ -236,7 +236,7 @@ License: MIT</pre>
</tbody>
</table>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Once this ZIP becomes active, the following new consensus rules are enforced:</p>
<ul>
<li>For each <code>(outpoint, witness)</code> pair in <code>tze_inputs</code>:
@ -256,17 +256,17 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
<li>The sum of amounts going out of the transparent value pool of a transaction (that is, Bitcoin-style outputs and TZE outputs, plus JoinSplit <code>vpub_old</code> values) MUST NOT exceed the sum of amounts going into that pool (that is, Bitcoin-style inputs and TZE inputs, plus JoinSplit <code>vpub_new</code> values, plus the Sapling <code>valueBalance</code> amount).</li>
</ul>
</section>
<section id="changes-to-signatures-over-transaction-digests"><h3><span class="section-heading">Changes to signatures over transaction digests</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-signatures-over-transaction-digests"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="changes-to-signatures-over-transaction-digests"><h3><span class="section-heading">Changes to signatures over transaction digests</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-signatures-over-transaction-digests"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>This ZIP MUST be deployed in conjunction with or after ZIP 244 <a id="id7" class="footnote_reference" href="#zip-0244">7</a>, which defines new non-malleable transaction identifier and signature digest algorithms.</p>
<p>The newly added parts of the transaction, excluding witness information (i.e. not the <code>witness</code> fields of TZE Input Encodings), will be included in transaction digests for transaction identifiers and signatures. See ZIP 245 <a id="id8" class="footnote_reference" href="#zip-0245">8</a> for the specification of these new digests. If the changes in this ZIP are deployed, those described in ZIP 245 MUST be deployed as well.</p>
</section>
</section>
<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="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Transactions that have both TZE inputs and outputs are required to use a single extension type, in order to prevent cross-protocol attacks. The downside is that this prevents all TZE-encumbered value from being spent directly into a different TZE type; the value needs to go through a regular address in between. This restriction might be relaxed in future ZIPs for specific combinations of <code>(type, mode)</code> pairs that have been analyzed for cross-protocol attacks, but we opt here for a fail-safe default behaviour.</p>
<p>Transactions with TZE inputs which do not contain TZE outputs are not subject to single-extension or single-mode restrictions; likewise, transactions which contain TZE outputs without any TZE inputs may produce TZE outputs for multiple extension-type/mode pairs as the potential for cross-protocol attacks in this situation is negligible.</p>
<p>An earlier draft version of this ZIP stored the payloads inside transparent inputs and outputs. Although this had the advantage of not requiring a transaction format change, the consensus rules were significantly more complicated, and the design coupled the extension logic too tightly to the transparent address logic. Instead, this ZIP uses dedicated transaction fields, and a separate unspent output set.</p>
</section>
<section id="security-and-privacy-considerations-for-future-tze-implementations"><h2><span class="section-heading">Security and Privacy Considerations for Future TZE Implementations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations-for-future-tze-implementations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="security-and-privacy-considerations-for-future-tze-implementations"><h2><span class="section-heading">Security and Privacy Considerations for Future TZE Implementations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations-for-future-tze-implementations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP assumes that the base transaction format is non-malleable. However, the <code>precondition</code> and <code>witness</code> byte sequences are treated here as opaque. It is the responsibility of <code>tze_verify</code> to enforce the following:</p>
<ul>
<li><code>precondition</code> MUST be non-malleable: any malleation MUST cause <code>tze_verify</code> to return <code>false</code>.</li>
@ -275,17 +275,17 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
<p>ZIPs defining new extension types MUST include a section explaining how any potential sources of malleability are handled.</p>
<p>This ZIP includes restrictions to prevent cross-protocol attacks, but the extension mode is another potential attack surface. It is the responsibility of ZIPs defining new extensions to examine the potential for cross-mode attacks within their security analysis, and/or appropriately restrict which modes may be combined within a single transaction.</p>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>Librustzcash reference implementation of TZE API: <a id="id9" class="footnote_reference" href="#librustzcash-zip222">10</a></li>
<li>Zcashd reference implementation of consensus rule changes: <a id="id10" class="footnote_reference" href="#zcashd-zip222">11</a></li>
</ul>
</section>
<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>
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The handler semantics of <code>tze_verify</code> were suggested by Zaki Manian, drawing on the design of Cosmos. Daira Hopwood and Sean Bowe gave useful feedback on an early draft of this ZIP, and helped to analyse the various sources of transaction ID malleability.</p>
<p>We would also like to thank the numerous other individuals who participated in discussions at Zcon1 that led to the earlier draft version of this ZIP.</p>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

38
zip-0224.html
View File

@ -19,14 +19,14 @@ Category: Consensus
Created: 2021-02-27
License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://github.com/zcash/zips/issues/435</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key word "MUST" in this document is to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol-networks">5</a>.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This document proposes the Orchard shielded protocol, which defines a new shielded pool with spending keys and payment addresses that are amenable to future scalability improvements.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Zcash currently has two active shielded protocols and associated shielded pools:</p>
<ul>
<li>The Sprout shielded protocol (based on the Zerocash paper with improvements and security fixes <a id="id3" class="footnote_reference" href="#protocol-differences">21</a>), which as of February 2021 is a "closing" shielded pool into which no new ZEC can be sent.</li>
@ -39,10 +39,10 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
</ul>
<p>We are thus motivated to deploy a new shielded protocol designed around a curve cycle, using a proving system that is both amenable to recursion and does not require an SRS.</p>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-orchard">4</a>.</p>
<p>Given that the Orchard protocol largely follows the design of the Sapling protocol, we provide here a list of differences, with references to their normative specifications and associated design rationale.</p>
<section id="curves"><h3><span class="section-heading">Curves</span><span class="section-anchor"> <a rel="bookmark" href="#curves"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="curves"><h3><span class="section-heading">Curves</span><span class="section-anchor"> <a rel="bookmark" href="#curves"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The Orchard protocol uses the Pallas / Vesta curve cycle, in place of BLS12-381 and its embedded curve Jubjub:</p>
<ul>
<li>Pallas is used as the "application curve", on which the Orchard protocol itself is implemented (c/f Jubjub).</li>
@ -60,11 +60,11 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<li>Supporting evidence: <a id="id10" class="footnote_reference" href="#pasta-evidence">34</a></li>
</ul>
</section>
<section id="proving-system"><h3><span class="section-heading">Proving system</span><span class="section-anchor"> <a rel="bookmark" href="#proving-system"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="proving-system"><h3><span class="section-heading">Proving system</span><span class="section-anchor"> <a rel="bookmark" href="#proving-system"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard uses the Halo 2 proving system <a id="id11" class="footnote_reference" href="#halo2-proving-system">23</a> with the PLONKish arithmetization [#halo2-arithmetization], instead of Groth16 and R1CS.</p>
<p>This proposal does not make use of Halo 2's support for recursive proofs, but this is expected to be leveraged by future protocol updates.</p>
</section>
<section id="circuit"><h3><span class="section-heading">Circuit</span><span class="section-anchor"> <a rel="bookmark" href="#circuit"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="circuit"><h3><span class="section-heading">Circuit</span><span class="section-anchor"> <a rel="bookmark" href="#circuit"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard uses a single circuit for both spends and outputs, similar to Sprout. An "action" contains both a single (possibly dummy) note being spent, and a single (possibly dummy) note being created.</p>
<p>An Orchard transaction contains a "bundle" of actions, and a single Halo 2 proof that covers all of the actions in the bundle.</p>
<ul>
@ -73,7 +73,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<li>Design rationale: <a id="id14" class="footnote_reference" href="#orchard-actions">25</a></li>
</ul>
</section>
<section id="commitments"><h3><span class="section-heading">Commitments</span><span class="section-anchor"> <a rel="bookmark" href="#commitments"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="commitments"><h3><span class="section-heading">Commitments</span><span class="section-anchor"> <a rel="bookmark" href="#commitments"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The Orchard protocol has equivalent commitment schemes to Sapling. For non-homomorphic commitments, Orchard uses the PLONKish-efficient Sinsemilla in place of Bowe–Hopwood Pedersen hashes.</p>
<ul>
<li>Sinsemilla hash function: <a id="id15" class="footnote_reference" href="#protocol-concretesinsemillahash">11</a></li>
@ -81,13 +81,13 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<li>Design rationale: <a id="id17" class="footnote_reference" href="#orchard-commitments">26</a></li>
</ul>
</section>
<section id="commitment-tree"><h3><span class="section-heading">Commitment tree</span><span class="section-anchor"> <a rel="bookmark" href="#commitment-tree"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="commitment-tree"><h3><span class="section-heading">Commitment tree</span><span class="section-anchor"> <a rel="bookmark" href="#commitment-tree"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard uses an identical commitment tree structure to Sapling, except that we instantiate it with Sinsemilla instead of a Bowe–Hopwood Pedersen hash.</p>
<ul>
<li>Design rationale and considered alternatives: <a id="id18" class="footnote_reference" href="#orchard-tree">27</a></li>
</ul>
</section>
<section id="keys-and-addresses"><h3><span class="section-heading">Keys and addresses</span><span class="section-anchor"> <a rel="bookmark" href="#keys-and-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="keys-and-addresses"><h3><span class="section-heading">Keys and addresses</span><span class="section-anchor"> <a rel="bookmark" href="#keys-and-addresses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard keys and payment addresses are structurally similar to Sapling, with the following changes:</p>
<ul>
<li>The proof authorizing key is removed, and
@ -115,7 +115,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<li>Design rationale: <a id="id28" class="footnote_reference" href="#orchard-keys">24</a></li>
</ul>
</section>
<section id="notes"><h3><span class="section-heading">Notes</span><span class="section-anchor"> <a rel="bookmark" href="#notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="notes"><h3><span class="section-heading">Notes</span><span class="section-anchor"> <a rel="bookmark" href="#notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard notes have the structure
<span class="math">\((addr, v, \rho, \psi, \mathsf{rcm}).\)</span>
<span class="math">\(\rho\)</span>
@ -128,7 +128,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<li>Orchard notes: <a id="id30" class="footnote_reference" href="#protocol-notes">7</a></li>
</ul>
</section>
<section id="nullifiers"><h3><span class="section-heading">Nullifiers</span><span class="section-anchor"> <a rel="bookmark" href="#nullifiers"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="nullifiers"><h3><span class="section-heading">Nullifiers</span><span class="section-anchor"> <a rel="bookmark" href="#nullifiers"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Nullifiers for Orchard notes are computed as:</p>
<p>
<span class="math">\(\mathsf{nf} = [F_{\mathsf{nk}}(\rho) + \psi \pmod{p}] \mathcal{G} + \mathsf{cm}\)</span>
@ -143,19 +143,19 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<li>Design rationale and considered alternatives: <a id="id32" class="footnote_reference" href="#orchard-nullifiers">28</a></li>
</ul>
</section>
<section id="signatures"><h3><span class="section-heading">Signatures</span><span class="section-anchor"> <a rel="bookmark" href="#signatures"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="signatures"><h3><span class="section-heading">Signatures</span><span class="section-anchor"> <a rel="bookmark" href="#signatures"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard uses RedPallas (RedDSA instantiated with the Pallas curve) as its signature scheme in place of Sapling's RedJubjub (RedDSA instantiated with the Jubjub curve).</p>
<ul>
<li>RedPallas: <a id="id33" class="footnote_reference" href="#protocol-concretereddsa">13</a></li>
</ul>
</section>
</section>
<section id="additional-rationale"><h2><span class="section-heading">Additional Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#additional-rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="additional-rationale"><h2><span class="section-heading">Additional Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#additional-rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The primary motivator for proposing a new shielded protocol and pool is the need to migrate spend authority to a recursion-friendly curve. Spend authority in the Sapling shielded pool is rooted in the Jubjub curve, but there is no known way to construct an efficient curve cycle (or path to one) from either Jubjub or BLS12-381.</p>
<p>Despite having recursion-friendliness as a design goal, we do not propose a recursive protocol in this ZIP. Deploying an entire scaling solution in a single upgrade would be a risky endeavour with a lot of moving parts. By focusing just on the components that enable a recursive protocol (namely the curve cycle and the proving system), we can start the migration of value to a scalable protocol before actually deploying the scalable protocol itself.</p>
<p>The remainder of the changes we make relative to Sapling are motivated by simplifying the Sapling protocol (and fixing deficiencies), and using protocol primitives that are more efficient in the UltraPLONK arithmetization.</p>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP defines a new shielded pool. As with Sapling, the Orchard protocol only supports spending Orchard notes, and moving ZEC into or out of the Orchard pool happens via the
<span class="math">\(\mathsf{valueBalanceOrchard}\)</span>
transaction field. This has the following considerations:</p>
@ -171,21 +171,21 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
</li>
</ul>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li><a href="https://github.com/zcash-hackworks/zcash-test-vectors/pull/14">https://github.com/zcash-hackworks/zcash-test-vectors/pull/14</a></li>
</ul>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li><a href="https://github.com/zcash/halo2">https://github.com/zcash/halo2</a></li>
<li><a href="https://github.com/zcash/orchard">https://github.com/zcash/orchard</a></li>
</ul>
</section>
<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>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP is proposed to activate with Network Upgrade 5.</p>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

26
zip-0225.html
View File

@ -19,30 +19,30 @@ Category: Consensus
Created: 2021-02-28
License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://github.com/zcash/zips/issues/440</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 character § is used when referring to sections 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines an update to the Zcash peer-to-peer transaction format to include support for data elements required to support the Orchard protocol <a id="id3" class="footnote_reference" href="#protocol">2</a>. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements.</p>
<p>This ZIP also depends upon and defines modifications to the computation of the values <strong>TxId Digest</strong>, <strong>Signature Digest</strong>, and <strong>Authorizing Data Commitment</strong> defined by ZIP 244 <a id="id4" class="footnote_reference" href="#zip-0244">7</a>.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The new Orchard shielded pool requires serialized data elements that are distinct from any previous Zcash transaction. In addition, with the activation of ZIP 244, the serialized transaction format will no longer be consensus-critical. It makes sense at this point to define a format that can readily accommodate future extension in a systematic fashion, where elements required for support for a given pool are kept separate.</p>
</section>
<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>
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The new format must fully support the Orchard protocol.</p>
<p>The new format should lend itself to future extension or pruning to add or remove value pools.</p>
<p>The computation of the non-malleable transaction identifier hash must include all newly incorporated elements except those that attest to transaction validity.</p>
<p>The computation of the commitment to authorizing data for a transaction must include all newly incorporated elements that attest to transaction validity.</p>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>More general forms of extensibility, such as definining a key/value format that allows for parsers that are unaware of some components, are not required.</p>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>All fields in this specification are encoded as little-endian.</p>
<p>The Zcash transaction format for transaction version 5 is as follows:</p>
<section id="transaction-format"><h3><span class="section-heading">Transaction Format</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-format"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="transaction-format"><h3><span class="section-heading">Transaction Format</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-format"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<table>
<thead>
<tr>
@ -277,7 +277,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
</ul>
<p>The encodings of <code>tx_in</code>, and <code>tx_out</code> are as in a version 4 transaction (i.e. unchanged from Canopy). The encodings of <code>SpendDescriptionV5</code>, <code>OutputDescriptionV5</code> and <code>OrchardAction</code> are described below. The encoding of Sapling Spends and Outputs has changed relative to prior versions in order to better separate data that describe the effects of the transaction from the proofs of and commitments to those effects, and for symmetry with this separation in the Orchard-related parts of the transaction format.</p>
</section>
<section id="sapling-spend-description-spenddescriptionv5"><h3><span class="section-heading">Sapling Spend Description (<code>SpendDescriptionV5</code>)</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-spend-description-spenddescriptionv5"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="sapling-spend-description-spenddescriptionv5"><h3><span class="section-heading">Sapling Spend Description (<code>SpendDescriptionV5</code>)</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-spend-description-spenddescriptionv5"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<table>
<thead>
<tr>
@ -310,7 +310,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
</table>
<p>The encodings of each of these elements are defined in §7.3 ‘Spend Description Encoding and Consensus’ of the Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol-spenddesc">3</a>.</p>
</section>
<section id="sapling-output-description-outputdescriptionv5"><h3><span class="section-heading">Sapling Output Description (<code>OutputDescriptionV5</code>)</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-output-description-outputdescriptionv5"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="sapling-output-description-outputdescriptionv5"><h3><span class="section-heading">Sapling Output Description (<code>OutputDescriptionV5</code>)</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-output-description-outputdescriptionv5"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<table>
<thead>
<tr>
@ -355,7 +355,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
</table>
<p>The encodings of each of these elements are defined in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-outputdesc">4</a>.</p>
</section>
<section id="orchard-action-description-orchardaction"><h3><span class="section-heading">Orchard Action Description (<code>OrchardAction</code>)</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-action-description-orchardaction"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="orchard-action-description-orchardaction"><h3><span class="section-heading">Orchard Action Description (<code>OrchardAction</code>)</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-action-description-orchardaction"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<table>
<thead>
<tr>
@ -413,7 +413,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
<p>The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ of the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#protocol-actiondesc">5</a>.</p>
</section>
</section>
<section id="alternatives"><h2><span class="section-heading">Alternatives</span><span class="section-anchor"> <a rel="bookmark" href="#alternatives"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="alternatives"><h2><span class="section-heading">Alternatives</span><span class="section-anchor"> <a rel="bookmark" href="#alternatives"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The original version of ZIP-225 included Sprout-related fields <code>nJoinSplit</code>, <code>vJoinSplit</code>, <code>joinSplitPubKey</code>, and <code>joinSplitSig</code> in the V5 transaction format. The Electric Coin Company and Zcash Foundation teams have elected to remove these fields from the V5 transaction format as part of the continuing process of deprecation of the Sprout shielded pool. As a consequence of these fields being removed:</p>
<ul>
<li>This effectively prohibits migration transactions that would directly move funds from the Sprout pool to the Orchard pool. Sprout -&gt; Transparent and Sprout -&gt; Sapling migration transactions will still be supported when using the V4 transaction format.</li>
@ -462,13 +462,13 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
.</li>
</ul>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li><a href="https://github.com/zcash/zcash/pull/5202">https://github.com/zcash/zcash/pull/5202</a> (in <cite>zcashd</cite>)</li>
<li><a href="https://github.com/zcash/librustzcash/pull/375">https://github.com/zcash/librustzcash/pull/375</a> (in <cite>librustzcash</cite>)</li>
</ul>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

16
zip-0239.html
View File

@ -16,7 +16,7 @@ Created: 2021-05-29
License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/515">https://github.com/zcash/zips/issues/515</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/516">https://github.com/zcash/zips/pull/516</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", 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 "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 terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
@ -24,10 +24,10 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/516">https://githu
<p>The term "authorizing data commitment" (denoted <code>auth_digest</code>), defined only for v5 and later transactions, is to be interpreted as described in <a id="id5" class="footnote_reference" href="#zip-0244">6</a>.</p>
<p>The term "witnessed transaction identifier" ("wtxid"), defined only for v5 and later transactions, is a 64-byte value given by concatenating the txid and the authorizing data commitment of the transaction.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP describes changes to the Zcash peer-to-peer protocol to support transaction relay based on a transaction's authorizing data commitment as well as its txid.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Historically, as in Bitcoin, the <code>inv</code> and <code>getdata</code> messages sent on the Zcash peer-to-peer network to announce or request transactions have referred to those transactions by txid.</p>
<p>Prior to the introduction of v5 transactions <a id="id6" class="footnote_reference" href="#zip-0225">5</a> in the NU5 network upgrade <a id="id7" class="footnote_reference" href="#zip-0252">7</a>, a txid was always defined as the SHA-256d hash of the transaction data, the encoding of which is the same in block data and in the peer-to-peer protocol.</p>
<p>For v5 transactions, a new transaction digest algorithm is defined that constructs the txid from a tree of hashes, which include only effecting data <a id="id8" class="footnote_reference" href="#zip-0244">6</a>. Witness data is committed to by a separate "authorizing data commitment". Unlike previous transaction versions, the format of serialized v5 transaction data is not consensus-critical.</p>
@ -36,13 +36,13 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/516">https://githu
<p>This ZIP is modelled after BIP 339: it adds a <code>MSG_WTX</code> inv type to the peer-to-peer protocol, analogous to BIP 339's <code>MSG_WTX</code> inv type, that announces transactions by their wtxid. Note that the encoding and length of a Zcash wtxid is different to that of a Bitcoin wtxid.</p>
<p>This ZIP does not introduce any equivalent of BIP 339's <code>wtxidrelay</code> message, since that is not needed for compatibility given that Zcash full nodes are required to support <code>MSG_WTX</code> based on the negotiated peer protocol version (see <a href="#deployment">Deployment</a>).</p>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>A new inv type <code>MSG_WTX</code> (0x00000005) is added, for use in both <code>inv</code> messages and <code>getdata</code> requests, indicating that the hash being referenced is the wtxid (i.e. the 64-byte value <code>txid</code> || <code>auth_digest</code>). This inv type MUST be used when announcing v5 transactions. The <code>txid</code> and <code>auth_digest</code> are as defined in <a id="id11" class="footnote_reference" href="#zip-0244">6</a>.</p>
<p>In the case of <code>getdata</code> requests, the format of a v5 transaction obtained by a <code>MSG_WTX</code> inv type is as given in the Zcash protocol specification. <a id="id12" class="footnote_reference" href="#protocol-txnencoding">3</a></p>
<p>An <code>inv</code> or <code>getdata</code> message MUST NOT use the <code>MSG_WTX</code> inv type for v4 or earlier transactions, or on peer connections that have not negotiated at least the peer protocol version specified in <a href="#deployment">Deployment</a>.</p>
<p>Note that <code>MSG_WTX</code> might also be used for future transaction versions after v5. Since such versions are not currently consensus-valid, this is left unspecified for now.</p>
<p><code>MSG_TX</code> and <code>MSG_WTX</code> entries may be mixed in arbitrary order in an <code>inv</code> message or a <code>getdata</code> message. Since these entry types are of different lengths (36 bytes or 68 bytes respectively including the 4-byte type field), this implies that the size of the message is not determined by its initial <code>count</code> field, and has to be determined by parsing the whole message.</p>
<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>
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>This ZIP is assumed to be deployed in advance of the network upgrade that introduces v5 transactions, i.e. NU5.</p>
<p>The peer protocol version that enables support for this specification is defined to be 170014 (on both Testnet and Mainnet). This is in advance of the minimum protocol version that signals support for NU5 on Testnet, which is 170015. <a id="id13" class="footnote_reference" href="#zip-0252">7</a></p>
<p>As specified in <a id="id14" class="footnote_reference" href="#zip-0200">4</a>, a node that supports a network upgrade will clear its mempool when reaching the block before that upgrade's activation block. Before this point, the node will not accept transactions into its mempool that are invalid according to the pre-upgrade consensus protocol (so, in this case, it would not accept v5 transactions). This means that a correctly functioning node will not use the <code>MSG_WTX</code> inv type until it has received the block preceding the NU5 network upgrade.</p>
@ -50,14 +50,14 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/516">https://githu
<p>As the <code>MSG_WTX</code> inv type is only enabled between peers that both support it, older clients remain fully compatible and interoperable before NU5 activates, or on a chain in which it does not activate.</p>
</section>
</section>
<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="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>A previous draft of this ZIP left as an open question whether to redefine <code>inv</code> and <code>getdata</code> to segregate <code>MSG_TX</code> and <code>MSG_WTX</code>. This could potentially have made these messages simpler or more efficient to parse, by avoiding variable-length entries in the message data. (See <a id="id15" class="footnote_reference" href="#p2p-inv">10</a> and <a id="id16" class="footnote_reference" href="#p2p-getdata">11</a> for how <code>inv</code> and <code>getdata</code> respectively are currently defined in Bitcoin.)</p>
<p>This option was rejected because the current specification is simple enough.</p>
</section>
<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>
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP is partly based on BIP 339, written by Suhas Daftuar. <a id="id17" class="footnote_reference" href="#bip-0339">9</a></p>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

36
zip-0243.html
View File

File diff suppressed because one or more lines are too long

88
zip-0244.html
View File

@ -17,21 +17,21 @@ Category: Consensus
Created: 2021-01-06
License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/411">https://github.com/zcash/zips/issues/411</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 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">3</a></p>
<p>The term "field encoding" refers to the binary serialized form of a Zcash transaction field, as specified in section 7.1 of the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol-txnencoding">2</a>.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a new transaction digest algorithm for the NU5 network upgrade onward, in order to introduce non-malleable transaction identifiers that commit to all transaction data except for attestations to transaction validity.</p>
<p>This proposal also defines a new transaction digest algorithm for signature validation, which shares all available structure produced during the construction of transaction identifiers, in order to minimize redundant data hashing in validation.</p>
<p>This proposal also defines a new name and semantics for the <code>hashLightClientRoot</code> field of the block header, to enable additional commitments to be represented in this hash and to provide a mechanism for future extensibility of the set of commitments represented.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>In all cases, but particularly in order to support the use of transactions in higher-level protocols, any modification of the transaction that has not been explicitly permitted (such as via anyone-can-spend inputs) should invalidate attestations to spend authority or to the included outputs. Following the activation of this proposed change, transaction identifiers will be stable irrespective of any possible malleation of "witness data" such as proofs and transaction signatures.</p>
<p>In addition, by specifying a transaction identifier and signature algorithm that is decoupled from the serialized format of the transaction as a whole, this change makes it so that the wire format of transactions is no longer consensus-critical.</p>
</section>
<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>
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>Continue to support existing functionality of the protocol (multisig, signing modes for transparent inputs).</li>
<li>Allow the use of transaction ids, and pairs of the form (transaction id, output index) as stable identifiers.</li>
@ -42,15 +42,15 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/411">https://g
<li>It should be possible to use the transaction id unmodified as the value that is used to produce a signature hash in the case that the transaction contains no transparent inputs.</li>
</ul>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>In order to support backwards-compatibility with parts of the ecosystem that have not yet upgraded to the non-malleable transaction format, it is not an initial requirement that all transactions be non-malleable.</p>
<p>It is not required that legacy (Sapling V4 and earlier) transaction formats support construction of non-malleable transaction identifiers, even though they may continue to be accepted by the network after the NU5 upgrade.</p>
</section>
<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="digests"><h3><span class="section-heading">Digests</span><span class="section-anchor"> <a rel="bookmark" href="#digests"><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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="digests"><h3><span class="section-heading">Digests</span><span class="section-anchor"> <a rel="bookmark" href="#digests"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>All digests are personalized BLAKE2b-256 hashes. In cases where no elements are available for hashing (for example, if there are no transparent transaction inputs or no Orchard actions), a personalized hash of the empty byte array will be used. The personalization string therefore provides domain separation for the hashes of even empty data fields.</p>
<p>The notation <code>BLAKE2b-256(personalization_string, [])</code> is used to refer to hashes constructed in this manner.</p>
<section id="txid-digest"><h4><span class="section-heading">TxId Digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="txid-digest"><h4><span class="section-heading">TxId Digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A new transaction digest algorithm is defined that constructs the identifier for a transaction from a tree of hashes. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:</p>
<pre>txid_digest
├── header_digest
@ -75,7 +75,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/411">https://g
   ├── valueBalanceOrchard
   └── anchorOrchard</pre>
<p>Each node written as <code>snake_case</code> in this tree is a BLAKE2b-256 hash of its children, initialized with a personalization string specific to that branch of the tree. Nodes that are not themselves digests are written in <code>camelCase</code>. In the specification below, nodes of the tree are presented in depth-first order.</p>
<section id="id4"><h5><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id4"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<section id="id4"><h5><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id4"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>T.1: header_digest (32-byte hash output)
T.2: transparent_digest (32-byte hash output)
@ -86,7 +86,7 @@ T.4: orchard_digest (32-byte hash output)</pre>
<p><code>ZcashTxHash_</code> has 1 underscore character.</p>
<p>As in ZIP 143 <a id="id5" class="footnote_reference" href="#zip-0143">6</a>, CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. Domain separation of the transaction id hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will not have the same transaction identifier on other consensus branches.</p>
<p>This signature hash personalization prefix has been changed to reflect the new role of this hash (relative to <code>ZcashSigHash</code> as specified in ZIP 143) as a transaction identifier rather than a commitment that is exclusively used for signature purposes. The previous computation of the transaction identifier was a SHA256d hash of the serialized transaction contents, and was not personalized.</p>
<section id="t-1-header-digest"><h6><span class="section-heading">T.1: header_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-1-header-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="t-1-header-digest"><h6><span class="section-heading">T.1: header_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-1-header-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>T.1a: version (4-byte little-endian version identifier including overwinter flag)
T.1b: version_group_id (4-byte little-endian version group identifier)
@ -96,7 +96,7 @@ T.1e: expiry_height (4-byte little-endian block height)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdHeadersHash"</pre>
</section>
<section id="t-2-transparent-digest"><h6><span class="section-heading">T.2: transparent_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-2-transparent-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="t-2-transparent-digest"><h6><span class="section-heading">T.2: transparent_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-2-transparent-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>In the case that transparent inputs or outputs are present, the transparent digest consists of a BLAKE2b-256 hash of the following values</p>
<pre>T.2a: prevouts_digest (32-byte hash)
T.2b: sequence_digest (32-byte hash)
@ -105,21 +105,21 @@ T.2c: outputs_digest (32-byte hash)</pre>
<pre>"ZTxIdTranspaHash"</pre>
<p>In the case that the transaction has no transparent components, <code>transparent_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdTranspaHash", [])</pre>
<section id="t-2a-prevouts-digest"><h7><span class="section-heading">T.2a: prevouts_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-2a-prevouts-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<section id="t-2a-prevouts-digest"><h7><span class="section-heading">T.2a: prevouts_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-2a-prevouts-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>A BLAKE2b-256 hash of the field encoding of all <code>outpoint</code> field values of transparent inputs to the transaction.</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdPrevoutHash"</pre>
<p>In the case that the transaction has transparent outputs but no transparent inputs, <code>prevouts_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdPrevoutHash", [])</pre>
</section>
<section id="t-2b-sequence-digest"><h7><span class="section-heading">T.2b: sequence_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-2b-sequence-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<section id="t-2b-sequence-digest"><h7><span class="section-heading">T.2b: sequence_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-2b-sequence-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>A BLAKE2b-256 hash of the 32-bit little-endian representation of all <code>nSequence</code> field values of transparent inputs to the transaction.</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdSequencHash"</pre>
<p>In the case that the transaction has transparent outputs but no transparent inputs, <code>sequence_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdSequencHash", [])</pre>
</section>
<section id="t-2c-outputs-digest"><h7><span class="section-heading">T.2c: outputs_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-2c-outputs-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<section id="t-2c-outputs-digest"><h7><span class="section-heading">T.2c: outputs_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-2c-outputs-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>A BLAKE2b-256 hash of the concatenated field encodings of all transparent output values of the transaction. The field encoding of such an output consists of the encoded output <code>amount</code> (8-byte little endian) followed by the <code>scriptPubKey</code> byte array (serialized as Bitcoin script).</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdOutputsHash"</pre>
@ -127,7 +127,7 @@ T.2c: outputs_digest (32-byte hash)</pre>
<pre>BLAKE2b-256("ZTxIdOutputsHash", [])</pre>
</section>
</section>
<section id="t-3-sapling-digest"><h6><span class="section-heading">T.3: sapling_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3-sapling-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="t-3-sapling-digest"><h6><span class="section-heading">T.3: sapling_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3-sapling-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>In the case that Sapling spends or outputs are present, the digest of Sapling components is composed of two subtrees which are organized to permit easy interoperability with the <code>CompactBlock</code> representation of Sapling data specified by the ZIP 307 Light Client Protocol <a id="id6" class="footnote_reference" href="#zip-0307">8</a>.</p>
<p>This digest is a BLAKE2b-256 hash of the following values</p>
<pre>T.3a: sapling_spends_digest (32-byte hash)
@ -137,7 +137,7 @@ T.3c: valueBalance (64-bit signed little-endian)</pre>
<pre>"ZTxIdSaplingHash"</pre>
<p>In the case that the transaction has no Sapling spends or outputs, <code>sapling_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdSaplingHash", [])</pre>
<section id="t-3a-sapling-spends-digest"><h7><span class="section-heading">T.3a: sapling_spends_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3a-sapling-spends-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<section id="t-3a-sapling-spends-digest"><h7><span class="section-heading">T.3a: sapling_spends_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3a-sapling-spends-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>In the case that Sapling spends are present, this digest is a BLAKE2b-256 hash of the following values</p>
<pre>T.3a.i: sapling_spends_compact_digest (32-byte hash)
T.3a.ii: sapling_spends_noncompact_digest (32-byte hash)</pre>
@ -145,12 +145,12 @@ T.3a.ii: sapling_spends_noncompact_digest (32-byte hash)</pre>
<pre>"ZTxIdSSpendsHash"</pre>
<p>In the case that the transaction has Sapling outputs but no Sapling spends, <code>sapling_spends_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdSSpendsHash", [])</pre>
<section id="t-3a-i-sapling-spends-compact-digest"><h8><span class="section-heading">T.3a.i: sapling_spends_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3a-i-sapling-spends-compact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<section id="t-3a-i-sapling-spends-compact-digest"><h8><span class="section-heading">T.3a.i: sapling_spends_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3a-i-sapling-spends-compact-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<p>A BLAKE2b-256 hash of the field encoding of all <code>nullifier</code> field values of Sapling shielded spends belonging to the transaction.</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdSSpendCHash"</pre>
</section>
<section id="t-3a-ii-sapling-spends-noncompact-digest"><h8><span class="section-heading">T.3a.ii: sapling_spends_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3a-ii-sapling-spends-noncompact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<section id="t-3a-ii-sapling-spends-noncompact-digest"><h8><span class="section-heading">T.3a.ii: sapling_spends_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3a-ii-sapling-spends-noncompact-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<p>A BLAKE2b-256 hash of the non-nullifier information for all Sapling shielded spends belonging to the transaction, excluding both zkproof data and spend authorization signature(s). For each spend, the following elements are included in the hash:</p>
<pre>T.3a.ii.1: cv (field encoding bytes)
T.3a.ii.2: anchor (field encoding bytes)
@ -160,7 +160,7 @@ T.3a.ii.3: rk (field encoding bytes)</pre>
<pre>"ZTxIdSSpendNHash"</pre>
</section>
</section>
<section id="t-3b-sapling-outputs-digest"><h7><span class="section-heading">T.3b: sapling_outputs_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-sapling-outputs-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<section id="t-3b-sapling-outputs-digest"><h7><span class="section-heading">T.3b: sapling_outputs_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-sapling-outputs-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>In the case that Sapling outputs are present, this digest is a BLAKE2b-256 hash of the following values</p>
<pre>T.3b.i: sapling_outputs_compact_digest (32-byte hash)
T.3b.ii: sapling_outputs_memos_digest (32-byte hash)
@ -169,7 +169,7 @@ T.3b.iii: sapling_outputs_noncompact_digest (32-byte hash)</pre>
<pre>"ZTxIdSOutputHash"</pre>
<p>In the case that the transaction has Sapling spends but no Sapling outputs, <code>sapling_outputs_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdSOutputHash", [])</pre>
<section id="t-3b-i-sapling-outputs-compact-digest"><h8><span class="section-heading">T.3b.i: sapling_outputs_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-i-sapling-outputs-compact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<section id="t-3b-i-sapling-outputs-compact-digest"><h8><span class="section-heading">T.3b.i: sapling_outputs_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-i-sapling-outputs-compact-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<p>A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP-307 <a id="id7" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
<pre>T.3b.i.1: cmu (field encoding bytes)
T.3b.i.2: ephemeral_key (field encoding bytes)
@ -177,13 +177,13 @@ T.3b.i.3: enc_ciphertext[..52] (First 52 bytes of field encoding)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdSOutC__Hash" (2 underscore characters)</pre>
</section>
<section id="t-3b-ii-sapling-outputs-memos-digest"><h8><span class="section-heading">T.3b.ii: sapling_outputs_memos_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-ii-sapling-outputs-memos-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<section id="t-3b-ii-sapling-outputs-memos-digest"><h8><span class="section-heading">T.3b.ii: sapling_outputs_memos_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-ii-sapling-outputs-memos-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<p>A BLAKE2b-256 hash of the subset of Sapling shielded memo field data for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
<pre>T.3b.ii.1: enc_ciphertext[52..564] (contents of the encrypted memo field)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdSOutM__Hash" (2 underscore characters)</pre>
</section>
<section id="t-3b-iii-sapling-outputs-noncompact-digest"><h8><span class="section-heading">T.3b.iii: sapling_outputs_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-iii-sapling-outputs-noncompact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<section id="t-3b-iii-sapling-outputs-noncompact-digest"><h8><span class="section-heading">T.3b.iii: sapling_outputs_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-iii-sapling-outputs-noncompact-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<p>A BLAKE2b-256 hash of the remaining subset of Sapling output information <strong>not</strong> included in the ZIP 307 <a id="id8" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format, excluding zkproof data, for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
<pre>T.3b.iii.1: cv (field encoding bytes)
T.3b.iii.2: enc_ciphertext[564..] (post-memo Poly1305 AEAD tag of field encoding)
@ -193,7 +193,7 @@ T.3b.iii.3: out_ciphertext (field encoding bytes)</pre>
</section>
</section>
</section>
<section id="t-4-orchard-digest"><h6><span class="section-heading">T.4: orchard_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4-orchard-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="t-4-orchard-digest"><h6><span class="section-heading">T.4: orchard_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4-orchard-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>In the case that Orchard actions are present in the transaction, this digest is a BLAKE2b-256 hash of the following values</p>
<pre>T.4a: orchard_actions_compact_digest (32-byte hash output)
T.4b: orchard_actions_memos_digest (32-byte hash output)
@ -205,7 +205,7 @@ T.4f: anchorOrchard (32 bytes)</pre>
<pre>"ZTxIdOrchardHash"</pre>
<p>In the case that the transaction has no Orchard actions, <code>orchard_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdOrchardHash", [])</pre>
<section id="t-4a-orchard-actions-compact-digest"><h7><span class="section-heading">T.4a: orchard_actions_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4a-orchard-actions-compact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<section id="t-4a-orchard-actions-compact-digest"><h7><span class="section-heading">T.4a: orchard_actions_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4a-orchard-actions-compact-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 <a id="id9" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4a.i : nullifier (field encoding bytes)
T.4a.ii : cmx (field encoding bytes)
@ -214,13 +214,13 @@ T.4a.iv : encCiphertext[..52] (First 52 bytes of field encoding)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdOrcActCHash"</pre>
</section>
<section id="t-4b-orchard-actions-memos-digest"><h7><span class="section-heading">T.4b: orchard_actions_memos_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4b-orchard-actions-memos-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<section id="t-4b-orchard-actions-memos-digest"><h7><span class="section-heading">T.4b: orchard_actions_memos_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4b-orchard-actions-memos-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>A BLAKE2b-256 hash of the subset of Orchard shielded memo field data for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4b.i: encCiphertext[52..564] (contents of the encrypted memo field)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdOrcActMHash"</pre>
</section>
<section id="t-4c-orchard-actions-noncompact-digest"><h7><span class="section-heading">T.4c: orchard_actions_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4c-orchard-actions-noncompact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<section id="t-4c-orchard-actions-noncompact-digest"><h7><span class="section-heading">T.4c: orchard_actions_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4c-orchard-actions-noncompact-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>A BLAKE2b-256 hash of the remaining subset of Orchard Action information <strong>not</strong> intended for inclusion in an updated version of the the ZIP 307 <a id="id10" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4c.i : cv (field encoding bytes)
T.4c.ii : rk (field encoding bytes)
@ -232,7 +232,7 @@ T.4c.iv : outCiphertext (field encoding bytes)</pre>
</section>
</section>
</section>
<section id="signature-digest"><h4><span class="section-heading">Signature Digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="signature-digest"><h4><span class="section-heading">Signature Digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A new per-input transaction digest algorithm is defined that constructs a hash that may be signed by a transaction creator to commit to the effects of the transaction. A signature digest is produced for each transparent input, each Sapling input, and each Orchard action. For transparent inputs, this follows closely the algorithms from ZIP 143 <a id="id11" class="footnote_reference" href="#zip-0143">6</a> and ZIP 243 <a id="id12" class="footnote_reference" href="#zip-0243">7</a>. For shielded inputs, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.</p>
<p>The overall structure of the hash is as follows; each name referenced here will be described in detail below:</p>
<pre>signature_digest
@ -240,7 +240,7 @@ T.4c.iv : outCiphertext (field encoding bytes)</pre>
├── transparent_sig_digest
├── sapling_digest
└── orchard_digest</pre>
<section id="id13"><h5><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id13"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<section id="id13"><h5><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id13"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>S.1: header_digest (32-byte hash output)
S.2: transparent_sig_digest (32-byte hash output)
@ -250,10 +250,10 @@ S.4: orchard_digest (32-byte hash output)</pre>
<pre>"ZcashTxHash_" || CONSENSUS_BRANCH_ID</pre>
<p><code>ZcashTxHash_</code> has 1 underscore character.</p>
<p>This value has the same personalization as the top hash of the transaction identifier digest tree, so that what is being signed in the case that there are no transparent inputs is just the transaction id.</p>
<section id="s-1-header-digest"><h6><span class="section-heading">S.1: header_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-1-header-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="s-1-header-digest"><h6><span class="section-heading">S.1: header_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-1-header-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>Identical to that specified for the transaction identifier.</p>
</section>
<section id="s-2-transparent-sig-digest"><h6><span class="section-heading">S.2: transparent_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2-transparent-sig-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="s-2-transparent-sig-digest"><h6><span class="section-heading">S.2: transparent_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2-transparent-sig-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, the value of <code>transparent_sig_digest</code> is identical to the value specified in section <a href="#t-2-transparent-digest">T.2</a>.</p>
<p>If we are producing a hash for signature over a transparent input, the value of <code>transparent_sig_digest</code> depends upon the value of a <code>hash_type</code> flag as in ZIP 143 <a id="id14" class="footnote_reference" href="#zip-0143">6</a>.</p>
<p>The construction of each component below depends upon the values of the <code>hash_type</code> flag bits. Each component will be described separately</p>
@ -264,7 +264,7 @@ S.2c: outputs_sig_digest (32-byte hash)
S.2d: txin_sig_digest (32-byte hash)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdTranspaHash"</pre>
<section id="s-2a-prevouts-sig-digest"><h7><span class="section-heading">S.2a: prevouts_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2a-prevouts-sig-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<section id="s-2a-prevouts-sig-digest"><h7><span class="section-heading">S.2a: prevouts_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2a-prevouts-sig-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>This is a BLAKE2b-256 hash initialized with the personalization field value <code>ZTxIdPrevoutHash</code>.</p>
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is not set:</p>
<pre>identical to the value of ``prevouts_digest`` as specified for the
@ -272,7 +272,7 @@ transaction identifier in section T.2a.</pre>
<p>otherwise:</p>
<pre>BLAKE2b-256(``ZTxIdPrevoutHash``, [])</pre>
</section>
<section id="s-2b-sequence-sig-digest"><h7><span class="section-heading">S.2b: sequence_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2b-sequence-sig-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<section id="s-2b-sequence-sig-digest"><h7><span class="section-heading">S.2b: sequence_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2b-sequence-sig-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>This is a BLAKE2b-256 hash initialized with the personalization field value <code>ZTxIdSequencHash</code>.</p>
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is not set, and the sighash type is neither <code>SIGHASH_SINGLE</code> nor <code>SIGHASH_NONE</code>:</p>
<pre>identical to the value of ``sequence_digest`` as specified for the
@ -280,7 +280,7 @@ transaction identifier in section T.2b.</pre>
<p>otherwise:</p>
<pre>BLAKE2b-256(``ZTxIdSequencHash``, [])</pre>
</section>
<section id="s-2c-outputs-sig-digest"><h7><span class="section-heading">S.2c: outputs_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2c-outputs-sig-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<section id="s-2c-outputs-sig-digest"><h7><span class="section-heading">S.2c: outputs_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2c-outputs-sig-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>This is a BLAKE2b-256 hash initialized with the personalization field value <code>ZTxIdOutputsHash</code>.</p>
<p>If the sighash type is neither <code>SIGHASH_SINGLE</code> nor <code>SIGHASH_NONE</code>:</p>
<pre>identical to the value of ``outputs_digest`` as specified for the
@ -291,7 +291,7 @@ index</pre>
<p>otherwise:</p>
<pre>BLAKE2b-256(``ZTxIdOutputsHash``, [])</pre>
</section>
<section id="s-2d-txin-sig-digest"><h7><span class="section-heading">S.2d: txin_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2d-txin-sig-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<section id="s-2d-txin-sig-digest"><h7><span class="section-heading">S.2d: txin_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2d-txin-sig-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>This is a BLAKE2b-256 hash of the following properties of the transparent input being signed, initialized with the personalization field value <code>Zcash___TxInHash</code> (3 underscores):</p>
<pre>S.2d.i: prevout (field encoding)
S.2d.ii: script_code (field encoding)
@ -300,15 +300,15 @@ S.2d.iv: nSequence (4-byte unsigned little-endian)</pre>
<p>Note: <code>value</code> is defined in the consensus rules to be a nonnegative value &lt;= <code>MAX_MONEY</code>, but all existing implementations parse this value as signed and enforce the nonnegative constraint as a consensus check. It is defined as signed here for consistency with those existing implementations.</p>
</section>
</section>
<section id="s-3-sapling-digest"><h6><span class="section-heading">S.3: sapling_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-3-sapling-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="s-3-sapling-digest"><h6><span class="section-heading">S.3: sapling_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-3-sapling-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>Identical to that specified for the transaction identifier.</p>
</section>
<section id="s-4-orchard-digest"><h6><span class="section-heading">S.4: orchard_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-4-orchard-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="s-4-orchard-digest"><h6><span class="section-heading">S.4: orchard_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-4-orchard-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>Identical to that specified for the transaction identifier.</p>
</section>
</section>
</section>
<section id="authorizing-data-commitment"><h4><span class="section-heading">Authorizing Data Commitment</span><span class="section-anchor"> <a rel="bookmark" href="#authorizing-data-commitment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="authorizing-data-commitment"><h4><span class="section-heading">Authorizing Data Commitment</span><span class="section-anchor"> <a rel="bookmark" href="#authorizing-data-commitment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A new transaction digest algorithm is defined that constructs a digest which commits to the authorizing data of a transaction from a tree of BLAKE2b-256 hashes. For v5 transactions, the overall structure of the hash is as follows:</p>
<pre>auth_digest
├── transparent_scripts_digest
@ -317,7 +317,7 @@ S.2d.iv: nSequence (4-byte unsigned little-endian)</pre>
<p>Each node written as <code>snake_case</code> in this tree is a BLAKE2b-256 hash of authorizing data of the transaction.</p>
<p>For transaction versions before v5, a placeholder value consisting of 32 bytes of <code>0xFF</code> is used in place of the authorizing data commitment. This is only used in the tree committed to by <code>hashAuthDataRoot</code>, as defined in <a href="#block-header-changes">Block Header Changes</a>.</p>
<p>The pair (Transaction Identifier, Auth Commitment) constitutes a commitment to all the data of a serialized transaction that may be included in a block.</p>
<section id="auth-digest"><h5><span class="section-heading">auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#auth-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<section id="auth-digest"><h5><span class="section-heading">auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#auth-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>A.1: transparent_scripts_digest (32-byte hash output)
A.2: sapling_auth_digest (32-byte hash output)
@ -325,14 +325,14 @@ A.3: orchard_auth_digest (32-byte hash output)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxAuthHash_" || CONSENSUS_BRANCH_ID</pre>
<p><code>ZTxAuthHash_</code> has 1 underscore character.</p>
<section id="a-1-transparent-scripts-digest"><h6><span class="section-heading">A.1: transparent_scripts_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-1-transparent-scripts-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="a-1-transparent-scripts-digest"><h6><span class="section-heading">A.1: transparent_scripts_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-1-transparent-scripts-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>In the case that the transaction contains transparent inputs, this is a BLAKE2b-256 hash of the field encoding of the concatenated values of the Bitcoin script values associated with each transparent input belonging to the transaction.</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxAuthTransHash"</pre>
<p>In the case that the transaction has no transparent inputs, <code>transparent_scripts_digest</code> is</p>
<pre>BLAKE2b-256("ZTxAuthTransHash", [])</pre>
</section>
<section id="a-2-sapling-auth-digest"><h6><span class="section-heading">A.2: sapling_auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-2-sapling-auth-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="a-2-sapling-auth-digest"><h6><span class="section-heading">A.2: sapling_auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-2-sapling-auth-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>In the case that Sapling Spends or Sapling Outputs are present, this is a BLAKE2b-256 hash of the field encoding of the Sapling <code>zkproof</code> value of each Sapling Spend Description, followed by the field encoding of the <code>spend_auth_sig</code> value of each Sapling Spend Description belonging to the transaction, followed by the field encoding of the <code>zkproof</code> field of each Sapling Output Description belonging to the transaction, followed by the field encoding of the binding signature:</p>
<pre>A.2a: spend_zkproofs (field encoding bytes)
A.2b: spend_auth_sigs (field encoding bytes)
@ -343,7 +343,7 @@ A.2d: binding_sig (field encoding bytes)</pre>
<p>In the case that the transaction has no Sapling Spends or Sapling Outputs, <code>sapling_auth_digest</code> is</p>
<pre>BLAKE2b-256("ZTxAuthSapliHash", [])</pre>
</section>
<section id="a-3-orchard-auth-digest"><h6><span class="section-heading">A.3: orchard_auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-3-orchard-auth-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="a-3-orchard-auth-digest"><h6><span class="section-heading">A.3: orchard_auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-3-orchard-auth-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>In the case that Orchard Actions are present, this is a BLAKE2b-256 hash of the field encoding of the <code>zkProofsOrchard</code>, <code>spendAuthSigsOrchard</code>, and <code>bindingSigOrchard</code> fields of the transaction:</p>
<pre>A.3a: proofsOrchard (field encoding bytes)
A.3b: vSpendAuthSigsOrchard (field encoding bytes)
@ -356,7 +356,7 @@ A.3c: bindingSigOrchard (field encoding bytes)</pre>
</section>
</section>
</section>
<section id="block-header-changes"><h3><span class="section-heading">Block Header Changes</span><span class="section-anchor"> <a rel="bookmark" href="#block-header-changes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="block-header-changes"><h3><span class="section-heading">Block Header Changes</span><span class="section-anchor"> <a rel="bookmark" href="#block-header-changes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The nonmalleable transaction identifier specified by this ZIP will be used in the place of the current malleable transaction identifier within the Merkle tree committed to by the <code>hashMerkleRoot</code> value. However, this change now means that <code>hashMerkleRoot</code> is not sufficient to fully commit to the transaction data, including witnesses, that appear within the block.</p>
<p>As a consequence, we now need to add a new commitment to the block header. This commitment will be the root of a Merkle tree having leaves that are transaction authorizing data commitments, produced according to the <a href="#authorizing-data-commitment">Authorizing Data Commitment</a> part of this specification. The insertion order for this Merkle tree MUST be identical to the insertion order of transaction identifiers into the Merkle tree that is used to construct <code>hashMerkleRoot</code>, such that a path through this Merkle tree to a transaction identifies the same transaction as that path reaches in the tree rooted at <code>hashMerkleRoot</code>.</p>
<p>This new commitment is named <code>hashAuthDataRoot</code> and is the root of a binary Merkle tree of transaction authorizing data commitments having height
@ -377,12 +377,12 @@ terminator [0u8;32]</pre>
<p>The block header byte format and version are not altered by this ZIP.</p>
</section>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li><a href="https://github.com/zcash/librustzcash/pull/319/files">https://github.com/zcash/librustzcash/pull/319/files</a></li>
</ul>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

32
zip-0245.html
View File

@ -14,15 +14,15 @@ Category: Consensus
Created: 2021-01-13
License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/384">https://github.com/zcash/zips/issues/384</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 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">2</a></p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines changes to ZIP 244 <a id="id3" class="footnote_reference" href="#zip-0244">4</a> transaction id and signature digest algorithms to accommodate the inclusion of transparent Zcash extensions (TZEs) as defined in ZIP 222 <a id="id4" class="footnote_reference" href="#zip-0222">3</a>.</p>
</section>
<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="txid-digest"><h3><span class="section-heading">TxId Digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest"><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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="txid-digest"><h3><span class="section-heading">TxId Digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The tree of hashes defined by ZIP 244 <a id="id5" class="footnote_reference" href="#zip-0244">4</a> is re-structured to include a new branch for TZE hashes. The <code>tze_digest</code> branch is the only new addition to the tree; <code>header_digest</code>, <code>transparent_digest</code>, <code>sprout_digest</code>, and <code>sapling_digest</code> are as in ZIP 244:</p>
<pre>txid_digest
├── header_digest
@ -32,7 +32,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/384">https://g
│   └── tzeout_digest
├── sprout_digest
└── sapling_digest</pre>
<section id="id6"><h4><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id6"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="id6"><h4><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id6"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The top hash of the <code>txid_digest</code> tree is modified from the ZIP 244 structure to be a BLAKE2b-256 hash of the following values</p>
<pre>T.1: header_digest (32-byte hash output)
T.2: transparent_digest (32-byte hash output)
@ -40,20 +40,20 @@ T.3: tze_digest (32-byte hash output)
T.4: sprout_digest (32-byte hash output)
T.5: sapling_digest (32-byte hash output)</pre>
<p>The personalization field of this hash is unmodified from ZIP 244.</p>
<section id="tze-digest"><h5><span class="section-heading">2: <code>tze_digest</code></span><span class="section-anchor"> <a rel="bookmark" href="#tze-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<section id="tze-digest"><h5><span class="section-heading">2: <code>tze_digest</code></span><span class="section-anchor"> <a rel="bookmark" href="#tze-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>T.2a: tzein_digest (32-byte hash)
T.2b: tzeout_digest (32-byte hash)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdTZE____Hash" (4 underscore characters)</pre>
<section id="a-tzein-digest"><h6><span class="section-heading">2a: tzein_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-tzein-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="a-tzein-digest"><h6><span class="section-heading">2a: tzein_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-tzein-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>A BLAKE2b-256 hash of all TZE inputs to the transaction, excluding witness data. For each TZE input, the following values are appended to this hash:</p>
<pre>2a.i: extension_id (CompactSize field encoding)
2a.ii: mode (CompactSize field encoding)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdTZEIns_Hash" (1 underscore character)</pre>
</section>
<section id="a-tzeout-digest"><h6><span class="section-heading">2a: tzeout_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-tzeout-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<section id="a-tzeout-digest"><h6><span class="section-heading">2a: tzeout_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-tzeout-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>A BLAKE2b-256 hash of the field encoding of all TZE outputs belonging to the transaction.</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdTzeOutsHash"</pre>
@ -61,7 +61,7 @@ T.2b: tzeout_digest (32-byte hash)</pre>
</section>
</section>
</section>
<section id="signature-digest"><h3><span class="section-heading">Signature Digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="signature-digest"><h3><span class="section-heading">Signature Digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The signature digest creation algorithm defined by ZIP 244 <a id="id7" class="footnote_reference" href="#zip-0244">4</a> is modified to include a new branch for TZE hashes. The <code>tze_digest</code> branch is the only new addition to the tree; <code>header_digest</code>, <code>transparent_digest</code>, <code>sprout_digest</code>, and <code>sapling_digest</code> are as in ZIP 244:</p>
<pre>signature_digest
├── header_digest
@ -71,7 +71,7 @@ T.2b: tzeout_digest (32-byte hash)</pre>
│   └── tzeout_digest
├── sprout_digest
└── sapling_digest</pre>
<section id="id8"><h4><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id8"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="id8"><h4><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id8"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>S.1: header_digest (32-byte hash output)
S.2: transparent_digest (32-byte hash output)
@ -82,7 +82,7 @@ S.5: sapling_digest (32-byte hash output)</pre>
<pre>"ZcashTxHash_" || CONSENSUS_BRANCH_ID</pre>
<p><code>ZcashTxHash_</code> has 1 underscore character.</p>
<p>This value must have the same personalization as the top hash of the transaction identifier digest tree, in order to make it possible to sign the transaction id in the case that there are no transparent inputs.</p>
<section id="s-3-tze-digest"><h5><span class="section-heading">S.3: tze_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-3-tze-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<section id="s-3-tze-digest"><h5><span class="section-heading">S.3: tze_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-3-tze-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>This digest is a BLAKE2b-256 hash of the following values of the TZE input being signed:</p>
<pre>S.3a: prevout_digest (field encoding bytes)
S.3b: extension_id (CompactSize field encoding)
@ -94,14 +94,14 @@ S.3e: value (8-byte little endian value of the output spent by this inp
</section>
</section>
</section>
<section id="authorizing-data-commitment"><h3><span class="section-heading">Authorizing Data Commitment</span><span class="section-anchor"> <a rel="bookmark" href="#authorizing-data-commitment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="authorizing-data-commitment"><h3><span class="section-heading">Authorizing Data Commitment</span><span class="section-anchor"> <a rel="bookmark" href="#authorizing-data-commitment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The tree of hashes defined by ZIP 244 <a id="id9" class="footnote_reference" href="#zip-0244">4</a> for authorizing data commitments is re-structured to include a new branch for TZE hashes. The <code>tze_witnesses_digest</code> branch is the only new addition to the tree; <code>transparent_auth_digest</code>, <code>sprout_auth_digest</code>, and <code>sapling_auth_digest</code> are as in ZIP 244:</p>
<pre>auth_digest
├── transparent_scripts_digest
├── tze_witnesses_digest
├── sprout_auth_digest
└── sapling_auth_digest</pre>
<section id="auth-digest"><h4><span class="section-heading">auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#auth-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="auth-digest"><h4><span class="section-heading">auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#auth-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The top hash of the <code>auth_digest</code> tree is modified from the ZIP 244 structure to be a BLAKE2b-256 hash of the following values</p>
<pre>A.1: transparent_scripts_digest (32-byte hash output)
A.2: tze_witnesses_digest (32-byte hash output)
@ -109,19 +109,19 @@ A.3: sprout_auth_digest (32-byte hash output)
A.4: sapling_auth_digest (32-byte hash output)</pre>
<p>The personalization field of this hash is unmodified from ZIP 244.</p>
</section>
<section id="tze-witnesses-digest"><h4><span class="section-heading">2: tze_witnesses_digest</span><span class="section-anchor"> <a rel="bookmark" href="#tze-witnesses-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="tze-witnesses-digest"><h4><span class="section-heading">2: tze_witnesses_digest</span><span class="section-anchor"> <a rel="bookmark" href="#tze-witnesses-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A BLAKE2b-256 hash of the field encoding of the witness <code>payload</code> data associated with each TZE input belonging to the transaction.</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxAuthTZE__Hash" (2 underscore characters)</pre>
</section>
</section>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li><a href="https://github.com/zcash/librustzcash/pull/319/files">https://github.com/zcash/librustzcash/pull/319/files</a></li>
</ul>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

14
zip-0250.html
View File

@ -13,7 +13,7 @@ Status: Final
Category: Consensus / Network
Created: 2020-02-28
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 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>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

14
zip-0251.html
View File

@ -13,17 +13,17 @@ Status: Implemented (zcashd)
Category: Consensus / Network
Created: 2020-02-28
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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">5</a></p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
<p>"Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" 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 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>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" 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" class="section-anchor" 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="id4" class="footnote_reference" href="#protocol">2</a></li>
@ -62,15 +62,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 rel="bookmark" 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" class="section-anchor" 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="id15" class="footnote_reference" href="#protocol-txnencoding">4</a>; and use the same transaction digest algorithm as defined in <a id="id16" class="footnote_reference" href="#zip-0243">12</a>. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. <a id="id17" class="footnote_reference" href="#zip-0243">12</a></p>
</section>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

24
zip-0252.html
View File

@ -16,16 +16,16 @@ Created: 2021-02-23
License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://github.com/zcash/zips/issues/440</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/446">https://github.com/zcash/zips/pull/446</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">7</a></p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines the deployment of the NU5 network upgrade.</p>
</section>
<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="nu5-deployment"><h3><span class="section-heading">NU5 deployment</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="nu5-deployment"><h3><span class="section-heading">NU5 deployment</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The primary sources of information about NU5 consensus and peer-to-peer protocol changes are:</p>
<ul>
<li>The Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol">2</a> <a id="id5" class="footnote_reference" href="#protocol-txnencoding">4</a></li>
@ -81,20 +81,20 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/446">https://githu
<p>Note: these peer-to-peer protocol changes are enabled whenever the relevant version (or higher) is negotiated on a given connection, which can happen in advance of the Testnet or Mainnet NU5 activation.</p>
</section>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Prior to the network upgrade activating on each network, NU5 and pre-NU5 nodes are compatible and can connect to each other.</p>
<p>Once the network upgrades, even though pre-NU5 nodes can still accept the numerically larger protocol version used by NU5 as being valid, NU5 nodes will always disconnect peers using lower protocol versions.</p>
<p>Unlike Blossom, Heartwood, and Canopy, and like Overwinter and Sapling, NU5 defines a new transaction version. Therefore, NU5 transactions MAY be in the new v5 format specified by <a id="id27" class="footnote_reference" href="#zip-0225">16</a>. Unlike previous transaction version updates, the existing v4 transaction format remains valid after NU5 activation. Both transaction formats MUST be accepted by NU5 nodes.</p>
<p>Backward compatibility of the new <code>MSG_WTX</code> inv type introduced for <code>inv</code> and <code>getdata</code> messages is discussed in <a id="id28" class="footnote_reference" href="#zip-0239">17</a>.</p>
<p>Backward compatibility of the new <code>addrv2</code> message (not technically part of NU5) is discussed in <a id="id29" class="footnote_reference" href="#zip-0155">6</a>.</p>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Support for NU5 on Testnet is implemented in <cite>zcashd</cite> version 4.5.1, which advertises protocol version 170015. (A previous revision of the NU5 consensus rules was implemented in <cite>zcashd</cite> version 4.5.0, but this revision contained critical bugs in the Orchard Action circuit. Before it could activate, <cite>zcashd</cite> version 4.5.1 was released, with the later NU5 Testnet activation height and consensus branch ID defined in this document.)</p>
<p>Support for NU5 on Mainnet will be implemented in <cite>zcashd</cite> version 5.0.0, which will advertise protocol version 170017.</p>
<section id="backward-compatibility-in-zcashd"><h3><span class="section-heading">Backward compatibility in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="backward-compatibility-in-zcashd"><h3><span class="section-heading">Backward compatibility in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility-in-zcashd"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The minimum peer protocol version that NU5-compatible <cite>zcashd</cite> nodes will connect to is 170002.</p>
</section>
<section id="nu5-deployment-for-zcashd"><h3><span class="section-heading">NU5 deployment for zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-deployment-for-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="nu5-deployment-for-zcashd"><h3><span class="section-heading">NU5 deployment for zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-deployment-for-zcashd"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>For each network, approximately 1.5 days (defined in terms of block height) before the corresponding NU5 activation height, nodes compatible with NU5 activation on that network will change the behaviour of their peer connection logic in order to prefer pre-NU5 peers on that network for eviction from the set of peer connections:</p>
<pre>/**
* The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks).
@ -105,21 +105,21 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<p>However, NU5 nodes will have a preference for connecting to other NU5 nodes, so pre-NU5 nodes will gradually be disconnected in the run up to activation.</p>
</section>
</section>
<section id="support-in-zebra"><h2><span class="section-heading">Support in Zebra</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zebra"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="support-in-zebra"><h2><span class="section-heading">Support in Zebra</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zebra"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Partial support for NU5 on Testnet will be implemented in Zebra version 1.0.0-alpha.18, which will advertise protocol version 170015. This version will validate a strict subset of NU5 consensus rules on Testnet.</p>
<section id="backward-compatibility-in-zebra"><h3><span class="section-heading">Backward compatibility in Zebra</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility-in-zebra"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="backward-compatibility-in-zebra"><h3><span class="section-heading">Backward compatibility in Zebra</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility-in-zebra"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The minimum peer protocol version that NU5-compatible Zebra nodes will connect to is 170002. However, Zebra will immediately disconnect from nodes with a protocol version less than:</p>
<ul>
<li>170012 on Testnet, or</li>
<li>170013 on Mainnet.</li>
</ul>
</section>
<section id="nu5-deployment-for-zebra"><h3><span class="section-heading">NU5 deployment for Zebra</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-deployment-for-zebra"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="nu5-deployment-for-zebra"><h3><span class="section-heading">NU5 deployment for Zebra</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-deployment-for-zebra"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>For each network, at the corresponding NU5 activation height, nodes compatible with NU5 activation on that network will close any new connections with pre-NU5 peers.</p>
<p>Since Zebra maintains a reasonably strict internal request-response protocol, pre-NU5 nodes will gradually be disconnected after activation. (Nodes are temporarily disconnected if they send gossip or chain sync hints outside the strict request-response sequence that Zebra expects.)</p>
</section>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

16
zip-0300.html
View File

@ -15,16 +15,16 @@ Category: Informational
Created: 2017-03-08
License: MIT
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/123">https://github.com/zcash/zips/pull/123</a>&gt;</pre>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This is an Informational ZIP describing a proposed specification for a standardized protocol for performing cross-chain atomic transactions (XCAT) between Zcash and Bitcoin, or other Bitcoin-derived cryptocurrencies.</p>
</section>
<section id="status"><h2><span class="section-heading">Status</span><span class="section-anchor"> <a rel="bookmark" href="#status"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="status"><h2><span class="section-heading">Status</span><span class="section-anchor"> <a rel="bookmark" href="#status"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal only supports transparent cross-chain swaps and relies on the scripting system inherited from Bitcoin. At the time of writing (September 2020), it has not achieved widespread adoption.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>A well-defined standard for performing cross-chain transactions would improve the liquidity of cryptocurrencies and be useful for third-party services, such as decentralized exchanges.</p>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The proposed protocol for XCAT is a set of hash time-locked contracts across both chains, created by two parties who wish to do a cross-chain exchange.</p>
<p>To perform an exchange, both parties need to have the public keys of the other, on both chains. The party that wishes to initiate the exchange (the "seller") constructs two hash time-locked contracts by generating pay-to-script-hash (P2SH) addresses using the XCAT protocol and the public key of their counterparty (the "buyer").</p>
<p>For the purposes of this example, the seller initiating the exchange will be named "Alice", and the buyer agreeing to complete the exchange will be named "Bob".</p>
@ -56,19 +56,19 @@ OP_CHECKSIG</pre>
<li>Success case: Bob uses R to spend the funds from this P2SH address, as Alice has already revealed R to Bob in the process of spending from the P2SH address he sent ZEC to on the Zcash blockchain. The cross-chain atomic transaction is now complete, and both parties have the funds they requested.</li>
<li>Fail case: Bob has not followed through on his part of the trade within the timeout period, so Alice sends her funds back to herself, canceling the transaction.</li>
</ol>
<section id="timeout-periods"><h3><span class="section-heading">Timeout Periods</span><span class="section-anchor"> <a rel="bookmark" href="#timeout-periods"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="timeout-periods"><h3><span class="section-heading">Timeout Periods</span><span class="section-anchor"> <a rel="bookmark" href="#timeout-periods"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Having timeout periods on both transactions allows the XCAT protocol to work by enabling refunds in case a counterparty misbehaves. The example above uses a timeout period of 24 hours for the first transaction and 48 hours for the second, but these are simply suggestions. Actual timeout periods should be considered to be variables that depend on the following factors for any given implementation of XCAT:</p>
<section id="duration"><h4><span class="section-heading">Duration</span><span class="section-anchor"> <a rel="bookmark" href="#duration"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="duration"><h4><span class="section-heading">Duration</span><span class="section-anchor"> <a rel="bookmark" href="#duration"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The time-lock period on the transaction in which the initiating party reveals R must be significantly shorter than the time-lock period on the second transaction in which the other party uses the revealed R, in order to give them enough time to make use of R to redeem their funds.</p>
<p>For example, once Alice reveals R by spending what Bob sent to her P2SH address, Bob must have enough time to use R to redeem his funds on the other blockchain before Alice can be allowed to refund herself. If there were an insufficient time delay between the first and second timeout periods, Alice could potentially spend Bob's funds at the last minute, then quickly refund herself on the other blockchain before Bob gets a chance to redeem his portion using the R she reveals.</p>
<p>Note that using long time-locks in the P2SH scripts does not necessarily mean that the transactions themselves will take a long time. If both parties are immediately responsive and execute their trades in a timely manner, providing the correct information, the full cross-chain atomic trade can happen quickly. The full duration of the timeout period for each transaction only elapses in the fail case, when either Alice or Bob defaults on their agreement to exchange.</p>
</section>
<section id="block-times"><h4><span class="section-heading">Block times</span><span class="section-anchor"> <a rel="bookmark" href="#block-times"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="block-times"><h4><span class="section-heading">Block times</span><span class="section-anchor"> <a rel="bookmark" href="#block-times"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The protection provided by the timeout period must take into account relative block times between the two blockchains.</p>
</section>
</section>
</section>
<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="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Users are free to come up with their own protocols for cross-chain atomic transactions, but having a well-defined protocol would aid adoption and support third-party services wishing to provide such functionality.</p>
</section>
</section>

40
zip-0301.html
View File

@ -18,17 +18,17 @@ Status: Final
Category: Standards / Ecosystem
Created: 2016-09-23
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", "MAY", and "RECOMMENDED" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP describes the Zcash variant of the Stratum protocol, used by miners to communicate with mining pool servers.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Many existing cryptocurrency miners and pools use the original Stratum protocol <a id="id2" class="footnote_reference" href="#slushpool-stratum">4</a> <a id="id3" class="footnote_reference" href="#bitcointalk-stratum">5</a> for communication, in situations where the miner does not require any control over what they mine (for example, a miner connected to a local <a id="id4" class="footnote_reference" href="#p2pool">6</a> node). However, the protocol is very specific to Bitcoin, in that it makes assumptions about the block header format, and the available nonce space <a id="id5" class="footnote_reference" href="#bitcoin-block">7</a>. Zcash has made changes that invalidate these assumptions.</p>
<p>Having a formal specification for a Zcash-compatible Stratum-style mining protocol means that existing pool operators and miner authors can quickly and easily migrate their frameworks to the Zcash network, with no ambiguity about interoperability.</p>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The Stratum protocol is an instance of <a id="id6" class="footnote_reference" href="#json-rpc-1-0">9</a>. The miner is a JSON-RPC client, and the Stratum server is a JSON-RPC server. The miner starts a session by opening a standard TCP connection to the server, which is then used for two-way line-based communication:</p>
<ul>
<li>The miner can send requests to the server.</li>
@ -39,7 +39,7 @@ License: MIT</pre>
<p>Each request or response is a JSON string, terminated by an ASCII LF character (denoted in the rest of this specification by <code>\n</code>). The LF character MUST NOT appear elsewhere in a request or response. Client and server implementations MAY assume that once they read a LF character, the current message has been completely received.</p>
<p>Per <a id="id7" class="footnote_reference" href="#json-rpc-1-0">9</a>, there is no requirement for the <code>id</code> property in requests and responses to be unique; only that servers MUST set <code>id</code> in their responses equal to that in the request they are responding to (or <code>null</code> for notifications). However, it is RECOMMENDED that clients use unique ids for their requests, to simplify their response parsing.</p>
<p>In the protocol messages below, <code>(content)</code> indicates that <code>content</code> is optional. Variable names are indicated in <em>EMPHASIS</em>. All other characters are part of the protocol message.</p>
<section id="error-objects"><h3><span class="section-heading">Error Objects</span><span class="section-anchor"> <a rel="bookmark" href="#error-objects"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="error-objects"><h3><span class="section-heading">Error Objects</span><span class="section-anchor"> <a rel="bookmark" href="#error-objects"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The <a id="id8" class="footnote_reference" href="#json-rpc-1-0">9</a> specification allows for error objects in responses, but does not specify their format. The original Stratum protocol uses the following format for error responses <a id="id9" class="footnote_reference" href="#slushpool-stratum">4</a>:</p>
<blockquote>
<p>{"id": ##, "result": null, "error": [<em>ERROR_CODE</em>, "<em>ERROR_MESSAGE</em>", <em>TRACEBACK</em>]} <code>\n</code></p>
@ -73,7 +73,7 @@ License: MIT</pre>
</dl>
<p>Miners SHOULD display a human-readable message to the user. This message can be derived from either <code>ERROR_CODE</code> or <code>ERROR_MESSAGE</code>, or both. An example of using <code>ERROR_CODE</code> over <code>ERROR_MESSAGE</code> might be that the miner UI offers localization.</p>
</section>
<section id="protocol-flow"><h3><span class="section-heading">Protocol Flow</span><span class="section-anchor"> <a rel="bookmark" href="#protocol-flow"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="protocol-flow"><h3><span class="section-heading">Protocol Flow</span><span class="section-anchor"> <a rel="bookmark" href="#protocol-flow"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<ul>
<li>Client sends <code>mining.subscribe</code> to set up the session.</li>
<li>Server replies with the session information.</li>
@ -87,7 +87,7 @@ License: MIT</pre>
<li>Server sends <code>mining.notify</code> again when there is a new job.</li>
</ul>
</section>
<section id="nonce-parts"><h3><span class="section-heading">Nonce Parts</span><span class="section-anchor"> <a rel="bookmark" href="#nonce-parts"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="nonce-parts"><h3><span class="section-heading">Nonce Parts</span><span class="section-anchor"> <a rel="bookmark" href="#nonce-parts"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>In Bitcoin, blocks contain two nonces: the 4-byte block header nonce, and an extra nonce in the coinbase transaction <a id="id11" class="footnote_reference" href="#bitcoin-block">7</a>. The original Stratum protocol splits this extra nonce into two parts: one set by the server (used for splitting the search space amongst connected miners), and the other iterated by the miner <a id="id12" class="footnote_reference" href="#slushpool-stratum">4</a>. The nonce in Zcash's block header is 32 bytes long <a id="id13" class="footnote_reference" href="#protocol-blockheader">2</a>, and thus can serve both purposes simultaneously.</p>
<p>We define two nonce parts:</p>
<dl>
@ -101,7 +101,7 @@ License: MIT</pre>
</dl>
<p>The nonce in the block header is the concatenation of <code>NONCE_1</code> and <code>NONCE_2</code> in hex. This means that a miner using bignum representations of nonce MUST increment by <code>1 &lt;&lt; len(NONCE_1)</code> to avoid altering <code>NONCE_1</code> (because the encoding of the nonce in the block header is little endian, in line with the other 32-byte fields <a id="id14" class="footnote_reference" href="#bitcoin-block">7</a> <a id="id15" class="footnote_reference" href="#protocol-blockheader">2</a>).</p>
</section>
<section id="session-resuming"><h3><span class="section-heading">Session Resuming</span><span class="section-anchor"> <a rel="bookmark" href="#session-resuming"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="session-resuming"><h3><span class="section-heading">Session Resuming</span><span class="section-anchor"> <a rel="bookmark" href="#session-resuming"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Servers that support session resuming identify this by setting a <code>SESSION_ID</code> in their initial response. Servers MAY set <code>SESSION_ID</code> to <code>null</code> to indicate that they do not support session resuming. Servers that do not set <code>SESSION_ID</code> to <code>null</code> MUST cache the following information:</p>
<ul>
<li>The session ID.</li>
@ -116,8 +116,8 @@ License: MIT</pre>
</ul>
<p>Miners MUST re-authorize all workers upon resuming a session.</p>
</section>
<section id="methods"><h3><span class="section-heading">Methods</span><span class="section-anchor"> <a rel="bookmark" href="#methods"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="mining-subscribe"><h4><span class="section-heading"><code>mining.subscribe()</code></span><span class="section-anchor"> <a rel="bookmark" href="#mining-subscribe"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="methods"><h3><span class="section-heading">Methods</span><span class="section-anchor"> <a rel="bookmark" href="#methods"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="mining-subscribe"><h4><span class="section-heading"><code>mining.subscribe()</code></span><span class="section-anchor"> <a rel="bookmark" href="#mining-subscribe"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Request:</p>
<blockquote>
<p>{"id": 1, "method": "mining.subscribe", "params": ["<em>MINER_USER_AGENT</em>", "<em>SESSION_ID</em>", "<em>CONNECT_HOST</em>", <em>CONNECT_PORT</em>]} <code>\n</code></p>
@ -155,7 +155,7 @@ License: MIT</pre>
<dd>The first part of the block header nonce (see <a href="#nonce-parts">Nonce Parts</a>).</dd>
</dl>
</section>
<section id="mining-authorize"><h4><span class="section-heading"><code>mining.authorize()</code></span><span class="section-anchor"> <a rel="bookmark" href="#mining-authorize"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="mining-authorize"><h4><span class="section-heading"><code>mining.authorize()</code></span><span class="section-anchor"> <a rel="bookmark" href="#mining-authorize"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A miner MUST authorize a worker in order to submit solutions. A miner MAY authorize multiple workers in the same session; this could be for statistical purposes on the particular server being used. Details of such purposes are outside the scope of this specification.</p>
<p>Request:</p>
<blockquote>
@ -181,7 +181,7 @@ License: MIT</pre>
</dd>
</dl>
</section>
<section id="mining-set-target"><h4><span class="section-heading"><code>mining.set_target()</code></span><span class="section-anchor"> <a rel="bookmark" href="#mining-set-target"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="mining-set-target"><h4><span class="section-heading"><code>mining.set_target()</code></span><span class="section-anchor"> <a rel="bookmark" href="#mining-set-target"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Server message:</p>
<blockquote>
<p>{"id": null, "method": "mining.set_target", "params": ["<em>TARGET</em>"]} <code>\n</code></p>
@ -196,7 +196,7 @@ License: MIT</pre>
</dl>
<p>When displaying the current target in the UI to users, miners MAY convert the target to an integer difficulty as used in Bitcoin miners. When doing so, miners SHOULD use <code>powLimit</code> (as defined in <code>src/chainparams.cpp</code>) as the basis for conversion.</p>
</section>
<section id="mining-notify"><h4><span class="section-heading"><code>mining.notify()</code></span><span class="section-anchor"> <a rel="bookmark" href="#mining-notify"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="mining-notify"><h4><span class="section-heading"><code>mining.notify()</code></span><span class="section-anchor"> <a rel="bookmark" href="#mining-notify"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Server message:</p>
<blockquote>
<p>{"id": null, "method": "mining.notify", "params": ["<em>JOB_ID</em>", "<em>VERSION</em>", "<em>PREVHASH</em>", "<em>MERKLEROOT</em>", "<em>RESERVED</em>", "<em>TIME</em>", "<em>BITS</em>", <em>CLEAN_JOBS</em>]} <code>\n</code></p>
@ -227,7 +227,7 @@ License: MIT</pre>
<dd>If true, a new block has arrived. The miner SHOULD abandon all previous jobs.</dd>
</dl>
</section>
<section id="mining-submit"><h4><span class="section-heading"><code>mining.submit()</code></span><span class="section-anchor"> <a rel="bookmark" href="#mining-submit"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="mining-submit"><h4><span class="section-heading"><code>mining.submit()</code></span><span class="section-anchor"> <a rel="bookmark" href="#mining-submit"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Request:</p>
<blockquote>
<p>{"id": 4, "method": "mining.submit", "params": ["<em>WORKER_NAME</em>", "<em>JOB_ID</em>", "<em>TIME</em>", "<em>NONCE_2</em>", "<em>EQUIHASH_SOLUTION</em>"]} <code>\n</code></p>
@ -267,7 +267,7 @@ License: MIT</pre>
</dd>
</dl>
</section>
<section id="client-reconnect"><h4><span class="section-heading"><code>client.reconnect()</code></span><span class="section-anchor"> <a rel="bookmark" href="#client-reconnect"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="client-reconnect"><h4><span class="section-heading"><code>client.reconnect()</code></span><span class="section-anchor"> <a rel="bookmark" href="#client-reconnect"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Server message:</p>
<blockquote>
<p>{"id": null, "method": "client.reconnect", "params": [("<em>HOST</em>", <em>PORT</em>, <em>WAIT_TIME</em>)]} <code>\n</code></p>
@ -288,7 +288,7 @@ License: MIT</pre>
</dl>
<p>If <code>client.reconnect</code> is sent with an empty parameter array, the miner SHOULD reconnect to the same host and port it is currently connected to.</p>
</section>
<section id="mining-suggest-target"><h4><span class="section-heading"><code>mining.suggest_target()</code></span><span class="section-anchor"> <a rel="bookmark" href="#mining-suggest-target"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="mining-suggest-target"><h4><span class="section-heading"><code>mining.suggest_target()</code></span><span class="section-anchor"> <a rel="bookmark" href="#mining-suggest-target"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Request (optional):</p>
<blockquote>
<p>{"id": 3, "method": "mining.suggest_target", "params": ["<em>TARGET</em>"]} <code>\n</code></p>
@ -301,7 +301,7 @@ License: MIT</pre>
</section>
</section>
</section>
<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="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Why does <code>mining.subscribe</code> include the host and port?</p>
<ul>
<li>It has the same use cases as the <code>Host:</code> header in HTTP. Specifically, it enables virtual hosting, where virtual pools or private URLs might be used for DDoS protection, but that are aggregated on Stratum server backends. As with HTTP, the server CANNOT trust the host string.</li>
@ -327,12 +327,12 @@ License: MIT</pre>
<li><code>WORKER_NAME</code> is only included here for statistical purposes (like monitoring performance and/or downtime). <code>JOB_ID</code> is used for pairing server-stored jobs with submissions.</li>
</ul>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li><a href="https://github.com/str4d/zcash/tree/standalone-miner">str4d's standalone miner</a></li>
</ul>
</section>
<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>
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Thanks to:</p>
<ul>
<li>5a1t for the initial brainstorming session.</li>
@ -341,7 +341,7 @@ License: MIT</pre>
<li>Jelle Bourdeaud'hui (razakal) and ocminer for their help with testing and finding implementation bugs in the specification.</li>
</ul>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

12
zip-0302.html
View File

@ -15,13 +15,13 @@ Category: Standards / RPC / Wallet
Created: 2017-02-08
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/366">https://github.com/zcash/zips/issues/366</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/105">https://github.com/zcash/zips/pull/105</a>&gt;</pre>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP describes a proposed specification for a standardized format for clients who wish to transmit or receive content within the encrypted memo field of shielded transactions.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>A well-defined standard for formatting content within the encrypted memo field will help expand its use within the Zcash ecosystem by providing a commonly recognized format for memo values carrying different types of data. Users and third-party services benefit from standardized formatting rules that define the type and length of the data contained within.</p>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Section 5.5 of the Zcash protocol specification <a id="id1" class="footnote_reference" href="#protocol">1</a> defines three cases for the encoding of a memo field:</p>
<ul>
<li>a UTF-8 human-readable string <a id="id2" class="footnote_reference" href="#utf-8">2</a>, padded by appending zero bytes; or</li>
@ -48,7 +48,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/105">https://githu
<li>If the first byte has a value of 0xFF then the reader should not make any other assumption about the memo. In order to put arbitrary data into a memo field (that might have some private non-standard structure), the value of the first byte SHOULD be set to 0xFF; the remaining 511 bytes are then unconstrained.</li>
</ul>
</section>
<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="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The new protocol specification is an improvement over the current memo field content specification that was in the protocol spec up to version 2020.1.0, which stated:</p>
<blockquote>
<p>The usage of the memo field is by agreement between the sender and recipient of the note. The memo field SHOULD be encoded either as:</p>
@ -61,10 +61,10 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/105">https://githu
</blockquote>
<p>See issue <a href="https://github.com/zcash/zcash/issues/1849">#1849</a> for further discussion.</p>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Encrypted memo field contents sent without the standardized format proposed here will be interpreted according to the specification set out in older versions of the protocol spec.</p>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="protocol" class="footnote">
<tbody>
<tr>

28
zip-0304.html
View File

@ -18,20 +18,20 @@ Created: 2020-06-01
License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/345">https://github.com/zcash/zips/issues/345</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://github.com/zcash/zips/pull/376</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST" and "SHOULD" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal describes a mechanism for creating signatures with Sapling addresses, suitable for use by the <code>signmessage</code> and <code>verifymessage</code> RPC methods in <code>zcashd</code>.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>There are a variety of situations where it is useful for a user to be able to prove that they control a given payment address. For example, before a high-value transfer of funds, the sender may want to verify that the recipient will definitely be able to spend them, to ensure that the funds won't be stuck in an invalid or unusable address.</p>
<p>A payment address is analogous (in some cases, identical) to a public key in a signature scheme. A transaction that spends funds received by the address, is authorized by making (the equivalent of) a signature with the corresponding spending key. This authorization protocol can be repurposed to instead sign a message provided by a third party.</p>
<p>Bitcoin Core's <code>bitcoind</code> provides a <code>signmessage</code> RPC method that implements message signing for Bitcoin addresses, leveraging the fact that a Bitcoin private key is just a <code>secp256k</code> private key, and a Bitcoin transaction authorizes spends with a signature. <code>zcashd</code> inherited this RPC method, and it can be used to make signatures for transparent Zcash addresses.</p>
<p>However, support for signing messages with shielded addresses was not possible when Zcash launched, because of the design of the Sprout protocol (and the state of zero-knowledge proof R&amp;D at the time). Shielded transactions, by design, do not expose the payment address of the sender when creating a transaction; in Sprout, this meant that the spending key was a private input to the zero-knowledge proof, and not a key that could be used to create a signature.</p>
<p>One of the R&amp;D achievements behind the Sapling protocol was the ability to use elliptic curves inside a circuit. With this primitive available, Sapling keys and payment addresses could be designed such that transaction authorization involved a signature. While this was designed to enable hardware wallets (which lack the power to create zero-knowledge proofs, but can easily create signatures), it also enables the creation of a mechanism for signing arbitrary messages. That mechanism is the subject of this ZIP.</p>
</section>
<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>
<section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#conventions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The following constants and functions used in this ZIP are defined in the Zcash protocol specification: <a id="id2" class="footnote_reference" href="#protocol">3</a></p>
<ul>
<li>
@ -90,7 +90,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
.</li>
</ul>
</section>
<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>
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Given a payment address, a message, and a valid signature, the following properties should hold:</p>
<ul>
<li><strong>Authentication:</strong> the signature will not verify with any other payment address.</li>
@ -98,10 +98,10 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<li><strong>Non-malleability:</strong> it should not be possible to obtain a second valid signature (with a different encoding) for the same payment address and message without access to the spending key for that payment address.</li>
</ul>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Multiple signatures by a single payment addresses are not required to be unlinkable.</p>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>A Sapling address signature is created by taking the process for creating a Sapling Spend description, and running it with fixed inputs:</p>
<ul>
<li>A fake Sapling note with a value of
@ -111,7 +111,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
.</li>
<li>A Sapling commitment tree that is empty except for the commitment for the fake note.</li>
</ul>
<section id="signature-algorithm"><h3><span class="section-heading">Signature algorithm</span><span class="section-anchor"> <a rel="bookmark" href="#signature-algorithm"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="signature-algorithm"><h3><span class="section-heading">Signature algorithm</span><span class="section-anchor"> <a rel="bookmark" href="#signature-algorithm"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The inputs to the signature algorithm are:</p>
<ul>
<li>The payment address
@ -192,7 +192,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
.</li>
</ul>
</section>
<section id="verification-algorithm"><h3><span class="section-heading">Verification algorithm</span><span class="section-anchor"> <a rel="bookmark" href="#verification-algorithm"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="verification-algorithm"><h3><span class="section-heading">Verification algorithm</span><span class="section-anchor"> <a rel="bookmark" href="#verification-algorithm"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The inputs to the verification algorithm are:</p>
<ul>
<li>The payment address
@ -251,7 +251,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<li>Return true.</li>
</ul>
</section>
<section id="signature-encoding"><h3><span class="section-heading">Signature encoding</span><span class="section-anchor"> <a rel="bookmark" href="#signature-encoding"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="signature-encoding"><h3><span class="section-heading">Signature encoding</span><span class="section-anchor"> <a rel="bookmark" href="#signature-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The raw form of a ZIP 304 signature is
<span class="math">\(\mathsf{nf}\,||\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_{\mathbb{J}}(\mathsf{rk}))\,||\,zkproof\,||\,spendAuthSig\)</span>
, for a total size of 320 bytes.</p>
@ -260,7 +260,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
followed by the result of Base64-encoding <a id="id18" class="footnote_reference" href="#rfc4648">2</a> the raw form of the signature.</p>
</section>
</section>
<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="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>We use a fake note within the signature scheme in order to reuse the Sapling Spend circuit and its parameters. It is possible to construct a signature scheme with a smaller encoded signature, but this would require a new circuit and another parameter-generation ceremony (if Groth16 were used).</p>
<p>We use a note value of
<span class="math">\(1\)</span>
@ -277,7 +277,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<span class="math">\(\mathsf{rcv}\)</span>
from the signature.</p>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>A normal (and desired) property of signature schemes is that all signatures for a specific public key are linkable if the public key is known. ZIP 304 signatures have the additional property that all signatures for a specific payment address are linkable without knowing the payment address, as the first 32 bytes of each signature will be identical.</p>
<p>A signature is bound to a specific diversified address of the spending key. Signatures for different diversified addresses of the same spending key are unlinkable, as long as
<span class="math">\(α\)</span>
@ -306,10 +306,10 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<span class="math">\(zkproof\)</span>
in the message digest.</p>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p><a href="https://github.com/zcash/librustzcash/pull/210">https://github.com/zcash/librustzcash/pull/210</a></p>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

46
zip-0307.html
View File

@ -17,7 +17,7 @@ Category: Standards / Ecosystem
Status: Draft
Created: 2018-09-17
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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>The terms below are to be interpreted as follows:</p>
<dl>
@ -25,13 +25,13 @@ License: MIT</pre>
<dd>A client that is not a full participant in the network of Zcash peers. It can send and receive payments, but does not store or validate a copy of the block chain.</dd>
</dl>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a protocol for a Zcash light client supporting Sapling shielded transactions.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Currently a client that wishes to send or receive shielded payments must be a full node participanting in the Zcash network. This requires an amount of available bandwidth, space, and processing power that may be unsuitable for some classes of user. This light client protocol addresses that need, and is appropriate for low-power, bandwidth-conscious, or otherwise limited machines (such as mobile phones).</p>
</section>
<section id="high-level-design"><h2><span class="section-heading">High-Level Design</span><span class="section-anchor"> <a rel="bookmark" href="#high-level-design"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="high-level-design"><h2><span class="section-heading">High-Level Design</span><span class="section-anchor"> <a rel="bookmark" href="#high-level-design"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>There are three logical components to a Zcash light client system:</p>
<ul>
<li><strong>Zcash node</strong> that provides chain state and serves as a root of trust for the system.</li>
@ -43,12 +43,12 @@ License: MIT</pre>
<figcaption>Outline of the light wallet architecture</figcaption>
</figure>
</section>
<section id="security-model"><h2><span class="section-heading">Security Model</span><span class="section-anchor"> <a rel="bookmark" href="#security-model"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="security-model"><h2><span class="section-heading">Security Model</span><span class="section-anchor"> <a rel="bookmark" href="#security-model"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>In this model, we propose <strong>payment detection privacy</strong> as our main security goal. That is, the proxy should not learn which transactions (received from the block chain) are addressed to a given light wallet. If we further assume network privacy (via Tor or similar), the proxy should not be able to link different connections or queries as deriving from the the same wallet.</p>
<p>In particular, the underlying Zcash node / proxy combination is assumed to be "honest but curious" and is trusted to provide a correct view of the current best chain state and to faithfully transmit queries and responses.</p>
<p>This ZIP does not address how to spend notes privately.</p>
</section>
<section id="compact-stream-format"><h2><span class="section-heading">Compact Stream Format</span><span class="section-anchor"> <a rel="bookmark" href="#compact-stream-format"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="compact-stream-format"><h2><span class="section-heading">Compact Stream Format</span><span class="section-anchor"> <a rel="bookmark" href="#compact-stream-format"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>A key observation in this protocol is that the current zcashd encrypted field is several hundred bytes long, due to the inclusion of a transaction “memo”. The need to download this entire field imposes a substantial bandwidth cost on each light wallets, which may be a limited mobile device on a restricted-bandwidth plan. While more efficient techniques can be developed in the future, for the moment we propose ignoring the memo field during payment detection. Futhermore, we can also ignore any information that is not directly relevant to a Sapling shielded transaction.</p>
<p>A <strong>compact block</strong> is a packaging of ONLY the data from a block needed to:</p>
<ol type="1">
@ -84,11 +84,11 @@ License: MIT</pre>
<span class="kt">bytes</span> <span class="na">epk</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
<span class="kt">bytes</span> <span class="na">ciphertext</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;</span>
<span class="p">}</span></pre>
<section id="encoding-details"><h3><span class="section-heading">Encoding Details</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-details"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="encoding-details"><h3><span class="section-heading">Encoding Details</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-details"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p><code>blockHash</code>, <code>txHash</code>, <code>nf</code>, <code>cmu</code>, and <code>epk</code> are encoded as specified in the Zcash Protocol Spec.</p>
<p>The output and spend descriptions are handled differently, as described in the following sections.</p>
</section>
<section id="output-compression"><h3><span class="section-heading">Output Compression</span><span class="section-anchor"> <a rel="bookmark" href="#output-compression"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="output-compression"><h3><span class="section-heading">Output Compression</span><span class="section-anchor"> <a rel="bookmark" href="#output-compression"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>In the normal Zcash protocol, the output ciphertext consists of the AEAD-encrypted form of a <em>note plaintext</em> <a id="id3" class="footnote_reference" href="#protocol-notept">5</a>:</p>
<table>
<tbody>
@ -106,7 +106,7 @@ License: MIT</pre>
<p>However, skipping the full ciphertext means that we can no longer calculate the authentication tag for the entire ciphertext and will need to do something else to validate the integrity of the decrypted note plaintext.</p>
<p>Since the note commitment is sent outside the ciphertext and is authenticated by the binding signature over the entire transaction, it serves as an adequate check on the validity of the decrypted plaintext (assuming you trust the entity assembling transactions). We therefore recalculate the note commitment from the decrypted plaintext. If the recalculated commitment matches the one in the output, we accept the note as valid and spendable.</p>
</section>
<section id="spend-compression"><h3><span class="section-heading">Spend Compression</span><span class="section-anchor"> <a rel="bookmark" href="#spend-compression"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="spend-compression"><h3><span class="section-heading">Spend Compression</span><span class="section-anchor"> <a rel="bookmark" href="#spend-compression"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Recall that a full Sapling Spend description is 384 bytes long <a id="id4" class="footnote_reference" href="#protocol-spendencoding">6</a>:</p>
<table>
<thead>
@ -152,7 +152,7 @@ License: MIT</pre>
<p>The only part necessary for detection is the nullifier, which allows a light client to detect when one of its own notes has been spent. This means we only need to take 32 bytes of each Spend, for a 90% improvement in bandwidth use.</p>
</section>
</section>
<section id="proxy-operation"><h2><span class="section-heading">Proxy operation</span><span class="section-anchor"> <a rel="bookmark" href="#proxy-operation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="proxy-operation"><h2><span class="section-heading">Proxy operation</span><span class="section-anchor"> <a rel="bookmark" href="#proxy-operation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The proxy's purpose is to provide a scalable and bandwidth-efficient interface between a Zcash node and any number of light clients. It accomplishes this by parsing a blockwise stream of transactions from the node and converting them into the compact format described above.</p>
<p><em>The details of the API described below may differ from the implementation.</em></p>
<p>The proxy offers the following API to clients:</p>
@ -190,13 +190,13 @@ License: MIT</pre>
<span class="kt">bytes</span> <span class="na">txHash</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;</span>
<span class="p">}</span></pre>
</section>
<section id="client-operation"><h2><span class="section-heading">Client operation</span><span class="section-anchor"> <a rel="bookmark" href="#client-operation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="client-operation"><h2><span class="section-heading">Client operation</span><span class="section-anchor"> <a rel="bookmark" href="#client-operation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Light clients obtain compact blocks from one or more proxy servers, which they then process locally to update their view of the block chain. We consider only a single proxy server here without loss of generality.</p>
<section id="local-processing"><h3><span class="section-heading">Local processing</span><span class="section-anchor"> <a rel="bookmark" href="#local-processing"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="local-processing"><h3><span class="section-heading">Local processing</span><span class="section-anchor"> <a rel="bookmark" href="#local-processing"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Given a <code>CompactBlock</code> at block height
<span class="math">\(\mathsf{height}\)</span>
received in height-sequential order from a proxy server, a light client can process it in four ways:</p>
<section id="scanning-for-relevant-transactions"><h4><span class="section-heading">Scanning for relevant transactions</span><span class="section-anchor"> <a rel="bookmark" href="#scanning-for-relevant-transactions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="scanning-for-relevant-transactions"><h4><span class="section-heading">Scanning for relevant transactions</span><span class="section-anchor"> <a rel="bookmark" href="#scanning-for-relevant-transactions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>For every <code>CompactOutput</code> in the <code>CompactBlock</code>, the light client can trial-decrypt it against a set of Sapling incoming viewing keys. The procedure for trial-decrypting a <code>CompactOutput</code>
<span class="math">\((\mathtt{cmu}, \mathtt{ephemeralKey}, \mathsf{ciphertext})\)</span>
with an incoming viewing key
@ -292,7 +292,7 @@ License: MIT</pre>
.</li>
</ul>
</section>
<section id="creating-and-updating-note-witnesses"><h4><span class="section-heading">Creating and updating note witnesses</span><span class="section-anchor"> <a rel="bookmark" href="#creating-and-updating-note-witnesses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="creating-and-updating-note-witnesses"><h4><span class="section-heading">Creating and updating note witnesses</span><span class="section-anchor"> <a rel="bookmark" href="#creating-and-updating-note-witnesses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>As <code>CompactBlocks</code> are received in height order, and the transactions within them have their order preserved, the <em>cmu</em> values in each <code>CompactOutput</code> can be sequentially appended to an incremental Merkle tree of depth 32 in order to maintain a local copy of the Sapling note commitment tree. <a id="id6" class="footnote_reference" href="#protocol-merkletree">2</a> This can then be used to create incremental witnesses for each unspent note the light client is tracking. <a id="id7" class="footnote_reference" href="#incremental-witness">10</a> An incremental witness updated to height <code>X</code> corresponds to a Merkle path from the note to the Sapling commitment tree anchor for block <code>X</code>. <a id="id8" class="footnote_reference" href="#protocol-merklepath">3</a></p>
<p>Let <code>tree</code> be the Sapling note commitment tree at height <code>X-1</code>, and <code>note_witnesses</code> be the incremental witnesses for unspent notes detected up to height <code>X-1</code>. When the <code>CompactBlock</code> at height <code>X</code> is received:</p>
<ul>
@ -314,10 +314,10 @@ License: MIT</pre>
</ul>
<p>Incremental Merkle trees cannot be rewound, so the light client should cache both the Sapling note commitment tree and per-note incremental witnesses for recent block heights. Cache management is implementation-dependent, but a cache size of 100 is reasonable, as no full Zcash node will roll back the chain by more than 100 blocks.</p>
</section>
<section id="detecting-spends"><h4><span class="section-heading">Detecting spends</span><span class="section-anchor"> <a rel="bookmark" href="#detecting-spends"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="detecting-spends"><h4><span class="section-heading">Detecting spends</span><span class="section-anchor"> <a rel="bookmark" href="#detecting-spends"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The <code>CompactSpend</code> entries can be checked against known local nullifiers, to for example ensure that a transaction has been received by the network and mined.</p>
</section>
<section id="block-header-validation"><h4><span class="section-heading">Block header validation</span><span class="section-anchor"> <a rel="bookmark" href="#block-header-validation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="block-header-validation"><h4><span class="section-heading">Block header validation</span><span class="section-anchor"> <a rel="bookmark" href="#block-header-validation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p><em>This section describes a proposed enhancement that has been only partially implemented: currently only</em> <code>prevHash</code> <em>is checked.</em></p>
<p>If the <code>CompactBlock</code> for height <code>X</code> contains a block header, the light client can validate it in a similar way to SPV clients <a id="id9" class="footnote_reference" href="#spv-clients">11</a> by performing the following checks:</p>
<ul>
@ -333,11 +333,11 @@ License: MIT</pre>
<p>Block header validation provides light clients with some assurance that the <code>CompactOutputs</code> being sent to them are indeed from valid blocks that have been mined. The strongest-possible assurance is achieved when all block headers are synchronised; this comes at the cost of bandwidth and storage.</p>
<p>By default, <code>CompactBlocks</code> only contain <code>CompactTxs</code> for transactions that contain Sapling spends or outputs. Thus they do not contain sufficient information to validate that the received transaction IDs correspond to the transaction tree root in the block header. This does not have a significant effect on light client security: light clients only directly depend on <code>CompactOutputs</code>, which can be authenticated via block header validation. If a txid is used in a <code>GetTransaction</code> call, the returned transaction SHOULD be checked against the corresponding <code>CompactOutputs</code>, in addition to verifying the transaction signatures.</p>
</section>
<section id="potential-extensions"><h4><span class="section-heading">Potential extensions</span><span class="section-anchor"> <a rel="bookmark" href="#potential-extensions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="potential-extensions"><h4><span class="section-heading">Potential extensions</span><span class="section-anchor"> <a rel="bookmark" href="#potential-extensions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A trivial extension (with corresponding bandwidth cost) would be to transmit empty <code>CompactTxs</code> corresponding to transactions that do not contain Sapling spends or outputs. A more complex extension would send the inner nodes within the transaction trees corresponding to non-Sapling-relevant subtrees; this would require strictly less bandwidth that the trivial extension. These extensions are not currently defined.</p>
</section>
</section>
<section id="client-server-interaction"><h3><span class="section-heading">Client-server interaction</span><span class="section-anchor"> <a rel="bookmark" href="#client-server-interaction"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="client-server-interaction"><h3><span class="section-heading">Client-server interaction</span><span class="section-anchor"> <a rel="bookmark" href="#client-server-interaction"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>We can divide the typical client-server interaction into four distinct phases:</p>
<pre data-language="text">Phase Client Server
===== ============================
@ -441,7 +441,7 @@ License: MIT</pre>
</ul>
</li>
</ul>
<section id="importing-a-pre-existing-seed"><h4><span class="section-heading">Importing a pre-existing seed</span><span class="section-anchor"> <a rel="bookmark" href="#importing-a-pre-existing-seed"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="importing-a-pre-existing-seed"><h4><span class="section-heading">Importing a pre-existing seed</span><span class="section-anchor"> <a rel="bookmark" href="#importing-a-pre-existing-seed"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Phase A of the interaction assumes that shielded addresses created by the light client will have never been used before. This is not a valid assumption if the light client is being initialised with a seed that it did not generate (e.g. a previously backed-up seed). In this case, phase A is modified as follows:</p>
<p><strong>Phase A:</strong> The light client starts up for the first time.</p>
<ul>
@ -453,7 +453,7 @@ License: MIT</pre>
</ul>
</section>
</section>
<section id="block-privacy-via-bucketing"><h3><span class="section-heading">Block privacy via bucketing</span><span class="section-anchor"> <a rel="bookmark" href="#block-privacy-via-bucketing"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="block-privacy-via-bucketing"><h3><span class="section-heading">Block privacy via bucketing</span><span class="section-anchor"> <a rel="bookmark" href="#block-privacy-via-bucketing"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p><em>This section describes a proposed enhancement that has not been implemented.</em></p>
<p>The above interaction reveals to the server at the start of each synchronisation phase (B and D) the block height which the light client had previously synchronised to. This is an information leak under our security model (assuming network privacy). We can reduce the information leakage by "bucketing" the start point of each synchronisation. Doing so also enables us to handle most chain reorgs simultaneously.</p>
<p>Let <code>⌊X⌋ = X - (X % N)</code> be the value of <code>X</code> rounded down to some multiple of the bucket size <code>N</code>. The synchronisation phases from the above interaction are modified as follows:</p>
@ -514,15 +514,15 @@ License: MIT</pre>
<li>Blocks between <code>Y+1</code> and <code>Z</code> are processed as before.</li>
</ul>
</section>
<section id="transaction-privacy"><h3><span class="section-heading">Transaction privacy</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-privacy"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="transaction-privacy"><h3><span class="section-heading">Transaction privacy</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-privacy"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The synchronisation phases give the light client sufficient information to determine accurate address balances, show when funds were received or spent, and spend any unspent notes. As synchronisation happens via a broadcast medium, it leaks no information about which transactions the light client is interested in.</p>
<p>If, however, the light client needs access to other components of a transaction (such as the memo fields for received notes, or the outgoing ciphertexts in order to recover spend information when importing a wallet seed), it will need to download the full transaction. The light client SHOULD obscure the exact transactions of interest by downloading numerous uninteresting transactions as well, and SHOULD download all transactions in any block from which a single full transaction is fetched (interesting or otherwise). It MUST convey to the user that fetching full transactions will reduce their privacy.</p>
</section>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal is supported by a set of libraries and reference code made available by the Electric Coin Company.</p>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

30
zip-0308.html
View File

@ -15,7 +15,7 @@ Status: Final
Category: Standards / RPC / Wallet
Created: 2018-11-27
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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">2</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 -&gt; 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

16
zip-0310.html
View File

@ -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 rel="bookmark" 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" class="section-anchor" 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">3</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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="protocol" class="footnote">
<tbody>
<tr>

24
zip-0313.html
View File

@ -18,21 +18,21 @@ Created: 2020-10-11
License: MIT
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/zip-reduce-default-shielded-transaction-fee-to-1000-zats/37566">https://forum.zcashcommunity.com/t/zip-reduce-default-shielded-transaction-fee-to-1000-zats/37566</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/408">https://github.com/zcash/zips/pull/408</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The term "conventional transaction fee" in this document is in reference to the value of a transaction fee that is conventionally used by wallets, and that a user can reasonably expect miners on the Zcash network to accept for including a transaction in a block.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The goal of this ZIP is to gather wallet developers, miners &amp; Zcash users for social consensus on reducing the conventional transaction fees and to get the Zcash conventional transaction fee reduced from 10,000 zatoshis to 1,000 zatoshis.</p>
<p>In addition, this specification harmonizes transaction fees between different kinds of transaction (involving shielded addresses, transparent addresses, or both), as proposed in <a id="id1" class="footnote_reference" href="#zcash-2942">6</a>.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The conventional transaction fee presently is 0.0001 ZEC or 10,000 zatoshis. At a ZEC market price of USD 100, for example, a user can send 10,000 transactions for 1 ZEC. This works out to 1 U.S. cent per transaction and it rises with any increase in the price of ZEC.</p>
<p>With increase in light wallet adoptions on mobile clients, many users will be new to the Zcash eco-system. And the fact that the transaction fees are paid by the sender (not the receiver) is new information to users who might use Zcash for e-commerce and app interactions that might result in several transactions each day.</p>
<p>Privacy must not cost a premium. The cost of 10 shielded transactions buys 1GB of mobile data <a href="https://www.cable.co.uk/mobiles/worldwide-data-pricing/">in India today</a>.</p>
<p>Zcash users must be able to do more with their ZEC balance than worry about paying the premium for shielded transactions.</p>
<p>With reduced fees, it will be cheaper to transact on the Zcash network, while also inviting novel use cases for privacy-preserving applications that would benefit from the privacy, security, and programmable money aspects of the Zcash chain.</p>
<p>The harmonization of fees between different kinds of transaction can be expected to improve usability, consistency, and predictability.</p>
<section id="requirements-for-adoption"><h3><span class="section-heading">Requirements for adoption</span><span class="section-anchor"> <a rel="bookmark" href="#requirements-for-adoption"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="requirements-for-adoption"><h3><span class="section-heading">Requirements for adoption</span><span class="section-anchor"> <a rel="bookmark" href="#requirements-for-adoption"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The change to the conventional transaction fees should be undertaken soon as it gets difficult to gain consensus with the growth in the network of wallets, exchanges, miners and third parties involved.</p>
<p>The following parties need to be part of the consensus:</p>
<ul>
@ -41,11 +41,11 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/408">https://githu
<li>Zcash documentation and community outreach must be undertaken to make the change known.</li>
</ul>
</section>
<section id="security-and-privacy-considerations"><h3><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></h3>
<section id="security-and-privacy-considerations"><h3><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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Unique transaction fees may reveal specific users or wallets or wallet versions, which would reduce privacy for those specific users and the rest of the network. Hence this change should be accepted by a majority of shielded transaction software providers before deploying the change.</p>
<p>Varying/unique fees are bad for privacy. For the short term before blocks get full, it is fine for everyone to use a constant fee, as long as it is enough to compensate miners for including the transaction. <a id="id2" class="footnote_reference" href="#nathan-1">1</a></p>
<p>Long term, the issue of fees needs to be re-visited in separate future proposals as the blocks start getting consistently full. New ZIPs with flexible fees, such as <a id="id3" class="footnote_reference" href="#ian-1">2</a>, along with scaling solutions, will need to be evaluated and applied.</p>
<section id="denial-of-service-vulnerability"><h4><span class="section-heading">Denial of Service Vulnerability</span><span class="section-anchor"> <a rel="bookmark" href="#denial-of-service-vulnerability"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="denial-of-service-vulnerability"><h4><span class="section-heading">Denial of Service Vulnerability</span><span class="section-anchor"> <a rel="bookmark" href="#denial-of-service-vulnerability"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A transaction-rate-based denial of service attack occurs when an attacker generates enough transactions over a window of time to prevent legitimate transactions from being mined, or to hinder syncing blocks for full nodes or miners.</p>
<p>There are two primary protections to this kind of attack in Zcash: the block size limit, and transaction fees. The block size limit ensures that full nodes and miners can keep up with the block chain even if blocks are completely full. However, users sending legitimate transactions may not have their transactions confirmed in a timely manner.</p>
<p>Variable fees could mitigate this kind of denial of service: if there are more transactions available than can fit into a single block, then a miner will typically choose the transactions that pay the highest fees. If legitimate wallets were to increase their fees during this condition, the attacker would also increase the fees of their transactions. It is sometimes argued that this would impose a cost to the attacker that would limit the time window for which they can continue the attack. However, there is little evidence that the actual costs involved would be a sufficient disincentive.</p>
@ -54,17 +54,17 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/408">https://githu
</section>
</section>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Wallets implementing this specification will use a default fee of 0.00001 ZEC (1000 zatoshis) from block 1,080,000, for all transactions.</p>
<section id="transaction-relaying"><h3><span class="section-heading">Transaction relaying</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-relaying"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="transaction-relaying"><h3><span class="section-heading">Transaction relaying</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-relaying"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>zcashd, and potentially other node implementations, implements fee-based restrictions on relaying of mempool transactions. Nodes that normally relay transactions are expected to do so for transactions that pay at least the conventional fee, unless there are other reasons not to do so for robustness or denial-of-service mitigation.</p>
<p>In zcashd 4.2.0, this change is implemented by <a id="id4" class="footnote_reference" href="#zcash-relaying">7</a>.</p>
</section>
<section id="mempool-size-limiting"><h3><span class="section-heading">Mempool size limiting</span><span class="section-anchor"> <a rel="bookmark" href="#mempool-size-limiting"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="mempool-size-limiting"><h3><span class="section-heading">Mempool size limiting</span><span class="section-anchor"> <a rel="bookmark" href="#mempool-size-limiting"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>zcashd limits the size of the mempool as described in <a id="id5" class="footnote_reference" href="#zip-0401">8</a>. This specifies a <em>low_fee_penalty</em> that is added to the "eviction weight" if the transaction pays a fee less than (in the original ZIP) 10,000 zatoshis. This threshold is modified to match the new conventional fee in zcashd 4.2.0.</p>
</section>
</section>
<section id="support"><h2><span class="section-heading">Support</span><span class="section-anchor"> <a rel="bookmark" href="#support"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="support"><h2><span class="section-heading">Support</span><span class="section-anchor"> <a rel="bookmark" href="#support"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The developers of the following wallets intend to implement the reduced fees:</p>
<ul>
<li>Zbay;</li>
@ -74,10 +74,10 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/408">https://githu
</ul>
<p>In zcashd this fee change is implemented in version 4.2.0 (not dependent on block height), and in that version is limited to transactions created using <cite>z_*</cite> RPC APIs. It is planned to extend this to all transactions in a future version <a id="id7" class="footnote_reference" href="#zcash-2942">6</a>.</p>
</section>
<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>
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Thanks to Nathan Wilcox for suggesting improvements to the denial of service section. Thanks to Daira Hopwood and Deirdre Connolly for reviewing and fixing the wording in this ZIP.</p>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="nathan-1" class="footnote">
<tbody>
<tr>

68
zip-0316.html
View File

@ -21,7 +21,7 @@ Category: Standards / RPC / Wallet
Created: 2021-04-07
License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://github.com/zcash/zips/issues/482</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", 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>
@ -64,10 +64,10 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
</dl>
<p>Notation for sequences, conversions, and arithmetic operations follows the Zcash protocol specification <a id="id2" class="footnote_reference" href="#protocol-notation">3</a>.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines Unified Addresses, which bundle together Zcash Addresses of different types in a way that can be presented as a single Address Encoding. It also defines Unified Viewing Keys, which perform a similar function for Zcash viewing keys.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Up to and including the Canopy network upgrade, Zcash supported the following Payment Address types:</p>
<ul>
<li>Transparent Addresses (P2PKH and P2SH)</li>
@ -91,13 +91,13 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<li>The standard should work well for Zcash today and upcoming potential upgrades, and also anticipate even broader use cases down the road such as cross-chain functionality.</li>
</ul>
</section>
<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>
<section id="overview"><h3><span class="section-heading">Overview</span><span class="section-anchor"> <a rel="bookmark" href="#overview"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="overview"><h3><span class="section-heading">Overview</span><span class="section-anchor"> <a rel="bookmark" href="#overview"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Unified Addresses specify multiple methods for payment to a Recipient's Wallet. The Sender's Wallet can then non-interactively select the method of payment.</p>
<p>Importantly, any wallet can support Unified Addresses, even when that wallet only supports a subset of payment methods for receiving and/or sending.</p>
<p>Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs <a id="id4" class="footnote_reference" href="#zip-0321">19</a> and similar schemes, and the Unified Address format is likely to be incorporated into such schemes as a new Address type.</p>
</section>
<section id="concepts"><h3><span class="section-heading">Concepts</span><span class="section-anchor"> <a rel="bookmark" href="#concepts"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="concepts"><h3><span class="section-heading">Concepts</span><span class="section-anchor"> <a rel="bookmark" href="#concepts"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Wallets follow a model <em>Interaction Flow</em> as follows:</p>
<ol type="1">
<li>A Producer <em>generates</em> an Address.</li>
@ -110,15 +110,15 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<p>Encodings of the same Address may be distributed zero or more times through different means. Zero or more Consumers may import Addresses. Zero or more of those (that are Senders) may execute a Transfer. A single Sender may execute multiple Transfers over time from a single import.</p>
<p>Steps 1 to 5 inclusive also apply to Interaction Flows for Unified Full Viewing Keys and Unified Incoming Viewing Keys.</p>
</section>
<section id="addresses"><h3><span class="section-heading">Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="addresses"><h3><span class="section-heading">Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#addresses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A Unified Address (or UA for short) combines one or more Receivers.</p>
<p>When new Transport Protocols are introduced to the Zcash protocol after Unified Addresses are standardized, those should introduce new Receiver Types but <em>not</em> different Address types outside of the UA standard. There needs to be a compelling reason to deviate from the standard, since the benefits of UA come precisely from their applicability across all new protocol upgrades.</p>
</section>
<section id="receivers"><h3><span class="section-heading">Receivers</span><span class="section-anchor"> <a rel="bookmark" href="#receivers"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="receivers"><h3><span class="section-heading">Receivers</span><span class="section-anchor"> <a rel="bookmark" href="#receivers"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Every Wallet must properly <em>parse</em> a Unified Address or Unified Viewing Key containing unrecognized Items.</p>
<p>A Wallet may process unrecognized Items by indicating to the user their presence or similar information for usability or diagnostic purposes.</p>
</section>
<section id="transport-encoding"><h3><span class="section-heading">Transport Encoding</span><span class="section-anchor"> <a rel="bookmark" href="#transport-encoding"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="transport-encoding"><h3><span class="section-heading">Transport Encoding</span><span class="section-anchor"> <a rel="bookmark" href="#transport-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The string encoding is “opaque” to human readers: it does <em>not</em> allow visual identification of which Receivers or Receiver Types are present.</p>
<p>The string encoding is resilient against typos, transcription errors, cut-and-paste errors, unanticipated truncation, or other anticipated UX hazards.</p>
<p>There is a well-defined encoding of a Unified Address (or UFVK or UIVK) as a QR Code, which produces QR codes that are reasonably compact and robust.</p>
@ -127,7 +127,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<p>The encoding must support sufficiently many Recipient Types to allow for reasonable future expansion.</p>
<p>The encoding must allow all wallets to safely and correctly parse out unrecognized Receiver Types well enough to ignore them.</p>
</section>
<section id="transfers"><h3><span class="section-heading">Transfers</span><span class="section-anchor"> <a rel="bookmark" href="#transfers"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="transfers"><h3><span class="section-heading">Transfers</span><span class="section-anchor"> <a rel="bookmark" href="#transfers"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>When executing a Transfer the Sender selects a Receiver via a Selection process.</p>
<p>Given a valid UA, Selection must treat any unrecognized Item as though it were absent.</p>
<ul>
@ -136,20 +136,20 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<li>This property also allows Transparent-Only wallets to upgrade to shielded support without re-acquiring counterparty UAs. If they are re-acquired, the user flow and usability will be minimally disrupted.</li>
</ul>
</section>
<section id="experimental-usage"><h3><span class="section-heading">Experimental Usage</span><span class="section-anchor"> <a rel="bookmark" href="#experimental-usage"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="experimental-usage"><h3><span class="section-heading">Experimental Usage</span><span class="section-anchor"> <a rel="bookmark" href="#experimental-usage"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Unified Addresses and Unified Viewing Keys must be able to include Receivers and Viewing Keys of experimental types, possibly alongside non-experimental ones. These experimental Receivers or Viewing Keys must be used only by wallets whose users have explicitly opted into the corresponding experiment.</p>
</section>
<section id="viewing-keys"><h3><span class="section-heading">Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#viewing-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="viewing-keys"><h3><span class="section-heading">Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#viewing-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A Unified Full Viewing Key (resp. Unified Incoming Viewing Key) can be used in a similar way to a Full Viewing Key (resp. Incoming Viewing Key) as described in the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-nu5">2</a>.</p>
<p>For a Transparent P2PKH Address that is derived according to BIP 32 <a id="id7" class="footnote_reference" href="#bip-0032">20</a> and BIP 44 <a id="id8" class="footnote_reference" href="#bip-0044">23</a>, the nearest equivalent to a Full Viewing Key or Incoming Viewing Key for a given BIP 44 account is an extended public key, as defined in the section “Extended keys” of BIP 32. Therefore, UFVKs and UIVKs should be able to include such extended public keys.</p>
<p>A wallet should support deriving a UIVK from a UFVK, and a Unified Address from a UIVK.</p>
</section>
<section id="open-issues-and-known-concerns"><h3><span class="section-heading">Open Issues and Known Concerns</span><span class="section-anchor"> <a rel="bookmark" href="#open-issues-and-known-concerns"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="open-issues-and-known-concerns"><h3><span class="section-heading">Open Issues and Known Concerns</span><span class="section-anchor"> <a rel="bookmark" href="#open-issues-and-known-concerns"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Privacy impacts of transparent or cross-pool transactions, and the associated UX issues, will be addressed in ZIP 315 (in preparation).</p>
</section>
</section>
<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="encoding-of-unified-addresses"><h3><span class="section-heading">Encoding of Unified Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-of-unified-addresses"><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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="encoding-of-unified-addresses"><h3><span class="section-heading">Encoding of Unified Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-of-unified-addresses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Rather than defining a Bech32 string encoding of Orchard Shielded Payment Addresses, we instead define a Unified Address format that is able to encode a set of Receivers of different types. This enables the Consumer of a Unified Address to choose the Receiver of the best type it supports, providing a better user experience as new Receiver Types are added in the future.</p>
<p>Assume that we are given a set of one or more Receiver Encodings for distinct types. That is, the set may optionally contain one Receiver of each of the Receiver Types in the following fixed Priority List:</p>
<ul>
@ -212,7 +212,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<p>For Unified Addresses on Mainnet, the Human-Readable Part (as defined in <a id="id14" class="footnote_reference" href="#bip-0350">25</a>) is “<code>u</code>”. For Unified Addresses on Testnet, the Human-Readable Part is “<code>utest</code>”.</p>
<p>A wallet MAY allow its user(s) to configure which Receiver Types it can send to. It MUST NOT allow the user(s) to change the order of the Priority List used to choose the Receiver Type, except by opting into experiments.</p>
</section>
<section id="encoding-of-unified-full-incoming-viewing-keys"><h3><span class="section-heading">Encoding of Unified Full/Incoming Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-of-unified-full-incoming-viewing-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="encoding-of-unified-full-incoming-viewing-keys"><h3><span class="section-heading">Encoding of Unified Full/Incoming Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-of-unified-full-incoming-viewing-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Unified Full or Incoming Viewing Keys are encoded and decoded analogously to Unified Addresses. A Consumer MUST use the decoding procedure from the previous section. For Viewing Keys, a Consumer will normally take the union of information provided by all contained Receivers, and therefore the Priority List defined in the previous section is not used.</p>
<p>For each FVK Type or IVK Type currently defined in this specification, the same Typecode is used as for the corresponding Receiver Type in a Unified Address. Additional FVK Types and IVK Types MAY be defined in future, and these will not necessarily use the same Typecode as the corresponding Unified Address.</p>
<p>The following FVK or IVK Encodings are used in place of the
@ -260,12 +260,12 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<li>“<code>uview</code>” for Unified Full Viewing Keys on Mainnet;</li>
<li>“<code>uviewtest</code>” for Unified Full Viewing Keys on Testnet.</li>
</ul>
<section id="rationale-for-address-derivation"><h4><span class="section-heading">Rationale for address derivation</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-address-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="rationale-for-address-derivation"><h4><span class="section-heading">Rationale for address derivation</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-address-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The design of address derivation is designed to maintain unlinkability between addresses derived from the same UIVK, to the extent possible. (This is only partially achieved if the UA contains a Transparent P2PKH Address, since the on-chain transaction graph can potentially be used to link transparent addresses.)</p>
<p>Note that it may be difficult to retain this property for Metadata Items, and this should be taken into account in the design of such Items.</p>
</section>
</section>
<section id="requirements-for-both-unified-addresses-and-unified-viewing-keys"><h3><span class="section-heading">Requirements for both Unified Addresses and Unified Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#requirements-for-both-unified-addresses-and-unified-viewing-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="requirements-for-both-unified-addresses-and-unified-viewing-keys"><h3><span class="section-heading">Requirements for both Unified Addresses and Unified Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#requirements-for-both-unified-addresses-and-unified-viewing-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<ul>
<li>A Unified Address or Unified Viewing Key MUST NOT contain only transparent P2SH or P2PKH addresses (Typecodes
<span class="math">\(\mathtt{0x00}\)</span>
@ -288,11 +288,11 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which the constituent Items are not ordered in ascending Typecode order. Note that this is different to priority order, and does not affect which Receiver in a Unified Address should be used by a Sender.</li>
<li>There MUST NOT be additional bytes at the end of the raw encoding that cannot be interpreted as specified above.</li>
</ul>
<section id="rationale-for-item-ordering"><h4><span class="section-heading">Rationale for item ordering</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-item-ordering"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="rationale-for-item-ordering"><h4><span class="section-heading">Rationale for item ordering</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-item-ordering"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The rationale for requiring Items to be canonically ordered by Typecode is that it enables implementations to use an in-memory representation that discards ordering, while retaining the same round-trip serialization of a UA / UVK (provided that unrecognized items are retained).</p>
</section>
</section>
<section id="adding-new-types"><h3><span class="section-heading">Adding new types</span><span class="section-anchor"> <a rel="bookmark" href="#adding-new-types"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="adding-new-types"><h3><span class="section-heading">Adding new types</span><span class="section-anchor"> <a rel="bookmark" href="#adding-new-types"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>It is intended that new Receiver Types and Viewing Key Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="id23" class="footnote_reference" href="#zip-0000">10</a>.</p>
<p>For experimentation prior to proposing a ZIP, experimental types MAY be added using the reserved Typecodes
<span class="math">\(\mathtt{0xFFFA}\)</span>
@ -301,7 +301,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
inclusive. This provides for six simultaneous experiments, which can be referred to as experiments A to F. This should be sufficient because experiments are expected to be reasonably short-term, and should otherwise be either standardized in a ZIP (and allocated a Typecode outside this reserved range) or discontinued.</p>
<p>New types SHOULD maintain the same distinction between FVK and IVK authority as existing types, i.e. an FVK is intended to give access to view all transactions to and from the address, while an IVK is intended to give access only to view incoming payments (as opposed to change).</p>
</section>
<section id="metadata-items"><h3><span class="section-heading">Metadata Items</span><span class="section-anchor"> <a rel="bookmark" href="#metadata-items"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="metadata-items"><h3><span class="section-heading">Metadata Items</span><span class="section-anchor"> <a rel="bookmark" href="#metadata-items"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Typecodes
<span class="math">\(\mathtt{0xE0}\)</span>
to
@ -310,7 +310,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<p>Since Metadata Items are not Receivers, they MUST NOT be selected by a Sender when choosing a Receiver to send to, and since they are not Viewing Keys, they MUST NOT provide additional authority to view information about transactions.</p>
<p>Currently no Metadata Types are defined. New Metadata Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="id24" class="footnote_reference" href="#zip-0000">10</a>.</p>
</section>
<section id="deriving-a-uivk-from-a-ufvk"><h3><span class="section-heading">Deriving a UIVK from a UFVK</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-uivk-from-a-ufvk"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="deriving-a-uivk-from-a-ufvk"><h3><span class="section-heading">Deriving a UIVK from a UFVK</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-uivk-from-a-ufvk"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The following derivations are applied to each component FVK:</p>
<ul>
<li>For a Sapling FVK, the corresponding Sapling IVK is obtained as specified in <a id="id25" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
@ -322,7 +322,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<p>In each case, the Typecode remains the same as in the FVK.</p>
<p>Items (including Metadata Items) that are unrecognized by a given Consumer, or that are specified in experiments that the user has not opted into (see <a href="#experimental-usage">Experimental Usage</a>), MUST be dropped when deriving a UIVK from a UFVK.</p>
</section>
<section id="deriving-a-unified-address-from-a-uivk"><h3><span class="section-heading">Deriving a Unified Address from a UIVK</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-unified-address-from-a-uivk"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="deriving-a-unified-address-from-a-uivk"><h3><span class="section-heading">Deriving a Unified Address from a UIVK</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-unified-address-from-a-uivk"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>To derive a Unified Address from a UIVK we need to choose a diversifier index, which MUST be valid for all of the Viewing Key Types in the UIVK. That is,</p>
<ul>
<li>A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” <a id="id28" class="footnote_reference" href="#zip-0032-sapling-diversifier-derivation">13</a>.</li>
@ -344,7 +344,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<p>In each case, the Typecode remains the same as in the IVK.</p>
<p>Items (including Metadata Items) that are unrecognized by a given Consumer, or that are specified in experiments that the user has not opted into (see <a href="#experimental-usage">Experimental Usage</a>), MUST be dropped when deriving a Receiver from a UIVK.</p>
</section>
<section id="jumbling"><h3><span class="section-heading">Jumbling</span><span class="section-anchor"> <a rel="bookmark" href="#jumbling"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="jumbling"><h3><span class="section-heading">Jumbling</span><span class="section-anchor"> <a rel="bookmark" href="#jumbling"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Security goal (<strong>near second preimage resistance</strong>):</p>
<ul>
<li>An adversary is given
@ -367,7 +367,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<ul>
<li>In this variant, part b) above is replaced by the meaning of the new Address/Viewing Key being “usefully” different than the one it is based on, even though the adversary does not know any of the private keys. For example, if it were possible to delete a shielded constituent Address from a UA leaving only a Transparent Address, that would be a significant malleability attack.</li>
</ul>
<section id="discussion"><h4><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></h4>
<section id="discussion"><h4><span class="section-heading">Discussion</span><span class="section-anchor"> <a rel="bookmark" href="#discussion"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>There is a generic brute force attack against near second preimage resistance. The adversary generates UAs / UVKs at random with known keys, until one has an encoding that partially collides with one of the
<span class="math">\(q\)</span>
targets. It may be possible to improve on this attack by making use of properties of checksums, etc.</p>
@ -387,7 +387,7 @@ c^{n+m}}{q}.\)</span>
<span class="math">\(p\)</span>
is the probability that a random decoding is of the required form.</p>
</section>
<section id="solution"><h4><span class="section-heading">Solution</span><span class="section-anchor"> <a rel="bookmark" href="#solution"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="solution"><h4><span class="section-heading">Solution</span><span class="section-anchor"> <a rel="bookmark" href="#solution"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>We use an unkeyed 4-round Feistel construction to approximate a random permutation. (As explained below, 3 rounds would not be sufficient.)</p>
<p>Let
<span class="math">\(H_i\)</span>
@ -489,7 +489,7 @@ c^{n+m}}{q}.\)</span>
<span class="math">\(128\)</span>
bytes.)</p>
</section>
<section id="usage-for-unified-addresses-ufvks-and-uivks"><h4><span class="section-heading">Usage for Unified Addresses, UFVKs, and UIVKs</span><span class="section-anchor"> <a rel="bookmark" href="#usage-for-unified-addresses-ufvks-and-uivks"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="usage-for-unified-addresses-ufvks-and-uivks"><h4><span class="section-heading">Usage for Unified Addresses, UFVKs, and UIVKs</span><span class="section-anchor"> <a rel="bookmark" href="#usage-for-unified-addresses-ufvks-and-uivks"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>In order to prevent the generic attack against nonmalleability, there needs to be some redundancy in the encoding. Therefore, the Producer of a Unified Address, UFVK, or UIVK appends the HRP, padded to 16 bytes with zero bytes, to the raw encoding, then applies
<span class="math">\(\mathsf{F4Jumble}\)</span>
before encoding the result with Bech32m.</p>
@ -504,7 +504,7 @@ c^{n+m}}{q}.\)</span>
<span class="math">\(\mathsf{F4Jumble}.\)</span>
)</p>
</section>
<section id="heuristic-analysis"><h4><span class="section-heading">Heuristic analysis</span><span class="section-anchor"> <a rel="bookmark" href="#heuristic-analysis"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="heuristic-analysis"><h4><span class="section-heading">Heuristic analysis</span><span class="section-anchor"> <a rel="bookmark" href="#heuristic-analysis"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A 3-round unkeyed Feistel, as shown, is not sufficient:</p>
<figure class="align-center" align="center">
<img width="372px" src="zip-0316-f3.png" />
@ -582,7 +582,7 @@ c^{n+m}}{q}.\)</span>
<p>It would be possible to make an attack more expensive by making the work done by a Producer more expensive. (This wouldn't necessarily have to increase the work done by the Consumer.) However, given that Unified Addresses may need to be produced on constrained computing platforms, this was not considered to be beneficial overall.</p>
<p>The padding contains the HRP so that the HRP has the same protection against malleation as the rest of the address. This may help against cross-network attacks, or attacks that confuse addresses with viewing keys.</p>
</section>
<section id="efficiency"><h4><span class="section-heading">Efficiency</span><span class="section-anchor"> <a rel="bookmark" href="#efficiency"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="efficiency"><h4><span class="section-heading">Efficiency</span><span class="section-anchor"> <a rel="bookmark" href="#efficiency"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The cost is dominated by 4 BLAKE2b compressions for
<span class="math">\(\ell_M \leq 128\)</span>
bytes. A UA containing a Transparent Address, a Sapling Address, and an Orchard Address, would have
@ -620,10 +620,10 @@ c^{n+m}}{q}.\)</span>
<span class="math">\(256\)</span>
bytes. Note that this effectively defines two conformance levels to this specification. A full implementation will support UAs / UVKs up to the maximum length.</p>
</section>
<section id="dependencies"><h4><span class="section-heading">Dependencies</span><span class="section-anchor"> <a rel="bookmark" href="#dependencies"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="dependencies"><h4><span class="section-heading">Dependencies</span><span class="section-anchor"> <a rel="bookmark" href="#dependencies"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>BLAKE2b, with personalization and variable output length, is the only external dependency.</p>
</section>
<section id="related-work"><h4><span class="section-heading">Related work</span><span class="section-anchor"> <a rel="bookmark" href="#related-work"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="related-work"><h4><span class="section-heading">Related work</span><span class="section-anchor"> <a rel="bookmark" href="#related-work"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p><a href="https://www.iacr.org/cryptodb/data/paper.php?pubkey=218">Eliminating Random Permutation Oracles in the Even–Mansour Cipher</a></p>
<ul>
<li>This paper argues that a 4-round unkeyed Feistel is sufficient to replace a random permutation in the Even–Mansour cipher construction.</li>
@ -633,16 +633,16 @@ c^{n+m}}{q}.\)</span>
</section>
</section>
</section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li><a href="https://github.com/zcash/librustzcash/pull/352">https://github.com/zcash/librustzcash/pull/352</a></li>
<li><a href="https://github.com/zcash/librustzcash/pull/416">https://github.com/zcash/librustzcash/pull/416</a></li>
</ul>
</section>
<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>
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The authors would like to thank Benjamin Winston, Zooko Wilcox, Francisco Gindre, Marshall Gaucher, Joseph Van Geffen, Brad Miller, Deirdre Connolly, Teor, Eran Tromer, Conrado Gouvêa, and Marek Bielik for discussions on the subject of Unified Addresses and Unified Viewing Keys.</p>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

30
zip-0321.html
View File

@ -16,7 +16,7 @@ Created: 2020-08-28
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/347">https://github.com/zcash/zips/issues/347</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/395">https://github.com/zcash/zips/pull/395</a>&gt;
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", 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 "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol-networks">10</a>.</p>
<p>The terms below are to be interpreted as follows:</p>
@ -27,21 +27,21 @@ License: MIT</pre>
<dd>A request for a wallet to construct a single Zcash transaction containing one or more payments.</dd>
</dl>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP proposes a standard format for payment request URIs. Wallets that recognize this format enable users to construct transactions simply by clicking links on webpages or scanning QR codes.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>In order for a robust transactional ecosystem to evolve for Zcash, it is necessary for vendors to be able to issue requests for payment. At present, the best option available is to manually specify a payment address, a payment amount, and potentially memo field content. Of these three components, existing wallets only provide functionality for reading payment addresses in a semi-automated fashion. It is then necessary for the user to manually enter payment amounts and any associated memo information, which is tedious and may be error-prone, particularly if a payment is intended for multiple recipients or the memo field information contains structured data that must be faithfully reproduced.</p>
<p>This ZIP seeks to eliminate these issues by proposing a standard format that wallet vendors may support so that human intervention is required only for approval, not creation, of such a transaction.</p>
<p>In Bitcoin, two different standards exist to permit vendors to issue payment requests that are understood by wallets: BIP-0021 <a id="id3" class="footnote_reference" href="#bip-0021">5</a> and BIP-0070 <a id="id4" class="footnote_reference" href="#bip-0070">6</a>. BIP-0021 provides a URI format that can be interpreted by a wallet to construct simple, single-recipient transactions; BIP-0070 uses a protobuf-based protocol that permits requests for transactions of arbitrary complexity.</p>
<p>The format proposed in this ZIP seeks a middle ground between these approaches: to provide a URI-based format which supports both the trivial use case and the slightly-more-complex situation where a transaction may include payments to multiple recipients.</p>
</section>
<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>
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The format must be a valid URI.</p>
<p>The format must permit the representation of one or more (payment address, amount, memo) tuples.</p>
</section>
<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="uri-syntax"><h3><span class="section-heading">URI Syntax</span><span class="section-anchor"> <a rel="bookmark" href="#uri-syntax"><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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="uri-syntax"><h3><span class="section-heading">URI Syntax</span><span class="section-anchor"> <a rel="bookmark" href="#uri-syntax"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The following syntax specification uses ABNF <a id="id5" class="footnote_reference" href="#rfc5234">2</a>.</p>
<pre data-language="EBNF"><span class="k">zcashurn </span><span class="o">=</span> <span class="s2">&quot;zcash:&quot;</span> <span class="p">(</span> <span class="k">zcashaddress </span><span class="p">[</span> <span class="s2">&quot;?&quot;</span> <span class="k">zcashparams </span><span class="p">]</span> <span class="err">/</span> <span class="s2">&quot;?&quot;</span> <span class="k">zcashparams </span><span class="p">)</span>
<span class="k">zcashaddress </span><span class="err">=</span> <span class="err">1*</span><span class="p">(</span> <span class="k">ALPHA </span><span class="err">/</span> <span class="k">DIGIT </span><span class="p">)</span>
@ -65,7 +65,7 @@ License: MIT</pre>
<p>Note that this grammar does not allow percent encoding outside the productions that use <code>qchar</code>, i.e. the values of label, message, <code>reqparam</code>, and <code>otherparam</code> parameters.</p>
<p>Purported ZIP 321 URIs that cannot be parsed according to the above grammar MUST NOT be accepted.</p>
</section>
<section id="uri-semantics"><h3><span class="section-heading">URI Semantics</span><span class="section-anchor"> <a rel="bookmark" href="#uri-semantics"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="uri-semantics"><h3><span class="section-heading">URI Semantics</span><span class="section-anchor"> <a rel="bookmark" href="#uri-semantics"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A ZIP-321 URI represents a request for the construction of a transaction having one or more <em>payments</em>. In the case that only a single payment is being requested, the recipient address SHOULD be included in the <code>hier-part</code> component of the RFC 3986 URI; otherwise, multiple recipient addresses can be specified using <code>addrparam</code> parameters with different indices.</p>
<p>Addresses, amounts, labels, and messages sharing the same <code>paramindex</code> (including the empty <code>paramindex</code>) are interpreted to be associated with the same payment for the purposes of payment construction. A <code>paramindex</code> MUST NOT have leading zero(s). There is no significance to the ordering of parameters, and <code>paramindex</code> values need not be sequential.</p>
<p>Due to restrictions on transaction construction described in <a id="id8" class="footnote_reference" href="#protocol-saplingbalance">11</a>, there may be no more than 2109 distinct payments requested by a single ZIP-321 URI.</p>
@ -79,7 +79,7 @@ License: MIT</pre>
<p>New address formats may be added in future. If the context of whether the payment URI is intended for Testnet or Mainnet is available, then each address SHOULD be checked to be for the correct network.</p>
<p>Sprout addresses MUST NOT be supported in payment requests. The rationale for this is that transfers to Sprout addresses will, at activation of the Canopy network upgrade, be restricted by ZIP 211 <a id="id13" class="footnote_reference" href="#zip-0211">9</a>; it cannot generally be expected that senders will have funds available in the Sprout pool with which to satisfy requests for payment to a Sprout address.</p>
</section>
<section id="transfer-amount"><h3><span class="section-heading">Transfer amount</span><span class="section-anchor"> <a rel="bookmark" href="#transfer-amount"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="transfer-amount"><h3><span class="section-heading">Transfer amount</span><span class="section-anchor"> <a rel="bookmark" href="#transfer-amount"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>If an amount is provided, it MUST be specified in decimal ZEC. If a decimal fraction is present then a period (<cite>.</cite>) MUST be used as the separating character to separate the whole number from the decimal fraction, and both the whole number and the decimal fraction MUST be nonempty. No other separators (such as commas for grouping or thousands) are permitted. Leading zeros in the whole number or trailing zeros in the decimal fraction are ignored. There MUST NOT be more than 8 digits in the decimal fraction.</p>
<dl>
<dt>For example,</dt>
@ -93,7 +93,7 @@ License: MIT</pre>
</dl>
<p>The amount MUST NOT be greater than 21000000 ZEC (in general, monetary amounts in Zcash cannot be greater than this value).</p>
</section>
<section id="query-keys"><h3><span class="section-heading">Query Keys</span><span class="section-anchor"> <a rel="bookmark" href="#query-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="query-keys"><h3><span class="section-heading">Query Keys</span><span class="section-anchor"> <a rel="bookmark" href="#query-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<dl>
<dt>label</dt>
<dd>Label for an address (e.g. name of receiver). If a label is present at a <code>paramindex</code>, a client rendering a payment for inspection by the user SHOULD display this label (if possible) as well as the associated address. If the label is displayed, it MUST be identifiable as distinct from the address.</dd>
@ -105,14 +105,14 @@ License: MIT</pre>
<dd>Message that clients can display for the purpose of presenting descriptive information about the payment at the associated <code>paramindex</code> to the user.</dd>
</dl>
</section>
<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>
<section id="valid-examples"><h4><span class="section-heading">Valid examples</span><span class="section-anchor"> <a rel="bookmark" href="#valid-examples"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="examples"><h3><span class="section-heading">Examples</span><span class="section-anchor"> <a rel="bookmark" href="#examples"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="valid-examples"><h4><span class="section-heading">Valid examples</span><span class="section-anchor"> <a rel="bookmark" href="#valid-examples"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<pre>zcash:ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez?amount=1&amp;memo=VGhpcyBpcyBhIHNpbXBsZSBtZW1vLg&amp;message=Thank%20you%20for%20your%20purchase</pre>
<p>A valid payment request for a payment of 1 ZEC to a single shielded address, with a base64url-encoded memo and a message for display by the wallet.</p>
<pre>zcash:?address=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU&amp;amount=123.456&amp;address.1=ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez&amp;amount.1=0.789&amp;memo.1=VGhpcyBpcyBhIHVuaWNvZGUgbWVtbyDinKjwn6aE8J-PhvCfjok</pre>
<p>A valid payment request with one transparent and one shielded recipient address, with an encoded Unicode memo for the shielded recipient.</p>
</section>
<section id="invalid-examples"><h4><span class="section-heading">Invalid Examples</span><span class="section-anchor"> <a rel="bookmark" href="#invalid-examples"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="invalid-examples"><h4><span class="section-heading">Invalid Examples</span><span class="section-anchor"> <a rel="bookmark" href="#invalid-examples"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<pre>zcash:?amount=3491405.05201255&amp;address.1=ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez&amp;amount.1=5740296.87793245</pre>
<p>An invalid payment request; this is missing a payment address with empty <code>paramindex</code>.</p>
<pre>zcash:?address=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU&amp;amount=1&amp;amount.1=2&amp;address.2=ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez</pre>
@ -131,15 +131,15 @@ zcash:%74mEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1</pre>
<p>Invalid; the grammar does not allow <code>//</code>. ZIP 321 URIs are not "hierarchical URIs" in the sense defined in <a id="id14" class="footnote_reference" href="#rfc3986">3</a> section 1.2.3, and do not have an "authority component".</p>
</section>
</section>
<section id="forward-compatibility"><h3><span class="section-heading">Forward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#forward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="forward-compatibility"><h3><span class="section-heading">Forward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#forward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Variables which are prefixed with a <code>req-</code> are considered required. If a parser does not recognize any variables which are prefixed with <code>req-</code>, it MUST consider the entire URI invalid. Any other variables that are not recognized, but that are not prefixed with a <code>req-</code>, SHOULD be ignored.</p>
</section>
<section id="backward-compatibility"><h3><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></h3>
<section id="backward-compatibility"><h3><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As this ZIP is written, several clients already implement a <code>zcash:</code> URI scheme similar to this one, however usually without the additional <code>req-</code> prefix requirement or the facility to specify multiple payments using <code>paramindex</code>. These implementations also generally do not support URIs, even with a single payment, where the address is specified as an <code>address=</code> query parameter rather than in the <code>hier-part</code> of the URI. They may also not support the <code>memo</code> parameter, or may not treat it as base64url-encoded.</p>
<p>Thus, it is RECOMMENDED that these features not be used in a mission-critical way until a grace period of 6 months from the finalization of this ZIP has passed, in order to allow client developers to release new versions, and users of old clients to upgrade.</p>
</section>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

22
zip-0400.html
View File

@ -13,16 +13,16 @@ Status: Draft
Category: Wallet
Created: 2020-05-26
License: MIT</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines the current format used in zcashd for wallet persistent storage, commonly known as <code>wallet.dat</code>.</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The process of saving wallet data into disk is currently unspecified. The key-values used in the current implementation are undocumented, and their structure and functionality are unknown without a deep analysis of the involved source code. This document details the schema and the mechanics of the wallet database. This is an informational document, no changes will be done to the source code.</p>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Zcash stores wallet information in a Berkeley database (BDB) <a id="id2" class="footnote_reference" href="#bdb">2</a> commonly known as <code>wallet.dat</code>. The main purpose of this is the persistence of public and private keys the user created and the ability to recover the wallet state after a node restart. This file also allows the migration of user information from one node to another by moving the database to the corresponding new data directory, assuming both zcashd instances are running the same or similar version. A re-index may be necessary after this operation.</p>
<p>The current database is a key-value store where keys and values can have multiple data types in binary format. The first data found in a database key is always the property name, the rest of the key is generally used to identify a record, for example:</p>
<pre>&lt;------ KEY ----+- VALUE -&gt;
@ -30,7 +30,7 @@ License: MIT</pre>
| zkey | pubkey | privkey |
---------------------------</pre>
<p>Here <code>zkey</code> is the property name located at the first position of the database key; the public key is also part of the database key, and it is located in the second position; the private key is saved in the database value column at the first position.</p>
<section id="schema"><h3><span class="section-heading">Schema</span><span class="section-anchor"> <a rel="bookmark" href="#schema"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="schema"><h3><span class="section-heading">Schema</span><span class="section-anchor"> <a rel="bookmark" href="#schema"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>According to Zcash v3.0.0-rc1 the following key-values can be found: the property names in <strong>bold</strong> mean only one instance of this type can exist in the entire database, while the others, suffixed by '*' can have multiple instances. Keys and Values columns of the table contain the types that the stored data is representing. Included also there are the variable names hoping it will add some clarity to what the stored data is representing.</p>
<table>
<thead>
@ -435,7 +435,7 @@ License: MIT</pre>
</tbody>
</table>
</section>
<section id="functionality"><h3><span class="section-heading">Functionality</span><span class="section-anchor"> <a rel="bookmark" href="#functionality"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="functionality"><h3><span class="section-heading">Functionality</span><span class="section-anchor"> <a rel="bookmark" href="#functionality"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>When a zcashd node built with wallet support is started for the first time, a new wallet database is created. By default the node will automatically execute wallet actions that will be saved in the database at the first flush time.</p>
<p>The following flow will happen when a node with wallet support is started for the first time:</p>
<ul>
@ -451,24 +451,24 @@ License: MIT</pre>
<p>At any time after the database is created, new properties can be added as the wallet users perform actions. For example, if the user creates a new Sapling address with the RPC command <code>z_getnewaddress</code> then new records with properties <cite>sapzkey</cite> and <cite>sapzkeymeta</cite> will be added to the database.</p>
<p>In zcashd, database changes do not happen immediately but they are flushed in its own thread by <code>ThreadFlushWalletDB()</code> function periodically to avoid overhead. The internal counter <code>nWalletDBUpdated</code> is increased each time a new write operation to the database is done, this is compared with the last flush in order to commit new stuff.</p>
<p>When the node goes down for whatever reason the information in the wallet database SHOULD persist in the disk; the next time the node starts, the software will detect the database file, read from there and add the values into memory structures that will guarantee wallet functionality.</p>
<section id="transactions"><h4><span class="section-heading">Transactions</span><span class="section-anchor"> <a rel="bookmark" href="#transactions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="transactions"><h4><span class="section-heading">Transactions</span><span class="section-anchor"> <a rel="bookmark" href="#transactions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The wallet database will not save all the transactions that are happening in the blockchain however it will save all transactions where wallet keys are involved. This is needed for example to get balances. Therefore the wallet must have all the transactions related to a key to compute the final value of coin available in the derived address.</p>
<p>The <code>tx</code> property will hold the transaction-related data with the transaction hash as the key and the full transaction as the value.</p>
</section>
<section id="wallet-state-and-transaction-reordering"><h4><span class="section-heading">Wallet state and transaction reordering</span><span class="section-anchor"> <a rel="bookmark" href="#wallet-state-and-transaction-reordering"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="wallet-state-and-transaction-reordering"><h4><span class="section-heading">Wallet state and transaction reordering</span><span class="section-anchor"> <a rel="bookmark" href="#wallet-state-and-transaction-reordering"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Transactions are saved in the database <code>tx</code> key as they arrive, this means transactions have a sequence. The set of all transactions from the begging to a specified timestamp is the wallet state at that instant. Wallet state is important among other things to get current balance for a wallet or address.</p>
<p>In the blockchain, transactions can be invalidated by rollbacks; wallet code will handle this by updating the transactions in the memory database. New state needs to be reflected in the disk database, this is done in zcashd by the flag <code>fAnyUnordered</code> where if true at start time, will launch a rescan over all transactions again.</p>
</section>
<section id="wallet-recovery"><h4><span class="section-heading">Wallet Recovery</span><span class="section-anchor"> <a rel="bookmark" href="#wallet-recovery"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="wallet-recovery"><h4><span class="section-heading">Wallet Recovery</span><span class="section-anchor"> <a rel="bookmark" href="#wallet-recovery"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The wallet database file may become corrupted. There are utilities in the <cite>zcutil/bin</cite> directory that may help with recovering it if this happens. Please ask for help on the Zcash forum or Community Discord.</p>
</section>
<section id="wallet-encryption"><h4><span class="section-heading">Wallet Encryption</span><span class="section-anchor"> <a rel="bookmark" href="#wallet-encryption"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="wallet-encryption"><h4><span class="section-heading">Wallet Encryption</span><span class="section-anchor"> <a rel="bookmark" href="#wallet-encryption"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Encryption will not be discussed in this document in detail as it is expected for the algorithm to change in the future according to the Wallet format ZIP issue: <a id="id4" class="footnote_reference" href="#zip400issue">3</a>.</p>
<p>For a deeper understanding of the current encryption mechanism please refer to <a id="id5" class="footnote_reference" href="#cryptercode">5</a></p>
</section>
</section>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

20
zip-0401.html
View File

@ -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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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">6</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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -57,7 +57,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 rel="bookmark" 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" class="section-anchor" 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="id7" class="footnote_reference" href="#bitcoincore-pr6722">6</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>
@ -68,16 +68,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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

18
zip-1001.html
View File

@ -14,7 +14,7 @@ Category: Consensus Process
Created: 2019-08-01
License: CC BY-SA 4.0 &lt;<a href="https://creativecommons.org/licenses/by-sa/4.0/">https://creativecommons.org/licenses/by-sa/4.0/</a>&gt;
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-keep-the-block-distribution-as-initaly-defined-90-to-miners/33843">https://forum.zcashcommunity.com/t/zip-proposal-keep-the-block-distribution-as-initaly-defined-90-to-miners/33843</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-kee
</tbody>
</table>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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) &gt;= 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: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-kee
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

20
zip-1002.html
View File

@ -14,7 +14,7 @@ Category: Consensus Process
Created: 2019-07-17
License: CC BY-SA 4.0 &lt;<a href="https://creativecommons.org/licenses/by-sa/4.0/">https://creativecommons.org/licenses/by-sa/4.0/</a>&gt;
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-opt-in-protocol-level-development-donation-option/33846">https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-opt-in-protocol-level-development-donation-option/33846</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-g
</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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-g
</tbody>
</table>
</section>
<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="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-g
</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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-g
<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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-g
</li>
</ul>
</section>
<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>
<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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-g
<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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

18
zip-1003.html
View File

@ -14,7 +14,7 @@ Category: Consensus Process
Created: 2019-06-19
License: MIT
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-20-split-between-the-ecc-and-the-foundation/33862">https://forum.zcashcommunity.com/t/dev-fund-proposal-20-split-between-the-ecc-and-the-foundation/33862</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<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 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>
<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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
@ -104,7 +104,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
</tbody>
</table>
<br></section>
<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>
<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" class="section-anchor" 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>

20
zip-1004.html
View File

@ -14,7 +14,7 @@ Category: Consensus Process
Created: 2019-06-19
License: public domain
Discussions-To: &lt;<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">https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-directed-dev-fund-was-20-to-any-combination-of-ecc-zfnd-parity-or-burn/33864</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
</ul>
</section>
</section>
<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>
<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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
@ -124,7 +124,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
</tbody>
</table>
<br></section>
<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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>2019-06-19 Initial post</li>
<li>2019-08-28

12
zip-1005.html
View File

@ -14,10 +14,10 @@ Category: Consensus Process
Created: 2019-06-23
License: MIT
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-zcfs-zcash-community-funding-system/33898">https://forum.zcashcommunity.com/t/zip-proposal-zcfs-zcash-community-funding-system/33898</a>&gt;</pre>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-zcf
<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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-zcf
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-zcf
<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 rel="bookmark" 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" class="section-anchor" 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>

22
zip-1006.html
View File

@ -17,7 +17,7 @@ Category: Consensus Process
Created: 2019-08-31
License: MIT
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/blocktown-development-fund-proposal-10-to-a-2-of-3-multisig-with-community-involved-third-entity/34782">https://forum.zcashcommunity.com/t/blocktown-development-fund-proposal-10-to-a-2-of-3-multisig-with-community-involved-third-entity/34782</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/blocktown-develo
<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 rel="bookmark" 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" class="section-anchor" 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 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>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/blocktown-develo
<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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/blocktown-develo
<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 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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/blocktown-develo
<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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/blocktown-develo
<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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/blocktown-develo
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

18
zip-1007.html
View File

@ -15,24 +15,24 @@ Category: Concensus Process
Created: 2019-08-24
License: CC BY-SA 4.0 &lt;<a href="https://creativecommons.org/licenses/by-sa/4.0/">https://creativecommons.org/licenses/by-sa/4.0/</a>&gt;
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter/34709">https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter/34709</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-supplem
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-supplem
<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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-supplem
</li>
</ul>
</section>
<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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

20
zip-1008.html
View File

@ -15,7 +15,7 @@ Category: Consensus Process
Created: 2019-09-02
License: CC BY-SA 4.0 &lt;<a href="https://creativecommons.org/licenses/by-sa/4.0/">https://creativecommons.org/licenses/by-sa/4.0/</a>&gt;
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/kek-s-proposal-fund-ecc-for-2-more-years/34778">https://forum.zcashcommunity.com/t/kek-s-proposal-fund-ecc-for-2-more-years/34778</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/kek-s-proposal-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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 &lt;<a href="https://www.zfnd.org/blog/community-sentiment-collection-poll/">https://www.zfnd.org/blog/community-sentiment-collection-poll/</a>&gt;, 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 &lt;<a href="https://forum.zcashcommunity.com/t/staked-poll-on-zcash-dev-fund-debate/34846/71">https://forum.zcashcommunity.com/t/staked-poll-on-zcash-dev-fund-debate/34846/71</a>&gt;, 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

16
zip-1009.html
View File

@ -14,7 +14,7 @@ Category: Consensus Process
Created: 2019-08-28
License: MIT
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entity-strategic-council-approach/34801">https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entity-strategic-council-approach/34801</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 &amp; 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<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 &amp; 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>
<section id="issues-further-discussion"><h2><span class="section-heading">Issues &amp; Further Discussion</span><span class="section-anchor"> <a rel="bookmark" href="#issues-further-discussion"><img width="24" height="24" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
</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 rel="bookmark" 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" class="section-anchor" 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>

30
zip-1010.html
View File

@ -20,14 +20,14 @@ Category: Consensus Process
Created: 2019-08-31
License: MIT
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812">https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/a-grand-compromi
<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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/a-grand-compromi
<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 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>
<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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/a-grand-compromi
</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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/a-grand-compromi
</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 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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/a-grand-compromi
<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 rel="bookmark" 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" class="section-anchor" 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 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>
<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" class="section-anchor" 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: &lt;<a href="https://forum.zcashcommunity.com/t/a-grand-compromi
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

40
zip-1011.html
View File

@ -16,29 +16,29 @@ Created: 2019-09-27
License: MIT
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252">https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/278">https://github.com/zcash/zips/pull/278</a>&gt;</pre>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" 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 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>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -53,7 +53,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/278">https://githu
</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 rel="bookmark" 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" class="section-anchor" 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>
@ -66,7 +66,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/278">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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>
@ -79,7 +79,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/278">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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>
@ -90,11 +90,11 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/278">https://githu
</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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -102,7 +102,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/278">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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>
@ -117,7 +117,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/278">https://githu
</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 rel="bookmark" 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" class="section-anchor" 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>
@ -125,7 +125,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/278">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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">
@ -136,7 +136,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/278">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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>
@ -150,25 +150,25 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/278">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>

38
zip-1012.html
View File

@ -15,7 +15,7 @@ Created: 2019-11-10
License: MIT
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fund-to-ecc-zfnd-major-grants/35364">https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fund-to-ecc-zfnd-major-grants/35364</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/291">https://github.com/zcash/zips/pull/291</a>&gt;</pre>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" 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>
@ -24,11 +24,11 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/291">https://githu
</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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -42,7 +42,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/291">https://githu
</ul>
</section>
</section>
<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>
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" 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>
@ -53,12 +53,12 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/291">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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 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>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" 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" class="section-anchor" 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>
@ -66,7 +66,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/291">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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>
@ -77,11 +77,11 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/291">https://githu
<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 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>
<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" class="section-anchor" 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 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>
<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" class="section-anchor" 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">
@ -97,12 +97,12 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/291">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -111,8 +111,8 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/291">https://githu
<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 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>
<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" class="section-anchor" 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" class="section-anchor" 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>
@ -131,12 +131,12 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/291">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -145,13 +145,13 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/291">https://githu
</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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -161,7 +161,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/291">https://githu
</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 rel="bookmark" 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" class="section-anchor" 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>

16
zip-1013.html
View File

@ -15,7 +15,7 @@ Created: 2019-11-14
License: Public Domain
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/zip-keep-it-simple-zcashers-kisz-10-to-ecc-10-to-zfnd/35425">https://forum.zcashcommunity.com/t/zip-keep-it-simple-zcashers-kisz-10-to-ecc-10-to-zfnd/35425</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/293">https://github.com/zcash/zips/pull/293</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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>
@ -27,12 +27,12 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/293">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -41,13 +41,13 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/293">https://githu
</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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -57,7 +57,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/293">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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>
@ -67,7 +67,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/293">https://githu
</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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

36
zip-1014.html
View File

@ -24,7 +24,7 @@ Created: 2019-11-10
License: MIT
Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560">https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">https://github.com/zcash/zips/pull/308</a>&gt;</pre>
<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>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" 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">6</a> and the Zcash Trademark Donation and License Agreement (<a id="id3" class="footnote_reference" href="#trademark">4</a> or successor agreement).</p>
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. <a id="id4" class="footnote_reference" href="#protocol">2</a></p>
@ -35,7 +35,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">https://githu
<p>"Community Advisory Panel" refers to the panel of community members assembled by the Zcash Foundation and described at <a id="id6" class="footnote_reference" href="#zf-community">11</a>.</p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#protocol-networks">3</a>.</p>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" 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 Bootstrap Project (the parent of the Electric Coin Company);</li>
@ -44,13 +44,13 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">https://githu
</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 rel="bookmark" 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" class="section-anchor" 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 any other entities. Consequently, no substantial new funding may be available to existing teams dedicated to furthering charitable, educational, or scientific purposes, such as research, development, and outreach: 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 crucial charitable, educational, and/or scientific aspects, such as research, 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>
<p>For these reasons, the Zcash Community desires to allocate and contribute a slice of the block subsidies otherwise allocated to miners as a donation to support charitable, educational, and scientific activities within the meaning of Section 501(c)(3).</p>
</section>
<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>
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" 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>
@ -61,13 +61,13 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Consensus changes implied by this specification are applicable to the Zcash Mainnet. Similar (but not necessarily identical) consensus changes SHOULD be applied to the Zcash Testnet for testing purposes.</p>
<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>
<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" class="section-anchor" 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 Bootstrap Project (denoted <strong>BP slice</strong>);</li>
@ -75,13 +75,13 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">https://githu
<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="bp-slice-bootstrap-project"><h4><span class="section-heading">BP slice (Bootstrap Project)</span><span class="section-anchor"> <a rel="bookmark" href="#bp-slice-bootstrap-project"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="bp-slice-bootstrap-project"><h4><span class="section-heading">BP slice (Bootstrap Project)</span><span class="section-anchor"> <a rel="bookmark" href="#bp-slice-bootstrap-project"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>This slice of the Dev Fund will flow as charitable contributions from the Zcash Community to the Bootstrap Project, the newly formed parent organization to the Electric Coin Company. The Bootstrap Project is organized for exempt educational, charitable, and scientific purposes in compliance with Section 501(c)(3), including but not limited to furthering education, information, resources, advocacy, support, community, and research relating to cryptocurrency and privacy, including Zcash. This slice will be used at the discretion of the Bootstrap Project for any purpose within its mandate to support financial privacy and the Zcash platform as permitted under Section 501(c)(3). The BP slice will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.</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 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>
<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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>This slice of the Dev Fund will flow as charitable contributions from the Zcash Community to ZF, to be used at its discretion for any purpose within its mandate to support financial privacy and the Zcash platform, including: development, education, supporting community communication online and via events, gathering community sentiment, and awarding external grants for all of the above, subject to the requirements of Section 501(c)(3). The ZF slice will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.</p>
</section>
<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>
<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" class="section-anchor" 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 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">https://githu
</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 rel="bookmark" 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" class="section-anchor" 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 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>
<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" class="section-anchor" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>BP, 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 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">https://githu
<p>BP's reports, 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="id8" class="footnote_reference" href="#osd">5</a>), preferably the MIT license.</p>
</section>
<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>
<section id="enforcement"><h4><span class="section-heading">Enforcement</span><span class="section-anchor"> <a rel="bookmark" href="#enforcement"><img width="24" height="24" class="section-anchor" 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>BP, 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 rel="bookmark" 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" class="section-anchor" 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 Advisory Panel or a successor mechanism– and to integrate them into this process by the end of 2021. BP, 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 rel="bookmark" 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" class="section-anchor" 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 ZF 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 Zcash Foundation SHOULD endeavor to use the Community Advisory 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 rel="bookmark" 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" class="section-anchor" 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="id9" class="footnote_reference" href="#zip-1012">10</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="id10" class="footnote_reference" href="#zip-1011">9</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="id11" class="footnote_reference" href="#zip-1003">7</a>, Josh Cincinnati's 'Compromise Dev Fund Proposal With Diverse Funding Streams' (ZIP 1010) <a id="id12" class="footnote_reference" href="#zip-1010">8</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 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>

24
zip-guide.html
View File

@ -17,11 +17,11 @@ Category: {Consensus | Standards Track | Network | RPC | Wallet | Informational
Created: yyyy-mm-dd
License: {usually MIT}
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/253">https://github.com/zcash/zips/pull/253</a>&gt;</pre>
<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>
<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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -31,29 +31,29 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/253">https://githu
<dd>{Definition.}</dd>
</dl>
</section>
<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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" 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> <a id="id3" class="footnote_reference" href="#protocol-introduction">3</a>.}</p>
</section>
<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="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" 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>
@ -61,7 +61,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/253">https://githu
<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 rel="bookmark" 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" class="section-anchor" 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 <code>rst2html5</code>. E.g. on Debian-based distros:</p>
<pre>sudo apt-get install python3-pip pandoc perl sed
sudo pip3 install rst2html5</pre>
@ -70,10 +70,10 @@ sudo pip3 install rst2html5</pre>
<p>(or just <code>make</code>) 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 rel="bookmark" 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" class="section-anchor" 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 rel="bookmark" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>