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

Merge remote-tracking branch 'upstream/main' into zip-frost

This commit is contained in:
Conrado Gouvea 2023-08-21 18:21:40 -03:00
parent 7bffa045d6 c7a50bfd1b
commit e2c611d2cb
157 changed files with 3079 additions and 1321 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.github/workflows/render.yml vendored
View File

@ -8,12 +8,12 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Set up Git repository
uses: actions/checkout@v3.0.2
uses: actions/checkout@v3.5.3
- name: Compile Zcash Protocol Specification
uses: ./.github/actions/render-protocol-pdf
- uses: EndBug/add-and-commit@v9.0.0
- uses: EndBug/add-and-commit@v9.1.3
with:
add: '**/*.pdf'
default_author: github_actions

6
Makefile
View File

@ -1,6 +1,4 @@
# Dependencies:
# sudo apt-get install python3-pip pandoc perl sed
# sudo pip3 install rst2html5
# Dependencies: see zip-guide.rst and protocol/README.rst
.PHONY: all all-zips release protocol discard
all-zips: .Makefile.uptodate
@ -19,7 +17,7 @@ protocol:
$(MAKE) -C protocol
discard:
git checkout -- '*.html' 'protocol/*.pdf'
git checkout -- '*.html' 'README.rst' 'protocol/*.pdf'
.Makefile.uptodate: Makefile
$(MAKE) clean

10
README.rst
View File

@ -107,8 +107,8 @@ Index of ZIPs
<tr> <td>222</td> <td class="left"><a href="zip-0222.rst">Transparent Zcash Extensions</a></td> <td>Draft</td>
<tr> <td>224</td> <td class="left"><a href="zip-0224.rst">Orchard Shielded Protocol</a></td> <td>Final</td>
<tr> <td>225</td> <td class="left"><a href="zip-0225.rst">Version 5 Transaction Format</a></td> <td>Final</td>
<tr> <td><span class="reserved">226</span></td> <td class="left"><a class="reserved" href="zip-0226.rst">Zcash Shielded Assets - Transfers and Burns</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">227</span></td> <td class="left"><a class="reserved" href="zip-0227.rst">Zcash Shielded Assets - Issuance</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">226</span></td> <td class="left"><a class="reserved" href="zip-0226.rst">Transfer and Burn of Zcash Shielded Assets</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">227</span></td> <td class="left"><a class="reserved" href="zip-0227.rst">Issuance of Zcash Shielded Assets</a></td> <td>Reserved</td>
<tr> <td>239</td> <td class="left"><a href="zip-0239.rst">Relay of Version 5 Transactions</a></td> <td>Final</td>
<tr> <td>243</td> <td class="left"><a href="zip-0243.rst">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
<tr> <td>244</td> <td class="left"><a href="zip-0244.rst">Transaction Identifier Non-Malleability</a></td> <td>Final</td>
@ -133,12 +133,16 @@ Index of ZIPs
<tr> <td><span class="reserved">314</span></td> <td class="left"><a class="reserved" href="zip-0314.rst">Privacy upgrades to the Zcash light client protocol</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">315</span></td> <td class="left"><a class="reserved" href="zip-0315.rst">Best Practices for Wallet Handling of Multiple Pools</a></td> <td>Reserved</td>
<tr> <td>316</td> <td class="left"><a href="zip-0316.rst">Unified Addresses and Unified Viewing Keys</a></td> <td>Final</td>
<tr> <td>317</td> <td class="left"><a href="zip-0317.rst">Proportional Transfer Fee Mechanism</a></td> <td>Active</td>
<tr> <td><span class="reserved">318</span></td> <td class="left"><a class="reserved" href="zip-0318.rst">Associated Payload Encryption</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">319</span></td> <td class="left"><a class="reserved" href="zip-0319.rst">Options for Shielded Pool Retirement</a></td> <td>Reserved</td>
<tr> <td>321</td> <td class="left"><a href="zip-0321.rst">Payment Request URIs</a></td> <td>Proposed</td>
<tr> <td><span class="reserved">322</span></td> <td class="left"><a class="reserved" href="zip-0322.rst">Generic Signed Message Format</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">323</span></td> <td class="left"><a class="reserved" href="zip-0323.rst">Specification of getblocktemplate for Zcash</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">332</span></td> <td class="left"><a class="reserved" href="zip-0332.rst">Wallet Recovery from zcashd HD Seeds</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">339</span></td> <td class="left"><a class="reserved" href="zip-0339.rst">Wallet Recovery Words</a></td> <td>Reserved</td>
<tr> <td>400</td> <td class="left"><a href="zip-0400.rst">Wallet.dat format</a></td> <td>Draft</td>
<tr> <td>401</td> <td class="left"><a href="zip-0401.rst">Addressing Mempool Denial-of-Service</a></td> <td>Final</td>
<tr> <td>401</td> <td class="left"><a href="zip-0401.rst">Addressing Mempool Denial-of-Service</a></td> <td>Active</td>
<tr> <td><span class="reserved">402</span></td> <td class="left"><a class="reserved" href="zip-0402.rst">New Wallet Database Format</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">403</span></td> <td class="left"><a class="reserved" href="zip-0403.rst">Verification Behaviour of zcashd</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">416</span></td> <td class="left"><a class="reserved" href="zip-0416.rst">Support for Unified Addresses in zcashd</a></td> <td>Reserved</td>

42
css/style.css
View File

@ -103,10 +103,12 @@ h5, h6, h7, h8 {
h1 {
font-size: 2.5rem;
margin-bottom: 1.5rem;
}
h2 {
font-size: 2.125rem;
margin-bottom: 1.125rem;
}
h3 {
@ -131,17 +133,14 @@ h5 {
h6 {
font-size: 1.3rem;
bottom-padding: 2rem;
}
h7 {
font-size: 1.25rem;
bottom-padding: 2rem;
}
h8 {
font-size: 1.2rem;
bottom-padding: 2rem;
}
blockquote {
@ -150,24 +149,32 @@ blockquote {
overflow-x: auto;
}
p, ul, ol, li, table {
margin-top: 0;
}
p {
margin-bottom: 1rem;
margin-top: 0;
margin-bottom: calc( 1rem + 1ex );
}
li {
margin-bottom: 0.2rem;
table {
margin-top: 0.5rem;
margin-bottom: calc( 1rem + 1ex );
}
ul, ol {
margin-top: -0.4rem;
margin-bottom: calc( 0.5rem + 1ex );
}
li ol {
margin-top: 0.25ex;
}
li ul {
margin-top: 0.625rem;
margin-top: 0.25ex;
}
ul, ol, table {
margin-bottom: calc( 0.5rem + 0.5ex );
li {
margin-top: 0.5ex;
margin-bottom: 0.5rem;
}
p, ul, ol, dl, table {
@ -194,13 +201,18 @@ span.math {
}
div.math {
transform: scale(1.3, 1.339);
-moz-transform: scale(1.3, 1.339);
-ms-transform: scale(1.3, 1.339);
-webkit-transform: scale(1.3, 1.339);
-o-transform: scale(1.3, 1.339);
display: block;
overflow-x: auto;
overflow-y: hidden;
margin: 0 1rem 1rem 1rem;
margin: 2.6rem 1rem 2.6rem 1rem;
text-align: center;
padding: 0;
font-size: 0.75rem;
font-size: 0.97rem;
}
a, a:visited {

10
index.html
View File

@ -81,8 +81,8 @@
<tr> <td>222</td> <td class="left"><a href="zip-0222">Transparent Zcash Extensions</a></td> <td>Draft</td>
<tr> <td>224</td> <td class="left"><a href="zip-0224">Orchard Shielded Protocol</a></td> <td>Final</td>
<tr> <td>225</td> <td class="left"><a href="zip-0225">Version 5 Transaction Format</a></td> <td>Final</td>
<tr> <td><span class="reserved">226</span></td> <td class="left"><a class="reserved" href="zip-0226">Zcash Shielded Assets - Transfers and Burns</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">227</span></td> <td class="left"><a class="reserved" href="zip-0227">Zcash Shielded Assets - Issuance</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">226</span></td> <td class="left"><a class="reserved" href="zip-0226">Transfer and Burn of Zcash Shielded Assets</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">227</span></td> <td class="left"><a class="reserved" href="zip-0227">Issuance of Zcash Shielded Assets</a></td> <td>Reserved</td>
<tr> <td>239</td> <td class="left"><a href="zip-0239">Relay of Version 5 Transactions</a></td> <td>Final</td>
<tr> <td>243</td> <td class="left"><a href="zip-0243">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
<tr> <td>244</td> <td class="left"><a href="zip-0244">Transaction Identifier Non-Malleability</a></td> <td>Final</td>
@ -107,12 +107,16 @@
<tr> <td><span class="reserved">314</span></td> <td class="left"><a class="reserved" href="zip-0314">Privacy upgrades to the Zcash light client protocol</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">315</span></td> <td class="left"><a class="reserved" href="zip-0315">Best Practices for Wallet Handling of Multiple Pools</a></td> <td>Reserved</td>
<tr> <td>316</td> <td class="left"><a href="zip-0316">Unified Addresses and Unified Viewing Keys</a></td> <td>Final</td>
<tr> <td>317</td> <td class="left"><a href="zip-0317">Proportional Transfer Fee Mechanism</a></td> <td>Active</td>
<tr> <td><span class="reserved">318</span></td> <td class="left"><a class="reserved" href="zip-0318">Associated Payload Encryption</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">319</span></td> <td class="left"><a class="reserved" href="zip-0319">Options for Shielded Pool Retirement</a></td> <td>Reserved</td>
<tr> <td>321</td> <td class="left"><a href="zip-0321">Payment Request URIs</a></td> <td>Proposed</td>
<tr> <td><span class="reserved">322</span></td> <td class="left"><a class="reserved" href="zip-0322">Generic Signed Message Format</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">323</span></td> <td class="left"><a class="reserved" href="zip-0323">Specification of getblocktemplate for Zcash</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">332</span></td> <td class="left"><a class="reserved" href="zip-0332">Wallet Recovery from zcashd HD Seeds</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">339</span></td> <td class="left"><a class="reserved" href="zip-0339">Wallet Recovery Words</a></td> <td>Reserved</td>
<tr> <td>400</td> <td class="left"><a href="zip-0400">Wallet.dat format</a></td> <td>Draft</td>
<tr> <td>401</td> <td class="left"><a href="zip-0401">Addressing Mempool Denial-of-Service</a></td> <td>Final</td>
<tr> <td>401</td> <td class="left"><a href="zip-0401">Addressing Mempool Denial-of-Service</a></td> <td>Active</td>
<tr> <td><span class="reserved">402</span></td> <td class="left"><a class="reserved" href="zip-0402">New Wallet Database Format</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">403</span></td> <td class="left"><a class="reserved" href="zip-0403">Verification Behaviour of zcashd</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">416</span></td> <td class="left"><a class="reserved" href="zip-0416">Support for Unified Addresses in zcashd</a></td> <td>Reserved</td>

7
protocol/Makefile
View File

@ -1,3 +1,5 @@
# Dependencies: see zip-guide.rst and protocol/README.rst
SHELL=/bin/bash -eo pipefail
# Experimental; options are pdflatex, lualatex, or xelatex.
@ -63,6 +65,7 @@ auxsapling:
printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/sapling.*
cp mymakeindex.sh aux
$(LATEXMK) -jobname=sapling -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
.PHONY: sapling
@ -75,6 +78,7 @@ auxblossom:
printf '\\toggletrue{isblossom}\n\\renewcommand{\\docversion}{Version %s [\\BlossomSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/blossom.*
cp mymakeindex.sh aux
$(LATEXMK) -jobname=blossom -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
.PHONY: blossom
@ -87,6 +91,7 @@ auxheartwood:
printf '\\toggletrue{isheartwood}\n\\renewcommand{\\docversion}{Version %s [\\HeartwoodSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/heartwood.*
cp mymakeindex.sh aux
$(LATEXMK) -jobname=heartwood -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
.PHONY: heartwood
@ -99,6 +104,7 @@ auxcanopy:
printf '\\toggletrue{iscanopy}\n\\renewcommand{\\docversion}{Version %s [\\CanopySpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/canopy.*
cp mymakeindex.sh aux
$(LATEXMK) -jobname=canopy -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
.PHONY: canopy
@ -111,6 +117,7 @@ auxnu5:
printf '\\toggletrue{isnufive}\n\\renewcommand{\\docversion}{Version %s [\\NUFiveSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/nu5.*
cp mymakeindex.sh aux
$(LATEXMK) -jobname=nu5 -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
.PHONY: nu5

17
protocol/README.rst
View File

@ -6,8 +6,17 @@ Build dependencies on Debian-based systems include, at least:
.. code::
apt-get install texlive texlive-science texlive-fonts-extra \
texlive-generic-recommended texlive-bibtex-extra biber latexmk perl awk
apt install python3-pip pandoc perl sed perl \
texlive texlive-science texlive-fonts-extra texlive-bibtex-extra biber latexmk
Prior to Bullseye you may also need the ``awk`` and ``texlive-generic-recommended``
packages.
For link checking, you will also need the following Python packages:
.. code::
pip3 install docutils==0.19 rst2html5 certifi PyPDF2
Building
@ -23,8 +32,10 @@ Use:
Sapling upgrades (``sapling.pdf``);
* ``make sprout`` to make a version of the specification that does not
include Overwinter or Sapling (``sprout.pdf``).
* ``make linkcheck`` (in the root of the repo) to build everything and also
perform link checking. This will access the network.
``make all`` is equivalent to ``make nufour heartwood blossom sapling sprout``.
``make all`` is equivalent to ``make nu5 canopy heartwood blossom sapling``.
By default these use ``latexmk``. If you have trouble getting ``latexmk`` to
work, you can instead use ``make nolatexmk-sapling``, etc. That is not the

BIN
protocol/blossom.pdf
View File

Binary file not shown.

BIN
protocol/canopy.pdf
View File

Binary file not shown.

BIN
protocol/heartwood.pdf
View File

Binary file not shown.

BIN
protocol/nu5.pdf
View File

Binary file not shown.

BIN
protocol/protocol.pdf
View File

Binary file not shown.

352
protocol/protocol.tex
View File

File diff suppressed because it is too large Load Diff

BIN
protocol/sapling.pdf
View File

Binary file not shown.

8
protocol/zcash.bib
View File

@ -554,8 +554,8 @@ Last updated December~16, 2020.}
presort={BDPA2007},
author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van Assche}},
title={Sponge functions},
url={https://www.researchgate.net/publication/242285874_Sponge_Functions},
urldate={2021-03-01},
url={https://keccak.team/files/SpongeFunctions.pdf},
urldate={2022-08-31},
howpublished={ECRYPT Hash Workshop (May 2007), also available as a public comment to NIST
as part of the Hash Algorithm Requirements and Evaluation Criteria for the SHA-3 competition.}
}
@ -1892,8 +1892,8 @@ Proceedings of the 14th Annual International Cryptology Conference
publisher={Springer},
isbn={978-3-540-48184-3},
doi={10.1007/3-540-48184-2_7},
url={https://www.researchgate.net/profile/Jeroen_Van_de_Graaf/publication/242379939_Multiparty_computations_ensuring_secrecy_of_each_party%27s_input_and_correctness_of_the_output},
urldate={2018-03-01}
url={https://link.springer.com/content/pdf/10.1007%2F3-540-48184-2_7.pdf},
urldate={2022-08-31}
}
@misc{Carroll1876,

93
zip-0000.html
View File

@ -8,9 +8,9 @@
<section>
<pre>ZIP: 0
Title: ZIP Process
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Deirdre Connolly &lt;deirdre@zfnd.org&gt;
Original-Authors: Daira Hopwood
Original-Authors: Daira Emma Hopwood
Josh Cincinnati
George Tankersley
Credits: Luke Dashjr
@ -19,8 +19,8 @@ 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" 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>
<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="footnote-reference-1" 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="footnote-reference-2" 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" 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>
@ -31,7 +31,7 @@ License: BSD-2-Clause</pre>
<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>
<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 ZIPs git repository <a id="footnote-reference-3" class="footnote_reference" href="#zips-repo">8</a> as a pull request. This draft must be written in ZIP style as described below, and named with an alias such as <code>draft-zatoshizakamoto-42millionzec</code> until the ZIP Editors have assigned it a ZIP number (Owners MUST NOT self-assign ZIP numbers).</p>
<p>ZIP Owners are responsible for collecting community feedback on both the initial idea and the ZIP before submitting it for review. However, wherever possible, long open-ended discussions on forums should be avoided.</p>
<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>
@ -43,30 +43,31 @@ License: BSD-2-Clause</pre>
<li>if it affects the consensus layer or the core protocol, assign a number in the range 200..299;</li>
<li>if it affects only higher layers but is needed for interoperability between node implementations or other parts of the ecosystem, assign a number in the range 300..399;</li>
<li>if it is specific to an implementation (e.g. zcashd or zebra), assign a number in the range 400..499;</li>
<li>if it concerns Consensus Process, assign a number in the range 0..9 or above 1000;</li>
<li>try to number ZIPs that should or will be deployed together consecutively (subject to the above conventions), and in a coherent reading order.</li>
</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" 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>
<p>If you are interested in assuming ownership of a ZIP, send a message asking to take over, addressed to all of the current Owner(s) and the ZIP Editors. If the Owner(s) who are proposed to be removed don't respond in a timely manner, the ZIP Editors and any remaining current Owners will make a decision (such decisions may 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 (without email addresses), 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" 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>
<p>The current ZIP Editors are Daira Emma 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" 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>
<p>For each new ZIP that comes in, a ZIP Editor confirms the following:</p>
<ul>
<li>Read the ZIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.</li>
<li>The title should accurately describe the content.</li>
<li>The ZIP draft must have been sent to the Zcash Community Forum or as a PR to the <a href="https://github.com/zcash/zips">ZIPs git repository</a></li>
<li>The ZIP draft must have been sent to the Zcash Community Forum or as a PR to the ZIPs git repository <a id="footnote-reference-4" class="footnote_reference" href="#zips-repo">8</a>.</li>
<li>Motivation and backward compatibility (when applicable) must be addressed.</li>
<li>The licensing terms are acceptable for ZIPs.</li>
</ul>
<p>If the ZIP isn't ready, the editor will send it back to the Owners for revision, with specific instructions.</p>
<p>Once the ZIP is ready for the repository it SHOULD be submitted as a "pull request" to the <a href="https://github.com/zcash/zips">ZIPs git repository</a> where it may get further feedback. It SHOULD NOT contain a ZIP number unless one had already been assigned by the ZIP Editors. The pull request SHOULD initially be marked as a Draft.</p>
<p>Once the ZIP is ready for the repository it SHOULD be submitted as a "pull request" to the ZIPs git repository <a id="footnote-reference-5" class="footnote_reference" href="#zips-repo">8</a> where it may get further feedback. It SHOULD NOT contain a ZIP number unless one had already been assigned by the ZIP Editors. The pull request SHOULD initially be marked as a Draft.</p>
<p>The ZIP Editors will:</p>
<ul>
<li>Assign a ZIP number in the pull request.</li>
@ -75,7 +76,7 @@ License: BSD-2-Clause</pre>
<p>The ZIP editors monitor ZIP changes and update ZIP headers as appropriate.</p>
<p>The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP for any of the following reasons:</p>
<ul>
<li>it violates the Zcash Code of Conduct <a id="id3" class="footnote_reference" href="#conduct">4</a> ;</li>
<li>it violates the Zcash Code of Conduct <a id="footnote-reference-6" class="footnote_reference" href="#conduct">4</a> ;</li>
<li>it appears too unfocused or broad;</li>
<li>it duplicates effort in other ZIPs without sufficient technical justification (however, alternative proposals to address similar or overlapping problems are not excluded for this reason);</li>
<li>it has manifest security flaws (including being unrealistically dependent on user vigilance to avoid security weaknesses);</li>
@ -93,17 +94,17 @@ License: BSD-2-Clause</pre>
<li>a new ZIP has been proposed for a category that does not reflect its content, or an update would change a ZIP to an inappropriate category;</li>
<li>it updates a Released ZIP to Draft when the specification is already implemented and has been in common use;</li>
<li>it violates any specific "MUST" or "MUST NOT" rule in this document;</li>
<li>the expressed political views of a Owner of the document are inimical to the Zcash Code of Conduct <a id="id4" class="footnote_reference" href="#conduct">4</a> (except in the case of an update removing that Owner);</li>
<li>the expressed political views of a Owner of the document are inimical to the Zcash Code of Conduct <a id="footnote-reference-7" class="footnote_reference" href="#conduct">4</a> (except in the case of an update removing that Owner);</li>
<li>it is not authorized by the stated ZIP Owners;</li>
<li>it removes an Owner without their consent (unless the reason for removal is directly related to a breach of the Code of Conduct by that Owner).</li>
</ul>
<p>The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal or update that does not violate any of these criteria. If they refuse a proposal or update, they MUST give an explanation of which of the criteria were violated, with the exception that spam may be deleted without an explanation.</p>
<p>Note that it is not the primary responsibility of the ZIP Editors to review proposals for security, correctness, or implementability.</p>
<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>
<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="footnote-reference-8" 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" 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>ZIPs SHOULD be written in reStructuredText <a id="footnote-reference-9" class="footnote_reference" href="#rst">5</a>, Markdown <a id="footnote-reference-10" class="footnote_reference" href="#markdown">6</a>, or LaTeX <a id="footnote-reference-11" 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>
<li>Preamble — Headers containing metadata about the ZIP (<a href="#zip-header-preamble">see below</a>). The License field of the preamble indicates the licensing terms, which MUST be acceptable according to <a href="#zip-licensing">the ZIP licensing requirements</a>.</li>
@ -111,13 +112,55 @@ License: BSD-2-Clause</pre>
<li>Abstract — A short (~200 word) description of the technical issue being addressed.</li>
<li>Motivation — The motivation is critical for ZIPs that want to change the Zcash protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the ZIP solves.</li>
<li>Specification — The technical specification should describe the interface and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Zcash platforms.</li>
<li>Rationale — The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.</li>
<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>Rationale — The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
<p>For longer ZIPs it can potentially be easier to have inline Rationale subsections interspersed throughout the Specification part. When taking this approach, the content of these subsections should be annotated with HTML tags to make it collapsible (so the rationale is available for review but doesn't get in the way of reading the specification). ZIPs written in Markdown can use the following syntax (note the newline after the <code>&lt;summary&gt;</code> tag):</p>
<pre># Specification
## Foobar
Important details.
&lt;details&gt;
&lt;summary&gt;
### Rationale for foobar
&lt;/summary&gt;
Important but hidden rationale!
&lt;/details&gt;</pre>
<p>ZIPs written in reStructuredText can use the following syntax:</p>
<pre>Specification
=============
Foobar
------
Important details.
Rationale for foobar
''''''''''''''''''''
.. raw:: html
&lt;details&gt;
&lt;summary&gt;Click to show/hide&lt;/summary&gt;
Important but hidden rationale!
.. raw:: html
&lt;/details&gt;</pre>
</li>
<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="footnote-reference-12" 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-stubs"><h3><span class="section-heading">ZIP stubs</span><span class="section-anchor"> <a rel="bookmark" href="#zip-stubs"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A ZIP stub records that the ZIP Editors have reserved a number for a ZIP that is under development. It is not a ZIP, but exists in the ZIPs git repository <a id="footnote-reference-13" class="footnote_reference" href="#zips-repo">8</a> at the same path that will be used for the corresponding ZIP if and when it is published. It consists only of a preamble.</p>
<p>ZIP stubs can be added and removed, or replaced by the corresponding ZIP, at the discretion of the ZIP Editors. If a ZIP stub is removed then its number MAY be reused, possibly for an entirely different ZIP.</p>
</section>
<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>
<p>Each ZIP or ZIP stub MUST begin with a RFC 822-style header preamble. For ZIPs and ZIP stubs 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 for ZIPs:</p>
<pre>ZIP:
Title:
Owners:
@ -125,7 +168,7 @@ Status:
Category:
Created:
License:</pre>
<p>The following additional header fields are OPTIONAL:</p>
<p>The following additional header fields are OPTIONAL for ZIPs:</p>
<pre>Credits:
Original-Authors:
Discussions-To:
@ -134,9 +177,11 @@ Obsoleted by:
Updated by:
Obsoletes:
Updates:</pre>
<p>For ZIP stubs, only the ZIP:, Title:, Status:, and Category: fields are REQUIRED. Typically the other fields applicable to ZIP stubs are Credits:, Discussions-To: and Pull-Request:, which are OPTIONAL.</p>
<p>The Owners header lists the names and email addresses of all the Owners of the ZIP. The format of the Owners header value SHOULD be:</p>
<pre>Random J. User &lt;address@dom.ain&gt;</pre>
<p>If there are multiple Owners, each should be on a separate line.</p>
<p>Credits: and Original-Authors: fields SHOULD NOT include email addresses.</p>
<p>The "Owners", "Credits", and "Original-Authors" headers always use these plural spellings even there is only one Owner, one person to be credited, or one original author.</p>
<p>While a ZIP is in public discussions (usually during the initial Draft phase), a Discussions-To header will indicate the URL where the ZIP is being discussed. No Discussions-To header is necessary if the ZIP is being discussed privately with the Owner.</p>
<p>The Pull-Request header, if present, gives an URL to a Pull Request for the ZIP.</p>
@ -311,6 +356,14 @@ Updates:</pre>
</tr>
</tbody>
</table>
<table id="zips-repo" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="https://github.com/zcash/zips">ZIPs git repository</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>

122
zip-0000.rst
View File

@ -2,9 +2,9 @@
ZIP: 0
Title: ZIP Process
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Deirdre Connolly <deirdre@zfnd.org>
Original-Authors: Daira Hopwood
Original-Authors: Daira Emma Hopwood
Josh Cincinnati
George Tankersley
Credits: Luke Dashjr
@ -81,11 +81,11 @@ has any chance of acceptance, a draft ZIP should be presented to the
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 `ZIPs git repository <https://github.com/zcash/zips>`__
as a pull request. This draft must be written in ZIP style as described
below, and named with an alias such as
``zip-zatoshizakamoto-42millionzec`` until the ZIP Editors have assigned
it a ZIP number (Owners MUST NOT self-assign ZIP numbers).
submitted to the ZIPs git repository [#zips-repo]_ as a pull request.
This draft must be written in ZIP style as described below, and named
with an alias such as ``draft-zatoshizakamoto-42millionzec`` until the
ZIP Editors have assigned it a ZIP number (Owners MUST NOT self-assign
ZIP numbers).
ZIP Owners are responsible for collecting community feedback on both
the initial idea and the ZIP before submitting it for review. However,
@ -126,6 +126,8 @@ ZIPs:
a number in the range 300..399;
* if it is specific to an implementation (e.g. zcashd or zebra), assign
a number in the range 400..499;
* if it concerns Consensus Process, assign a number in the range 0..9
or above 1000;
* try to number ZIPs that should or will be deployed together
consecutively (subject to the above conventions), and in a coherent
reading order.
@ -148,20 +150,20 @@ ZIP. We try to build consensus around a ZIP, but if that's not possible,
you can always submit a competing ZIP.
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 :).
asking to take over, addressed to all of the current Owner(s) and the
ZIP Editors. If the Owner(s) who are proposed to be removed don't respond
in a timely manner, the ZIP Editors and any remaining current Owners will
make a decision (such decisions may be reversed).
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.
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
(without email addresses), unless the original author(s) request otherwise.
ZIP Editors
-----------
The current ZIP Editors are Daira Hopwood, representing the Electric Coin
The current ZIP Editors are Daira Emma Hopwood, representing the Electric Coin
Company, and Deirdre Connolly, representing the Zcash Foundation. Both
can be reached at zips@z.cash . The current design of the ZIP Process
dictates that there are always at least two ZIP Editors: one from the
@ -175,14 +177,14 @@ ZIP Editor Responsibilities & Workflow
The ZIP Editors subscribe to the `Zcash Community Forum.
<https://forum.zcashcommunity.com/>`__
For each new ZIP that comes in an Editor confirms the following:
For each new ZIP that comes in, a ZIP Editor confirms the following:
* Read the ZIP to check if it is ready: sound and complete. The ideas
must make technical sense, even if they don't seem likely to be
accepted.
* The title should accurately describe the content.
* The ZIP draft must have been sent to the Zcash Community Forum or as
a PR to the `ZIPs git repository <https://github.com/zcash/zips>`__
a PR to the ZIPs git repository [#zips-repo]_.
* Motivation and backward compatibility (when applicable) must be
addressed.
* The licensing terms are acceptable for ZIPs.
@ -191,10 +193,10 @@ If the ZIP isn't ready, the editor will send it back to the Owners for
revision, with specific instructions.
Once the ZIP is ready for the repository it SHOULD be submitted as a
"pull request" to the `ZIPs git repository <https://github.com/zcash/zips>`__
where it may get further feedback. It SHOULD NOT contain a ZIP number
unless one had already been assigned by the ZIP Editors. The pull
request SHOULD initially be marked as a Draft.
"pull request" to the ZIPs git repository [#zips-repo]_ where it may
get further feedback. It SHOULD NOT contain a ZIP number unless one
had already been assigned by the ZIP Editors. The pull request SHOULD
initially be marked as a Draft.
The ZIP Editors will:
@ -298,6 +300,53 @@ Each ZIP SHOULD have the following parts:
consensus within the community and discuss important objections or
concerns raised during discussion.
For longer ZIPs it can potentially be easier to have inline Rationale
subsections interspersed throughout the Specification part. When taking
this approach, the content of these subsections should be annotated
with HTML tags to make it collapsible (so the rationale is available
for review but doesn't get in the way of reading the specification).
ZIPs written in Markdown can use the following syntax (note the
newline after the ``<summary>`` tag)::
# Specification
## Foobar
Important details.
<details>
<summary>
### Rationale for foobar
</summary>
Important but hidden rationale!
</details>
ZIPs written in reStructuredText can use the following syntax::
Specification
=============
Foobar
------
Important details.
Rationale for foobar
''''''''''''''''''''
.. raw:: html
<details>
<summary>Click to show/hide</summary>
Important but hidden rationale!
.. raw:: html
</details>
* 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
@ -310,14 +359,28 @@ Each ZIP SHOULD have the following parts:
but it generally need not be completed before the ZIP is accepted
into “Proposed”.
ZIP stubs
---------
A ZIP stub records that the ZIP Editors have reserved a number for a
ZIP that is under development. It is not a ZIP, but exists in the ZIPs
git repository [#zips-repo]_ at the same path that will be used for the
corresponding ZIP if and when it is published. It consists only of a
preamble.
ZIP stubs can be added and removed, or replaced by the corresponding ZIP,
at the discretion of the ZIP Editors. If a ZIP stub is removed then its
number MAY be reused, possibly for an entirely different ZIP.
ZIP header preamble
-------------------
Each ZIP MUST begin with a RFC 822-style header preamble. For ZIPs written
in reStructuredText, this is represented as ``::`` on the first line,
followed by a blank line, then the preamble indented by 2 spaces.
Each ZIP or ZIP stub MUST begin with a RFC 822-style header preamble.
For ZIPs and ZIP stubs written in reStructuredText, this is represented
as ``::`` on the first line, followed by a blank line, then the preamble
indented by 2 spaces.
The following header fields are REQUIRED::
The following header fields are REQUIRED for ZIPs::
ZIP:
Title:
@ -327,7 +390,7 @@ The following header fields are REQUIRED::
Created:
License:
The following additional header fields are OPTIONAL::
The following additional header fields are OPTIONAL for ZIPs::
Credits:
Original-Authors:
@ -338,6 +401,10 @@ The following additional header fields are OPTIONAL::
Obsoletes:
Updates:
For ZIP stubs, only the ZIP:, Title:, Status:, and Category: fields
are REQUIRED. Typically the other fields applicable to ZIP stubs are
Credits:, Discussions-To: and Pull-Request:, which are OPTIONAL.
The Owners header lists the names and email addresses of all the
Owners of the ZIP. The format of the Owners header value SHOULD be::
@ -345,6 +412,8 @@ Owners of the ZIP. The format of the Owners header value SHOULD be::
If there are multiple Owners, each should be on a separate line.
Credits: and Original-Authors: fields SHOULD NOT include email addresses.
The "Owners", "Credits", and "Original-Authors" headers always use
these plural spellings even there is only one Owner, one person to be
credited, or one original author.
@ -635,3 +704,4 @@ References
.. [#rst] `reStructuredText documentation <https://docutils.sourceforge.io/rst.html>`_
.. [#markdown] `The Markdown Guide <https://www.markdownguide.org/>`_
.. [#latex] `LaTeX — a document preparation system <https://www.latex-project.org/>`_
.. [#zips-repo] `ZIPs git repository <https://github.com/zcash/zips>`_

84
zip-0032.html
View File

@ -10,7 +10,7 @@
<pre>ZIP: 32
Title: Shielded Hierarchical Deterministic Wallets
Owners: Jack Grigg &lt;str4d@electriccoin.co&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Credits: Sean Bowe
Kris Nuttycombe
Ying Tong Lai
@ -25,34 +25,34 @@ License: MIT</pre>
<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" 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">15</a>.</p>
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>"Jubjub" refers to the elliptic curve defined in <a id="footnote-reference-2" class="footnote_reference" href="#protocol-jubjub">15</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">10</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="footnote-reference-3" class="footnote_reference" href="#protocol-networks">10</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" 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>This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 <a id="footnote-reference-4" 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>
<li>Sapling</li>
<li>Orchard</li>
</ul>
<p>Previous versions of this document also defined a similar derivation system for the Sprout shielded pool. This has been removed since it was never used, and is unlikely to be used given that <cite>zcashd</cite> no longer generates Sprout addresses (and neither <cite>Zebra</cite> nor the mobile SDKs have ever done so).</p>
<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>The last part shows how to use these trees in the context of existing BIP 44 <a id="footnote-reference-5" 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" 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>
<p>BIP 32 <a id="footnote-reference-6" 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="footnote-reference-7" 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>
<li>A one-time backup of the seed (usually stored as a word phrase <a id="id8" class="footnote_reference" href="#bip-0039">3</a>) can be used to recover funds from all future addresses.</li>
<li>A one-time backup of the seed (usually stored as a word phrase <a id="footnote-reference-8" class="footnote_reference" href="#bip-0039">3</a>) can be used to recover funds from all future addresses.</li>
<li>Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level structures.</li>
<li>Viewing authority or spending authority can be delegated independently for sub-trees without compromising the master seed.</li>
</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" 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">9</a>. They are reproduced here for convenience:</p>
<p>Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification <a id="footnote-reference-9" class="footnote_reference" href="#protocol">9</a>. They are reproduced here for convenience:</p>
<ul>
<li>
<span class="math">\(\mathsf{truncate}_k(S)\)</span>
@ -104,7 +104,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{repr}_\mathbb{J}(P)\)</span>
is the representation of the Jubjub elliptic curve point
<span class="math">\(P\)</span>
as a bit sequence, defined in <a id="id10" class="footnote_reference" href="#protocol-jubjub">15</a>.</li>
as a bit sequence, defined in <a id="footnote-reference-10" class="footnote_reference" href="#protocol-jubjub">15</a>.</li>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\)</span>
refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string
@ -144,9 +144,9 @@ License: MIT</pre>
<span class="math">\(d\)</span>
to a base point on the Jubjub elliptic curve, or to
<span class="math">\(\bot\)</span>
if the diversifier is invalid. It is instantiated in <a id="id11" class="footnote_reference" href="#protocol-concretediversifyhash">13</a>.</li>
if the diversifier is invalid. It is instantiated in <a id="footnote-reference-11" class="footnote_reference" href="#protocol-concretediversifyhash">13</a>.</li>
</ul>
<p>The following algorithm standardized in <a id="id12" class="footnote_reference" href="#nist-sp-800-38g">22</a> is used:</p>
<p>The following algorithm standardized in <a id="footnote-reference-12" class="footnote_reference" href="#nist-sp-800-38g">22</a> is used:</p>
<ul>
<li>
<span class="math">\(\mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(key, tweak, x)\)</span>
@ -181,11 +181,11 @@ License: MIT</pre>
.</li>
</ul>
<p>Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling and Orchard specifications), which is the opposite of BIP 32.</p>
<p>We adapt the path notation of BIP 32 <a id="id13" class="footnote_reference" href="#bip-0032">2</a> to describe shielded HD paths, using prime marks (
<p>We adapt the path notation of BIP 32 <a id="footnote-reference-13" class="footnote_reference" href="#bip-0032">2</a> to describe shielded HD paths, using prime marks (
<span class="math">\('\)</span>
) to indicate hardened derivation (
<span class="math">\(i' = i + 2^{31}\)</span>
) as in BIP 44 <a id="id14" class="footnote_reference" href="#bip-0044">5</a>:</p>
) as in BIP 44 <a id="footnote-reference-14" class="footnote_reference" href="#bip-0044">5</a>:</p>
<ul>
<li>
<span class="math">\(\mathsf{CDKfvk}(\mathsf{CDKfvk}(\mathsf{CDKfvk}(m_\mathsf{Sapling}, a), b), c)\)</span>
@ -269,7 +269,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{nsk}_m\)</span>
, and
<span class="math">\(\mathsf{ovk}_m\)</span>
via the standard Sapling derivation <a id="id15" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>:
via the standard Sapling derivation <a id="footnote-reference-15" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>:
<ul>
<li>
<span class="math">\(\mathsf{ask}_m = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))\)</span>
@ -303,7 +303,7 @@ License: MIT</pre>
<span class="math">\(0\)</span>
, or if the corresponding
<span class="math">\(\mathsf{ivk}\)</span>
derived as specified in <a id="id16" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
derived as specified in <a id="footnote-reference-16" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
@ -334,7 +334,7 @@ License: MIT</pre>
<span class="math">\((\mathsf{nk}_{par}, \mathsf{ak}_{par}, \mathsf{ovk}_{par})\)</span>
is the full viewing key derived from
<span class="math">\((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par})\)</span>
as described in <a id="id17" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
as described in <a id="footnote-reference-17" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
</ul>
</li>
<li>Split
@ -378,16 +378,16 @@ License: MIT</pre>
<span class="math">\(0\)</span>
, or if the corresponding
<span class="math">\(\mathsf{ivk}\)</span>
derived as specified in <a id="id18" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
derived as specified in <a id="footnote-reference-18" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Let
<span class="math">\(\mathcal{G}^\mathsf{Sapling}\)</span>
be as defined in <a id="id19" class="footnote_reference" href="#protocol-concretespendauthsig">14</a> and let
be as defined in <a id="footnote-reference-19" class="footnote_reference" href="#protocol-concretespendauthsig">14</a> and let
<span class="math">\(\mathcal{H}^\mathsf{Sapling}\)</span>
be as defined in <a id="id20" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
be as defined in <a id="footnote-reference-20" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
<p>
<span class="math">\(\mathsf{CDKfvk}((\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)\)</span>
<span class="math">\(\rightarrow (\mathsf{ak}_{i}, \mathsf{nk}_{i}, \mathsf{ovk}_{i}, \mathsf{dk}_{i}, \mathsf{c}_{i})\)</span>
@ -444,13 +444,13 @@ License: MIT</pre>
<span class="math">\(\mathsf{ak}_i\)</span>
is the zero point of Jubjub, or if the corresponding
<span class="math">\(\mathsf{ivk}\)</span>
derived as specified in <a id="id21" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
derived as specified in <a id="footnote-reference-21" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
</section>
<section id="sapling-internal-key-derivation"><h3><span class="section-heading">Sapling internal key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-internal-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree <a id="id22" class="footnote_reference" href="#bip-0044">5</a>, for any external full viewing key we only need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.</p>
<p>The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree <a id="footnote-reference-22" class="footnote_reference" href="#bip-0044">5</a>, for any external full viewing key we only need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.</p>
<section id="deriving-a-sapling-internal-spending-key"><h4><span class="section-heading">Deriving a Sapling internal spending key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-sapling-internal-spending-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Let
<span class="math">\((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk}, \mathsf{dk})\)</span>
@ -460,7 +460,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{ak}\)</span>
and
<span class="math">\(\mathsf{nk}\)</span>
as specified in <a id="id23" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
as specified in <a id="footnote-reference-23" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
<li>Let
<span class="math">\(I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))\)</span>
.</li>
@ -488,14 +488,14 @@ License: MIT</pre>
<span class="math">\(\mathsf{ak}\)</span>
is the zero point of Jubjub, or if the corresponding
<span class="math">\(\mathsf{ivk}\)</span>
derived as specified in <a id="id24" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
derived as specified in <a id="footnote-reference-24" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
<section id="deriving-a-sapling-internal-full-viewing-key"><h4><span class="section-heading">Deriving a Sapling internal full viewing key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-sapling-internal-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{H}^\mathsf{Sapling}\)</span>
be as defined in <a id="id25" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
be as defined in <a id="footnote-reference-25" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
<p>Let
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\)</span>
be the external full viewing key.</p>
@ -534,16 +534,16 @@ License: MIT</pre>
<span class="math">\(R\)</span>
are the same between deriving a full viewing key, and deriving the corresponding spending key. Both of these derivations are shown in the following diagram:</p>
<figure class="align-center" align="center">
<img width="900px" src="zip-0032-sapling-internal-key-derivation.png" />
<img width="900" src="zip-0032-sapling-internal-key-derivation.png" alt="" />
<figcaption>Diagram of Sapling internal key derivation</figcaption>
</figure>
<p>(For simplicity, the proof authorizing key is not shown.)</p>
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="id26" class="footnote_reference" href="#zip-0316">8</a>.</p>
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="footnote-reference-26" class="footnote_reference" href="#zip-0316">8</a>.</p>
<p>Note that the internal extended key is invalid if
<span class="math">\(\mathsf{ak}\)</span>
is the zero point of Jubjub, or if the corresponding
<span class="math">\(\mathsf{ivk_{internal}}\)</span>
derived from the internal full viewing key as specified in <a id="id27" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
derived from the internal full viewing key as specified in <a id="footnote-reference-27" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
@ -655,7 +655,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{c}_i\)</span>
.</li>
</ul>
<p>Note that the resulting child spending key may produce an invalid external FVK, as specified in <a id="id28" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>, with small probability. The corresponding internal FVK derived as specified in the next section may also be invalid with small probability.</p>
<p>Note that the resulting child spending key may produce an invalid external FVK, as specified in <a id="footnote-reference-28" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>, with small probability. The corresponding internal FVK derived as specified in the next section may also be invalid with small probability.</p>
</section>
<section id="orchard-internal-key-derivation"><h3><span class="section-heading">Orchard internal key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-internal-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As in the case of Sapling, for a given external address, we want to produce another address for use by wallets for internal operations such as change and auto-shielding. That is, for any external full viewing key we need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.</p>
@ -663,7 +663,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{ask}\)</span>
be the spend authorizing key if available, and let
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\)</span>
be the corresponding external full viewing key, obtained as specified in <a id="id29" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
be the corresponding external full viewing key, obtained as specified in <a id="footnote-reference-29" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
<p>Define
<span class="math">\(\mathsf{DeriveInternalFVK^{Orchard}}(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\)</span>
as follows:</p>
@ -691,13 +691,13 @@ License: MIT</pre>
<span class="math">\(\mathsf{ivk_{internal}}\)</span>
and
<span class="math">\(\mathsf{ovk_{internal}}\)</span>
fields being derived, as specified in <a id="id30" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a> and shown in the following diagram:</p>
fields being derived, as specified in <a id="footnote-reference-30" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a> and shown in the following diagram:</p>
<figure class="align-center" align="center">
<img width="720px" src="zip-0032-orchard-internal-key-derivation.png" />
<img width="720" src="zip-0032-orchard-internal-key-derivation.png" alt="" />
<figcaption>Diagram of Orchard internal key derivation, also showing derivation from the parent extended spending key</figcaption>
</figure>
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="id31" class="footnote_reference" href="#zip-0316">8</a>.</p>
<p>Note that the resulting FVK may be invalid, as specified in <a id="id32" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="footnote-reference-31" class="footnote_reference" href="#zip-0316">8</a>.</p>
<p>Note that the resulting FVK may be invalid, as specified in <a id="footnote-reference-32" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
</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" 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>
@ -738,7 +738,7 @@ License: MIT</pre>
</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" 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="id33" 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>
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="footnote-reference-33" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Sapling and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:</p>
<ul>
@ -751,7 +751,7 @@ License: MIT</pre>
) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification.</li>
<li>
<span class="math">\(coin\_type\)</span>
: a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="id34" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cryptocurrency testnets share
: a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="footnote-reference-34" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cryptocurrency testnets share
<span class="math">\(coin\_type\)</span>
index
<span class="math">\(1\)</span>
@ -760,7 +760,7 @@ License: MIT</pre>
<span class="math">\(account\)</span>
: numbered from index
<span class="math">\(0\)</span>
in sequentially increasing manner. Defined as in BIP 44 <a id="id35" class="footnote_reference" href="#bip-0044">5</a>.</li>
in sequentially increasing manner. Defined as in BIP 44 <a id="footnote-reference-35" class="footnote_reference" href="#bip-0044">5</a>.</li>
</ul>
<p>Unlike BIP 44, none of the shielded key paths have a
<span class="math">\(change\)</span>
@ -782,7 +782,7 @@ License: MIT</pre>
payment addresses, because each diversifier has around a 50% chance of being invalid.</p>
<p>If in certain circumstances a wallet needs to derive independent spend authorities within a single account, they MAY additionally support a non-hardened
<span class="math">\(address\_index\)</span>
path level as in <a id="id36" class="footnote_reference" href="#bip-0044">5</a>:</p>
path level as in <a id="footnote-reference-36" class="footnote_reference" href="#bip-0044">5</a>:</p>
<ul>
<li>
<span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)</span>
@ -814,7 +814,7 @@ License: MIT</pre>
<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="id37" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">18</a>) is given by:</p>
(as specified in <a id="footnote-reference-37" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">18</a>) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\)</span>
@ -826,7 +826,7 @@ License: MIT</pre>
<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="id38" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">20</a>) is given by:</p>
(as specified in <a id="footnote-reference-38" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">20</a>) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})\)</span>
@ -851,7 +851,7 @@ License: MIT</pre>
</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" 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="id39" class="footnote_reference" href="#bip-0173">7</a> encoding.</p>
<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="footnote-reference-39" 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" 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>
@ -943,7 +943,7 @@ License: MIT</pre>
<span class="math">\(0\)</span>
.</p>
<p>When encoded as Bech32, the Human-Readable Part is <code>secret-orchard-extsk-main</code> for Mainnet, or <code>secret-orchard-extsk-test</code> for Testnet.</p>
<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="id40" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a>.</p>
<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="footnote-reference-40" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a>.</p>
</section>
</section>
<section id="values-reserved-due-to-previous-specification-for-sprout"><h2><span class="section-heading">Values reserved due to previous specification for Sprout</span><span class="section-anchor"> <a rel="bookmark" href="#values-reserved-due-to-previous-specification-for-sprout"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>

2
zip-0032.rst
View File

@ -3,7 +3,7 @@
ZIP: 32
Title: Shielded Hierarchical Deterministic Wallets
Owners: Jack Grigg <str4d@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Daira Emma Hopwood <daira@electriccoin.co>
Credits: Sean Bowe
Kris Nuttycombe
Ying Tong Lai

2
zip-0076.html
View File

@ -9,7 +9,7 @@
<pre>ZIP: 76
Title: Transaction Signature Validation before Overwinter
Owners: Jack Grigg &lt;str4d@electriccoin.co&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Status: Reserved
Category: Consensus
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/130">https://github.com/zcash/zips/issues/130</a>&gt;</pre>

2
zip-0076.rst
View File

@ -3,7 +3,7 @@
ZIP: 76
Title: Transaction Signature Validation before Overwinter
Owners: Jack Grigg <str4d@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Daira Emma Hopwood <daira@electriccoin.co>
Status: Reserved
Category: Consensus
Discussions-To: <https://github.com/zcash/zips/issues/130>

166
zip-0143.html
View File

@ -9,7 +9,7 @@
<pre>ZIP: 143
Title: Transaction Signature Validation for Overwinter
Owners: Jack Grigg &lt;str4d@electriccoin.co&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Credits: Johnson Lau
Pieter Wuille
Bitcoin-ABC
@ -18,19 +18,19 @@ Category: Consensus
Created: 2017-12-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" 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">10</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">11</a></p>
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" class="footnote_reference" href="#zip-0200">10</a></p>
<p>The term "Overwinter" in this document is to be interpreted as described in ZIP 201. <a id="footnote-reference-3" class="footnote_reference" href="#zip-0201">11</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a new transaction digest algorithm for signature validation from the Overwinter network upgrade, in order to minimize redundant data hashing in validation, and to cover the input value by the signature.</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>There are 4 ECDSA signature validation operations in the original Zcash script system: <code>CHECKSIG</code>, <code>CHECKSIGVERIFY</code>, <code>CHECKMULTISIG</code>, <code>CHECKMULTISIGVERIFY</code> ("sigops"). According to the sighash type (<code>ALL</code>, <code>NONE</code>, or <code>SINGLE</code>, possibly modified by <code>ANYONECANPAY</code>), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is validated against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. <a id="id4" class="footnote_reference" href="#wiki-checksig">3</a> The transaction digest is additionally used for the JoinSplit signature (solely with sighash type <code>ALL</code>). <a id="id5" class="footnote_reference" href="#protocol-sproutsend">2</a></p>
<p>There are 4 ECDSA signature validation operations in the original Zcash script system: <code>CHECKSIG</code>, <code>CHECKSIGVERIFY</code>, <code>CHECKMULTISIG</code>, <code>CHECKMULTISIGVERIFY</code> ("sigops"). According to the sighash type (<code>ALL</code>, <code>NONE</code>, or <code>SINGLE</code>, possibly modified by <code>ANYONECANPAY</code>), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is validated against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. <a id="footnote-reference-4" class="footnote_reference" href="#wiki-checksig">3</a> The transaction digest is additionally used for the JoinSplit signature (solely with sighash type <code>ALL</code>). <a id="footnote-reference-5" class="footnote_reference" href="#protocol-sproutsend">2</a></p>
<p>Unfortunately, there are at least 2 weaknesses in the original SignatureHash transaction digest algorithm:</p>
<ul>
<li>For the validation of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n<sup>2</sup>) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to validate with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to validate. This could be fixed by optimizing the digest algorithm by introducing some reusable "midstate", so the time complexity becomes O(n). <a id="id6" class="footnote_reference" href="#quadratic">4</a></li>
<li>The algorithm does not involve the value being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the lack of knowledge of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of a lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funds would be lost. <a id="id7" class="footnote_reference" href="#offline-wallets">5</a></li>
<li>For the validation of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n<sup>2</sup>) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to validate with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to validate. This could be fixed by optimizing the digest algorithm by introducing some reusable "midstate", so the time complexity becomes O(n). <a id="footnote-reference-6" class="footnote_reference" href="#quadratic">4</a></li>
<li>The algorithm does not involve the value being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the lack of knowledge of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of a lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funds would be lost. <a id="footnote-reference-7" class="footnote_reference" href="#offline-wallets">5</a></li>
</ul>
<p>Deploying the aforementioned fixes in the original script system is not a simple task.</p>
</section>
@ -52,11 +52,11 @@ License: MIT</pre>
b. scriptCode of the input (serialized as scripts inside CTxOuts)
c. value of the output spent by this input (8-byte little endian)
d. nSequence of the input (4-byte little endian)</pre>
<p>The new algorithm is based on the Bitcoin transaction digest algorithm defined in BIP 143, <a id="id8" class="footnote_reference" href="#bip-0143">6</a> with replay protection inspired by BUIP-HF v1.2. <a id="id9" class="footnote_reference" href="#buip-hf">7</a></p>
<p>The new algorithm MUST be used for signatures created over the Overwinter transaction format. <a id="id10" class="footnote_reference" href="#zip-0202">12</a> Combined with the new consensus rule that v1 and v2 transaction formats will be invalid from the Overwinter upgrade, <a id="id11" class="footnote_reference" href="#zip-0202">12</a> this effectively means that all transaction signatures from the Overwinter activation height will use the new algorithm. <a id="id12" class="footnote_reference" href="#zip-0201">11</a></p>
<p>The BLAKE2b-256 personalization field <a id="id13" class="footnote_reference" href="#blake2-personalization">8</a> is set to:</p>
<p>The new algorithm is based on the Bitcoin transaction digest algorithm defined in BIP 143, <a id="footnote-reference-8" class="footnote_reference" href="#bip-0143">6</a> with replay protection inspired by BUIP-HF v1.2. <a id="footnote-reference-9" class="footnote_reference" href="#buip-hf">7</a></p>
<p>The new algorithm MUST be used for signatures created over the Overwinter transaction format. <a id="footnote-reference-10" class="footnote_reference" href="#zip-0202">12</a> Combined with the new consensus rule that v1 and v2 transaction formats will be invalid from the Overwinter upgrade, <a id="footnote-reference-11" class="footnote_reference" href="#zip-0202">12</a> this effectively means that all transaction signatures from the Overwinter activation height will use the new algorithm. <a id="footnote-reference-12" class="footnote_reference" href="#zip-0201">11</a></p>
<p>The BLAKE2b-256 personalization field <a id="footnote-reference-13" class="footnote_reference" href="#blake2-personalization">8</a> is set to:</p>
<pre>"ZcashSigHash" || CONSENSUS_BRANCH_ID</pre>
<p><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 transaction. <a id="id14" class="footnote_reference" href="#zip-0200">10</a> Domain separation of the signature hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will have invalid signatures on other consensus branches.</p>
<p><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 transaction. <a id="footnote-reference-14" class="footnote_reference" href="#zip-0200">10</a> Domain separation of the signature hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will have invalid signatures on other consensus branches.</p>
<p>Transaction creators MUST specify the epoch they want their transaction to be mined in. Across a network upgrade, this means that if a transaction is not mined before the activation height, it will never be mined.</p>
<p>Semantics of the original sighash types remain unchanged, except the following:</p>
<ol type="1">
@ -65,12 +65,12 @@ License: MIT</pre>
<li><code>SINGLE</code> does not commit to the input index. When <code>ANYONECANPAY</code> is not set, the semantics are unchanged since <code>hashPrevouts</code> and <code>outpoint</code> together implictly commit to the input index. When <code>SINGLE</code> is used with <code>ANYONECANPAY</code>, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index.</li>
</ol>
<section id="field-definitions"><h3><span class="section-heading">Field definitions</span><span class="section-anchor"> <a rel="bookmark" href="#field-definitions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The items 7, 9, 10a, 10d have the same meaning as the original algorithm from Bitcoin. <a id="id15" class="footnote_reference" href="#wiki-checksig">3</a></p>
<p>The items 7, 9, 10a, 10d have the same meaning as the original algorithm from Bitcoin. <a id="footnote-reference-15" class="footnote_reference" href="#wiki-checksig">3</a></p>
<section id="header"><h4><span class="section-heading">1: <code>header</code></span><span class="section-anchor"> <a rel="bookmark" href="#header"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Deserialized into two transaction properties: <code>fOverwintered</code> and <code>nVersion</code>. For transactions that use this transaction digest algorithm, <code>fOverwintered</code> is always set. <a id="id16" class="footnote_reference" href="#zip-0202">12</a></p>
<p>Deserialized into two transaction properties: <code>fOverwintered</code> and <code>nVersion</code>. For transactions that use this transaction digest algorithm, <code>fOverwintered</code> is always set. <a id="footnote-reference-16" class="footnote_reference" href="#zip-0202">12</a></p>
</section>
<section id="nversiongroupid"><h4><span class="section-heading">2: <code>nVersionGroupId</code></span><span class="section-anchor"> <a rel="bookmark" href="#nversiongroupid"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Provides domain separation of <code>nVersion</code>. It is only defined if <code>fOverwintered</code> is set, which means that it is always defined for transactions that use this algorithm. <a id="id17" class="footnote_reference" href="#zip-0202">12</a></p>
<p>Provides domain separation of <code>nVersion</code>. It is only defined if <code>fOverwintered</code> is set, which means that it is always defined for transactions that use this algorithm. <a id="footnote-reference-17" class="footnote_reference" href="#zip-0202">12</a></p>
</section>
<section id="hashprevouts"><h4><span class="section-heading">3: <code>hashPrevouts</code></span><span class="section-anchor"> <a rel="bookmark" href="#hashprevouts"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<ul>
@ -101,7 +101,7 @@ License: MIT</pre>
<li>The BLAKE2b-256 personalization field is set to <code>ZcashOutputsHash</code> in both cases above.</li>
</ul>
</li>
<li>Otherwise, <code>hashOutputs</code> is a <code>uint256</code> of <code>0x0000......0000</code>. <a id="id18" class="footnote_reference" href="#change">9</a></li>
<li>Otherwise, <code>hashOutputs</code> is a <code>uint256</code> of <code>0x0000......0000</code>. <a id="footnote-reference-18" class="footnote_reference" href="#change">9</a></li>
</ul>
<p>Note: the encoding of the sighash type is masked with <code>0x1F</code> when checking whether or not the <code>SINGLE</code> and <code>NONE</code> flags are set.</p>
</section>
@ -117,7 +117,7 @@ License: MIT</pre>
</ul>
</section>
<section id="nexpiryheight"><h4><span class="section-heading">8: <code>nExpiryHeight</code></span><span class="section-anchor"> <a rel="bookmark" href="#nexpiryheight"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The block height after which the transaction becomes unilaterally invalid, and can never be mined. <a id="id19" class="footnote_reference" href="#zip-0203">13</a></p>
<p>The block height after which the transaction becomes unilaterally invalid, and can never be mined. <a id="footnote-reference-19" class="footnote_reference" href="#zip-0203">13</a></p>
</section>
<section id="b-scriptcode"><h4><span class="section-heading">10b: <code>scriptCode</code></span><span class="section-anchor"> <a rel="bookmark" href="#b-scriptcode"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The script being currently executed: <code>redeemScript</code> for P2SH, or <code>scriptPubKey</code> in the general case. This is the same script as serialized in the Sprout transaction digest algorithm.</p>
@ -129,98 +129,98 @@ License: MIT</pre>
<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>The <code>hashPrevouts</code>, <code>hashSequence</code>, <code>hashOutputs</code>, and <code>hashJoinSplits</code> calculated in an earlier validation can be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n<sup>2</sup>) to O(n).</p>
<p>Refer to the reference implementation, reproduced below, for the precise algorithm:</p>
<pre data-language="cpp"><span class="k">const</span> <span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">ZCASH_PREVOUTS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span> <span class="o">=</span>
<span class="p">{</span><span class="sc">&#39;Z&#39;</span><span class="p">,</span><span class="sc">&#39;c&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">,</span><span class="sc">&#39;P&#39;</span><span class="p">,</span><span class="sc">&#39;r&#39;</span><span class="p">,</span><span class="sc">&#39;e&#39;</span><span class="p">,</span><span class="sc">&#39;v&#39;</span><span class="p">,</span><span class="sc">&#39;o&#39;</span><span class="p">,</span><span class="sc">&#39;u&#39;</span><span class="p">,</span><span class="sc">&#39;t&#39;</span><span class="p">,</span><span class="sc">&#39;H&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">};</span>
<span class="k">const</span> <span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">ZCASH_SEQUENCE_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span> <span class="o">=</span>
<span class="p">{</span><span class="sc">&#39;Z&#39;</span><span class="p">,</span><span class="sc">&#39;c&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">,</span><span class="sc">&#39;S&#39;</span><span class="p">,</span><span class="sc">&#39;e&#39;</span><span class="p">,</span><span class="sc">&#39;q&#39;</span><span class="p">,</span><span class="sc">&#39;u&#39;</span><span class="p">,</span><span class="sc">&#39;e&#39;</span><span class="p">,</span><span class="sc">&#39;n&#39;</span><span class="p">,</span><span class="sc">&#39;c&#39;</span><span class="p">,</span><span class="sc">&#39;H&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">};</span>
<span class="k">const</span> <span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">ZCASH_OUTPUTS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span> <span class="o">=</span>
<span class="p">{</span><span class="sc">&#39;Z&#39;</span><span class="p">,</span><span class="sc">&#39;c&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">,</span><span class="sc">&#39;O&#39;</span><span class="p">,</span><span class="sc">&#39;u&#39;</span><span class="p">,</span><span class="sc">&#39;t&#39;</span><span class="p">,</span><span class="sc">&#39;p&#39;</span><span class="p">,</span><span class="sc">&#39;u&#39;</span><span class="p">,</span><span class="sc">&#39;t&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;H&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">};</span>
<span class="k">const</span> <span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">ZCASH_JOINSPLITS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span> <span class="o">=</span>
<span class="p">{</span><span class="sc">&#39;Z&#39;</span><span class="p">,</span><span class="sc">&#39;c&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">,</span><span class="sc">&#39;J&#39;</span><span class="p">,</span><span class="sc">&#39;S&#39;</span><span class="p">,</span><span class="sc">&#39;p&#39;</span><span class="p">,</span><span class="sc">&#39;l&#39;</span><span class="p">,</span><span class="sc">&#39;i&#39;</span><span class="p">,</span><span class="sc">&#39;t&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;H&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">};</span>
<pre data-language="cpp"><span class="k">const</span><span class="w"> </span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">char</span><span class="w"> </span><span class="n">ZCASH_PREVOUTS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span><span class="w"> </span><span class="o">=</span>
<span class="w"> </span><span class="p">{</span><span class="sc">&#39;Z&#39;</span><span class="p">,</span><span class="sc">&#39;c&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">,</span><span class="sc">&#39;P&#39;</span><span class="p">,</span><span class="sc">&#39;r&#39;</span><span class="p">,</span><span class="sc">&#39;e&#39;</span><span class="p">,</span><span class="sc">&#39;v&#39;</span><span class="p">,</span><span class="sc">&#39;o&#39;</span><span class="p">,</span><span class="sc">&#39;u&#39;</span><span class="p">,</span><span class="sc">&#39;t&#39;</span><span class="p">,</span><span class="sc">&#39;H&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">};</span>
<span class="k">const</span><span class="w"> </span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">char</span><span class="w"> </span><span class="n">ZCASH_SEQUENCE_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span><span class="w"> </span><span class="o">=</span>
<span class="w"> </span><span class="p">{</span><span class="sc">&#39;Z&#39;</span><span class="p">,</span><span class="sc">&#39;c&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">,</span><span class="sc">&#39;S&#39;</span><span class="p">,</span><span class="sc">&#39;e&#39;</span><span class="p">,</span><span class="sc">&#39;q&#39;</span><span class="p">,</span><span class="sc">&#39;u&#39;</span><span class="p">,</span><span class="sc">&#39;e&#39;</span><span class="p">,</span><span class="sc">&#39;n&#39;</span><span class="p">,</span><span class="sc">&#39;c&#39;</span><span class="p">,</span><span class="sc">&#39;H&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">};</span>
<span class="k">const</span><span class="w"> </span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">char</span><span class="w"> </span><span class="n">ZCASH_OUTPUTS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span><span class="w"> </span><span class="o">=</span>
<span class="w"> </span><span class="p">{</span><span class="sc">&#39;Z&#39;</span><span class="p">,</span><span class="sc">&#39;c&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">,</span><span class="sc">&#39;O&#39;</span><span class="p">,</span><span class="sc">&#39;u&#39;</span><span class="p">,</span><span class="sc">&#39;t&#39;</span><span class="p">,</span><span class="sc">&#39;p&#39;</span><span class="p">,</span><span class="sc">&#39;u&#39;</span><span class="p">,</span><span class="sc">&#39;t&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;H&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">};</span>
<span class="k">const</span><span class="w"> </span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">char</span><span class="w"> </span><span class="n">ZCASH_JOINSPLITS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span><span class="w"> </span><span class="o">=</span>
<span class="w"> </span><span class="p">{</span><span class="sc">&#39;Z&#39;</span><span class="p">,</span><span class="sc">&#39;c&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">,</span><span class="sc">&#39;J&#39;</span><span class="p">,</span><span class="sc">&#39;S&#39;</span><span class="p">,</span><span class="sc">&#39;p&#39;</span><span class="p">,</span><span class="sc">&#39;l&#39;</span><span class="p">,</span><span class="sc">&#39;i&#39;</span><span class="p">,</span><span class="sc">&#39;t&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;H&#39;</span><span class="p">,</span><span class="sc">&#39;a&#39;</span><span class="p">,</span><span class="sc">&#39;s&#39;</span><span class="p">,</span><span class="sc">&#39;h&#39;</span><span class="p">};</span>
<span class="c1">// The default values are zeroes</span>
<span class="n">uint256</span> <span class="n">hashPrevouts</span><span class="p">;</span>
<span class="n">uint256</span> <span class="n">hashSequence</span><span class="p">;</span>
<span class="n">uint256</span> <span class="n">hashOutputs</span><span class="p">;</span>
<span class="n">uint256</span> <span class="n">hashJoinSplits</span><span class="p">;</span>
<span class="n">uint256</span><span class="w"> </span><span class="n">hashPrevouts</span><span class="p">;</span>
<span class="n">uint256</span><span class="w"> </span><span class="n">hashSequence</span><span class="p">;</span>
<span class="n">uint256</span><span class="w"> </span><span class="n">hashOutputs</span><span class="p">;</span>
<span class="n">uint256</span><span class="w"> </span><span class="n">hashJoinSplits</span><span class="p">;</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="p">(</span><span class="n">nHashType</span> <span class="o">&amp;</span> <span class="n">SIGHASH_ANYONECANPAY</span><span class="p">))</span> <span class="p">{</span>
<span class="n">CBLAKE2bWriter</span> <span class="n">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">ZCASH_PREVOUTS_HASH_PERSONALIZATION</span><span class="p">);</span>
<span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">n</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">n</span> <span class="o">&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">.</span><span class="n">size</span><span class="p">();</span> <span class="n">n</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">n</span><span class="p">].</span><span class="n">prevout</span><span class="p">;</span>
<span class="p">}</span>
<span class="n">hashPrevouts</span> <span class="o">=</span> <span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
<span class="k">if</span><span class="w"> </span><span class="p">(</span><span class="o">!</span><span class="p">(</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&amp;</span><span class="w"> </span><span class="n">SIGHASH_ANYONECANPAY</span><span class="p">))</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">CBLAKE2bWriter</span><span class="w"> </span><span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span><span class="w"> </span><span class="mi">0</span><span class="p">,</span><span class="w"> </span><span class="n">ZCASH_PREVOUTS_HASH_PERSONALIZATION</span><span class="p">);</span>
<span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="p">(</span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">int</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="p">;</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o">&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">.</span><span class="n">size</span><span class="p">();</span><span class="w"> </span><span class="n">n</span><span class="o">++</span><span class="p">)</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">n</span><span class="p">].</span><span class="n">prevout</span><span class="p">;</span>
<span class="w"> </span><span class="p">}</span>
<span class="w"> </span><span class="n">hashPrevouts</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
<span class="p">}</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="p">(</span><span class="n">nHashType</span> <span class="o">&amp;</span> <span class="n">SIGHASH_ANYONECANPAY</span><span class="p">)</span> <span class="o">&amp;&amp;</span> <span class="p">(</span><span class="n">nHashType</span> <span class="o">&amp;</span> <span class="mh">0x1f</span><span class="p">)</span> <span class="o">!=</span> <span class="n">SIGHASH_SINGLE</span> <span class="o">&amp;&amp;</span> <span class="p">(</span><span class="n">nHashType</span> <span class="o">&amp;</span> <span class="mh">0x1f</span><span class="p">)</span> <span class="o">!=</span> <span class="n">SIGHASH_NONE</span><span class="p">)</span> <span class="p">{</span>
<span class="n">CBLAKE2bWriter</span> <span class="n">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">ZCASH_SEQUENCE_HASH_PERSONALIZATION</span><span class="p">);</span>
<span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">n</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">n</span> <span class="o">&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">.</span><span class="n">size</span><span class="p">();</span> <span class="n">n</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">n</span><span class="p">].</span><span class="n">nSequence</span><span class="p">;</span>
<span class="p">}</span>
<span class="n">hashSequence</span> <span class="o">=</span> <span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
<span class="k">if</span><span class="w"> </span><span class="p">(</span><span class="o">!</span><span class="p">(</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&amp;</span><span class="w"> </span><span class="n">SIGHASH_ANYONECANPAY</span><span class="p">)</span><span class="w"> </span><span class="o">&amp;&amp;</span><span class="w"> </span><span class="p">(</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&amp;</span><span class="w"> </span><span class="mh">0x1f</span><span class="p">)</span><span class="w"> </span><span class="o">!=</span><span class="w"> </span><span class="n">SIGHASH_SINGLE</span><span class="w"> </span><span class="o">&amp;&amp;</span><span class="w"> </span><span class="p">(</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&amp;</span><span class="w"> </span><span class="mh">0x1f</span><span class="p">)</span><span class="w"> </span><span class="o">!=</span><span class="w"> </span><span class="n">SIGHASH_NONE</span><span class="p">)</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">CBLAKE2bWriter</span><span class="w"> </span><span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span><span class="w"> </span><span class="mi">0</span><span class="p">,</span><span class="w"> </span><span class="n">ZCASH_SEQUENCE_HASH_PERSONALIZATION</span><span class="p">);</span>
<span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="p">(</span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">int</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="p">;</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o">&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">.</span><span class="n">size</span><span class="p">();</span><span class="w"> </span><span class="n">n</span><span class="o">++</span><span class="p">)</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">n</span><span class="p">].</span><span class="n">nSequence</span><span class="p">;</span>
<span class="w"> </span><span class="p">}</span>
<span class="w"> </span><span class="n">hashSequence</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
<span class="p">}</span>
<span class="k">if</span> <span class="p">((</span><span class="n">nHashType</span> <span class="o">&amp;</span> <span class="mh">0x1f</span><span class="p">)</span> <span class="o">!=</span> <span class="n">SIGHASH_SINGLE</span> <span class="o">&amp;&amp;</span> <span class="p">(</span><span class="n">nHashType</span> <span class="o">&amp;</span> <span class="mh">0x1f</span><span class="p">)</span> <span class="o">!=</span> <span class="n">SIGHASH_NONE</span><span class="p">)</span> <span class="p">{</span>
<span class="n">CBLAKE2bWriter</span> <span class="n">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">ZCASH_OUTPUTS_HASH_PERSONALIZATION</span><span class="p">);</span>
<span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">n</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">n</span> <span class="o">&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">.</span><span class="n">size</span><span class="p">();</span> <span class="n">n</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">[</span><span class="n">n</span><span class="p">];</span>
<span class="p">}</span>
<span class="n">hashOutputs</span> <span class="o">=</span> <span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
<span class="p">}</span> <span class="k">else</span> <span class="k">if</span> <span class="p">((</span><span class="n">nHashType</span> <span class="o">&amp;</span> <span class="mh">0x1f</span><span class="p">)</span> <span class="o">==</span> <span class="n">SIGHASH_SINGLE</span> <span class="o">&amp;&amp;</span> <span class="n">nIn</span> <span class="o">&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">.</span><span class="n">size</span><span class="p">())</span> <span class="p">{</span>
<span class="n">CBLAKE2bWriter</span> <span class="n">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">ZCASH_OUTPUTS_HASH_PERSONALIZATION</span><span class="p">);</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">[</span><span class="n">nIn</span><span class="p">];</span>
<span class="n">hashOutputs</span> <span class="o">=</span> <span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
<span class="k">if</span><span class="w"> </span><span class="p">((</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&amp;</span><span class="w"> </span><span class="mh">0x1f</span><span class="p">)</span><span class="w"> </span><span class="o">!=</span><span class="w"> </span><span class="n">SIGHASH_SINGLE</span><span class="w"> </span><span class="o">&amp;&amp;</span><span class="w"> </span><span class="p">(</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&amp;</span><span class="w"> </span><span class="mh">0x1f</span><span class="p">)</span><span class="w"> </span><span class="o">!=</span><span class="w"> </span><span class="n">SIGHASH_NONE</span><span class="p">)</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">CBLAKE2bWriter</span><span class="w"> </span><span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span><span class="w"> </span><span class="mi">0</span><span class="p">,</span><span class="w"> </span><span class="n">ZCASH_OUTPUTS_HASH_PERSONALIZATION</span><span class="p">);</span>
<span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="p">(</span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">int</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="p">;</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o">&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">.</span><span class="n">size</span><span class="p">();</span><span class="w"> </span><span class="n">n</span><span class="o">++</span><span class="p">)</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">[</span><span class="n">n</span><span class="p">];</span>
<span class="w"> </span><span class="p">}</span>
<span class="w"> </span><span class="n">hashOutputs</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
<span class="p">}</span><span class="w"> </span><span class="k">else</span><span class="w"> </span><span class="k">if</span><span class="w"> </span><span class="p">((</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&amp;</span><span class="w"> </span><span class="mh">0x1f</span><span class="p">)</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="n">SIGHASH_SINGLE</span><span class="w"> </span><span class="o">&amp;&amp;</span><span class="w"> </span><span class="n">nIn</span><span class="w"> </span><span class="o">&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">.</span><span class="n">size</span><span class="p">())</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">CBLAKE2bWriter</span><span class="w"> </span><span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span><span class="w"> </span><span class="mi">0</span><span class="p">,</span><span class="w"> </span><span class="n">ZCASH_OUTPUTS_HASH_PERSONALIZATION</span><span class="p">);</span>
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">[</span><span class="n">nIn</span><span class="p">];</span>
<span class="w"> </span><span class="n">hashOutputs</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
<span class="p">}</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">txTo</span><span class="p">.</span><span class="n">vjoinsplit</span><span class="p">.</span><span class="n">empty</span><span class="p">())</span> <span class="p">{</span>
<span class="n">CBLAKE2bWriter</span> <span class="n">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">ZCASH_JOINSPLITS_HASH_PERSONALIZATION</span><span class="p">);</span>
<span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">n</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">n</span> <span class="o">&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vjoinsplit</span><span class="p">.</span><span class="n">size</span><span class="p">();</span> <span class="n">n</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vjoinsplit</span><span class="p">[</span><span class="n">n</span><span class="p">];</span>
<span class="p">}</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">joinSplitPubKey</span><span class="p">;</span>
<span class="n">hashJoinSplits</span> <span class="o">=</span> <span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
<span class="k">if</span><span class="w"> </span><span class="p">(</span><span class="o">!</span><span class="n">txTo</span><span class="p">.</span><span class="n">vjoinsplit</span><span class="p">.</span><span class="n">empty</span><span class="p">())</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">CBLAKE2bWriter</span><span class="w"> </span><span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span><span class="w"> </span><span class="mi">0</span><span class="p">,</span><span class="w"> </span><span class="n">ZCASH_JOINSPLITS_HASH_PERSONALIZATION</span><span class="p">);</span>
<span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="p">(</span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">int</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="p">;</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o">&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vjoinsplit</span><span class="p">.</span><span class="n">size</span><span class="p">();</span><span class="w"> </span><span class="n">n</span><span class="o">++</span><span class="p">)</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vjoinsplit</span><span class="p">[</span><span class="n">n</span><span class="p">];</span>
<span class="w"> </span><span class="p">}</span>
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">joinSplitPubKey</span><span class="p">;</span>
<span class="w"> </span><span class="n">hashJoinSplits</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
<span class="p">}</span>
<span class="kt">uint32_t</span> <span class="n">leConsensusBranchId</span> <span class="o">=</span> <span class="n">htole32</span><span class="p">(</span><span class="n">consensusBranchId</span><span class="p">);</span>
<span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">personalization</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span> <span class="o">=</span> <span class="p">{};</span>
<span class="n">memcpy</span><span class="p">(</span><span class="n">personalization</span><span class="p">,</span> <span class="s">&quot;ZcashSigHash&quot;</span><span class="p">,</span> <span class="mi">12</span><span class="p">);</span>
<span class="n">memcpy</span><span class="p">(</span><span class="n">personalization</span><span class="o">+</span><span class="mi">12</span><span class="p">,</span> <span class="o">&amp;</span><span class="n">leConsensusBranchId</span><span class="p">,</span> <span class="mi">4</span><span class="p">);</span>
<span class="kt">uint32_t</span><span class="w"> </span><span class="n">leConsensusBranchId</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">htole32</span><span class="p">(</span><span class="n">consensusBranchId</span><span class="p">);</span>
<span class="kt">unsigned</span><span class="w"> </span><span class="kt">char</span><span class="w"> </span><span class="n">personalization</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{};</span>
<span class="n">memcpy</span><span class="p">(</span><span class="n">personalization</span><span class="p">,</span><span class="w"> </span><span class="s">&quot;ZcashSigHash&quot;</span><span class="p">,</span><span class="w"> </span><span class="mi">12</span><span class="p">);</span>
<span class="n">memcpy</span><span class="p">(</span><span class="n">personalization</span><span class="o">+</span><span class="mi">12</span><span class="p">,</span><span class="w"> </span><span class="o">&amp;</span><span class="n">leConsensusBranchId</span><span class="p">,</span><span class="w"> </span><span class="mi">4</span><span class="p">);</span>
<span class="n">CBLAKE2bWriter</span> <span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">personalization</span><span class="p">);</span>
<span class="n">CBLAKE2bWriter</span><span class="w"> </span><span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span><span class="w"> </span><span class="mi">0</span><span class="p">,</span><span class="w"> </span><span class="n">personalization</span><span class="p">);</span>
<span class="c1">// fOverwintered and nVersion</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">GetHeader</span><span class="p">();</span>
<span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">GetHeader</span><span class="p">();</span>
<span class="c1">// Version group ID</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">nVersionGroupId</span><span class="p">;</span>
<span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">nVersionGroupId</span><span class="p">;</span>
<span class="c1">// Input prevouts/nSequence (none/all, depending on flags)</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">hashPrevouts</span><span class="p">;</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">hashSequence</span><span class="p">;</span>
<span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">hashPrevouts</span><span class="p">;</span>
<span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">hashSequence</span><span class="p">;</span>
<span class="c1">// Outputs (none/one/all, depending on flags)</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">hashOutputs</span><span class="p">;</span>
<span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">hashOutputs</span><span class="p">;</span>
<span class="c1">// JoinSplits</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">hashJoinSplits</span><span class="p">;</span>
<span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">hashJoinSplits</span><span class="p">;</span>
<span class="c1">// Locktime</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">nLockTime</span><span class="p">;</span>
<span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">nLockTime</span><span class="p">;</span>
<span class="c1">// Expiry height</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">nExpiryHeight</span><span class="p">;</span>
<span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">nExpiryHeight</span><span class="p">;</span>
<span class="c1">// Sighash type</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">nHashType</span><span class="p">;</span>
<span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">nHashType</span><span class="p">;</span>
<span class="k">if</span> <span class="p">(</span><span class="n">nIn</span> <span class="o">!=</span> <span class="n">NOT_AN_INPUT</span><span class="p">)</span> <span class="p">{</span>
<span class="c1">// The input being signed (replacing the scriptSig with scriptCode + amount)</span>
<span class="c1">// The prevout may already be contained in hashPrevout, and the nSequence</span>
<span class="c1">// may already be contained in hashSequence.</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">nIn</span><span class="p">].</span><span class="n">prevout</span><span class="p">;</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="k">static_cast</span><span class="o">&lt;</span><span class="k">const</span> <span class="n">CScriptBase</span><span class="o">&amp;&gt;</span><span class="p">(</span><span class="n">scriptCode</span><span class="p">);</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">amount</span><span class="p">;</span>
<span class="n">ss</span> <span class="o">&lt;&lt;</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">nIn</span><span class="p">].</span><span class="n">nSequence</span><span class="p">;</span>
<span class="k">if</span><span class="w"> </span><span class="p">(</span><span class="n">nIn</span><span class="w"> </span><span class="o">!=</span><span class="w"> </span><span class="n">NOT_AN_INPUT</span><span class="p">)</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="c1">// The input being signed (replacing the scriptSig with scriptCode + amount)</span>
<span class="w"> </span><span class="c1">// The prevout may already be contained in hashPrevout, and the nSequence</span>
<span class="w"> </span><span class="c1">// may already be contained in hashSequence.</span>
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">nIn</span><span class="p">].</span><span class="n">prevout</span><span class="p">;</span>
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="k">static_cast</span><span class="o">&lt;</span><span class="k">const</span><span class="w"> </span><span class="n">CScriptBase</span><span class="o">&amp;&gt;</span><span class="p">(</span><span class="n">scriptCode</span><span class="p">);</span>
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">amount</span><span class="p">;</span>
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o">&lt;&lt;</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">nIn</span><span class="p">].</span><span class="n">nSequence</span><span class="p">;</span>
<span class="p">}</span>
<span class="k">return</span> <span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span></pre>
<span class="k">return</span><span class="w"> </span><span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span></pre>
</section>
</section>
<section id="example"><h2><span class="section-heading">Example</span><span class="section-anchor"> <a rel="bookmark" href="#example"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>To ensure consistency in consensus-critical behaviour, developers should test their implementations against the ZIP 143 test vectors <a id="id20" class="footnote_reference" href="#test-vectors">14</a>. The first two test vectors are broken out below for clarity. Note that 32-byte values below are exactly as the hash function returns, and are not reversed. Further examples can be found in the SignatureHash test data <a id="id21" class="footnote_reference" href="#sighash-tests">15</a>.</p>
<p>The test vectors below should be verified with the Overwinter consensus branch ID (0x5ba81b19) <a id="id22" class="footnote_reference" href="#zip-0201">11</a>.</p>
<p>To ensure consistency in consensus-critical behaviour, developers should test their implementations against the ZIP 143 test vectors <a id="footnote-reference-20" class="footnote_reference" href="#test-vectors">14</a>. The first two test vectors are broken out below for clarity. Note that 32-byte values below are exactly as the hash function returns, and are not reversed. Further examples can be found in the SignatureHash test data <a id="footnote-reference-21" class="footnote_reference" href="#sighash-tests">15</a>.</p>
<p>The test vectors below should be verified with the Overwinter consensus branch ID (0x5ba81b19) <a id="footnote-reference-22" class="footnote_reference" href="#zip-0201">11</a>.</p>
<section id="test-vector-1"><h3><span class="section-heading">Test vector 1</span><span class="section-anchor"> <a rel="bookmark" href="#test-vector-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Raw transaction:</p>
<pre>030000807082c4030002e7719811893e0000095200ac6551ac636565b2835a0805750200025151481cdd86b3cc431800
@ -339,7 +339,7 @@ sighash: 23652e76cb13b85a0e3363bb5fca061fa791c40c533eccee899364e6e60bb4f7</pre>
</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal is deployed with the Overwinter network upgrade. <a id="id23" class="footnote_reference" href="#zip-0201">11</a></p>
<p>This proposal is deployed with the Overwinter network upgrade. <a id="footnote-reference-23" class="footnote_reference" href="#zip-0201">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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal is backwards-compatible with old UTXOs. It is <strong>not</strong> backwards-compatible with older software. All transactions will be required to use this transaction digest algorithm for signatures, and so transactions created by older software will be rejected by the network.</p>

2
zip-0143.rst
View File

@ -3,7 +3,7 @@
ZIP: 143
Title: Transaction Signature Validation for Overwinter
Owners: Jack Grigg <str4d@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Daira Emma Hopwood <daira@electriccoin.co>
Credits: Johnson Lau
Pieter Wuille
Bitcoin-ABC

30
zip-0155.html
View File

@ -8,7 +8,7 @@
<section>
<pre>ZIP: 155
Title: addrv2 message
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Credits: Wladimir J. van der Laan
Zancas Wilcox
Status: Proposed
@ -18,9 +18,9 @@ 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" 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>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="footnote-reference-1" 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="footnote-reference-2" 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="footnote-reference-3" 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>
@ -28,11 +28,11 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/543">https://githu
<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" 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>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="footnote-reference-4" 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="footnote-reference-5" 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" 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>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="footnote-reference-6" 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="footnote-reference-7" 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>
<table>
@ -127,14 +127,14 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/543">https://githu
</tbody>
</table>
</blockquote>
<p>Network ID <code>0x03</code> is intentionally not assigned. In BIP 155 <a id="id8" class="footnote_reference" href="#bip-0155">3</a> it was assigned to Tor v2 onion addresses, but those addresses are no longer supported by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.</p>
<p>Network ID <code>0x03</code> is intentionally not assigned. In BIP 155 <a id="footnote-reference-8" class="footnote_reference" href="#bip-0155">3</a> it was assigned to Tor v2 onion addresses, but those addresses are no longer supported by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.</p>
<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" 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" 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>
<p>According to the spec <a id="footnote-reference-9" 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>
<p>where:</p>
@ -143,30 +143,30 @@ CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
<li><code>VERSION</code> is a one-byte version field (default value <code>0x03</code>);</li>
<li><code>".onion"</code> and <code>".onion checksum"</code> are constant strings;</li>
<li><code>CHECKSUM</code> is truncated to two bytes before inserting it in <code>onion_address</code>;</li>
<li><code>H()</code> is the SHA3-256 cryptographic hash function. <a id="id10" class="footnote_reference" href="#nist-sha3">10</a></li>
<li><code>H()</code> is the SHA3-256 cryptographic hash function. <a id="footnote-reference-10" class="footnote_reference" href="#nist-sha3">10</a></li>
</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" 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>Like Tor, I2P naming uses a base32-encoded address format <a id="footnote-reference-11" 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" 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>
<p>Cjdns addresses are simply IPv6 addresses in the <code>fc00::/8</code> range <a id="footnote-reference-12" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>TODO: change ${PLACEHOLDER} to a specific peer protocol version.</p>
<p>Support for this specification is signalled by peer protocol version ${PLACEHOLDER} (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>Support for this specification is signalled by peer protocol version ${PLACEHOLDER} (on both Testnet and Mainnet). Note that this is the same peer protocol version that signals support for NU5 on Mainnet <a id="footnote-reference-13" class="footnote_reference" href="#zip-0252">6</a>.</p>
<p>Nodes that have not negotiated peer protocol version ${PLACEHOLDER} 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 ${PLACEHOLDER} 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" 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>
<p>This ZIP is closely based on BIP 155 <a id="footnote-reference-14" 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 ${PLACEHOLDER} 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>
<li>Deployment: support for the <code>addrv2</code> message is signalled by advertising a peer protocol version of ${PLACEHOLDER} 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="footnote-reference-15" class="footnote_reference" href="#zip-0239">5</a>, have taken the same approach to signalling.</li>
<li>No Network ID for Tor v2 onion addresses: the Tor network is expected to have removed support for these addresses in the timeframe for deployment of this ZIP.</li>
<li>Clients MUST, rather than SHOULD, reject <code>addrv2</code> messages with more than 1,000 addresses. Making this a consistent requirement promotes interoperability.</li>
<li>Clients MUST NOT, rather than SHOULD NOT, gossip addresses from unknown networks.</li>
@ -177,7 +177,7 @@ CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
<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" 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>This ZIP is closely based on BIP 155 <a id="footnote-reference-16" 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>
<li>Jonas Schnelli: change <code>services</code> field to <code>CompactSize</code>, to make the message more compact in the likely case instead of always using 8 bytes.</li>

2
zip-0155.rst
View File

@ -2,7 +2,7 @@
ZIP: 155
Title: addrv2 message
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Credits: Wladimir J. van der Laan
Zancas Wilcox
Status: Proposed

20
zip-0173.html
View File

@ -8,7 +8,7 @@
<section>
<pre>ZIP: 173
Title: Bech32 Format
Author: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Credits: Pieter Wuille &lt;pieter.wuille@gmail.com&gt;
Greg Maxwell &lt;greg@xiph.org&gt;
Rusty Russell
@ -18,15 +18,15 @@ 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" 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>
<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="footnote-reference-1" 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="footnote-reference-2" 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="footnote-reference-3" 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" 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" 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>
<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="footnote-reference-4" 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>
<li>The mixed case in Base58 makes it inconvenient to reliably write down, type on mobile keyboards, or read out loud.</li>
@ -34,11 +34,11 @@ License: MIT</pre>
<li>Most of the research on error-detecting codes only applies to character-set sizes that are a <a href="https://en.wikipedia.org/wiki/Prime_power">prime power</a>, which 58 is not.</li>
<li>Base58 decoding is complicated and relatively slow.</li>
</ul>
<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>
<p>To address these issues, Bitcoin adopted a new encoding called Bech32 <a id="footnote-reference-5" 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="footnote-reference-6" class="footnote_reference" href="#zip-0205">5</a>.</p>
<p>Since the description of Bech32 in <a id="footnote-reference-7" 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="footnote-reference-8" 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="footnote-reference-9" 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" 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>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="footnote-reference-10" class="footnote_reference" href="#protocol">2</a>.</p>
<p>A Bech32 string consists of:</p>
<ul>
<li>The <em>human-readable part</em>, which is intended to convey the type of data, or anything else that is relevant to the reader. This part MUST contain 1 to 83 US-ASCII characters, with each character having a value in the range [33-126]. HRP validity may be further restricted by specific applications.</li>
@ -158,7 +158,7 @@ def bech32_verify_checksum(hrp, data):
<li>The resulting groups are interpreted as the raw encoding of the appropriate address or key type, with the most significant bit first in each byte.</li>
</ul>
<p>Decoders SHOULD enforce known-length restrictions on address and key types.</p>
<p>For example, <a id="id11" class="footnote_reference" href="#protocol">2</a> specifies that the length of the raw encoding of a Sapling payment address is 43 bytes (88 + 256 bits). This results in a Bech32-encoded Sapling payment address being 78 characters long.</p>
<p>For example, <a id="footnote-reference-11" class="footnote_reference" href="#protocol">2</a> specifies that the length of the raw encoding of a Sapling payment address is 43 bytes (88 + 256 bits). This results in a Bech32-encoded Sapling payment address being 78 characters long.</p>
</section>
</section>
</section>
@ -183,7 +183,7 @@ def bech32_verify_checksum(hrp, data):
<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" 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>
<p>This design choice had a rationale for Bitcoin Segregated Witness addresses (see <a id="footnote-reference-12" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>

2
zip-0173.rst
View File

@ -2,7 +2,7 @@
ZIP: 173
Title: Bech32 Format
Author: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Credits: Pieter Wuille <pieter.wuille@gmail.com>
Greg Maxwell <greg@xiph.org>
Rusty Russell

28
zip-0200.html
View File

@ -14,7 +14,7 @@ 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" 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 key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Block chain</dt>
@ -33,8 +33,8 @@ License: MIT</pre>
<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" 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>
<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="footnote-reference-2" 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="footnote-reference-3" class="footnote_reference" href="#release-lifecycle">3</a></p>
<ul>
<li>It gives the same systemic advantage of removing old software as auto-upgrade behavior.</li>
<li>It requires users to individually choose one of the following options:
@ -70,18 +70,18 @@ License: MIT</pre>
<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>
<span class="c1">// Overwinter-specific logic</span>
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
<span class="c1">// Non-Overwinter logic</span>
<pre data-language="cpp"><span class="k">if</span><span class="w"> </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="w"> </span><span class="n">Params</span><span class="p">().</span><span class="n">GetConsensus</span><span class="p">())</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_OVERWINTER</span><span class="p">)</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="c1">// Overwinter-specific logic</span>
<span class="p">}</span><span class="w"> </span><span class="k">else</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="c1">// Non-Overwinter logic</span>
<span class="p">}</span>
<span class="c1">// ...</span>
<span class="k">if</span> <span class="p">(</span><span class="n">NetworkUpgradeActive</span><span class="p">(</span><span class="n">pindex</span><span class="o">-&gt;</span><span class="n">nHeight</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="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_OVERWINTER</span><span class="p">))</span> <span class="p">{</span>
<span class="c1">// Overwinter consensus rules applied to block</span>
<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="k">if</span><span class="w"> </span><span class="p">(</span><span class="n">NetworkUpgradeActive</span><span class="p">(</span><span class="n">pindex</span><span class="o">-&gt;</span><span class="n">nHeight</span><span class="p">,</span><span class="w"> </span><span class="n">Params</span><span class="p">().</span><span class="n">GetConsensus</span><span class="p">(),</span><span class="w"> </span><span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_OVERWINTER</span><span class="p">))</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="c1">// Overwinter consensus rules applied to block</span>
<span class="p">}</span><span class="w"> </span><span class="k">else</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </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" 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>
@ -99,8 +99,8 @@ License: MIT</pre>
<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" 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>
<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="footnote-reference-4" 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="footnote-reference-5" 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" 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>
@ -108,7 +108,7 @@ License: MIT</pre>
</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" 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>
<p>This proposal will be deployed with the Overwinter network upgrade. <a id="footnote-reference-6" 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" 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>

30
zip-0201.html
View File

@ -8,15 +8,15 @@
<section>
<pre>ZIP: 201
Title: Network Peer Management for Overwinter
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Original-Authors: Simon Liu
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" 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 key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" class="footnote_reference" href="#zip-0200">3</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Overwinter</dt>
@ -24,12 +24,12 @@ License: MIT</pre>
</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" 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>This proposal defines an upgrade to the network handshake and peer management required for network upgrades following the Network Upgrade Mechanism <a id="footnote-reference-3" class="footnote_reference" href="#zip-0200">3</a>.</p>
<p>Related to:</p>
<ul>
<li>Transaction Signature Validation for Overwinter <a id="id4" class="footnote_reference" href="#zip-0143">2</a>.</li>
<li>Version 3 Transaction Format for Overwinter <a id="id5" class="footnote_reference" href="#zip-0202">4</a>.</li>
<li>Transaction Expiry <a id="id6" class="footnote_reference" href="#zip-0203">5</a>.</li>
<li>Transaction Signature Validation for Overwinter <a id="footnote-reference-4" class="footnote_reference" href="#zip-0143">2</a>.</li>
<li>Version 3 Transaction Format for Overwinter <a id="footnote-reference-5" class="footnote_reference" href="#zip-0202">4</a>.</li>
<li>Transaction Expiry <a id="footnote-reference-6" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -37,7 +37,7 @@ License: MIT</pre>
</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" 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>
<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="footnote-reference-7" 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
R -&gt; L: Send version message back
R -&gt; L: Send verack message
@ -70,7 +70,7 @@ static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
<p>To prepare for mainnet activation, Overwinter nodes will contain the following constants:</p>
<pre>static const int PROTOCOL_VERSION = 170005;
static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
<p>On mainnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is &lt;= 170004. (Nodes running protocol version 170003 or 170004 do not have a mainnet activation height set. The intermediate protocol version 170004 is used to indicate support for the <code>NODE_BLOOM</code> service bit defined in <a id="id8" class="footnote_reference" href="#bip-0111">6</a>.)</p>
<p>On mainnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is &lt;= 170004. (Nodes running protocol version 170003 or 170004 do not have a mainnet activation height set. The intermediate protocol version 170004 is used to indicate support for the <code>NODE_BLOOM</code> service bit defined in <a id="footnote-reference-8" class="footnote_reference" href="#bip-0111">6</a>.)</p>
<p>These constants allow pre-Overwinter nodes that support protocol versions 170002 to 170004 inclusive, and Overwinter nodes (which support protocol versions 170002 to 170005 inclusive before Overwinter activation) to remain connected until the activation.</p>
<p>As these constants cannot be changed at run-time, once Overwinter activates on testnet or mainnet, Overwinter nodes should take steps to:</p>
<ul>
@ -80,7 +80,7 @@ static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
</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" 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>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="footnote-reference-9" 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>
<p>Currently, an eviction process takes place when new inbound connections arrive, but the node has already connected to the maximum number of inbound peers:</p>
<pre>if (nInbound &gt;= nMaxInbound)
@ -158,7 +158,7 @@ if (nActivationHeight &gt; 0 &amp;&amp;
</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" 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>
<p>The Overwinter network upgrade defines the following network upgrade constants <a id="footnote-reference-10" class="footnote_reference" href="#zip-0200">3</a>:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0x5ba81b19</code></dd>
@ -170,11 +170,11 @@ if (nActivationHeight &gt; 0 &amp;&amp;
</dl>
<p>The following ZIPs are deployed by Overwinter:</p>
<ul>
<li>ZIP 200 <a id="id11" class="footnote_reference" href="#zip-0200">3</a></li>
<li>ZIP 200 <a id="footnote-reference-11" class="footnote_reference" href="#zip-0200">3</a></li>
<li>ZIP 201 (this ZIP)</li>
<li>ZIP 202 <a id="id12" class="footnote_reference" href="#zip-0202">4</a></li>
<li>ZIP 203 <a id="id13" class="footnote_reference" href="#zip-0203">5</a></li>
<li>ZIP 143 <a id="id14" class="footnote_reference" href="#zip-0143">2</a></li>
<li>ZIP 202 <a id="footnote-reference-12" class="footnote_reference" href="#zip-0202">4</a></li>
<li>ZIP 203 <a id="footnote-reference-13" class="footnote_reference" href="#zip-0203">5</a></li>
<li>ZIP 143 <a id="footnote-reference-14" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>

2
zip-0201.rst
View File

@ -2,7 +2,7 @@
ZIP: 201
Title: Network Peer Management for Overwinter
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Original-Authors: Simon Liu
Status: Final
Category: Network

24
zip-0202.html
View File

@ -8,19 +8,19 @@
<section>
<pre>ZIP: 202
Title: Version 3 Transaction Format for Overwinter
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Original-Authors: Simon Liu
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" 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>
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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="footnote-reference-3" 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" 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>
<p>This proposal defines a new transaction format required for Network Upgrade Mechanism <a id="footnote-reference-4" class="footnote_reference" href="#zip-0200">3</a> and Transaction Expiry <a id="footnote-reference-5" 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" 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>
@ -98,12 +98,12 @@ License: MIT</pre>
</table>
<p>A new transaction format is required to:</p>
<ul>
<li>support safe network upgrades as specified in Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">3</a>;</li>
<li>support safe network upgrades as specified in Network Upgrade Mechanism <a id="footnote-reference-6" class="footnote_reference" href="#zip-0200">3</a>;</li>
<li>provide replay protection between pre-Overwinter and Overwinter consensus branches during upgrades;</li>
<li>provide replay protection between different consensus branches post-Overwinter;</li>
<li>enable a consensus branch to support multiple transaction version formats;</li>
<li>ensure transaction formats are parsed uniquely across parallel consensus branches;</li>
<li>support transaction expiry <a id="id7" class="footnote_reference" href="#zip-0203">5</a>.</li>
<li>support transaction expiry <a id="footnote-reference-7" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -268,7 +268,7 @@ License: MIT</pre>
<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" 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>
<p>The expiry height field, as defined in the Transaction Expiry ZIP <a id="footnote-reference-8" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A valid Overwinter transaction intended for Zcash MUST have:</p>
@ -283,7 +283,7 @@ License: MIT</pre>
<li>the version group ID is unknown; or</li>
<li>the version number is unknown.</li>
</ul>
<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>
<p>Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="footnote-reference-9" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -317,14 +317,14 @@ License: MIT</pre>
}</pre>
<p>It is expected that this test involving <code>nVersionGroupId</code> is only required when a transaction is being constructed or deserialized e.g. when an external transaction enters the system.</p>
<p>However, it's possible that a clone of Zcash is using the same version group ID and passes the conditional.</p>
<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>
<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="footnote-reference-10" 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" 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>
<p>This proposal will be deployed with the Overwinter network upgrade. The activation block height proposal is in <a id="footnote-reference-11" 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" 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>This proposal intentionally creates what is known as a "bilateral consensus rule change" <a id="footnote-reference-12" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>

2
zip-0202.rst
View File

@ -2,7 +2,7 @@
ZIP: 202
Title: Version 3 Transaction Format for Overwinter
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Original-Authors: Simon Liu
Status: Final
Category: Consensus

10
zip-0203.html
View File

@ -9,7 +9,7 @@
<section>
<pre>ZIP: 203
Title: Transaction Expiry
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Original-Authors: Jay Graber
Status: Final
Category: Consensus
@ -41,17 +41,17 @@ License: MIT</pre>
"version": 3,
"locktime": 2089,
"expiryheight": 3539,</pre>
<p>Default: 20 blocks from the current height, or about 50 minutes at 2.5-minute target block spacing. A configuration option can be used to set the user's default.</p>
<p>Default: (Before Blossom) 20 blocks from the current height, or about 50 minutes at 2.5-minute target block spacing. A configuration option can be used to set the user's default.</p>
<p>Minimum: No minimum</p>
<p>Maximum: 499999999, which is about 1185 years from now at 75 seconds/block.</p>
<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" 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>
<p>On Blossom activation <a id="footnote-reference-1" 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" 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>
<p>As mentioned above, <code>nExpiryHeight</code> is ignored for coinbase transactions. However, from NU5 activation <a id="footnote-reference-2" 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="footnote-reference-3" 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" 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>
@ -69,7 +69,7 @@ License: MIT</pre>
<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" 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>
<p>This feature will be deployed with Overwinter. The activation blockheight proposal is in <a id="footnote-reference-4" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>

7
zip-0203.rst
View File

@ -2,7 +2,7 @@
ZIP: 203
Title: Transaction Expiry
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Original-Authors: Jay Graber
Status: Final
Category: Consensus
@ -64,8 +64,9 @@ included in is 3539. After that, it will be removed from the mempool.
"locktime": 2089,
"expiryheight": 3539,
Default: 20 blocks from the current height, or about 50 minutes at 2.5-minute target
block spacing. A configuration option can be used to set the user's default.
Default: (Before Blossom) 20 blocks from the current height, or about 50 minutes at
2.5-minute target block spacing. A configuration option can be used to set the user's
default.
Minimum: No minimum

1
zip-0204.html
View File

@ -8,6 +8,7 @@
<section>
<pre>ZIP: 204
Title: Zcash P2P Network Protocol
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Status: Reserved
Category: Network
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/352">https://github.com/zcash/zips/issues/352</a>&gt;</pre>

1
zip-0204.rst
View File

@ -2,6 +2,7 @@
ZIP: 204
Title: Zcash P2P Network Protocol
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Status: Reserved
Category: Network
Discussions-To: <https://github.com/zcash/zips/issues/352>

24
zip-0205.html
View File

@ -8,16 +8,16 @@
<section>
<pre>ZIP: 205
Title: Deployment of the Sapling Network Upgrade
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Credits: Simon Liu
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" 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>
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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="footnote-reference-3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Sapling</dt>
@ -31,12 +31,12 @@ License: MIT</pre>
<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>
<li>Transaction Signature Validation for Sapling <a id="id5" class="footnote_reference" href="#zip-0243">9</a>.</li>
<li>Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">7</a>.</li>
<li>The Zcash Protocol Specification <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a>.</li>
<li>Transaction Signature Validation for Sapling <a id="footnote-reference-5" class="footnote_reference" href="#zip-0243">9</a>.</li>
<li>Network Upgrade Mechanism <a id="footnote-reference-6" class="footnote_reference" href="#zip-0200">7</a>.</li>
</ul>
<p>The network handshake and peer management mechanisms defined in <a id="id7" class="footnote_reference" href="#zip-0201">8</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="id8" class="footnote_reference" href="#zip-0200">7</a> are defined for the Sapling upgrade:</p>
<p>The network handshake and peer management mechanisms defined in <a id="footnote-reference-7" class="footnote_reference" href="#zip-0201">8</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="footnote-reference-8" class="footnote_reference" href="#zip-0200">7</a> are defined for the Sapling upgrade:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0x76b809bb</code></dd>
@ -52,7 +52,7 @@ License: MIT</pre>
<p>Approximately three days (defined in terms of block height) before the Sapling activation height, Sapling-compatible nodes will change the behaviour of their peer connection logic in order to prefer pre-Sapling peers 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). */
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
<p>The implementation is similar to that for Overwinter which was described in <a id="id9" class="footnote_reference" href="#zip-0201">8</a>.</p>
<p>The implementation is similar to that for Overwinter which was described in <a id="footnote-reference-9" class="footnote_reference" href="#zip-0201">8</a>.</p>
<p>Once Sapling activates on Testnet or Mainnet, Sapling nodes SHOULD take steps to:</p>
<ul>
<li>reject new connections from pre-Sapling nodes;</li>
@ -60,8 +60,8 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
</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" 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>Section 7.6.3 of the Zcash Protocol Specification <a id="footnote-reference-10" 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="footnote-reference-11" class="footnote_reference" href="#protocol-constants">4</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="footnote-reference-12" 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>

2
zip-0205.rst
View File

@ -2,7 +2,7 @@
ZIP: 205
Title: Deployment of the Sapling Network Upgrade
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Credits: Simon Liu
Status: Final
Category: Consensus / Network

24
zip-0206.html
View File

@ -8,23 +8,23 @@
<section>
<pre>ZIP: 206
Title: Deployment of the Blossom Network Upgrade
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Credits: Simon Liu
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" 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 key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" class="footnote_reference" href="#zip-0200">3</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Blossom</dt>
<dd>Code-name for the third Zcash network upgrade, also known as Network Upgrade 2.</dd>
<dt>Testnet</dt>
<dd>The Zcash test network, as defined in <a id="id3" class="footnote_reference" href="#protocol">2</a>.</dd>
<dd>The Zcash test network, as defined in <a id="footnote-reference-3" class="footnote_reference" href="#protocol">2</a>.</dd>
<dt>Mainnet</dt>
<dd>The Zcash production network, as defined in <a id="id4" class="footnote_reference" href="#protocol">2</a>.</dd>
<dd>The Zcash production network, as defined in <a id="footnote-reference-4" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -34,12 +34,12 @@ License: MIT</pre>
<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>
<li>Shorter Block Target Spacing <a id="id6" class="footnote_reference" href="#zip-0208">5</a>.</li>
<li>Network Upgrade Mechanism <a id="id7" class="footnote_reference" href="#zip-0200">3</a>.</li>
<li>The Zcash Protocol Specification <a id="footnote-reference-5" class="footnote_reference" href="#protocol">2</a>.</li>
<li>Shorter Block Target Spacing <a id="footnote-reference-6" class="footnote_reference" href="#zip-0208">5</a>.</li>
<li>Network Upgrade Mechanism <a id="footnote-reference-7" class="footnote_reference" href="#zip-0200">3</a>.</li>
</ul>
<p>The network handshake and peer management mechanisms defined in <a id="id8" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="id9" class="footnote_reference" href="#zip-0200">3</a> are defined for the Blossom upgrade:</p>
<p>The network handshake and peer management mechanisms defined in <a id="footnote-reference-8" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="footnote-reference-9" class="footnote_reference" href="#zip-0200">3</a> are defined for the Blossom upgrade:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0x2BB40E60</code></dd>
@ -54,7 +54,7 @@ License: MIT</pre>
<p>For each network (testnet and mainnet), approximately three days (defined in terms of block height) before the corresponding Blossom activation height, nodes compatible with Blossom activation on that network will change the behaviour of their peer connection logic in order to prefer pre-Blossom 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). */
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
<p>The implementation is similar to that for Overwinter which was described in <a id="id10" class="footnote_reference" href="#zip-0201">4</a>.</p>
<p>The implementation is similar to that for Overwinter which was described in <a id="footnote-reference-10" class="footnote_reference" href="#zip-0201">4</a>.</p>
<p>Once Blossom activates on testnet or mainnet, Blossom nodes SHOULD take steps to:</p>
<ul>
<li>reject new connections from pre-Blossom nodes on that network;</li>
@ -65,7 +65,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<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>
<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="footnote-reference-11" 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" 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>

2
zip-0206.rst
View File

@ -2,7 +2,7 @@
ZIP: 206
Title: Deployment of the Blossom Network Upgrade
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Credits: Simon Liu
Status: Final
Category: Consensus / Network

34
zip-0207.html
View File

@ -10,40 +10,40 @@
<pre>ZIP: 207
Title: Funding Streams
Owners: Jack Grigg &lt;str4d@electriccoin.co&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Status: Final
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" 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>
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" class="footnote_reference" href="#protocol-subsidyconcepts">3</a> <a id="footnote-reference-3" 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="footnote-reference-4" class="footnote_reference" href="#zip-0200">10</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Canopy</dt>
<dd>Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</dd>
<dt>Testnet</dt>
<dd>The Zcash test network, as defined in the Zcash Protocol Specification. <a id="id5" class="footnote_reference" href="#protocol-networks">4</a></dd>
<dd>The Zcash test network, as defined in the Zcash Protocol Specification. <a id="footnote-reference-5" class="footnote_reference" href="#protocol-networks">4</a></dd>
<dt>Mainnet</dt>
<dd>The Zcash production network, as defined in the Zcash Protocol Specification. <a id="id6" class="footnote_reference" href="#protocol-networks">4</a></dd>
<dd>The Zcash production network, as defined in the Zcash Protocol Specification. <a id="footnote-reference-6" 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" 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>
<p>This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 <a id="footnote-reference-7" class="footnote_reference" href="#zip-0214">14</a>. It should be read in conjunction with ZIP 1014 <a id="footnote-reference-8" 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" 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>Motivation for the Zcash Development Fund is considered in ZIP 1014 <a id="footnote-reference-9" 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" 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>The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 <a id="footnote-reference-10" 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="footnote-reference-11" 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" 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>
<p>We use the following constants and functions defined in <a id="footnote-reference-12" class="footnote_reference" href="#protocol-constants">5</a>, <a id="footnote-reference-13" class="footnote_reference" href="#protocol-diffadjustment">6</a>, <a id="footnote-reference-14" class="footnote_reference" href="#protocol-subsidies">7</a>, and <a id="footnote-reference-15" class="footnote_reference" href="#protocol-foundersreward">8</a>:</p>
<ul>
<li>
<span class="math">\(\mathsf{BlossomActivationHeight}\)</span>
@ -74,7 +74,7 @@ License: MIT</pre>
</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" 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>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="footnote-reference-16" 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>
<div class="math">\(\mathsf{FundingStream[FUND].Value}(\mathsf{height}) =
\mathsf{floor}\left(
@ -196,21 +196,21 @@ License: MIT</pre>
<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" 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>Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. <a id="footnote-reference-17" class="footnote_reference" href="#protocol-foundersreward">8</a></p>
<p>Once the Canopy network upgrade activates:</p>
<ul>
<li>The existing consensus rule for payment of the Founders' Reward <a id="id18" class="footnote_reference" href="#protocol-foundersreward">8</a> is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)</li>
<li>The existing consensus rule for payment of the Founders' Reward <a id="footnote-reference-18" class="footnote_reference" href="#protocol-foundersreward">8</a> is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)</li>
<li>The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.</li>
<li>The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form <code>OP_HASH160 RedeemScriptHash(height) OP_EQUAL</code> as the <code>scriptPubKey</code>.</li>
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="id19" class="footnote_reference" href="#zip-0213">13</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="footnote-reference-19" class="footnote_reference" href="#zip-0213">13</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be
<span class="math">\(\mathbf{0x02}\)</span>
, as specified in <a id="id20" class="footnote_reference" href="#zip-0212">12</a>.</li>
, as specified in <a id="footnote-reference-20" class="footnote_reference" href="#zip-0212">12</a>.</li>
</ul>
<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>
<p>For the funding stream definitions to be activated at Canopy, see ZIP 214. <a id="footnote-reference-21" 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="footnote-reference-22" 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" 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>
<p>This proposal is intended to be deployed with Canopy. <a id="footnote-reference-23" 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" 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>

2
zip-0207.rst
View File

@ -3,7 +3,7 @@
ZIP: 207
Title: Funding Streams
Owners: Jack Grigg <str4d@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Daira Emma Hopwood <daira@electriccoin.co>
Status: Final
Category: Consensus
Created: 2019-01-04

34
zip-0208.html
View File

@ -8,8 +8,8 @@
<section>
<pre>ZIP: 208
Title: Shorter Block Target Spacing
Owner: Daira Hopwood &lt;daira@electriccoin.co&gt;
Original-Authors: Daira Hopwood
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Original-Authors: Daira Emma Hopwood
Simon Liu
Status: Final
Category: Consensus
@ -17,13 +17,13 @@ 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" 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>
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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="footnote-reference-3" 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="footnote-reference-4" 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" 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>This proposal specifies a change in the block target spacing, to take effect in the Blossom network upgrade <a id="footnote-reference-5" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -33,15 +33,15 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<li>Greater throughput of transactions in unit time.</li>
</ul>
<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>
<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="footnote-reference-6" 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" 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>
<p>The changes described in this section are to be made in the Zcash Protocol Specification <a id="footnote-reference-7" 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" 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>Throughout the specification, rename HalvingInterval to PreBlossomHalvingInterval, and rename PoWTargetSpacing to PreBlossomTargetSpacing. These constants retain their values from <a id="footnote-reference-8" 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>
<p>For a given network (production or test), define BlossomActivationHeight as the height at which Blossom activates on that network, as specified in <a id="id9" class="footnote_reference" href="#zip-0206">11</a>.</p>
<p>For a given network (production or test), define BlossomActivationHeight as the height at which Blossom activates on that network, as specified in <a id="footnote-reference-9" class="footnote_reference" href="#zip-0206">11</a>.</p>
<p>In section 7.6.3 (Difficulty adjustment) [later moved to section 7.7.3], make the following changes:</p>
<p>Define IsBlossomActivated(<em>height</em>) to return true if <em>height</em> ≥ BlossomActivationHeight, otherwise false.</p>
<p>This specification assumes that BlossomActivationHeight ≥ SlowStartInterval.</p>
@ -111,9 +111,9 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<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" 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>On Testnet from block height 299188 onward, the difficulty adjustment algorithm <a id="footnote-reference-10" class="footnote_reference" href="#protocol-diffadjustment">6</a> allows minimum-difficulty blocks, as described in <a id="footnote-reference-11" 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="footnote-reference-12" class="footnote_reference" href="#protocol-constants">5</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="footnote-reference-13" class="footnote_reference" href="#protocol-nbits">7</a>.</p>
<p>Note: a previous revision of this ZIP (and <a id="footnote-reference-14" 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>
@ -127,7 +127,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<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" 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>ZIP 308 <a id="footnote-reference-15" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
@ -137,7 +137,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
// chain if they are valid, and no more than a month older (both in time, and in
// best equivalent proof of work) than the best header chain we know about.</pre>
<p>We make no assertion about the significance of fingerprinting for Zcash, and (despite the word "prevent" in the above comment) no claim about the effectiveness of this mitigation.</p>
<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>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="footnote-reference-16" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
@ -194,7 +194,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
</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" 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>
<p>This proposal will be deployed with the Blossom network upgrade. <a id="footnote-reference-17" 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" 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>

4
zip-0208.rst
View File

@ -2,8 +2,8 @@
ZIP: 208
Title: Shorter Block Target Spacing
Owner: Daira Hopwood <daira@electriccoin.co>
Original-Authors: Daira Hopwood
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Original-Authors: Daira Emma Hopwood
Simon Liu
Status: Final
Category: Consensus

12
zip-0209.html
View File

@ -9,18 +9,18 @@
<pre>ZIP: 209
Title: Prohibit Negative Shielded Chain Value Pool Balances
Owners: Sean Bowe &lt;sean@electriccoin.co&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
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" 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 key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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>
<p>The "Sapling chain value pool balance" for a given block chain is the negation of the sum of all <code>valueBalanceSapling</code> fields for transactions in the block chain.</p>
<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>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-3" 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" 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>
@ -34,9 +34,9 @@ License: MIT</pre>
<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" 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>This consensus rule is not deployed as part of a network upgrade as defined in ZIP-200 <a id="footnote-reference-4" 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>
<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="footnote-reference-5" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">

2
zip-0209.rst
View File

@ -3,7 +3,7 @@
ZIP: 209
Title: Prohibit Negative Shielded Chain Value Pool Balances
Owners: Sean Bowe <sean@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Daira Emma Hopwood <daira@electriccoin.co>
Status: Final
Category: Consensus
Created: 2019-02-25

12
zip-0210.html
View File

@ -14,19 +14,19 @@ 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" 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>
<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="footnote-reference-1" 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" 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>
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-2" 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="footnote-reference-3" 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="footnote-reference-4" 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" 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" 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>The Sapling network upgrade <a id="footnote-reference-5" 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="footnote-reference-6" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>

22
zip-0211.html
View File

@ -8,29 +8,29 @@
<section>
<pre>ZIP: 211
Title: Disabling Addition of New Value to the Sprout Chain Value Pool
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Credits: Sean Bowe
Status: Final
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" 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 key words "MUST", "SHOULD", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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>
<p>The term "Sapling shielded protocol" in this document refers to the shielded payment protocol introduced in the Sapling network upgrade <a id="footnote-reference-3" class="footnote_reference" href="#zip-0205">4</a> <a id="footnote-reference-4" 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="footnote-reference-5" 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" 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" 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 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="footnote-reference-6" class="footnote_reference" href="#zerocash">8</a></p>
<p>The Sapling network upgrade <a id="footnote-reference-7" 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>
<p>For example, a vulnerability was discovered in the zero-knowledge proving system originally used by Zcash that could have allowed counterfeiting <a id="id8" class="footnote_reference" href="#counterfeiting">9</a>. While this particular vulnerability was addressed (also for Sprout shielded transactions) by the Sapling upgrade, and we are not aware of others at the time of writing, the possibility of other cryptographic weaknesses cannot be entirely ruled out.</p>
<p>For example, a vulnerability was discovered in the zero-knowledge proving system originally used by Zcash that could have allowed counterfeiting <a id="footnote-reference-8" class="footnote_reference" href="#counterfeiting">9</a>. While this particular vulnerability was addressed (also for Sprout shielded transactions) by the Sapling upgrade, and we are not aware of others at the time of writing, the possibility of other cryptographic weaknesses cannot be entirely ruled out.</p>
<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>
<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="footnote-reference-9" 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" 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>
@ -47,7 +47,7 @@ License: MIT</pre>
<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>
<ul>
<li>Privacy concerns raised as a consequence of preventing the use of internal change between JoinSplits, and/or change sent back to the input Sprout addresses. This would have required the total value of the input Sprout notes (or, for some considered designs, the total value of the two Sprout inputs to each JoinSplit) to be leaked. As it is, there is an unavoidable leak of the total value extracted from the Sprout value pool, but not of the sum of values of particular subsets of notes.</li>
<li>Modifications would have been needed to the design of the Sprout to Sapling migration procedure described in <a id="id10" class="footnote_reference" href="#zip-0308">7</a>.</li>
<li>Modifications would have been needed to the design of the Sprout to Sapling migration procedure described in <a id="footnote-reference-10" class="footnote_reference" href="#zip-0308">7</a>.</li>
<li>A new transaction version would have been required.</li>
</ul>
</section>
@ -56,7 +56,7 @@ License: MIT</pre>
<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" 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>
<p>This proposal will be deployed with the Canopy network upgrade. <a id="footnote-reference-11" 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" 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>

2
zip-0211.rst
View File

@ -2,7 +2,7 @@
ZIP: 211
Title: Disabling Addition of New Value to the Sprout Chain Value Pool
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Credits: Sean Bowe
Status: Final
Category: Consensus

38
zip-0212.html
View File

@ -15,37 +15,37 @@ 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" 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>
<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="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The following functions are defined in the Zcash Protocol Specification <a id="footnote-reference-2" class="footnote_reference" href="#protocol">2</a> according to the type (Sapling or Orchard) of note plaintext being processed:</p>
<ul>
<li>let
<span class="math">\(\mathsf{ToScalar}\)</span>
be
<span class="math">\(\mathsf{ToScalar^{Sapling}}\)</span>
defined in section 4.2.2 <a id="id3" class="footnote_reference" href="#protocol-saplingkeycomponents">5</a> or
defined in section 4.2.2 <a id="footnote-reference-3" class="footnote_reference" href="#protocol-saplingkeycomponents">5</a> or
<span class="math">\(\mathsf{ToScalar^{Orchard}}\)</span>
defined in section 4.2.3 <a id="id4" class="footnote_reference" href="#protocol-orchardkeycomponents">6</a>;</li>
defined in section 4.2.3 <a id="footnote-reference-4" class="footnote_reference" href="#protocol-orchardkeycomponents">6</a>;</li>
<li>let
<span class="math">\(\mathsf{DiversifyHash}\)</span>
be
<span class="math">\(\mathsf{DiversifyHash^{Sapling}}\)</span>
or
<span class="math">\(\mathsf{DiversifyHash^{Orchard}}\)</span>
defined in section 5.4.1.6 <a id="id5" class="footnote_reference" href="#protocol-concretediversifyhash">12</a>;</li>
defined in section 5.4.1.6 <a id="footnote-reference-5" class="footnote_reference" href="#protocol-concretediversifyhash">12</a>;</li>
<li>let
<span class="math">\(\mathsf{KA}\)</span>
be
<span class="math">\(\mathsf{KA^{Sapling}}\)</span>
defined in section 5.4.5.3 <a id="id6" class="footnote_reference" href="#protocol-concretesaplingkeyagreement">13</a> or
defined in section 5.4.5.3 <a id="footnote-reference-6" class="footnote_reference" href="#protocol-concretesaplingkeyagreement">13</a> or
<span class="math">\(\mathsf{KA^{Orchard}}\)</span>
defined in section 5.4.5.5 <a id="id7" class="footnote_reference" href="#protocol-concreteorchardkeyagreement">14</a>;</li>
defined in section 5.4.5.5 <a id="footnote-reference-7" class="footnote_reference" href="#protocol-concreteorchardkeyagreement">14</a>;</li>
<li>let
<span class="math">\(\mathsf{NoteCommit}\)</span>
be
<span class="math">\(\mathsf{NoteCommit^{Sapling}}\)</span>
or
<span class="math">\(\mathsf{NoteCommit^{Orchard}}\)</span>
defined in section 4.1.8 <a id="id8" class="footnote_reference" href="#protocol-abstractcommit">4</a>.</li>
defined in section 4.1.8 <a id="footnote-reference-8" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -113,8 +113,8 @@ License: MIT</pre>
.</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" 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
<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="footnote-reference-9" 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="footnote-reference-10" class="footnote_reference" href="#protocol-abstractprfs">3</a>. We will be adapting
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
for the purposes of this ZIP. This function is keyed by a 256-bit key
<span class="math">\(\mathsf{sk}\)</span>
@ -122,7 +122,7 @@ License: MIT</pre>
<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" 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
<p>Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification <a id="footnote-reference-11" 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
<span class="math">\(256\)</span>
@ -151,7 +151,7 @@ License: MIT</pre>
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" 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
<p>The process of sending notes is described in section 4.7.2 of the Zcash Protocol Specification for Sapling <a id="footnote-reference-12" class="footnote_reference" href="#protocol-saplingsend">7</a> and section 4.7.3 for Orchard <a id="footnote-reference-13" 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="footnote-reference-14" 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
<span class="math">\(\mathsf{esk}\)</span>
@ -178,10 +178,10 @@ License: MIT</pre>
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\)</span>
.</li>
</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>
<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="footnote-reference-15" 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" 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>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="footnote-reference-16" class="footnote_reference" href="#protocol-decryptivk">10</a> <a id="footnote-reference-17" 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>
MUST still be accepted.</p>
@ -223,11 +223,11 @@ License: MIT</pre>
, 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" 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
<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="footnote-reference-18" class="footnote_reference" href="#zip-0213">17</a>, MUST have note plaintext lead byte equal to
<span class="math">\(\mathtt{0x02}\)</span>
.</p>
<p>This applies even during the “grace period”, and also applies to funding stream outputs <a id="id19" class="footnote_reference" href="#zip-0207">16</a> sent to shielded payment addresses, if there are any.</p>
<p>Since NU5 activates after the end of the grace period <a id="id20" class="footnote_reference" href="#zip-0252">19</a>, Orchard outputs will always require a note plaintext lead byte equal to
<p>This applies even during the “grace period”, and also applies to funding stream outputs <a id="footnote-reference-19" class="footnote_reference" href="#zip-0207">16</a> sent to shielded payment addresses, if there are any.</p>
<p>Since NU5 activates after the end of the grace period <a id="footnote-reference-20" class="footnote_reference" href="#zip-0252">19</a>, Orchard outputs will always require a note plaintext lead byte equal to
<span class="math">\(\mathtt{0x02}\)</span>
.</p>
</section>
@ -253,7 +253,7 @@ License: MIT</pre>
that were sent conformantly and not mined before the upgrade.</p>
<p>Historical note: in practice some note plaintexts with lead byte
<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>
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="footnote-reference-21" 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" 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>
@ -264,7 +264,7 @@ License: MIT</pre>
) 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" 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>
<p>This proposal will be deployed with the Canopy network upgrade. <a id="footnote-reference-22" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>In zcashd:</p>

14
zip-0213.html
View File

@ -14,18 +14,18 @@ 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" 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>
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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="footnote-reference-3" 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="footnote-reference-4" 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" 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" 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>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="footnote-reference-5" 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>
<p>The Sapling network upgrade <a id="footnote-reference-6" 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="footnote-reference-7" 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" 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>
@ -71,7 +71,7 @@ License: MIT</pre>
<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" 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>
<p>This proposal will be deployed with the Heartwood network upgrade. <a id="footnote-reference-8" 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" 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>

32
zip-0214.html
View File

@ -8,20 +8,20 @@
<section>
<pre>ZIP: 214
Title: Consensus rules for a Zcash Development Fund
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Status: Final
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" 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>
<p>The term "block subsidy" in this document is to be interpreted as described in section 3.10 of the Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol-subsidyconcepts">3</a>.</p>
<p>The term "halving" in this document are to be interpreted as described in sections 7.8 of the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-subsidies">5</a>.</p>
<p>The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "BP slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 <a id="id7" class="footnote_reference" href="#zip-1014">12</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="id8" class="footnote_reference" href="#protocol-networks">4</a>.</p>
<p>The key words "MUST", "SHALL", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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="footnote-reference-3" class="footnote_reference" href="#zip-0200">8</a> and the Zcash Trademark Donation and License Agreement (<a id="footnote-reference-4" class="footnote_reference" href="#trademark">6</a> or successor agreement).</p>
<p>The term "block subsidy" in this document is to be interpreted as described in section 3.10 of the Zcash Protocol Specification <a id="footnote-reference-5" class="footnote_reference" href="#protocol-subsidyconcepts">3</a>.</p>
<p>The term "halving" in this document are to be interpreted as described in sections 7.8 of the Zcash Protocol Specification <a id="footnote-reference-6" class="footnote_reference" href="#protocol-subsidies">5</a>.</p>
<p>The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "BP slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 <a id="footnote-reference-7" class="footnote_reference" href="#zip-1014">12</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="footnote-reference-8" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -31,7 +31,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/community-sentim
<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" 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>Motivation for the Zcash Development Fund itself is considered in ZIP 1014 <a id="footnote-reference-9" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -42,9 +42,9 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/community-sentim
<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" 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>The Blossom network upgrade changed the height of the first halving to block height 1046400 <a id="footnote-reference-10" 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>
<p>ZIP 207 <a id="footnote-reference-11" class="footnote_reference" href="#zip-0207">9</a> SHALL be activated in Canopy.</p>
<p>The following funding streams are defined for Mainnet:</p>
<blockquote>
<table>
@ -82,7 +82,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/community-sentim
</tbody>
</table>
</blockquote>
<p>As specified in <a id="id12" class="footnote_reference" href="#zip-0207">9</a>, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.</p>
<p>As specified in <a id="footnote-reference-12" class="footnote_reference" href="#zip-0207">9</a>, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.</p>
<p>The following funding streams are defined for Testnet:</p>
<blockquote>
<table>
@ -132,10 +132,10 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/community-sentim
<li>ZF SHALL generate the addresses for the <code>FS_ZIP214_ZF</code> and <code>FS_ZIP214_MG</code> funding streams, which on Mainnet correspond to the <strong>ZF slice</strong> and <strong>MG slice</strong> respectively.</li>
</ul>
<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>Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 <a id="footnote-reference-13" 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" 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>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="footnote-reference-14" 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>
@ -259,12 +259,12 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
</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" 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>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="footnote-reference-15" 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" 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>
<p>This proposal is intended to be deployed with Canopy. <a id="footnote-reference-16" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">

2
zip-0214.rst
View File

@ -2,7 +2,7 @@
ZIP: 214
Title: Consensus rules for a Zcash Development Fund
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Status: Final
Category: Consensus
Created: 2020-02-28

14
zip-0215.html
View File

@ -15,19 +15,19 @@ 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" 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>
<p>The key words "MUST" and "MUST NOT" in this document is to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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" 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>
<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="footnote-reference-2" 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" 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>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="footnote-reference-3" 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" 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>
validation rules in <a id="footnote-reference-4" class="footnote_reference" href="#protocol-concreteed25519">5</a> are changed to the following:</p>
<ul>
<li>
<span class="math">\(\underline{A}\)</span>
@ -51,11 +51,11 @@ License: BSD-2-Clause</pre>
<span class="math">\(k\)</span>
and
<span class="math">\(B\)</span>
are defined as in RFC 8032 sections §5.1.7 and §5.1 respectively. <a id="id5" class="footnote_reference" href="#rfc8032">2</a></li>
are defined as in RFC 8032 sections §5.1.7 and §5.1 respectively. <a id="footnote-reference-5" class="footnote_reference" href="#rfc8032">2</a></li>
</ul>
<p>The language about
<span class="math">\(\mathsf{ExcludedPointEncodings}\)</span>
in §5.4.5 of the Zcash specification <a id="id6" class="footnote_reference" href="#protocol-concreteed25519">5</a> no longer applies.</p>
in §5.4.5 of the Zcash specification <a id="footnote-reference-6" class="footnote_reference" href="#protocol-concreteed25519">5</a> no longer applies.</p>
<p>It is <em>not</em> required that
<span class="math">\(\underline{A}\)</span>
and
@ -77,7 +77,7 @@ License: BSD-2-Clause</pre>
<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" 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>
<p>This is intended to be deployed with the Canopy Network Upgrade <a id="footnote-reference-7" class="footnote_reference" href="#zip-0251">6</a>, which is scheduled to activate on Mainnet <a id="footnote-reference-8" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">

36
zip-0216.html
View File

@ -10,28 +10,28 @@
<pre>ZIP: 216
Title: Require Canonical Jubjub Point Encodings
Owners: Jack Grigg &lt;jack@electriccoin.co&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Status: Final
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" 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>
<p>The key word "MUST" in this document is to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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" 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" 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
<p>The Sapling specification was originally written with the intent that all values, including Jubjub points, are strongly typed with canonical representations. <a id="footnote-reference-3" 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="footnote-reference-4" 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>
-coordinate is zero, there are two encodings that will be accepted:</p>
<pre data-language="rust"><span class="c1">// Fix the sign of `u` if necessary</span>
<span class="kd">let</span><span class="w"> </span><span class="n">flip_sign</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">Choice</span>::<span class="n">from</span><span class="p">((</span><span class="n">u</span><span class="p">.</span><span class="n">to_bytes</span><span class="p">()[</span><span class="mi">0</span><span class="p">]</span><span class="w"> </span><span class="o">^</span><span class="w"> </span><span class="n">sign</span><span class="p">)</span><span class="w"> </span><span class="o">&amp;</span><span class="w"> </span><span class="mi">1</span><span class="p">);</span><span class="w"></span>
<span class="kd">let</span><span class="w"> </span><span class="n">u_negated</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="o">-</span><span class="n">u</span><span class="p">;</span><span class="w"></span>
<span class="kd">let</span><span class="w"> </span><span class="n">final_u</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">Fq</span>::<span class="n">conditional_select</span><span class="p">(</span><span class="o">&amp;</span><span class="n">u</span><span class="p">,</span><span class="w"> </span><span class="o">&amp;</span><span class="n">u_negated</span><span class="p">,</span><span class="w"> </span><span class="n">flip_sign</span><span class="p">);</span><span class="w"></span></pre>
<span class="kd">let</span><span class="w"> </span><span class="n">flip_sign</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">Choice</span>::<span class="n">from</span><span class="p">((</span><span class="n">u</span><span class="p">.</span><span class="n">to_bytes</span><span class="p">()[</span><span class="mi">0</span><span class="p">]</span><span class="w"> </span><span class="o">^</span><span class="w"> </span><span class="n">sign</span><span class="p">)</span><span class="w"> </span><span class="o">&amp;</span><span class="w"> </span><span class="mi">1</span><span class="p">);</span>
<span class="kd">let</span><span class="w"> </span><span class="n">u_negated</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="o">-</span><span class="n">u</span><span class="p">;</span>
<span class="kd">let</span><span class="w"> </span><span class="n">final_u</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">Fq</span>::<span class="n">conditional_select</span><span class="p">(</span><span class="o">&amp;</span><span class="n">u</span><span class="p">,</span><span class="w"> </span><span class="o">&amp;</span><span class="n">u_negated</span><span class="p">,</span><span class="w"> </span><span class="n">flip_sign</span><span class="p">);</span></pre>
<p>This code accepts either sign bit, because <code>u_negated == u</code>.</p>
<p>There are two points on the Jubjub curve with
<span class="math">\(u\!\)</span>
@ -58,7 +58,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<span class="math">\(\mathsf{repr}_{\mathbb{J}}\)</span>
, and
<span class="math">\(q_{\mathbb{J}}\)</span>
be as defined in <a id="id5" class="footnote_reference" href="#protocol-jubjub">6</a>.</p>
be as defined in <a id="footnote-reference-5" class="footnote_reference" href="#protocol-jubjub">6</a>.</p>
<p>Define a non-canonical compressed encoding of a Jubjub point to be a sequence of
<span class="math">\(256\)</span>
bits,
@ -80,7 +80,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<span class="math">\(\mathtt{0x80}\)</span>
byte.</p>
<p>Once this ZIP activates, the following places within the Sapling consensus protocol where Jubjub points occur MUST reject non-canonical Jubjub point encodings.</p>
<p>In Sapling Spend descriptions <a id="id6" class="footnote_reference" href="#protocol-spenddesc">3</a>:</p>
<p>In Sapling Spend descriptions <a id="footnote-reference-6" class="footnote_reference" href="#protocol-spenddesc">3</a>:</p>
<blockquote>
<ul>
<li>the
@ -92,7 +92,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
RedDSA signature.</li>
</ul>
</blockquote>
<p>In transactions <a id="id7" class="footnote_reference" href="#protocol-txnencoding">10</a>:</p>
<p>In transactions <a id="footnote-reference-7" class="footnote_reference" href="#protocol-txnencoding">10</a>:</p>
<blockquote>
<ul>
<li>the
@ -106,7 +106,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
</blockquote>
<p>In the plaintext obtained by decrypting the
<span class="math">\(\mathsf{C^{out}}\)</span>
field of a Sapling transmitted note ciphertext <a id="id8" class="footnote_reference" href="#protocol-decryptovk">5</a>:</p>
field of a Sapling transmitted note ciphertext <a id="footnote-reference-8" class="footnote_reference" href="#protocol-decryptovk">5</a>:</p>
<blockquote>
<ul>
<li>
@ -116,7 +116,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
</blockquote>
<p>(This affects decryption of
<span class="math">\(\mathsf{C^{out}}\)</span>
in all cases, but is consensus-critical only in the case of a shielded coinbase output. <a id="id9" class="footnote_reference" href="#protocol-txnencoding">10</a>)</p>
in all cases, but is consensus-critical only in the case of a shielded coinbase output. <a id="footnote-reference-9" class="footnote_reference" href="#protocol-txnencoding">10</a>)</p>
<p>There are some additional fields in the consensus protocol that encode Jubjub points, but where non-canonical encodings MUST already be rejected as a side-effect of existing consensus rules.</p>
<p>In Sapling Spend descriptions:</p>
<blockquote>
@ -129,7 +129,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
</li>
</ul>
</blockquote>
<p>In Sapling Output descriptions <a id="id10" class="footnote_reference" href="#protocol-outputdesc">4</a>:</p>
<p>In Sapling Output descriptions <a id="footnote-reference-10" class="footnote_reference" href="#protocol-outputdesc">4</a>:</p>
<blockquote>
<ul>
<li>
@ -145,7 +145,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<p>In addition, Sapling addresses and full viewing keys MUST be considered invalid when imported if they contain non-canonical Jubjub point encodings, or encodings of points that are not in the prime-order subgroup
<span class="math">\(\mathbb{J}^{(r)}\)</span>
. These requirements MAY be enforced in advance of NU5 activation.</p>
<p>In Sapling addresses <a id="id11" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">8</a>:</p>
<p>In Sapling addresses <a id="footnote-reference-11" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">8</a>:</p>
<blockquote>
<ul>
<li>the encoding of
@ -153,7 +153,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
.</li>
</ul>
</blockquote>
<p>In Sapling full viewing keys <a id="id12" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">9</a> and extended full viewing keys <a id="id13" class="footnote_reference" href="#zip-0032-extfvk">11</a>:</p>
<p>In Sapling full viewing keys <a id="footnote-reference-12" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">9</a> and extended full viewing keys <a id="footnote-reference-13" class="footnote_reference" href="#zip-0032-extfvk">11</a>:</p>
<blockquote>
<ul>
<li>the encoding of
@ -169,7 +169,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<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" 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>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="footnote-reference-14" class="footnote_reference" href="#zip-0215">13</a> (which activated with the Canopy network upgrade <a id="footnote-reference-15" 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>
<li>The chance of the identity occurring anywhere within the Sapling components of transactions from implementations following the standard protocol is cryptographically negligible.</li>
@ -197,7 +197,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
, and BLS12-381
<span class="math">\(\mathbb{G}_2\)</span>
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>
<p>Encodings of elliptic curve points on the Pallas and Vesta curves in the NU5 proposal <a id="footnote-reference-16" 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" 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>

2
zip-0216.rst
View File

@ -3,7 +3,7 @@
ZIP: 216
Title: Require Canonical Jubjub Point Encodings
Owners: Jack Grigg <jack@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Daira Emma Hopwood <daira@electriccoin.co>
Status: Final
Category: Consensus
Created: 2021-02-11

2
zip-0217.html
View File

@ -8,7 +8,7 @@
<section>
<pre>ZIP: 217
Title: Aggregate Signatures
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Status: Reserved
Category: Consensus
Discussions-To: &lt;<a href="https://github.com/zcash/zcash/issues/2914">https://github.com/zcash/zcash/issues/2914</a>&gt;</pre>

2
zip-0217.rst
View File

@ -2,7 +2,7 @@
ZIP: 217
Title: Aggregate Signatures
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Status: Reserved
Category: Consensus
Discussions-To: <https://github.com/zcash/zcash/issues/2914>

2
zip-0219.html
View File

@ -8,7 +8,7 @@
<section>
<pre>ZIP: 219
Title: Disabling Addition of New Value to the Sapling Chain Value Pool
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Status: Reserved
Category: Consensus
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/428">https://github.com/zcash/zips/issues/428</a>&gt;</pre>

2
zip-0219.rst
View File

@ -2,7 +2,7 @@
ZIP: 219
Title: Disabling Addition of New Value to the Sapling Chain Value Pool
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Status: Reserved
Category: Consensus
Discussions-To: <https://github.com/zcash/zips/issues/428>

2
zip-0220.html
View File

@ -9,7 +9,7 @@
<pre>ZIP: 220
Title: Zcash Shielded Assets
Owners: Jack Grigg &lt;jack@electriccoin.co&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Status: Withdrawn
Category: Consensus
Discussions-To: &lt;<a href="https://github.com/zcash/zcash/issues/830">https://github.com/zcash/zcash/issues/830</a>&gt;

2
zip-0220.rst
View File

@ -3,7 +3,7 @@
ZIP: 220
Title: Zcash Shielded Assets
Owners: Jack Grigg <jack@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Daira Emma Hopwood <daira@electriccoin.co>
Status: Withdrawn
Category: Consensus
Discussions-To: <https://github.com/zcash/zcash/issues/830>

56
zip-0221.html
View File

@ -18,8 +18,8 @@ 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" 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>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" class="footnote_reference" href="#zip-0200">8</a></p>
<dl>
<dt><em>Light client</em></dt>
<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>
@ -40,7 +40,7 @@ License: MIT</pre>
</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" 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>
<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="footnote-reference-3" 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" 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
@ -48,7 +48,7 @@ License: MIT</pre>
operations and only requires knowledge of the previous subtree roots, of which there are fewer than
<span class="math">\(\log(n)\)</span>
.</p>
<p>(example adapted from <a id="id4" class="footnote_reference" href="#mimblewimble">6</a>) To illustrate this, consider a list of 11 leaves. We first construct the biggest perfect binary subtrees possible by joining any balanced sibling trees that are the same size. We do this starting from the left to the right, adding a parent as soon as 2 children exist. This leaves us with three subtrees ("mountains") of altitudes 3, 1, and 0:</p>
<p>(example adapted from <a id="footnote-reference-4" class="footnote_reference" href="#mimblewimble">6</a>) To illustrate this, consider a list of 11 leaves. We first construct the biggest perfect binary subtrees possible by joining any balanced sibling trees that are the same size. We do this starting from the left to the right, adding a parent as soon as 2 children exist. This leaves us with three subtrees ("mountains") of altitudes 3, 1, and 0:</p>
<pre data-language="text"> /\
/ \
/\ /\
@ -151,7 +151,7 @@ License: MIT</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" 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>
<p>MMR proofs are used in the FlyClient protocol <a id="footnote-reference-5" 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>
<li>the inclusion of a block
@ -171,7 +171,7 @@ License: MIT</pre>
<p>(
<span class="math">\(x\)</span>
is the activation height of the preceding network upgrade.)</p>
<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>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="footnote-reference-6" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -196,7 +196,7 @@ License: MIT</pre>
<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" 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>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="footnote-reference-7" 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">
<li><code>hashSubtreeCommitment</code>
@ -287,7 +287,7 @@ License: MIT</pre>
<dt>Leaf node</dt>
<dd>The protocol-defined work of the block:
<span class="math">\(\mathsf{floor}(2^{256} / (\mathsf{ToTarget}(\mathsf{nBits}) + 1))\)</span>
. <a id="id8" class="footnote_reference" href="#protocol-workdef">4</a></dd>
. <a id="footnote-reference-8" class="footnote_reference" href="#protocol-workdef">4</a></dd>
<dt>Internal or root node</dt>
<dd>
<p>The sum of the <code>nSubTreeTotalWork</code> fields of both children.</p>
@ -357,7 +357,7 @@ License: MIT</pre>
<p>Serialized as <code>CompactSize uint</code>.</p>
</li>
</ol>
<p>The fields marked "[NU5 onward]" are omitted before NU5 activation <a id="id9" class="footnote_reference" href="#zip-0252">11</a>.</p>
<p>The fields marked "[NU5 onward]" are omitted before NU5 activation <a id="footnote-reference-9" class="footnote_reference" href="#zip-0252">11</a>.</p>
<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>
@ -391,10 +391,10 @@ License: MIT</pre>
<span class="nd">@classmethod</span>
<span class="k">def</span> <span class="nf">from_block</span><span class="p">(</span><span class="n">Z</span><span class="p">,</span> <span class="n">block</span><span class="p">:</span> <span class="n">ZcashBlock</span><span class="p">)</span> <span class="o">-&gt;</span> <span class="n">ZcashMMRNode</span><span class="p">:</span>
<span class="sd">&#39;&#39;&#39;Create a leaf node from a block&#39;&#39;&#39;</span>
<span class="w"> </span><span class="sd">&#39;&#39;&#39;Create a leaf node from a block&#39;&#39;&#39;</span>
<span class="k">return</span> <span class="n">Z</span><span class="p">(</span>
<span class="n">left_child</span><span class="o">=</span><span class="bp">None</span><span class="p">,</span>
<span class="n">right_child</span><span class="o">=</span><span class="bp">None</span><span class="p">,</span>
<span class="n">left_child</span><span class="o">=</span><span class="kc">None</span><span class="p">,</span>
<span class="n">right_child</span><span class="o">=</span><span class="kc">None</span><span class="p">,</span>
<span class="n">hashSubtreeCommitment</span><span class="o">=</span><span class="n">block</span><span class="o">.</span><span class="n">header_hash</span><span class="p">,</span>
<span class="n">nEarliestTimestamp</span><span class="o">=</span><span class="n">block</span><span class="o">.</span><span class="n">timestamp</span><span class="p">,</span>
<span class="n">nLatestTimestamp</span><span class="o">=</span><span class="n">block</span><span class="o">.</span><span class="n">timestamp</span><span class="p">,</span>
@ -412,7 +412,7 @@ License: MIT</pre>
<span class="n">consensusBranchId</span><span class="o">=</span><span class="n">block</span><span class="o">.</span><span class="n">consensusBranchId</span><span class="p">)</span>
<span class="k">def</span> <span class="nf">serialize</span><span class="p">(</span><span class="bp">self</span><span class="p">)</span> <span class="o">-&gt;</span> <span class="nb">bytes</span><span class="p">:</span>
<span class="sd">&#39;&#39;&#39;serializes a node&#39;&#39;&#39;</span>
<span class="w"> </span><span class="sd">&#39;&#39;&#39;serializes a node&#39;&#39;&#39;</span>
<span class="n">buf</span> <span class="o">=</span> <span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">hashSubtreeCommitment</span>
<span class="o">+</span> <span class="n">serialize_uint32</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">nEarliestTimestamp</span><span class="p">)</span>
<span class="o">+</span> <span class="n">serialize_uint32</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">nLatestTimestamp</span><span class="p">)</span>
@ -424,7 +424,7 @@ License: MIT</pre>
<span class="o">+</span> <span class="n">serialize_compact_uint</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">nEarliestHeight</span><span class="p">)</span>
<span class="o">+</span> <span class="n">serialize_compact_uint</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">nLatestHeight</span><span class="p">)</span>
<span class="o">+</span> <span class="n">serialize_compact_uint</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">nSaplingTxCount</span><span class="p">))</span>
<span class="k">if</span> <span class="n">hashEarliestOrchardRoot</span> <span class="ow">is</span> <span class="ow">not</span> <span class="bp">None</span><span class="p">:</span>
<span class="k">if</span> <span class="n">hashEarliestOrchardRoot</span> <span class="ow">is</span> <span class="ow">not</span> <span class="kc">None</span><span class="p">:</span>
<span class="n">buf</span> <span class="o">+=</span> <span class="p">(</span><span class="n">hashEarliestOrchardRoot</span>
<span class="o">+</span> <span class="n">hashLatestOrchardRoot</span>
<span class="o">+</span> <span class="n">serialize_compact_uint</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">nOrchardTxCount</span><span class="p">))</span>
@ -452,12 +452,12 @@ License: MIT</pre>
<span class="n">hashEarliestOrchardRoot</span><span class="o">=</span><span class="n">left_child</span><span class="o">.</span><span class="n">orchard_root</span><span class="p">,</span>
<span class="n">hashLatestOrchardRoot</span><span class="o">=</span><span class="n">right_child</span><span class="o">.</span><span class="n">orchard_root</span><span class="p">,</span>
<span class="n">nOrchardTxCount</span><span class="o">=</span><span class="p">(</span><span class="n">left_child</span><span class="o">.</span><span class="n">nOrchardTxCount</span> <span class="o">+</span> <span class="n">right_child</span><span class="o">.</span><span class="n">nOrchardTxCount</span>
<span class="k">if</span> <span class="n">left_child</span><span class="o">.</span><span class="n">nOrchardTxCount</span> <span class="ow">is</span> <span class="ow">not</span> <span class="bp">None</span> <span class="ow">and</span> <span class="n">right_child</span><span class="o">.</span><span class="n">nOrchardTxCount</span> <span class="ow">is</span> <span class="ow">not</span> <span class="bp">None</span>
<span class="k">else</span> <span class="bp">None</span><span class="p">),</span>
<span class="k">if</span> <span class="n">left_child</span><span class="o">.</span><span class="n">nOrchardTxCount</span> <span class="ow">is</span> <span class="ow">not</span> <span class="kc">None</span> <span class="ow">and</span> <span class="n">right_child</span><span class="o">.</span><span class="n">nOrchardTxCount</span> <span class="ow">is</span> <span class="ow">not</span> <span class="kc">None</span>
<span class="k">else</span> <span class="kc">None</span><span class="p">),</span>
<span class="n">consensusBranchId</span><span class="o">=</span><span class="n">left_child</span><span class="o">.</span><span class="n">consensusBranchId</span><span class="p">)</span>
<span class="k">def</span> <span class="nf">make_root_commitment</span><span class="p">(</span><span class="n">root</span><span class="p">:</span> <span class="n">ZcashMMRNode</span><span class="p">)</span> <span class="o">-&gt;</span> <span class="nb">bytes</span><span class="p">:</span>
<span class="sd">&#39;&#39;&#39;Makes the root commitment for a blockheader&#39;&#39;&#39;</span>
<span class="w"> </span><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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -465,7 +465,7 @@ License: MIT</pre>
<span class="math">\(B_n\)</span>
, we append a new MMR leaf node corresponding to block
<span class="math">\(B_{n-1}\)</span>
. The <code>append</code> operation is detailed below in pseudocode (adapted from <a id="id10" class="footnote_reference" href="#flyclient">2</a>):</p>
. The <code>append</code> operation is detailed below in pseudocode (adapted from <a id="footnote-reference-10" class="footnote_reference" href="#flyclient">2</a>):</p>
<pre data-language="python"><span class="k">def</span> <span class="nf">get_peaks</span><span class="p">(</span><span class="n">node</span><span class="p">:</span> <span class="n">ZcashMMRNode</span><span class="p">)</span> <span class="o">-&gt;</span> <span class="n">List</span><span class="p">[</span><span class="n">ZcashMMRNode</span><span class="p">]:</span>
<span class="n">peaks</span><span class="p">:</span> <span class="n">List</span><span class="p">[</span><span class="n">ZcashMMRNode</span><span class="p">]</span> <span class="o">=</span> <span class="p">[]</span>
@ -488,7 +488,7 @@ License: MIT</pre>
<span class="k">def</span> <span class="nf">bag_peaks</span><span class="p">(</span><span class="n">peaks</span><span class="p">:</span> <span class="n">List</span><span class="p">[</span><span class="n">ZcashMMRNode</span><span class="p">])</span> <span class="o">-&gt;</span> <span class="n">ZcashMMRNode</span><span class="p">:</span>
<span class="sd">&#39;&#39;&#39;</span>
<span class="w"> </span><span class="sd">&#39;&#39;&#39;</span>
<span class="sd"> &quot;Bag&quot; a list of peaks, and return the final root</span>
<span class="sd"> &#39;&#39;&#39;</span>
<span class="n">root</span> <span class="o">=</span> <span class="n">peaks</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span>
@ -498,7 +498,7 @@ License: MIT</pre>
<span class="k">def</span> <span class="nf">append</span><span class="p">(</span><span class="n">root</span><span class="p">:</span> <span class="n">ZcashMMRNode</span><span class="p">,</span> <span class="n">leaf</span><span class="p">:</span> <span class="n">ZcashMMRNode</span><span class="p">)</span> <span class="o">-&gt;</span> <span class="n">ZcashMMRNode</span><span class="p">:</span>
<span class="sd">&#39;&#39;&#39;Append a leaf to an existing tree, return the new tree root&#39;&#39;&#39;</span>
<span class="w"> </span><span class="sd">&#39;&#39;&#39;Append a leaf to an existing tree, return the new tree root&#39;&#39;&#39;</span>
<span class="c1"># recursively find a list of peaks in the current tree</span>
<span class="n">peaks</span><span class="p">:</span> <span class="n">List</span><span class="p">[</span><span class="n">ZcashMMRNode</span><span class="p">]</span> <span class="o">=</span> <span class="n">get_peaks</span><span class="p">(</span><span class="n">root</span><span class="p">)</span>
<span class="n">merged</span><span class="p">:</span> <span class="n">List</span><span class="p">[</span><span class="n">ZcashMMRNode</span><span class="p">]</span> <span class="o">=</span> <span class="p">[]</span>
@ -525,7 +525,7 @@ License: MIT</pre>
<span class="math">\(k\)</span>
is the number of leaves in the right subtree of the MMR root.</p>
<pre data-language="python"><span class="k">def</span> <span class="nf">delete</span><span class="p">(</span><span class="n">root</span><span class="p">:</span> <span class="n">ZcashMMRNode</span><span class="p">)</span> <span class="o">-&gt;</span> <span class="n">ZcashMMRNode</span><span class="p">:</span>
<span class="sd">&#39;&#39;&#39;</span>
<span class="w"> </span><span class="sd">&#39;&#39;&#39;</span>
<span class="sd"> Delete the rightmost leaf node from an existing MMR</span>
<span class="sd"> Return the new tree root</span>
<span class="sd"> &#39;&#39;&#39;</span>
@ -553,9 +553,9 @@ License: MIT</pre>
<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" 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>
<p>The following specification is accurate before NU5 activation. See <a id="footnote-reference-11" 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="footnote-reference-12" 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="footnote-reference-13" class="footnote_reference" href="#protocol-blockheader">3</a></p>
<blockquote>
<p>[Sapling onward] <code>hashLightClientRoot</code> MUST be
<span class="math">\(\mathsf{LEBS2OSP}_{256}(\mathsf{rt})\)</span>
@ -625,7 +625,7 @@ License: MIT</pre>
</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" 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>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="footnote-reference-14" 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="footnote-reference-15" 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>
<p>We also considered putting <code>hashChainHistoryRoot</code> in the <code>hashPrevBlock</code> field as it commits to the entire chain history, but quickly realized it would require massive refactoring of the existing code base and would negatively impact performance. Reorgs in particular are fragile, performance-critical, and rely on backwards iteration over the chain history. If a chain were to be designed from scratch there may be some efficient implementation that would join these commitments, but it is clearly not appropriate for Zcash as it exists.</p>
<p>The calculation of <code>hashChainHistoryRoot</code> is not well-defined for the genesis block, since then
@ -641,11 +641,11 @@ License: MIT</pre>
<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>
<p>FlyClient, like all light clients, requires a connection to a light client server. That server may collect information about client requests, and may use that information to attempt to deanonymize clients. However, because FlyClient proofs are non-interactive and publicly verifiable, they could be shared among many light clients after the initial server interaction.</p>
<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>
<p>In addition, <a id="footnote-reference-16" 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" 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>
<p>On the Zcash Mainnet and Testnet, this proposal will be deployed with the Heartwood network upgrade. <a id="footnote-reference-17" class="footnote_reference" href="#zip-0250">10</a></p>
<p>Additional fields are added on activation of the NU5 network upgrade <a id="footnote-reference-18" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>

24
zip-0222.html
View File

@ -11,24 +11,24 @@ Title: Transparent Zcash Extensions
Owners: Jack Grigg &lt;jack@electriccoin.co&gt;
Kris Nuttycombe &lt;kris@electriccoin.co&gt;
Credits: Zaki Manian
Daira Hopwood
Daira Emma Hopwood
Sean Bowe
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" 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 key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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>
<p>The term "non-malleable" in this document is to be interpreted as described in ZIP 244 <a id="footnote-reference-3" 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="footnote-reference-4" 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" 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" 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>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="footnote-reference-5" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -249,7 +249,7 @@ License: MIT</pre>
<li>Non-coinbase transactions MUST have at least one of the following: - nonempty transparent inputs - nonempty shielded inputs - nonempty <code>tze_inputs</code></li>
</ul>
<p>The above rule replaces <code>[Sapling onward] At least one of tx_in_count,
nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="footnote_reference" href="#protocol-txnconsensus">4</a>.</p>
nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="footnote-reference-6" class="footnote_reference" href="#protocol-txnconsensus">4</a>.</p>
<ul>
<li>Transactions MUST have at least one of the following: - nonempty transparent outputs - nonempty shielded outputs - nonempty <code>tze_outputs</code></li>
<li>All <code>amount</code> field values of <code>tze_output</code> records MUST be nonnegative and not greater than <code>MAX_MONEY</code>.</li>
@ -257,8 +257,8 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
</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" 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>
<p>This ZIP MUST be deployed in conjunction with or after ZIP 244 <a id="footnote-reference-7" 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="footnote-reference-8" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -277,12 +277,12 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
</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" 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>
<li>Librustzcash reference implementation of TZE API: <a id="footnote-reference-9" class="footnote_reference" href="#librustzcash-zip222">10</a></li>
<li>Zcashd reference implementation of consensus rule changes: <a id="footnote-reference-10" 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" 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>The handler semantics of <code>tze_verify</code> were suggested by Zaki Manian, drawing on the design of Cosmos. Daira Emma 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>

4
zip-0222.rst
View File

@ -5,7 +5,7 @@
Owners: Jack Grigg <jack@electriccoin.co>
Kris Nuttycombe <kris@electriccoin.co>
Credits: Zaki Manian
Daira Hopwood
Daira Emma Hopwood
Sean Bowe
Status: Draft
Category: Consensus
@ -311,7 +311,7 @@ Acknowledgements
================
The handler semantics of ``tze_verify`` were suggested by Zaki Manian, drawing on the
design of Cosmos. Daira Hopwood and Sean Bowe gave useful feedback on an early draft of
design of Cosmos. Daira Emma 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.
We would also like to thank the numerous other individuals who participated in discussions

60
zip-0224.html
View File

@ -9,7 +9,7 @@
<section>
<pre>ZIP: 224
Title: Orchard Shielded Protocol
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Jack Grigg &lt;jack@electriccoin.co&gt;
Sean Bowe &lt;sean@electriccoin.co&gt;
Kris Nuttycombe &lt;kris@electriccoin.co&gt;
@ -20,8 +20,8 @@ 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" 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>
<p>The key word "MUST" in this document is to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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" 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>
@ -29,18 +29,18 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<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>
<li>The Sprout shielded protocol (based on the Zerocash paper with improvements and security fixes <a id="footnote-reference-3" 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>
<li>The Sapling shielded protocol, which consisted of numerous improvements to functionality and improved performance by orders of magnitude, and as of Feburary 2021 is the "active" shielded pool.</li>
</ul>
<p>Both of these shielded protocols suffer from two issues:</p>
<ul>
<li>Neither Sprout nor Sapling are compatible with known efficient scalability techniques. Recursive zero-knowledge proofs (where a proof verifies an earlier instance of itself along with new state) that are suitable for deployment in a block chain like Zcash require a cycle of elliptic curves. The Sprout protocol does not use elliptic curves and thus is an inherently inefficient protocol to implement inside a circuit, while the Sapling protocol uses curves for which there is no known way to construct an efficient curve cycle (or path to one).</li>
<li>The Sprout and Sapling circuits are implemented using a proving system (Groth16) that requires a "trusted setup": the circuit parameters are a Structured Reference String (SRS) with hidden structure, that if known could be used to create fake proofs and thus counterfeit funds. The parameters are in practice generated using a multiparty computation (MPC), where as long as at least one participant was honest and not compromised, the hidden structure is unrecoverable. The MPCs themselves have improved over the years (Zcash had 6 participants in the Sprout MPC, and around 90 per round in the Sapling MPC two years later <a id="id4" class="footnote_reference" href="#zcash-paramgen">2</a>), but it remains the case that generating these parameters is a point of risk within the protocol. For example, the original proving system used for the Sprout circuit (BCTV14) had a bug that made the Sprout shielded protocol vulnerable to counterfeiting, <a id="id5" class="footnote_reference" href="#bctv14-vuln">3</a> which needed to be resolved by changing the proving system and running a new MPC.</li>
<li>The Sprout and Sapling circuits are implemented using a proving system (Groth16) that requires a "trusted setup": the circuit parameters are a Structured Reference String (SRS) with hidden structure, that if known could be used to create fake proofs and thus counterfeit funds. The parameters are in practice generated using a multiparty computation (MPC), where as long as at least one participant was honest and not compromised, the hidden structure is unrecoverable. The MPCs themselves have improved over the years (Zcash had 6 participants in the Sprout MPC, and around 90 per round in the Sapling MPC two years later <a id="footnote-reference-4" class="footnote_reference" href="#zcash-paramgen">2</a>), but it remains the case that generating these parameters is a point of risk within the protocol. For example, the original proving system used for the Sprout circuit (BCTV14) had a bug that made the Sprout shielded protocol vulnerable to counterfeiting, <a id="footnote-reference-5" class="footnote_reference" href="#bctv14-vuln">3</a> which needed to be resolved by changing the proving system and running a new MPC.</li>
</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" 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>The Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification <a id="footnote-reference-6" 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" 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>
@ -50,41 +50,41 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
</ul>
<p>We use the "simplified SWU" algorithm to define an infallible
<span class="math">\(\mathsf{GroupHash}\)</span>
, instead of the fallible BLAKE2s-based mechanism used for Sapling. It is intended to follow (version 10 of) the IETF hash-to-curve Internet Draft <a id="id7" class="footnote_reference" href="#ietf-hash-to-curve">33</a> (but the protocol specification takes precedence in the case of any discrepancy).</p>
, instead of the fallible BLAKE2s-based mechanism used for Sapling. It is intended to follow (version 10 of) the IETF hash-to-curve Internet Draft <a id="footnote-reference-7" class="footnote_reference" href="#ietf-hash-to-curve">33</a> (but the protocol specification takes precedence in the case of any discrepancy).</p>
<p>The presence of the curve cycle is an explicit design choice. This proposal only uses half of the cycle (Pallas being an embedded curve of Vesta); the full cycle is expected to be leveraged by future protocol updates.</p>
<ul>
<li>Curve specifications: <a id="id8" class="footnote_reference" href="#protocol-pallasandvesta">15</a></li>
<li>Curve specifications: <a id="footnote-reference-8" class="footnote_reference" href="#protocol-pallasandvesta">15</a></li>
<li>
<span class="math">\(\mathsf{GroupHash}\)</span>
: <a id="id9" class="footnote_reference" href="#protocol-concretegrouphashpallasandvesta">16</a></li>
<li>Supporting evidence: <a id="id10" class="footnote_reference" href="#pasta-evidence">34</a></li>
: <a id="footnote-reference-9" class="footnote_reference" href="#protocol-concretegrouphashpallasandvesta">16</a></li>
<li>Supporting evidence: <a id="footnote-reference-10" 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" 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 <a id="id12" class="footnote_reference" href="#halo2-arithmetization">22</a>, instead of Groth16 and R1CS.</p>
<p>Orchard uses the Halo 2 proving system <a id="footnote-reference-11" class="footnote_reference" href="#halo2-proving-system">23</a> with the PLONKish arithmetization <a id="footnote-reference-12" class="footnote_reference" href="#halo2-arithmetization">22</a>, 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" 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>
<li>Action description: <a id="id13" class="footnote_reference" href="#protocol-actions">8</a></li>
<li>Circuit statement: <a id="id14" class="footnote_reference" href="#protocol-actionstatement">9</a></li>
<li>Design rationale: <a id="id15" class="footnote_reference" href="#orchard-actions">25</a></li>
<li>Action description: <a id="footnote-reference-13" class="footnote_reference" href="#protocol-actions">8</a></li>
<li>Circuit statement: <a id="footnote-reference-14" class="footnote_reference" href="#protocol-actionstatement">9</a></li>
<li>Design rationale: <a id="footnote-reference-15" 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" 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="id16" class="footnote_reference" href="#protocol-concretesinsemillahash">11</a></li>
<li>Sinsemilla commitments: <a id="id17" class="footnote_reference" href="#protocol-concretesinsemillacommit">14</a></li>
<li>Design rationale: <a id="id18" class="footnote_reference" href="#orchard-commitments">26</a></li>
<li>Sinsemilla hash function: <a id="footnote-reference-16" class="footnote_reference" href="#protocol-concretesinsemillahash">11</a></li>
<li>Sinsemilla commitments: <a id="footnote-reference-17" class="footnote_reference" href="#protocol-concretesinsemillacommit">14</a></li>
<li>Design rationale: <a id="footnote-reference-18" 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" 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="id19" class="footnote_reference" href="#orchard-tree">27</a></li>
<li>Design rationale and considered alternatives: <a id="footnote-reference-19" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -105,14 +105,14 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
, instead of being a component of the spending key.</li>
<li>All diversifiers now result in valid payment addresses.</li>
</ul>
<p>There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in <a id="id20" class="footnote_reference" href="#zip-0316">32</a>. Orchard spending keys are encoded using Bech32m as specified in <a id="id21" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a>.</p>
<p>There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in <a id="footnote-reference-20" class="footnote_reference" href="#zip-0316">32</a>. Orchard spending keys are encoded using Bech32m as specified in <a id="footnote-reference-21" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a>.</p>
<p>Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt the Sapling HD mechanism from ZIP 32 to Orchard; instead, we define a hardened-only derivation mechanism (similar to Sprout).</p>
<ul>
<li>Key components diagram: <a id="id22" class="footnote_reference" href="#protocol-addressesandkeys">6</a></li>
<li>Key components specification: <a id="id23" class="footnote_reference" href="#protocol-orchardkeycomponents">10</a></li>
<li>Encodings: <a id="id24" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">17</a> <a id="id25" class="footnote_reference" href="#protocol-orchardinviewingkeyencoding">18</a> <a id="id26" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">19</a> <a id="id27" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a></li>
<li>HD key derivation specification: <a id="id28" class="footnote_reference" href="#zip-0032">29</a></li>
<li>Design rationale: <a id="id29" class="footnote_reference" href="#orchard-keys">24</a></li>
<li>Key components diagram: <a id="footnote-reference-22" class="footnote_reference" href="#protocol-addressesandkeys">6</a></li>
<li>Key components specification: <a id="footnote-reference-23" class="footnote_reference" href="#protocol-orchardkeycomponents">10</a></li>
<li>Encodings: <a id="footnote-reference-24" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">17</a> <a id="footnote-reference-25" class="footnote_reference" href="#protocol-orchardinviewingkeyencoding">18</a> <a id="footnote-reference-26" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">19</a> <a id="footnote-reference-27" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a></li>
<li>HD key derivation specification: <a id="footnote-reference-28" class="footnote_reference" href="#zip-0032">29</a></li>
<li>Design rationale: <a id="footnote-reference-29" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -123,9 +123,9 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<span class="math">\(\psi\)</span>
and
<span class="math">\(\mathsf{rcm}\)</span>
are derived from a random seed (as with Sapling after ZIP 212 <a id="id30" class="footnote_reference" href="#zip-0212">30</a>).</p>
are derived from a random seed (as with Sapling after ZIP 212 <a id="footnote-reference-30" class="footnote_reference" href="#zip-0212">30</a>).</p>
<ul>
<li>Orchard notes: <a id="id31" class="footnote_reference" href="#protocol-notes">7</a></li>
<li>Orchard notes: <a id="footnote-reference-31" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -139,14 +139,14 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<span class="math">\(\mathcal{G}\)</span>
is a fixed independent base.</p>
<ul>
<li>Poseidon: <a id="id32" class="footnote_reference" href="#protocol-poseidonhash">12</a></li>
<li>Design rationale and considered alternatives: <a id="id33" class="footnote_reference" href="#orchard-nullifiers">28</a></li>
<li>Poseidon: <a id="footnote-reference-32" class="footnote_reference" href="#protocol-poseidonhash">12</a></li>
<li>Design rationale and considered alternatives: <a id="footnote-reference-33" 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" 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="id34" class="footnote_reference" href="#protocol-concretereddsa">13</a></li>
<li>RedPallas: <a id="footnote-reference-34" class="footnote_reference" href="#protocol-concretereddsa">13</a></li>
</ul>
</section>
</section>
@ -166,7 +166,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
field, combined with the consensus checks that each pool's balance cannot be negative, together enforce that any potential counterfeiting bugs in the Orchard protocol or implementation are contained within the Orchard pool, and similarly any potential counterfeiting bugs in existing shielded pools cannot cause inflation of the Orchard pool.</li>
<li>Spending funds residing in the Orchard pool to a non-Orchard address will reveal the value of the transaction. This is a necessary side-effect of the transparent turnstile, but can be mitigated by migrating the majority of shielded activity to the Orchard pool and making these transactions a minority. Wallets should convey within their transaction creation UX that amounts are revealed in these situations.
<ul>
<li>Wallets should take steps to migrate their user bases to store funds uniformly within the Orchard pool. Best practices for wallet handling of multiple pools will be covered in a subsequent ZIP. <a id="id35" class="footnote_reference" href="#zip-0315">31</a></li>
<li>Wallets should take steps to migrate their user bases to store funds uniformly within the Orchard pool. Best practices for wallet handling of multiple pools will be covered in a subsequent ZIP. <a id="footnote-reference-35" class="footnote_reference" href="#zip-0315">31</a></li>
</ul>
</li>
</ul>

2
zip-0224.rst
View File

@ -2,7 +2,7 @@
ZIP: 224
Title: Orchard Shielded Protocol
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Jack Grigg <jack@electriccoin.co>
Sean Bowe <sean@electriccoin.co>
Kris Nuttycombe <kris@electriccoin.co>

22
zip-0225.html
View File

@ -9,7 +9,7 @@
<section>
<pre>ZIP: 225
Title: Version 5 Transaction Format
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Jack Grigg &lt;jack@electriccoin.co&gt;
Sean Bowe &lt;sean@electriccoin.co&gt;
Kris Nuttycombe &lt;kris@electriccoin.co&gt;
@ -20,12 +20,12 @@ 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" 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>
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The character § is used when referring to sections of the Zcash Protocol Specification <a id="footnote-reference-2" 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" 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>
<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="footnote-reference-3" 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="footnote-reference-4" 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" 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>
@ -262,7 +262,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
<li>The fields <code>valueBalanceSapling</code> and <code>bindingSigSapling</code> are present if and only if
<span class="math">\(\mathtt{nSpendsSapling} + \mathtt{nOutputsSapling} &gt; 0\)</span>
. If <code>valueBalanceSapling</code> is not present, then
<span class="math">\(\mathsf{v^{balanceSapling}}\)</span>
<span class="math">\(\mathsf{v^{balanceSapling}}`\)</span>
is defined to be 0.</li>
<li>The field <code>anchorSapling</code> is present if and only if
<span class="math">\(\mathtt{nSpendsSapling} &gt; 0\)</span>
@ -310,7 +310,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
</tr>
</tbody>
</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>
<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="footnote-reference-5" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<table>
@ -355,7 +355,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
</tr>
</tbody>
</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>
<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="footnote-reference-6" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<table>
@ -412,7 +412,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
</tr>
</tbody>
</table>
<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>
<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="footnote-reference-7" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -423,9 +423,9 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
<p>Removing these fields reduces the complexity of the NU5 upgrade in the following ways:</p>
<ul>
<li>V5 parsing and serialization code does not need to take these fields into account.</li>
<li>ZIP 244 <a id="id8" class="footnote_reference" href="#zip-0244">7</a> transaction identifier, signature hash, and authorizing data commitment computations are simplified by excluding consideration of these fields.</li>
<li>ZIP 244 <a id="footnote-reference-8" class="footnote_reference" href="#zip-0244">7</a> transaction identifier, signature hash, and authorizing data commitment computations are simplified by excluding consideration of these fields.</li>
</ul>
<p>Removal of these fields means that that in the future, removing the support for the V4 transaction format will also effectively end support for Sprout transactions on the Zcash network, though it might be possible to restore limited support for migration via a future ZIP 222 <a id="id9" class="footnote_reference" href="#zip-0222">6</a> extension or by other means not yet determined.</p>
<p>Removal of these fields means that that in the future, removing the support for the V4 transaction format will also effectively end support for Sprout transactions on the Zcash network, though it might be possible to restore limited support for migration via a future ZIP 222 <a id="footnote-reference-9" class="footnote_reference" href="#zip-0222">6</a> extension or by other means not yet determined.</p>
<p>The original definitions for the transaction fields that have been removed are:</p>
<table>
<tbody>

2
zip-0225.rst
View File

@ -2,7 +2,7 @@
ZIP: 225
Title: Version 5 Transaction Format
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Jack Grigg <jack@electriccoin.co>
Sean Bowe <sean@electriccoin.co>
Kris Nuttycombe <kris@electriccoin.co>

15
zip-0226.html
View File

@ -1,17 +1,24 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 226: Zcash Shielded Assets - Transfers and Burns</title>
<title>ZIP 226: Transfer and Burn of Zcash Shielded Assets</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 226
Title: Zcash Shielded Assets - Transfers and Burns
Owners: Daniel Bennaroch
Title: Transfer and Burn of Zcash Shielded Assets
Owners: Pablo Kogan &lt;pablo@qed-it.com&gt;
Vivek Arte &lt;vivek@qed-it.com&gt;
Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Jack Grigg &lt;str4d@electriccoin.co&gt;
Deirdre Connolly &lt;deirdre@zfnd.org&gt;
Credits: Daniel Benarroch
Aurelien Nicolas
Status: Reserved
Category: Consensus
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/618">https://github.com/zcash/zips/issues/618</a>&gt;</pre>
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/618">https://github.com/zcash/zips/issues/618</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/649">https://github.com/zcash/zips/pull/649</a>&gt;</pre>
</section>
</body>
</html>

11
zip-0226.rst
View File

@ -1,8 +1,15 @@
::
ZIP: 226
Title: Zcash Shielded Assets - Transfers and Burns
Owners: Daniel Bennaroch
Title: Transfer and Burn of Zcash Shielded Assets
Owners: Pablo Kogan <pablo@qed-it.com>
Vivek Arte <vivek@qed-it.com>
Daira Emma Hopwood <daira@electriccoin.co>
Jack Grigg <str4d@electriccoin.co>
Deirdre Connolly <deirdre@zfnd.org>
Credits: Daniel Benarroch
Aurelien Nicolas
Status: Reserved
Category: Consensus
Discussions-To: <https://github.com/zcash/zips/issues/618>
Pull-Request: <https://github.com/zcash/zips/pull/649>

17
zip-0227.html
View File

@ -1,17 +1,24 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 227: Zcash Shielded Assets - Issuance</title>
<title>ZIP 227: Issuance of Zcash Shielded Assets</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 226
Title: Zcash Shielded Assets - Issuance
Owners: Daniel Bennaroch
<pre>ZIP: 227
Title: Issuance of Zcash Shielded Assets
Owners: Pablo Kogan &lt;pablo@qed-it.com&gt;
Vivek Arte &lt;vivek@qed-it.com&gt;
Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Jack Grigg &lt;str4d@electriccoin.co&gt;
Deirdre Connolly &lt;deirdre@zfnd.org&gt;
Credits: Daniel Benarroch
Aurelien Nicolas
Status: Reserved
Category: Consensus
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/618">https://github.com/zcash/zips/issues/618</a>&gt;</pre>
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/618">https://github.com/zcash/zips/issues/618</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/649">https://github.com/zcash/zips/pull/649</a>&gt;</pre>
</section>
</body>
</html>

13
zip-0227.rst
View File

@ -1,8 +1,15 @@
::
ZIP: 226
Title: Zcash Shielded Assets - Issuance
Owners: Daniel Bennaroch
ZIP: 227
Title: Issuance of Zcash Shielded Assets
Owners: Pablo Kogan <pablo@qed-it.com>
Vivek Arte <vivek@qed-it.com>
Daira Emma Hopwood <daira@electriccoin.co>
Jack Grigg <str4d@electriccoin.co>
Deirdre Connolly <deirdre@zfnd.org>
Credits: Daniel Benarroch
Aurelien Nicolas
Status: Reserved
Category: Consensus
Discussions-To: <https://github.com/zcash/zips/issues/618>
Pull-Request: <https://github.com/zcash/zips/pull/649>

32
zip-0239.html
View File

@ -8,7 +8,7 @@
<section>
<pre>ZIP: 239
Title: Relay of Version 5 Transactions
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Jack Grigg &lt;jack@electriccoin.co&gt;
Status: Final
Category: Network
@ -17,11 +17,11 @@ 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 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>
<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>The term "txid" means a transaction identifier, computed as a SHA-256d hash of the transaction data for v4 and earlier transactions, or as specified in <a id="id4" class="footnote_reference" href="#zip-0244">6</a> for v5 and later transactions.</p>
<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 key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "RECOMMENDED" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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="footnote-reference-3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
<p>The term "txid" means a transaction identifier, computed as a SHA-256d hash of the transaction data for v4 and earlier transactions, or as specified in <a id="footnote-reference-4" class="footnote_reference" href="#zip-0244">6</a> for v5 and later transactions.</p>
<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="footnote-reference-5" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -29,23 +29,23 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/516">https://githu
</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" 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>
<p>Prior to the introduction of v5 transactions <a id="footnote-reference-6" class="footnote_reference" href="#zip-0225">5</a> in the NU5 network upgrade <a id="footnote-reference-7" 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="footnote-reference-8" 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>
<p>Not committing to the witness data in v5 transaction announcements would create inefficiencies: because a v5 transaction's witness can be malleated without altering the txid, a node in receipt of a v5 transaction that the node does not accept would generally still have to download that same transaction when announced by other peers. This is because the alternative — of not downloading a v5 transaction with a given txid after rejecting a previous transaction with that txid — would allow a third party to interfere with transaction relay by malleating a transaction's witness and announcing the resulting invalid transaction to nodes, preventing relay of the valid version of the transaction as well.</p>
<p>This inefficiency was present in Bitcoin for almost 3 years after activation of its Segwit upgrade <a id="id9" class="footnote_reference" href="#bip-0141">8</a>, until the adoption of BIP 339 <a id="id10" class="footnote_reference" href="#bip-0339">9</a>. The latter BIP specifies a way to use the Segwit "wtxid" (which commits to both effecting and witness data) in place of the txid when announcing and fetching transactions. In Zcash, the analogous identifier is also called the wtxid, but it encodes the pair (txid, auth_digest).</p>
<p>This inefficiency was present in Bitcoin for almost 3 years after activation of its Segwit upgrade <a id="footnote-reference-9" class="footnote_reference" href="#bip-0141">8</a>, until the adoption of BIP 339 <a id="footnote-reference-10" class="footnote_reference" href="#bip-0339">9</a>. The latter BIP specifies a way to use the Segwit "wtxid" (which commits to both effecting and witness data) in place of the txid when announcing and fetching transactions. In Zcash, the analogous identifier is also called the wtxid, but it encodes the pair (txid, auth_digest).</p>
<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" 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>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="footnote-reference-11" 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="footnote-reference-12" 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" 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. <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>
<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. <a id="footnote-reference-13" class="footnote_reference" href="#zip-0252">7</a></p>
<p>As specified in <a id="footnote-reference-14" 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>
<p>Nevertheless, it is possible for a node to receive an <code>inv</code> or <code>getdata</code> message containing an inventory entry of type <code>MSG_WTX</code>, on a peer connection that has negotiated protocol version 170014 or later, before NU5 has activated. In this case, the node MUST NOT advertise, fetch, or provide v5 transactions.</p>
<p>Note that the behaviour of a node receiving an <code>inv</code> or <code>getdata</code> message with one or more inventory entries of an unrecognized type was previously unspecified. The behaviour of <cite>zcashd</cite> in such a case was to assume that the length of each inventory entry is 36 bytes (including the type field), regardless of the type. This would result in misparsing the <code>inv</code> or <code>getdata</code> message if the length of the corresponding inventory entry were not 36 bytes.</p>
<p>The RECOMMENDED behaviour is to parse the <code>inv</code> or <code>getdata</code> message completely, and reject the message if it contains any inventory entries of an unrecognized type. For a <code>getdata</code> message, the set of recognized inventory types, and corresponding entry lengths including the type field, is:</p>
@ -57,15 +57,15 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/516">https://githu
</ul>
<p>For an <code>inv</code> message, the set of recognized inventory types is the same, but the <code>MSG_FILTERED_BLOCK</code> type has no useful purpose. Senders of <code>inv</code> messages SHOULD NOT include <code>MSG_FILTERED_BLOCK</code> entries. In order to allow using the same parser for the two message types, a node receiving a <code>MSG_FILTERED_BLOCK</code> entry in an <code>inv</code> message SHOULD ignore it.</p>
<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>
<p>Further information on how <cite>zcashd</cite> handles data propagation in the peer-to-peer network is given in <a id="id15" class="footnote_reference" href="#zcashd-propagation">12</a>.</p>
<p>Further information on how <cite>zcashd</cite> handles data propagation in the peer-to-peer network is given in <a id="footnote-reference-15" class="footnote_reference" href="#zcashd-propagation">12</a>.</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" 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="id16" class="footnote_reference" href="#p2p-inv">10</a> and <a id="id17" 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>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="footnote-reference-16" class="footnote_reference" href="#p2p-inv">10</a> and <a id="footnote-reference-17" 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" 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="id18" class="footnote_reference" href="#bip-0339">9</a></p>
<p>This ZIP is partly based on BIP 339, written by Suhas Daftuar. <a id="footnote-reference-18" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">

2
zip-0239.rst
View File

@ -2,7 +2,7 @@
ZIP: 239
Title: Relay of Version 5 Transactions
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Jack Grigg <jack@electriccoin.co>
Status: Final
Category: Network

204
zip-0243.html
View File

File diff suppressed because one or more lines are too long

2
zip-0243.rst
View File

@ -3,7 +3,7 @@
ZIP: 243
Title: Transaction Signature Validation for Sapling
Owners: Jack Grigg <str4d@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Daira Emma Hopwood <daira@electriccoin.co>
Credits: Simon Liu
Status: Final
Category: Consensus

44
zip-0244.html
View File

@ -10,7 +10,7 @@
<pre>ZIP: 244
Title: Transaction Identifier Non-Malleability
Owners: Kris Nuttycombe &lt;kris@electriccoin.co&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Jack Grigg &lt;str4d@electriccoin.co&gt;
Status: Final
Category: Consensus
@ -18,9 +18,9 @@ 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" 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>
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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="footnote-reference-3" 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" 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>
@ -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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<section id="txid-digest-1"><h5><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest-1"><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)
@ -84,7 +84,7 @@ T.4: orchard_digest (32-byte hash output)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZcashTxHash_" || CONSENSUS_BRANCH_ID</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>As in ZIP 143 <a id="footnote-reference-4" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>A BLAKE2b-256 hash of the following values</p>
@ -128,7 +128,7 @@ T.2c: outputs_digest (32-byte hash)</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" 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>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="footnote-reference-5" 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)
T.3b: sapling_outputs_digest (32-byte hash)
@ -170,7 +170,7 @@ T.3b.iii: sapling_outputs_noncompact_digest (32-byte hash)</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" 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>
<p>A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP-307 <a id="footnote-reference-6" 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)
T.3b.i.3: enc_ciphertext[..52] (First 52 bytes of field encoding)</pre>
@ -184,7 +184,7 @@ T.3b.i.3: enc_ciphertext[..52] (First 52 bytes of field encoding)</pre>
<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" 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>
<p>A BLAKE2b-256 hash of the remaining subset of Sapling output information <strong>not</strong> included in the ZIP 307 <a id="footnote-reference-7" 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)
T.3b.iii.3: out_ciphertext (field encoding bytes)</pre>
@ -206,7 +206,7 @@ T.4f: anchorOrchard (32 bytes)</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" 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>
<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="footnote-reference-8" 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)
T.4a.iii: ephemeralKey (field encoding bytes)
@ -221,7 +221,7 @@ T.4a.iv : encCiphertext[..52] (First 52 bytes of field encoding)</pre>
<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" 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>
<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="footnote-reference-9" 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)
T.4c.iii: encCiphertext[564..] (post-memo suffix of field encoding)
@ -233,14 +233,14 @@ T.4c.iv : outCiphertext (field encoding bytes)</pre>
</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" 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>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="footnote-reference-10" class="footnote_reference" href="#zip-0143">6</a> and ZIP 243 <a id="footnote-reference-11" 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
├── header_digest
├── 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<section id="signature-digest-1"><h5><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest-1"><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)
@ -284,14 +284,14 @@ transaction identifier in section T.2a.</pre>
<pre>BLAKE2b-256(``ZTxIdPrevoutHash``, [])</pre>
</section>
<section id="s-2c-amounts-sig-digest"><h7><span class="section-heading">S.2c: amounts_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2c-amounts-sig-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is not set, the value of <code>amounts_sig_digest</code> is a BLAKE2b-256 hash of the concatenation of the 8-byte signed little-endian representations of all <code>value</code> fields <a id="id14" class="footnote_reference" href="#bdr-txout">14</a> for the coins spent by the transparent inputs to the transaction.</p>
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is not set, the value of <code>amounts_sig_digest</code> is a BLAKE2b-256 hash of the concatenation of the 8-byte signed little-endian representations of all <code>value</code> fields <a id="footnote-reference-12" class="footnote_reference" href="#bdr-txout">14</a> for the coins spent by the transparent inputs to the transaction.</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxTrAmountsHash"</pre>
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is set, <code>amounts_sig_digest</code> is:</p>
<pre>BLAKE2b-256("ZTxTrAmountsHash", [])</pre>
</section>
<section id="s-2d-scriptpubkeys-sig-digest"><h7><span class="section-heading">S.2d: scriptpubkeys_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2d-scriptpubkeys-sig-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is not set, the value of <code>scriptpubkeys_sig_digest</code> is a BLAKE2b-256 hash of the concatenation of the field encodings (each including a leading <code>CompactSize</code>) of all <code>pk_script</code> fields <a id="id15" class="footnote_reference" href="#bdr-txout">14</a> for the coins spent by the transparent inputs to the transaction.</p>
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is not set, the value of <code>scriptpubkeys_sig_digest</code> is a BLAKE2b-256 hash of the concatenation of the field encodings (each including a leading <code>CompactSize</code>) of all <code>pk_script</code> fields <a id="footnote-reference-13" class="footnote_reference" href="#bdr-txout">14</a> for the coins spent by the transparent inputs to the transaction.</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxTrScriptsHash"</pre>
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is set, <code>scriptpubkeys_sig_digest</code> is:</p>
@ -325,7 +325,7 @@ S.2g.iv: nSequence (4-byte unsigned little-endian)</pre>
<p>Notes:</p>
<ul>
<li><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.</li>
<li><code>scriptPubKey</code> is the field encoding (including a leading <code>CompactSize</code>) of the <code>pk_script</code> field <a id="id16" class="footnote_reference" href="#bdr-txout">14</a> for the coin spent by the transparent input. For P2SH coins, this differs from the <code>redeemScript</code> committed to in ZIP 243 <a id="id17" class="footnote_reference" href="#zip-0243">7</a>.</li>
<li><code>scriptPubKey</code> is the field encoding (including a leading <code>CompactSize</code>) of the <code>pk_script</code> field <a id="footnote-reference-14" class="footnote_reference" href="#bdr-txout">14</a> for the coin spent by the transparent input. For P2SH coins, this differs from the <code>redeemScript</code> committed to in ZIP 243 <a id="footnote-reference-15" class="footnote_reference" href="#zip-0243">7</a>.</li>
</ul>
<p>If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, <code>txin_sig_digest</code> is:</p>
<pre>BLAKE2b-256("Zcash___TxInHash", [])</pre>
@ -397,7 +397,7 @@ A.3c: bindingSigOrchard (field encoding bytes)</pre>
is well-defined because
<span class="math">\(\mathsf{tx\_count} &gt; 0\)</span>
, due to the coinbase transaction in each block. Non-leaf hashes in this tree are BLAKE2b-256 hashes personalized by the string <code>"ZcashAuthDatHash"</code>.</p>
<p>Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the <code>hashLightClientRoot</code> field, described in ZIP 221 <a id="id18" class="footnote_reference" href="#zip-0221">4</a>, is changed.</p>
<p>Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the <code>hashLightClientRoot</code> field, described in ZIP 221 <a id="footnote-reference-16" class="footnote_reference" href="#zip-0221">4</a>, is changed.</p>
<p><code>hashLightClientRoot</code> is renamed to <code>hashBlockCommitments</code>. The value of this hash is the BLAKE2b-256 hash personalized by the string <code>"ZcashBlockCommit"</code> of the following elements:</p>
<pre>hashLightClientRoot (as described in ZIP 221)
hashAuthDataRoot (as described below)
@ -410,19 +410,19 @@ terminator [0u8;32]</pre>
</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>In S.2, we use the same personalization strings for fields that have matching fields in T.2, in order to facilitate reuse of their digests. In particular, the "no transparent inputs or outputs" case of S.2 is identical to the equivalent case in T.2; thus for fully shielded transactions, <code>signature_digest</code> is equal to <code>txid_digest</code>.</p>
<p>Several changes in this ZIP (relative to ZIP 243 <a id="id19" class="footnote_reference" href="#zip-0243">7</a>) were made to align with BIP 341 <a id="id20" class="footnote_reference" href="#bip-0341">9</a>:</p>
<p>Several changes in this ZIP (relative to ZIP 243 <a id="footnote-reference-17" class="footnote_reference" href="#zip-0243">7</a>) were made to align with BIP 341 <a id="footnote-reference-18" class="footnote_reference" href="#bip-0341">9</a>:</p>
<ul>
<li>The <code>hash_type</code> field is now restricted via a new consensus rule to be one of a specific set of sighash type encodings. The rationale for this change is inherited from BIP 341 <a id="id21" class="footnote_reference" href="#bip-0341-hash-type">10</a>.
<li>The <code>hash_type</code> field is now restricted via a new consensus rule to be one of a specific set of sighash type encodings. The rationale for this change is inherited from BIP 341 <a id="footnote-reference-19" class="footnote_reference" href="#bip-0341-hash-type">10</a>.
<ul>
<li>Note however that we do not define <code>SIGHASH_DEFAULT</code>, as it is equivalent to <code>SIGHASH_ALL</code>, and we prefer the encodings to be canonical.</li>
</ul>
</li>
<li>Two new commitments (<code>amounts_sig_digest</code> and <code>scriptpubkeys_sig_digest</code>) were added, to address difficulties in the case of a hardware wallet signing transparent inputs. <code>scriptpubkeys_sig_digest</code> helps the hardware wallet to determine the subset of inputs belonging to it <a id="id22" class="footnote_reference" href="#bip-0341-scriptpubkey">11</a>. <code>amounts_sig_digest</code> prevents the transaction creator from lying to the hardware wallet about the transaction fee <a id="id23" class="footnote_reference" href="#bip-0341-amount">12</a>. Without these commitments, the hardware wallet would need to be sent every transaction containing an outpoint referenced in the transaction being signed.</li>
<li>The semantics of <code>sequence_sig_digest</code> were changed, to commit to <code>nSequence</code> even if <code>SIGHASH_SINGLE</code> or <code>SIGHASH_NONE</code> is set. The rationale for this change is inherited from BIP 341 <a id="id24" class="footnote_reference" href="#bip-0341-nsequence">13</a>.</li>
<li>Two new commitments (<code>amounts_sig_digest</code> and <code>scriptpubkeys_sig_digest</code>) were added, to address difficulties in the case of a hardware wallet signing transparent inputs. <code>scriptpubkeys_sig_digest</code> helps the hardware wallet to determine the subset of inputs belonging to it <a id="footnote-reference-20" class="footnote_reference" href="#bip-0341-scriptpubkey">11</a>. <code>amounts_sig_digest</code> prevents the transaction creator from lying to the hardware wallet about the transaction fee <a id="footnote-reference-21" class="footnote_reference" href="#bip-0341-amount">12</a>. Without these commitments, the hardware wallet would need to be sent every transaction containing an outpoint referenced in the transaction being signed.</li>
<li>The semantics of <code>sequence_sig_digest</code> were changed, to commit to <code>nSequence</code> even if <code>SIGHASH_SINGLE</code> or <code>SIGHASH_NONE</code> is set. The rationale for this change is inherited from BIP 341 <a id="footnote-reference-22" class="footnote_reference" href="#bip-0341-nsequence">13</a>.</li>
<li>The semantics of <code>outputs_sig_digest</code> were changed, via a new consensus rule that rejects transparent inputs for which <code>SIGHASH_SINGLE</code> is set without a corresponding transparent output at the same index. BIP 341 does not give a rationale for this change, but without it these inputs were effectively using <code>SIGHASH_NONE</code>, which is silently misleading.</li>
<li>The semantics of <code>txin_sig_digest</code> were changed, to always commit to the <code>scriptPubKey</code> field of the transparent coin being spent, instead of the script actually being executed at the time <code>signature_digest</code> is calculated.
<ul>
<li>This ensures that the signature commits to the entire committed script. In Taproot, this makes it possible to prove to a hardware wallet what (unused) execution paths exist <a id="id25" class="footnote_reference" href="#bip-0341-scriptpubkey">11</a>. Alternate execution paths don't exist for P2PKH (where the executed script is <code>scriptPubKey</code>) or P2SH (where <code>scriptPubKey</code> is fully executed prior to <code>redeemScript</code>).</li>
<li>This ensures that the signature commits to the entire committed script. In Taproot, this makes it possible to prove to a hardware wallet what (unused) execution paths exist <a id="footnote-reference-23" class="footnote_reference" href="#bip-0341-scriptpubkey">11</a>. Alternate execution paths don't exist for P2PKH (where the executed script is <code>scriptPubKey</code>) or P2SH (where <code>scriptPubKey</code> is fully executed prior to <code>redeemScript</code>).</li>
<li>For P2SH, this means we commit to the Hash160 digest of <code>redeemScript</code> instead of the actual script. Note that the Bitcoin P2SH design depends entirely on Hash160 being preimage-resistant, because otherwise anyone would be able to spend someone else's P2SH UTXO using a preimage. We do need to ensure that there is no collision attack; this holds because even if an adversary could find a Hash160 collision, it would only enable them to alter the input's <code>scriptSig</code> field. Doing so doesn't alter the effecting data of the transaction, which by definition means the transaction has the same effect under consensus (spends the same inputs and produces the same outputs).</li>
</ul>
</li>

2
zip-0244.rst
View File

@ -3,7 +3,7 @@
ZIP: 244
Title: Transaction Identifier Non-Malleability
Owners: Kris Nuttycombe <kris@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Daira Emma Hopwood <daira@electriccoin.co>
Jack Grigg <str4d@electriccoin.co>
Status: Final
Category: Consensus

16
zip-0245.html
View File

@ -15,15 +15,15 @@ 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" 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>
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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" 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>
<p>This proposal defines changes to ZIP 244 <a id="footnote-reference-3" 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="footnote-reference-4" 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" 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>
<p>The tree of hashes defined by ZIP 244 <a id="footnote-reference-5" 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
├── transparent_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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="txid-digest-1"><h4><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest-1"><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)
@ -62,7 +62,7 @@ T.2b: tzeout_digest (32-byte hash)</pre>
</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" 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>
<p>The signature digest creation algorithm defined by ZIP 244 <a id="footnote-reference-6" 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
├── transparent_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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<section id="signature-digest-1"><h4><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest-1"><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)
@ -95,7 +95,7 @@ S.3e: value (8-byte little endian value of the output spent by this inp
</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" 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>
<p>The tree of hashes defined by ZIP 244 <a id="footnote-reference-7" 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

26
zip-0250.html
View File

@ -8,22 +8,22 @@
<section>
<pre>ZIP: 250
Title: Deployment of the Heartwood Network Upgrade
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
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" 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 key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" class="footnote_reference" href="#zip-0200">3</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Heartwood</dt>
<dd>Code-name for the fourth Zcash network upgrade, also known as Network Upgrade 3.</dd>
<dt>Testnet</dt>
<dd>The Zcash test network, as defined in <a id="id3" class="footnote_reference" href="#protocol">2</a>.</dd>
<dd>The Zcash test network, as defined in <a id="footnote-reference-3" class="footnote_reference" href="#protocol">2</a>.</dd>
<dt>Mainnet</dt>
<dd>The Zcash production network, as defined in <a id="id4" class="footnote_reference" href="#protocol">2</a>.</dd>
<dd>The Zcash production network, as defined in <a id="footnote-reference-4" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -33,13 +33,13 @@ License: MIT</pre>
<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>
<li>ZIP 200: Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">3</a></li>
<li>ZIP 213: Shielded Coinbase <a id="id7" class="footnote_reference" href="#zip-0213">5</a></li>
<li>ZIP 221: FlyClient - Consensus-Layer Changes <a id="id8" class="footnote_reference" href="#zip-0221">6</a>.</li>
<li>The Zcash Protocol Specification <a id="footnote-reference-5" class="footnote_reference" href="#protocol">2</a></li>
<li>ZIP 200: Network Upgrade Mechanism <a id="footnote-reference-6" class="footnote_reference" href="#zip-0200">3</a></li>
<li>ZIP 213: Shielded Coinbase <a id="footnote-reference-7" class="footnote_reference" href="#zip-0213">5</a></li>
<li>ZIP 221: FlyClient - Consensus-Layer Changes <a id="footnote-reference-8" class="footnote_reference" href="#zip-0221">6</a>.</li>
</ul>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id9" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="id10" class="footnote_reference" href="#zip-0200">3</a> are defined for the Heartwood upgrade:</p>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="footnote-reference-9" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="footnote-reference-10" class="footnote_reference" href="#zip-0200">3</a> are defined for the Heartwood upgrade:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0xF5B9230B</code></dd>
@ -57,7 +57,7 @@ License: MIT</pre>
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
*/
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<p>The implementation is similar to that for Overwinter which was described in <a id="id11" class="footnote_reference" href="#zip-0201">4</a>.</p>
<p>The implementation is similar to that for Overwinter which was described in <a id="footnote-reference-11" class="footnote_reference" href="#zip-0201">4</a>.</p>
<p>Once Heartwood activates on testnet or mainnet, Heartwood nodes SHOULD take steps to:</p>
<ul>
<li>reject new connections from pre-Heartwood nodes on that network;</li>
@ -68,7 +68,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<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>
<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="footnote-reference-12" class="footnote_reference" href="#protocol">2</a> section 7.1, and the same transaction digest algorithm as defined in <a id="footnote-reference-13" 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="footnote-reference-14" 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" 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>

2
zip-0250.rst
View File

@ -2,7 +2,7 @@
ZIP: 250
Title: Deployment of the Heartwood Network Upgrade
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Status: Final
Category: Consensus / Network
Created: 2020-02-28

32
zip-0251.html
View File

@ -8,15 +8,15 @@
<section>
<pre>ZIP: 251
Title: Deployment of the Canopy Network Upgrade
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
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" 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>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" 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="footnote-reference-3" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -26,17 +26,17 @@ License: MIT</pre>
<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>
<li>ZIP 200: Network Upgrade Mechanism <a id="id5" class="footnote_reference" href="#zip-0200">5</a></li>
<li>ZIP 207: Funding Streams <a id="id6" class="footnote_reference" href="#zip-0207">7</a></li>
<li>ZIP 211: Disabling Addition of New Value to the Sprout Value Pool <a id="id7" class="footnote_reference" href="#zip-0211">8</a></li>
<li>ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <a id="id8" class="footnote_reference" href="#zip-0212">9</a></li>
<li>ZIP 214: Consensus rules for a Zcash Development Fund <a id="id9" class="footnote_reference" href="#zip-0214">10</a></li>
<li>ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules <a id="id10" class="footnote_reference" href="#zip-0215">11</a></li>
<li>ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <a id="id11" class="footnote_reference" href="#zip-1014">13</a>.</li>
<li>The Zcash Protocol Specification <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a></li>
<li>ZIP 200: Network Upgrade Mechanism <a id="footnote-reference-5" class="footnote_reference" href="#zip-0200">5</a></li>
<li>ZIP 207: Funding Streams <a id="footnote-reference-6" class="footnote_reference" href="#zip-0207">7</a></li>
<li>ZIP 211: Disabling Addition of New Value to the Sprout Value Pool <a id="footnote-reference-7" class="footnote_reference" href="#zip-0211">8</a></li>
<li>ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <a id="footnote-reference-8" class="footnote_reference" href="#zip-0212">9</a></li>
<li>ZIP 214: Consensus rules for a Zcash Development Fund <a id="footnote-reference-9" class="footnote_reference" href="#zip-0214">10</a></li>
<li>ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules <a id="footnote-reference-10" class="footnote_reference" href="#zip-0215">11</a></li>
<li>ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <a id="footnote-reference-11" class="footnote_reference" href="#zip-1014">13</a>.</li>
</ul>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id12" class="footnote_reference" href="#zip-0201">6</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="id13" class="footnote_reference" href="#zip-0200">5</a> are defined for the Canopy upgrade:</p>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="footnote-reference-12" class="footnote_reference" href="#zip-0201">6</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="footnote-reference-13" class="footnote_reference" href="#zip-0200">5</a> are defined for the Canopy upgrade:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0xE9FF75A6</code></dd>
@ -54,7 +54,7 @@ License: MIT</pre>
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
*/
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<p>The implementation is similar to that for Overwinter which was described in <a id="id14" class="footnote_reference" href="#zip-0201">6</a>.</p>
<p>The implementation is similar to that for Overwinter which was described in <a id="footnote-reference-14" class="footnote_reference" href="#zip-0201">6</a>.</p>
<p>Once Canopy activates on testnet or mainnet, Canopy nodes SHOULD take steps to:</p>
<ul>
<li>reject new connections from pre-Canopy nodes on that network;</li>
@ -65,7 +65,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<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>
<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="footnote-reference-15" class="footnote_reference" href="#protocol-txnencoding">4</a>; and use the same transaction digest algorithm as defined in <a id="footnote-reference-16" 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="footnote-reference-17" 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" 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>

2
zip-0251.rst
View File

@ -2,7 +2,7 @@
ZIP: 251
Title: Deployment of the Canopy Network Upgrade
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Status: Final
Category: Consensus / Network
Created: 2020-02-28

54
zip-0252.html
View File

@ -9,7 +9,7 @@
<pre>ZIP: 252
Title: Deployment of the NU5 Network Upgrade
Owners: teor &lt;teor@zfnd.org&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Status: Final
Category: Consensus / Network
Created: 2021-02-23
@ -17,9 +17,9 @@ 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" 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">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="id3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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="footnote-reference-2" class="footnote_reference" href="#zip-0200">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="footnote-reference-3" 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" 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>
@ -28,29 +28,29 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/446">https://githu
<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>
<li>ZIP 200: Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">6</a></li>
<li>ZIP 216: Require Canonical Point Encodings <a id="id7" class="footnote_reference" href="#zip-0216">12</a></li>
<li>ZIP 224: Orchard Shielded Protocol <a id="id8" class="footnote_reference" href="#zip-0224">14</a></li>
<li>ZIP 225: Version 5 Transaction Format <a id="id9" class="footnote_reference" href="#zip-0225">15</a></li>
<li>ZIP 239: Relay of Version 5 Transactions <a id="id10" class="footnote_reference" href="#zip-0239">16</a></li>
<li>ZIP 244: Transaction Identifier Non-Malleability <a id="id11" class="footnote_reference" href="#zip-0244">17</a></li>
<li>The Orchard Book <a id="id12" class="footnote_reference" href="#orchard-book">20</a></li>
<li>The halo2 Book <a id="id13" class="footnote_reference" href="#halo2-book">21</a></li>
<li>The Zcash Protocol Specification <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a> <a id="footnote-reference-5" class="footnote_reference" href="#protocol-txnencoding">4</a></li>
<li>ZIP 200: Network Upgrade Mechanism <a id="footnote-reference-6" class="footnote_reference" href="#zip-0200">6</a></li>
<li>ZIP 216: Require Canonical Point Encodings <a id="footnote-reference-7" class="footnote_reference" href="#zip-0216">12</a></li>
<li>ZIP 224: Orchard Shielded Protocol <a id="footnote-reference-8" class="footnote_reference" href="#zip-0224">14</a></li>
<li>ZIP 225: Version 5 Transaction Format <a id="footnote-reference-9" class="footnote_reference" href="#zip-0225">15</a></li>
<li>ZIP 239: Relay of Version 5 Transactions <a id="footnote-reference-10" class="footnote_reference" href="#zip-0239">16</a></li>
<li>ZIP 244: Transaction Identifier Non-Malleability <a id="footnote-reference-11" class="footnote_reference" href="#zip-0244">17</a></li>
<li>The Orchard Book <a id="footnote-reference-12" class="footnote_reference" href="#orchard-book">20</a></li>
<li>The halo2 Book <a id="footnote-reference-13" class="footnote_reference" href="#halo2-book">21</a></li>
</ul>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id14" class="footnote_reference" href="#zip-0201">7</a> also apply to this upgrade.</p>
<p>Unified addresses and viewing keys are described in ZIP 316 <a id="id15" class="footnote_reference" href="#zip-0316">18</a>.</p>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="footnote-reference-14" class="footnote_reference" href="#zip-0201">7</a> also apply to this upgrade.</p>
<p>Unified addresses and viewing keys are described in ZIP 316 <a id="footnote-reference-15" class="footnote_reference" href="#zip-0316">18</a>.</p>
<p>The following ZIPs have been updated in varying degrees to take into account Orchard:</p>
<ul>
<li>ZIP 32: Shielded Hierarchical Deterministic Wallets <a id="id16" class="footnote_reference" href="#zip-0032">5</a></li>
<li>ZIP 203: Transaction Expiry <a id="id17" class="footnote_reference" href="#zip-0203">8</a></li>
<li>ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances <a id="id18" class="footnote_reference" href="#zip-0209">9</a></li>
<li>ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext <a id="id19" class="footnote_reference" href="#zip-0212">10</a></li>
<li>ZIP 213: Shielded Coinbase <a id="id20" class="footnote_reference" href="#zip-0213">11</a></li>
<li>ZIP 221: FlyClient - Consensus-Layer Changes <a id="id21" class="footnote_reference" href="#zip-0221">13</a></li>
<li>ZIP 401: Addressing Mempool Denial-of-Service <a id="id22" class="footnote_reference" href="#zip-0401">19</a></li>
<li>ZIP 32: Shielded Hierarchical Deterministic Wallets <a id="footnote-reference-16" class="footnote_reference" href="#zip-0032">5</a></li>
<li>ZIP 203: Transaction Expiry <a id="footnote-reference-17" class="footnote_reference" href="#zip-0203">8</a></li>
<li>ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances <a id="footnote-reference-18" class="footnote_reference" href="#zip-0209">9</a></li>
<li>ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext <a id="footnote-reference-19" class="footnote_reference" href="#zip-0212">10</a></li>
<li>ZIP 213: Shielded Coinbase <a id="footnote-reference-20" class="footnote_reference" href="#zip-0213">11</a></li>
<li>ZIP 221: FlyClient - Consensus-Layer Changes <a id="footnote-reference-21" class="footnote_reference" href="#zip-0221">13</a></li>
<li>ZIP 401: Addressing Mempool Denial-of-Service <a id="footnote-reference-22" class="footnote_reference" href="#zip-0401">19</a></li>
</ul>
<p>The following network upgrade constants <a id="id23" class="footnote_reference" href="#zip-0200">6</a> are defined for the NU5 upgrade:</p>
<p>The following network upgrade constants <a id="footnote-reference-23" class="footnote_reference" href="#zip-0200">6</a> are defined for the NU5 upgrade:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0xc2d6d0b4</code></dd>
@ -73,14 +73,14 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/446">https://githu
<li>reject new connections from pre-NU5 nodes on that network;</li>
<li>disconnect any existing connections to pre-NU5 nodes on that network.</li>
</ul>
<p>The change to the peer-to-peer protocol described in ZIP 239 took effect from peer protocol version 170014 onward, on both Testnet and Mainnet. <a id="id24" class="footnote_reference" href="#zip-0239">16</a></p>
<p>The change to the peer-to-peer protocol described in ZIP 239 took effect from peer protocol version 170014 onward, on both Testnet and Mainnet. <a id="footnote-reference-24" class="footnote_reference" href="#zip-0239">16</a></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" 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. (In the case of Testnet, there was a prolonged period of network fracturing due to a consensus bug, but this is expected to be resolved with the release of <cite>zcashd</cite> v4.7.0.)</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="id25" class="footnote_reference" href="#zip-0225">15</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="id26" class="footnote_reference" href="#zip-0239">16</a>.</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="footnote-reference-25" class="footnote_reference" href="#zip-0225">15</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="footnote-reference-26" class="footnote_reference" href="#zip-0239">16</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Several versions of <cite>zcashd</cite> have implemented versions of the NU5 consensus rules on Testnet:</p>
@ -100,7 +100,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/446">https://githu
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
*/
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<p>The implementation is similar to that for Overwinter which was described in <a id="id27" class="footnote_reference" href="#zip-0201">7</a>.</p>
<p>The implementation is similar to that for Overwinter which was described in <a id="footnote-reference-27" class="footnote_reference" href="#zip-0201">7</a>.</p>
<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>

2
zip-0252.rst
View File

@ -3,7 +3,7 @@
ZIP: 252
Title: Deployment of the NU5 Network Upgrade
Owners: teor <teor@zfnd.org>
Daira Hopwood <daira@electriccoin.co>
Daira Emma Hopwood <daira@electriccoin.co>
Status: Final
Category: Consensus / Network
Created: 2021-02-23

2
zip-0300.html
View File

@ -8,7 +8,7 @@
<section>
<pre>ZIP: 300
Title: Cross-chain Atomic Transactions
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Original-Authors: Jay Graber
Status: Proposed
Category: Informational

2
zip-0300.rst
View File

@ -2,7 +2,7 @@
ZIP: 300
Title: Cross-chain Atomic Transactions
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Original-Authors: Jay Graber
Status: Proposed
Category: Informational

32
zip-0301.html
View File

@ -8,9 +8,9 @@
<section>
<pre>ZIP: 301
Title: Zcash Stratum Protocol
Owner: Jack Grigg &lt;str4d@electriccoin.co&gt;
Owners: Jack Grigg &lt;str4d@electriccoin.co&gt;
Credits: 5a1t
Daira Hopwood
Daira Emma Hopwood
Marek Palatinus (slush) and colleagues
Jelle Bourdeaud'hui (razakal)
ocminer
@ -19,17 +19,17 @@ 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" 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>
<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="footnote-reference-1" 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" 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" 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>Many existing cryptocurrency miners and pools use the original Stratum protocol <a id="footnote-reference-2" class="footnote_reference" href="#slushpool-stratum">4</a> <a id="footnote-reference-3" 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="footnote-reference-4" 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="footnote-reference-5" 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" 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>
<p>The Stratum protocol is an instance of <a id="footnote-reference-6" 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>
<li>The server can respond to requests.</li>
@ -37,10 +37,10 @@ License: MIT</pre>
</ul>
<p>All communication for a particular session happens through a single connection, which is kept open for the duration of the session. If the connection is broken or either party disconnects, the active session is ended. Servers MAY support session resuming; this is negotiated between the client and server during initial setup (see <a href="#session-resuming">Session Resuming</a>).</p>
<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>Per <a id="footnote-reference-7" 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" 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>
<p>The <a id="footnote-reference-8" 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="footnote-reference-9" 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>
</blockquote>
@ -52,7 +52,7 @@ License: MIT</pre>
<dt><code>ERROR_CODE</code> (int)</dt>
<dd>
<p>Indicates the type of error that occurred.</p>
<p>The error codes are to be interpreted as described in <a id="id10" class="footnote_reference" href="#json-rpc-2-0">10</a>. The following application error codes are defined:</p>
<p>The error codes are to be interpreted as described in <a id="footnote-reference-10" class="footnote_reference" href="#json-rpc-2-0">10</a>. The following application error codes are defined:</p>
<ul>
<li>20 - Other/Unknown</li>
<li>21 - Job not found (=stale)</li>
@ -88,7 +88,7 @@ License: MIT</pre>
</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" 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>In Bitcoin, blocks contain two nonces: the 4-byte block header nonce, and an extra nonce in the coinbase transaction <a id="footnote-reference-11" 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="footnote-reference-12" class="footnote_reference" href="#slushpool-stratum">4</a>. The nonce in Zcash's block header is 32 bytes long <a id="footnote-reference-13" class="footnote_reference" href="#protocol-blockheader">2</a>, and thus can serve both purposes simultaneously.</p>
<p>We define two nonce parts:</p>
<dl>
<dt><code>NONCE_1</code></dt>
@ -99,7 +99,7 @@ License: MIT</pre>
<p>In hex, <code>lenHex(NONCE_2) = 64 - lenHex(NONCE_1)</code>, and both lengths are even.</p>
</dd>
</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>
<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="footnote-reference-14" class="footnote_reference" href="#bitcoin-block">7</a> <a id="footnote-reference-15" 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" 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>
@ -173,7 +173,7 @@ License: MIT</pre>
</blockquote>
<dl>
<dt><code>AUTHORIZED</code> (bool)</dt>
<dd>This MUST be <code>true</code> if authorization succeeded. Per <a id="id16" class="footnote_reference" href="#json-rpc-1-0">9</a>, it MUST be <code>null</code> if there was an error.</dd>
<dd>This MUST be <code>true</code> if authorization succeeded. Per <a id="footnote-reference-16" class="footnote_reference" href="#json-rpc-1-0">9</a>, it MUST be <code>null</code> if there was an error.</dd>
<dt><code>ERROR</code> (obj)</dt>
<dd>
<p>An error object. This MUST be <code>null</code> if authorization succeeded.</p>
@ -189,7 +189,7 @@ License: MIT</pre>
<dl>
<dt><code>TARGET</code> (hex)</dt>
<dd>
<p>The server target for the next received job and all subsequent jobs (until the next time this message is sent). The miner compares proposed block hashes with this target as a 256-bit big-endian integer, and valid blocks MUST NOT have hashes larger than (above) the current target (in accordance with the Zcash network consensus rules <a id="id17" class="footnote_reference" href="#protocol-difficulty">3</a>).</p>
<p>The server target for the next received job and all subsequent jobs (until the next time this message is sent). The miner compares proposed block hashes with this target as a 256-bit big-endian integer, and valid blocks MUST NOT have hashes larger than (above) the current target (in accordance with the Zcash network consensus rules <a id="footnote-reference-17" class="footnote_reference" href="#protocol-difficulty">3</a>).</p>
<p>Miners SHOULD NOT submit work above this target. Miners SHOULD validate their solutions before submission (to avoid both unnecessary network traffic and wasted miner time).</p>
<p>Servers MUST NOT accept submissions above this target for jobs sent after this message. Servers MAY accept submissions above this target for jobs sent before this message, but MUST check them against the previous target.</p>
</dd>
@ -251,7 +251,7 @@ License: MIT</pre>
<dt><code>NONCE_2</code> (hex)</dt>
<dd>The second part of the block header nonce (see <a href="#nonce-parts">Nonce Parts</a>).</dd>
<dt><code>EQUIHASH_SOLUTION</code> (hex)</dt>
<dd>The Equihash solution, encoded as in a block header (including the compactSize at the beginning in canonical form <a id="id18" class="footnote_reference" href="#bitcoin-compactsize">8</a>).</dd>
<dd>The Equihash solution, encoded as in a block header (including the compactSize at the beginning in canonical form <a id="footnote-reference-18" class="footnote_reference" href="#bitcoin-compactsize">8</a>).</dd>
</dl>
<p>Result:</p>
<blockquote>
@ -259,10 +259,10 @@ License: MIT</pre>
</blockquote>
<dl>
<dt><code>ACCEPTED</code> (bool)</dt>
<dd>This MUST be <code>true</code> if the submission was accepted. Per <a id="id19" class="footnote_reference" href="#json-rpc-1-0">9</a>, it MUST be <code>null</code> if there was an error.</dd>
<dd>This MUST be <code>true</code> if the submission was accepted. Per <a id="footnote-reference-19" class="footnote_reference" href="#json-rpc-1-0">9</a>, it MUST be <code>null</code> if there was an error.</dd>
<dt><code>ERROR</code> (obj)</dt>
<dd>
<p>An error object. Per <a id="id20" class="footnote_reference" href="#json-rpc-1-0">9</a>, this MUST be <code>null</code> if the submission was accepted without error.</p>
<p>An error object. Per <a id="footnote-reference-20" class="footnote_reference" href="#json-rpc-1-0">9</a>, this MUST be <code>null</code> if the submission was accepted without error.</p>
<p>If the submission was not accepted, the server MUST provide an error object describing the reason for not accepting the submission. See <a href="#error-objects">Error Objects</a> for the object format.</p>
</dd>
</dl>
@ -336,7 +336,7 @@ License: MIT</pre>
<p>Thanks to:</p>
<ul>
<li>5a1t for the initial brainstorming session.</li>
<li>Daira Hopwood for hir input on API selection and design.</li>
<li>Daira Emma Hopwood for their input on API selection and design.</li>
<li>Marek Palatinus (slush) and his colleagues for their refinements, suggestions, and robust discussion.</li>
<li>Jelle Bourdeaud'hui (razakal) and ocminer for their help with testing and finding implementation bugs in the specification.</li>
</ul>

6
zip-0301.rst
View File

@ -2,9 +2,9 @@
ZIP: 301
Title: Zcash Stratum Protocol
Owner: Jack Grigg <str4d@electriccoin.co>
Owners: Jack Grigg <str4d@electriccoin.co>
Credits: 5a1t
Daira Hopwood
Daira Emma Hopwood
Marek Palatinus (slush) and colleagues
Jelle Bourdeaud'hui (razakal)
ocminer
@ -476,7 +476,7 @@ Thanks to:
- 5a1t for the initial brainstorming session.
- Daira Hopwood for hir input on API selection and design.
- Daira Emma Hopwood for their input on API selection and design.
- Marek Palatinus (slush) and his colleagues for their refinements, suggestions, and
robust discussion.

6
zip-0302.html
View File

@ -9,7 +9,7 @@
<pre>ZIP: 302
Title: Standardized Memo Field Format
Owners: Jack Grigg &lt;jack@electriccoin.co&gt;
Original-Author: Jay Graber
Original-Authors: Jay Graber
Status: Draft
Category: Standards / RPC / Wallet
Created: 2017-02-08
@ -22,9 +22,9 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/105">https://githu
<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" 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>
<p>Section 5.5 of the Zcash protocol specification <a id="footnote-reference-1" 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>
<li>a UTF-8 human-readable string <a id="footnote-reference-2" class="footnote_reference" href="#utf-8">2</a>, padded by appending zero bytes; or</li>
<li>the byte <code>0xF6</code> followed by 511 <code>0x00</code> bytes, indicating "no memo"; or</li>
<li>any other sequence of 512 bytes starting with a byte value <code>0xF5</code> or greater (which is therefore not a valid UTF-8 string), as specified in ZIP 302.</li>
</ul>

2
zip-0302.rst
View File

@ -3,7 +3,7 @@
ZIP: 302
Title: Standardized Memo Field Format
Owners: Jack Grigg <jack@electriccoin.co>
Original-Author: Jay Graber
Original-Authors: Jay Graber
Status: Draft
Category: Standards / RPC / Wallet
Created: 2017-02-08

38
zip-0304.html
View File

@ -10,7 +10,7 @@
<pre>ZIP: 304
Title: Sapling Address Signatures
Owners: Jack Grigg &lt;jack@electriccoin.co&gt;
Credits: Daira Hopwood &lt;daira@electriccoin.co&gt;
Credits: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Sean Bowe &lt;sean@electriccoin.co&gt;
Status: Draft
Category: Standards / RPC / Wallet
@ -19,7 +19,7 @@ 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" 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>
<p>The key words "MUST" and "SHOULD" in this document is to be interpreted as described in RFC 2119. <a id="footnote-reference-1" 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" 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>
@ -32,25 +32,25 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<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" 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>
<p>The following constants and functions used in this ZIP are defined in the Zcash protocol specification: <a id="footnote-reference-2" class="footnote_reference" href="#protocol">3</a></p>
<ul>
<li>
<span class="math">\(\mathsf{MerkleDepth}^\mathsf{Sapling}\)</span>
and
<span class="math">\(\mathsf{Uncommitted}^\mathsf{Sapling}\)</span>
<a id="id3" class="footnote_reference" href="#protocol-constants">6</a></li>
<a id="footnote-reference-3" class="footnote_reference" href="#protocol-constants">6</a></li>
<li>
<span class="math">\(\mathsf{MerkleCRH}^\mathsf{Sapling}\)</span>
<a id="id4" class="footnote_reference" href="#protocol-saplingmerklecrh">7</a></li>
<a id="footnote-reference-4" class="footnote_reference" href="#protocol-saplingmerklecrh">7</a></li>
<li>
<span class="math">\(\mathsf{DiversifyHash}(\mathsf{d})\)</span>
<a id="id5" class="footnote_reference" href="#protocol-concretediversifyhash">8</a></li>
<a id="footnote-reference-5" class="footnote_reference" href="#protocol-concretediversifyhash">8</a></li>
<li>
<span class="math">\(\mathsf{MixingPedersenHash}(\mathsf{cm}, position)\)</span>
<a id="id6" class="footnote_reference" href="#protocol-concretemixinghash">9</a></li>
<a id="footnote-reference-6" class="footnote_reference" href="#protocol-concretemixinghash">9</a></li>
<li>
<span class="math">\(\mathsf{PRF}^\mathsf{nfSapling}_\mathsf{nk}(ρ)\)</span>
<a id="id7" class="footnote_reference" href="#protocol-concreteprfs">10</a></li>
<a id="footnote-reference-7" class="footnote_reference" href="#protocol-concreteprfs">10</a></li>
<li>
<span class="math">\(\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})\)</span>
,
@ -59,13 +59,13 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<span class="math">\(\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)\)</span>
, and
<span class="math">\(\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)\)</span>
<a id="id8" class="footnote_reference" href="#protocol-concretespendauthsig">11</a></li>
<a id="footnote-reference-8" class="footnote_reference" href="#protocol-concretespendauthsig">11</a></li>
<li>
<span class="math">\(\mathsf{NoteCommit}^\mathsf{Sapling}_\mathsf{rcm}(\mathsf{g_d}, \mathsf{pk_d}, value)\)</span>
<a id="id9" class="footnote_reference" href="#protocol-concretewindowedcommit">12</a></li>
<a id="footnote-reference-9" class="footnote_reference" href="#protocol-concretewindowedcommit">12</a></li>
<li>
<span class="math">\(\mathsf{ValueCommit}_\mathsf{rcv}(value)\)</span>
<a id="id10" class="footnote_reference" href="#protocol-concretehomomorphiccommit">13</a></li>
<a id="footnote-reference-10" class="footnote_reference" href="#protocol-concretehomomorphiccommit">13</a></li>
</ul>
<p>We also reproduce some notation and functions here for convenience:</p>
<ul>
@ -80,7 +80,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<span class="math">\(\mathsf{repr}_\mathbb{J}(P)\)</span>
is the representation of the Jubjub elliptic curve point
<span class="math">\(P\)</span>
as a bit sequence, defined in <a id="id11" class="footnote_reference" href="#protocol-jubjub">14</a>.</li>
as a bit sequence, defined in <a id="footnote-reference-11" class="footnote_reference" href="#protocol-jubjub">14</a>.</li>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\)</span>
refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string
@ -120,7 +120,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<li>Its corresponding expanded spending key
<span class="math">\((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk})\)</span>
,</li>
<li>The SLIP-44 <a id="id12" class="footnote_reference" href="#slip-0044">15</a> coin type, and</li>
<li>The SLIP-44 <a id="footnote-reference-12" class="footnote_reference" href="#slip-0044">15</a> coin type, and</li>
<li>The message
<span class="math">\(msg\)</span>
to be signed.</li>
@ -151,7 +151,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<span class="math">\(path\)</span>
be the Merkle path from position 0 to
<span class="math">\(\mathsf{rt}\)</span>
. <a id="id13" class="footnote_reference" href="#protocol-merklepath">4</a></li>
. <a id="footnote-reference-13" class="footnote_reference" href="#protocol-merklepath">4</a></li>
<li>Let
<span class="math">\(\mathsf{cv} = \mathsf{ValueCommit}_0(1)\)</span>
.
@ -174,7 +174,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<span class="math">\((\mathsf{rt}, \mathsf{cv}, \mathsf{nf}, \mathsf{rk})\)</span>
and auxiliary input
<span class="math">\((path, 0, \mathsf{g_d}, \mathsf{pk_d}, 1, 0, \mathsf{cm}, 0, α, \mathsf{ak}, \mathsf{nsk})\)</span>
. <a id="id14" class="footnote_reference" href="#protocol-spendstatement">5</a></li>
. <a id="footnote-reference-14" class="footnote_reference" href="#protocol-spendstatement">5</a></li>
<li>Let
<span class="math">\(\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{ask})\)</span>
.</li>
@ -198,7 +198,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<li>The payment address
<span class="math">\((\mathsf{d}, \mathsf{pk_d})\)</span>
,</li>
<li>The SLIP-44 <a id="id15" class="footnote_reference" href="#slip-0044">15</a> coin type,</li>
<li>The SLIP-44 <a id="footnote-reference-15" class="footnote_reference" href="#slip-0044">15</a> coin type,</li>
<li>The message
<span class="math">\(msg\)</span>
that is claimed to be signed, and</li>
@ -235,7 +235,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<span class="math">\(path\)</span>
be the Merkle path from position 0 to
<span class="math">\(\mathsf{rt}\)</span>
. <a id="id16" class="footnote_reference" href="#protocol-merklepath">4</a></li>
. <a id="footnote-reference-16" class="footnote_reference" href="#protocol-merklepath">4</a></li>
<li>Let
<span class="math">\(\mathsf{cv} = \mathsf{ValueCommit}_0(1)\)</span>
.
@ -247,7 +247,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<span class="math">\(zkproof\)</span>
as a Sapling spend proof with primary input
<span class="math">\((\mathsf{rt}, \mathsf{cv}, \mathsf{nf}, \mathsf{rk})\)</span>
. <a id="id17" class="footnote_reference" href="#protocol-spendstatement">5</a> If verification fails, return false.</li>
. <a id="footnote-reference-17" class="footnote_reference" href="#protocol-spendstatement">5</a> If verification fails, return false.</li>
<li>Return true.</li>
</ul>
</section>
@ -257,7 +257,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
, for a total size of 320 bytes.</p>
<p>When encoding a ZIP 304 signature in a human-readable format, implementations <strong>SHOULD</strong> use standard Base64 for compatibility with the <code>signmessage</code> and <code>verifymessage</code> RPC methods in <code>zcashd</code>. ZIP 304 signatures in this form are 428 bytes. The encoded form is the string
<span class="math">\(\texttt{"zip304:"}\)</span>
followed by the result of Base64-encoding <a id="id18" class="footnote_reference" href="#rfc4648">2</a> the raw form of the signature.</p>
followed by the result of Base64-encoding <a id="footnote-reference-18" 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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>

2
zip-0304.rst
View File

@ -3,7 +3,7 @@
ZIP: 304
Title: Sapling Address Signatures
Owners: Jack Grigg <jack@electriccoin.co>
Credits: Daira Hopwood <daira@electriccoin.co>
Credits: Daira Emma Hopwood <daira@electriccoin.co>
Sean Bowe <sean@electriccoin.co>
Status: Draft
Category: Standards / RPC / Wallet

2
zip-0305.html
View File

@ -8,7 +8,7 @@
<section>
<pre>ZIP: 305
Title: Best Practices for Hardware Wallets supporting Sapling
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Status: Reserved
Category: Wallet
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/346">https://github.com/zcash/zips/issues/346</a>&gt;</pre>

2
zip-0305.rst
View File

@ -2,7 +2,7 @@
ZIP: 305
Title: Best Practices for Hardware Wallets supporting Sapling
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Status: Reserved
Category: Wallet
Discussions-To: <https://github.com/zcash/zips/issues/346>

2
zip-0306.html
View File

@ -8,7 +8,7 @@
<section>
<pre>ZIP: 306
Title: Security Considerations for Anchor Selection
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Owners: Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Status: Reserved
Category: Informational
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/351">https://github.com/zcash/zips/issues/351</a>&gt;</pre>

2
zip-0306.rst
View File

@ -2,7 +2,7 @@
ZIP: 306
Title: Security Considerations for Anchor Selection
Owners: Daira Hopwood <daira@electriccoin.co>
Owners: Daira Emma Hopwood <daira@electriccoin.co>
Status: Reserved
Category: Informational
Discussions-To: <https://github.com/zcash/zips/issues/351>

84
zip-0307.html
View File

@ -10,7 +10,7 @@
<pre>ZIP: 307
Title: Light Client Protocol for Payment Detection
Owners: Jack Grigg &lt;jack@electriccoin.co&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Daira Emma Hopwood &lt;daira@electriccoin.co&gt;
Original-Authors: George Tankersley
Credits: Matthew Green
Category: Standards / Ecosystem
@ -18,7 +18,7 @@ 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" 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 key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Light client</dt>
@ -39,7 +39,7 @@ License: MIT</pre>
<li><strong>Light client</strong> that subscribes to the stream from a proxy server and uses that data to update its own view of the chain state. The light client MAY be attached to a wallet backend that will track particular Sapling notes.</li>
</ul>
<figure class="align-center" align="center">
<img src="zip-0307-arch.png" />
<img src="zip-0307-arch.png" alt="" />
<figcaption>Outline of the light wallet architecture</figcaption>
</figure>
</section>
@ -56,40 +56,40 @@ License: MIT</pre>
<li>Detect a spend of your shielded Sapling notes</li>
<li>Update your witnesses to generate new Sapling spend proofs.</li>
</ol>
<p>A compact block and its component compact transactions are encoded on the wire using the following Protocol Buffers <a id="id2" class="footnote_reference" href="#protocolbuffers">9</a> format:</p>
<pre data-language="proto"><span class="kd">message</span> <span class="nc">BlockID</span> <span class="p">{</span>
<span class="kt">uint64</span> <span class="na">blockHeight</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="kt">bytes</span> <span class="na">blockHash</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
<p>A compact block and its component compact transactions are encoded on the wire using the following Protocol Buffers <a id="footnote-reference-2" class="footnote_reference" href="#protocolbuffers">9</a> format:</p>
<pre data-language="proto"><span class="kd">message</span><span class="w"> </span><span class="nc">BlockID</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="kt">uint64</span><span class="w"> </span><span class="na">blockHeight</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">blockHash</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">2</span><span class="p">;</span>
<span class="p">}</span>
<span class="kd">message</span> <span class="nc">CompactBlock</span> <span class="p">{</span>
<span class="n">BlockID</span> <span class="na">id</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="k">repeated</span> <span class="n">CompactTx</span> <span class="na">vtx</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;</span>
<span class="kd">message</span><span class="w"> </span><span class="nc">CompactBlock</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">BlockID</span><span class="w"> </span><span class="na">id</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
<span class="w"> </span><span class="k">repeated</span><span class="w"> </span><span class="n">CompactTx</span><span class="w"> </span><span class="na">vtx</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">3</span><span class="p">;</span>
<span class="p">}</span>
<span class="kd">message</span> <span class="nc">CompactTx</span> <span class="p">{</span>
<span class="kt">uint64</span> <span class="na">txIndex</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="kt">bytes</span> <span class="na">txHash</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
<span class="kd">message</span><span class="w"> </span><span class="nc">CompactTx</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="kt">uint64</span><span class="w"> </span><span class="na">txIndex</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">txHash</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">2</span><span class="p">;</span>
<span class="k">repeated</span> <span class="n">CompactSpend</span> <span class="na">spends</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;</span>
<span class="k">repeated</span> <span class="n">CompactOutput</span> <span class="na">outputs</span> <span class="o">=</span> <span class="mi">4</span><span class="p">;</span>
<span class="w"> </span><span class="k">repeated</span><span class="w"> </span><span class="n">CompactSpend</span><span class="w"> </span><span class="na">spends</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">3</span><span class="p">;</span>
<span class="w"> </span><span class="k">repeated</span><span class="w"> </span><span class="n">CompactOutput</span><span class="w"> </span><span class="na">outputs</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">4</span><span class="p">;</span>
<span class="p">}</span>
<span class="kd">message</span> <span class="nc">CompactSpend</span> <span class="p">{</span>
<span class="kt">bytes</span> <span class="na">nf</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="kd">message</span><span class="w"> </span><span class="nc">CompactSpend</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">nf</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
<span class="p">}</span>
<span class="kd">message</span> <span class="nc">CompactOutput</span> <span class="p">{</span>
<span class="kt">bytes</span> <span class="na">cmu</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<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="kd">message</span><span class="w"> </span><span class="nc">CompactOutput</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">cmu</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">epk</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">2</span><span class="p">;</span>
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">ciphertext</span><span class="w"> </span><span class="o">=</span><span class="w"> </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" 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" 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>
<p>In the normal Zcash protocol, the output ciphertext consists of the AEAD-encrypted form of a <em>note plaintext</em> <a id="footnote-reference-3" class="footnote_reference" href="#protocol-notept">5</a>:</p>
<table>
<tbody>
<tr>
@ -107,7 +107,7 @@ License: MIT</pre>
<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" 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>
<p>Recall that a full Sapling Spend description is 384 bytes long <a id="footnote-reference-4" class="footnote_reference" href="#protocol-spendencoding">6</a>:</p>
<table>
<thead>
<tr>
@ -156,38 +156,38 @@ License: MIT</pre>
<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>
<pre data-language="proto"><span class="kd">service</span> <span class="n">CompactTxStreamer</span> <span class="p">{</span>
<span class="k">rpc</span> <span class="n">GetLatestBlock</span><span class="p">(</span><span class="n">ChainSpec</span><span class="p">)</span> <span class="k">returns</span> <span class="p">(</span><span class="n">BlockID</span><span class="p">)</span> <span class="p">{}</span>
<span class="k">rpc</span> <span class="n">GetBlock</span><span class="p">(</span><span class="n">BlockID</span><span class="p">)</span> <span class="k">returns</span> <span class="p">(</span><span class="n">CompactBlock</span><span class="p">)</span> <span class="p">{}</span>
<span class="k">rpc</span> <span class="n">GetBlockRange</span><span class="p">(</span><span class="n">RangeFilter</span><span class="p">)</span> <span class="k">returns</span> <span class="p">(</span><span class="n">stream</span> <span class="n">CompactBlock</span><span class="p">)</span> <span class="p">{}</span>
<span class="k">rpc</span> <span class="n">GetTransaction</span><span class="p">(</span><span class="n">TxFilter</span><span class="p">)</span> <span class="k">returns</span> <span class="p">(</span><span class="n">FullTransaction</span><span class="p">)</span> <span class="p">{}</span>
<pre data-language="proto"><span class="kd">service</span><span class="w"> </span><span class="n">CompactTxStreamer</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="k">rpc</span><span class="w"> </span><span class="n">GetLatestBlock</span><span class="p">(</span><span class="n">ChainSpec</span><span class="p">)</span><span class="w"> </span><span class="k">returns</span><span class="w"> </span><span class="p">(</span><span class="n">BlockID</span><span class="p">)</span><span class="w"> </span><span class="p">{}</span>
<span class="w"> </span><span class="k">rpc</span><span class="w"> </span><span class="n">GetBlock</span><span class="p">(</span><span class="n">BlockID</span><span class="p">)</span><span class="w"> </span><span class="k">returns</span><span class="w"> </span><span class="p">(</span><span class="n">CompactBlock</span><span class="p">)</span><span class="w"> </span><span class="p">{}</span>
<span class="w"> </span><span class="k">rpc</span><span class="w"> </span><span class="n">GetBlockRange</span><span class="p">(</span><span class="n">RangeFilter</span><span class="p">)</span><span class="w"> </span><span class="k">returns</span><span class="w"> </span><span class="p">(</span><span class="n">stream</span><span class="w"> </span><span class="n">CompactBlock</span><span class="p">)</span><span class="w"> </span><span class="p">{}</span>
<span class="w"> </span><span class="k">rpc</span><span class="w"> </span><span class="n">GetTransaction</span><span class="p">(</span><span class="n">TxFilter</span><span class="p">)</span><span class="w"> </span><span class="k">returns</span><span class="w"> </span><span class="p">(</span><span class="n">FullTransaction</span><span class="p">)</span><span class="w"> </span><span class="p">{}</span>
<span class="p">}</span>
<span class="c1">// Remember that proto3 fields are all optional.</span>
<span class="c1">// Someday we may want to specify e.g. a particular chain fork.</span>
<span class="kd">message</span> <span class="nc">ChainSpec</span> <span class="p">{}</span>
<span class="kd">message</span><span class="w"> </span><span class="nc">ChainSpec</span><span class="w"> </span><span class="p">{}</span>
<span class="c1">// A BlockID message contains identifiers to select a block: either a</span>
<span class="c1">// height or a hash.</span>
<span class="kd">message</span> <span class="nc">BlockID</span> <span class="p">{</span>
<span class="kt">uint64</span> <span class="na">blockHeight</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="kt">bytes</span> <span class="na">blockHash</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
<span class="kd">message</span><span class="w"> </span><span class="nc">BlockID</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="kt">uint64</span><span class="w"> </span><span class="na">blockHeight</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">blockHash</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">2</span><span class="p">;</span>
<span class="p">}</span>
<span class="kd">message</span> <span class="nc">RangeFilter</span> <span class="p">{</span>
<span class="n">BlockID</span> <span class="na">start</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="n">BlockID</span> <span class="na">end</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
<span class="kd">message</span><span class="w"> </span><span class="nc">RangeFilter</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">BlockID</span><span class="w"> </span><span class="na">start</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
<span class="w"> </span><span class="n">BlockID</span><span class="w"> </span><span class="na">end</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">2</span><span class="p">;</span>
<span class="p">}</span>
<span class="c1">// A TxFilter contains the information needed to identify a particular</span>
<span class="c1">// transaction: either a block and an index, or a direct transaction hash.</span>
<span class="kd">message</span> <span class="nc">TxFilter</span> <span class="p">{</span>
<span class="n">BlockID</span> <span class="na">blockID</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="kt">uint64</span> <span class="na">txIndex</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
<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="kd">message</span><span class="w"> </span><span class="nc">TxFilter</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">BlockID</span><span class="w"> </span><span class="na">blockID</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
<span class="w"> </span><span class="kt">uint64</span><span class="w"> </span><span class="na">txIndex</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">2</span><span class="p">;</span>
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">txHash</span><span class="w"> </span><span class="o">=</span><span class="w"> </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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -201,7 +201,7 @@ License: MIT</pre>
<span class="math">\((\mathtt{cmu}, \mathtt{ephemeralKey}, \mathsf{ciphertext})\)</span>
with an incoming viewing key
<span class="math">\(\mathsf{ivk}\)</span>
is a slight deviation from the standard decryption process <a id="id5" class="footnote_reference" href="#protocol-saplingdecryptivk">4</a> (all constants and algorithms are as defined there):</p>
is a slight deviation from the standard decryption process <a id="footnote-reference-5" class="footnote_reference" href="#protocol-saplingdecryptivk">4</a> (all constants and algorithms are as defined there):</p>
<ul>
<li>let
<span class="math">\(\mathsf{epk} = \mathsf{abst}_{\mathbb{J}}(\mathtt{ephemeralKey})\)</span>
@ -293,7 +293,7 @@ License: MIT</pre>
</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" 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>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="footnote-reference-6" 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="footnote-reference-7" 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="footnote-reference-8" 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>
<li>For each <code>CompactTx</code> in <code>CompactBlock</code>:
@ -319,7 +319,7 @@ License: MIT</pre>
</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" 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>
<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="footnote-reference-9" class="footnote_reference" href="#spv-clients">11</a> by performing the following checks:</p>
<ul>
<li><code>version &gt;= MIN_BLOCK_VERSION</code></li>
<li><code>prevHash == prevBlock.id.blockHash</code> where <code>prevBlock</code> is the previous <code>CompactBlock</code> received (at height <code>X-1</code>).</li>

2
zip-0307.rst
View File

@ -3,7 +3,7 @@
ZIP: 307
Title: Light Client Protocol for Payment Detection
Owners: Jack Grigg <jack@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Daira Emma Hopwood <daira@electriccoin.co>
Original-Authors: George Tankersley
Credits: Matthew Green
Category: Standards / Ecosystem

Some files were not shown because too many files have changed in this diff Show More