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

Regularize references, especially to RFCs and the Protocol Spec. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-11-09 15:59:51 +00:00
parent c136527758
commit c762d1ca67
84 changed files with 522 additions and 475 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
zip-0000.html
View File

@ -247,7 +247,7 @@ Updates:</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -255,7 +255,7 @@ Updates:</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc3552.html">Guidelines for Writing RFC Text on Security Considerations</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc3552.html">RFC 3552: Guidelines for Writing RFC Text on Security Considerations</a></td>
</tr>
</tbody>
</table>
@ -287,7 +287,7 @@ Updates:</pre>
<tbody>
<tr>
<th>6</th>
<td><a href="https://www.latex-project.org/">LaTeX -- a document preparation system</a></td>
<td><a href="https://www.latex-project.org/">LaTeX — a document preparation system</a></td>
</tr>
</tbody>
</table>

6
zip-0000.rst
View File

@ -612,10 +612,10 @@ See Also
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC3552] `Guidelines for Writing RFC Text on Security Considerations <https://www.rfc-editor.org/rfc/rfc3552.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC3552] `RFC 3552: Guidelines for Writing RFC Text on Security Considerations <https://www.rfc-editor.org/rfc/rfc3552.html>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#conduct] `Zcash Code of Conduct <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`_
.. [#rst] `reStructuredText documentation <http://docutils.sourceforge.net/rst.html>`_
.. [#latex] `LaTeX -- a document preparation system <https://www.latex-project.org/>`_
.. [#latex] `LaTeX — a document preparation system <https://www.latex-project.org/>`_

58
zip-0032.html
View File

@ -23,7 +23,7 @@ License: MIT</pre>
</p>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>"Jubjub" refers to the elliptic curve defined in <a id="id2" class="footnote_reference" href="#sapling-jubjub">12</a>.</p>
<p>"Jubjub" refers to the elliptic curve defined in <a id="id2" class="footnote_reference" href="#protocol-jubjub">12</a>.</p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 <a id="id3" class="footnote_reference" href="#bip-0032">2</a>, to support Zcash's shielded addresses.</p>
@ -41,7 +41,7 @@ License: MIT</pre>
<p>At present, no such equivalent exists for Zcash's shielded addresses. This is of particular concern for hardware wallets; all currently-marketed devices only store a seed internally, and have trained their users to only backup that seed. Given that the Sapling upgrade will make it feasible to use hardware wallets with shielded addresses, it is desirable to have a standard mechanism for deriving them.</p>
</section>
<section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#conventions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Most of the notation and functions used in this ZIP are defined in the Sapling protocol specification <a id="id8" class="footnote_reference" href="#sapling-spec">8</a>. They are reproduced here for convenience:</p>
<p>Most of the notation and functions used in this ZIP are defined in the Sapling protocol specification <a id="id8" class="footnote_reference" href="#protocol">8</a>. They are reproduced here for convenience:</p>
<ul>
<li>
<span class="math">\(\mathsf{truncate}_k(S)\)</span>
@ -93,7 +93,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="id9" class="footnote_reference" href="#sapling-jubjub">12</a>.</li>
as a bit sequence, defined in <a id="id9" class="footnote_reference" href="#protocol-jubjub">12</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
@ -126,7 +126,7 @@ 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="id10" class="footnote_reference" href="#sapling-diversifyhash">10</a>.</li>
if the diversifier is invalid. It is instantiated in <a id="id10" class="footnote_reference" href="#protocol-concretediversifyhash">10</a>.</li>
</ul>
<p>The following algorithm standardized in <a id="id11" class="footnote_reference" href="#nist-sp-800-38g">16</a> is used:</p>
<ul>
@ -256,7 +256,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="id14" class="footnote_reference" href="#sapling-key-components">9</a>:
via the standard Sapling derivation <a id="id14" class="footnote_reference" href="#protocol-saplingkeycomponents">9</a>:
<ul>
<li>
<span class="math">\(\mathsf{ask}_m = \mathsf{ToScalar}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))\)</span>
@ -312,7 +312,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="id15" class="footnote_reference" href="#sapling-key-components">9</a>.</li>
as described in <a id="id15" class="footnote_reference" href="#protocol-saplingkeycomponents">9</a>.</li>
</ul>
</li>
<li>Split
@ -354,9 +354,9 @@ License: MIT</pre>
<section id="deriving-a-child-extended-full-viewing-key"><h4><span class="section-heading">Deriving a child extended full viewing key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-child-extended-full-viewing-key"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Let
<span class="math">\(\mathcal{G}\)</span>
be as defined in <a id="id16" class="footnote_reference" href="#sapling-spendauthsig">11</a> and let
be as defined in <a id="id16" class="footnote_reference" href="#protocol-concretespendauthsig">11</a> and let
<span class="math">\(\mathcal{H}\)</span>
be as defined in <a id="id17" class="footnote_reference" href="#sapling-key-components">9</a>.</p>
be as defined in <a id="id17" class="footnote_reference" href="#protocol-saplingkeycomponents">9</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>
@ -458,7 +458,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{EncodeASK}(\mathsf{a_{sk}})\)</span>
be the 32-byte encoding of
<span class="math">\(\mathsf{a_{sk}}\)</span>
in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in <a id="id18" class="footnote_reference" href="#sprout-spending-keys">15</a>.</p>
in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in <a id="id18" class="footnote_reference" href="#protocol-sproutspendingkeyencoding">15</a>.</p>
<p>Let
<span class="math">\(\mathsf{DecodeASK}(ASK)\)</span>
be the result of clearing the 4 most significant bits of the first byte of
@ -597,7 +597,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" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding
<span class="math">\(FVK\)</span>
(as specified in <a id="id23" class="footnote_reference" href="#sapling-full-viewing-keys">14</a>) is given by:</p>
(as specified in <a id="id23" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">14</a>) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, FVK)\)</span>
@ -609,7 +609,7 @@ License: MIT</pre>
<section id="sprout-address-fingerprints-and-tags"><h3><span class="section-heading">Sprout Address Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-address-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A "Sprout address fingerprint" of a Sprout payment address with raw encoding
<span class="math">\(ADDR\)</span>
(as specified in <a id="id24" class="footnote_reference" href="#sprout-shielded-addresses">13</a>, including the lead bytes) is given by:</p>
(as specified in <a id="id24" class="footnote_reference" href="#protocol-sproutpaymentaddrencoding">13</a>, including the lead bytes) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, ADDR)\)</span>
@ -748,7 +748,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -800,67 +800,67 @@ License: MIT</pre>
</tr>
</tbody>
</table>
<table id="sapling-spec" class="footnote">
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2019.0.8 or later [Overwinter+Sapling+Blossom]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>
<table id="sapling-key-components" class="footnote">
<table id="protocol-saplingkeycomponents" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Section 4.2.2 Sapling Key Components</a></td>
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2020.1.15. Section 4.2.2: Sapling Key Components</a></td>
</tr>
</tbody>
</table>
<table id="sapling-diversifyhash" class="footnote">
<table id="protocol-concretediversifyhash" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Section 5.4.1.6 DiversifyHash Hash Function</a></td>
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.6: DiversifyHash Hash Function</a></td>
</tr>
</tbody>
</table>
<table id="sapling-spendauthsig" class="footnote">
<table id="protocol-concretespendauthsig" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="protocol/protocol.pdf#concretespendauthsig">Zcash Protocol Specification, Section 5.4.6.1 Spend Authorization Signature</a></td>
<td><a href="protocol/protocol.pdf#concretespendauthsig">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature</a></td>
</tr>
</tbody>
</table>
<table id="sapling-jubjub" class="footnote">
<table id="protocol-jubjub" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="protocol/protocol.pdf#jubjub">Zcash Protocol Specification, Section 5.4.8.3 Jubjub</a></td>
<td><a href="protocol/protocol.pdf#jubjub">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.8.3: Jubjub</a></td>
</tr>
</tbody>
</table>
<table id="sprout-shielded-addresses" class="footnote">
<table id="protocol-sproutpaymentaddrencoding" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="protocol/protocol.pdf#sproutpaymentaddrencoding">Zcash Protocol Specification, Section 5.6.3 Sprout Shielded Payment Addresses</a></td>
<td><a href="protocol/protocol.pdf#sproutpaymentaddrencoding">Zcash Protocol Specification, Version 2020.1.15. Section 5.6.3: Sprout Shielded Payment Addresses</a></td>
</tr>
</tbody>
</table>
<table id="sapling-full-viewing-keys" class="footnote">
<table id="protocol-saplingfullviewingkeyencoding" class="footnote">
<tbody>
<tr>
<th>14</th>
<td><a href="protocol/protocol.pdf#saplingfullviewingkeyencoding">Zcash Protocol Specification, Section 5.6.7 Sapling Full Viewing Keys</a></td>
<td><a href="protocol/protocol.pdf#saplingfullviewingkeyencoding">Zcash Protocol Specification, Version 2020.1.15. Section 5.6.7: Sapling Full Viewing Keys</a></td>
</tr>
</tbody>
</table>
<table id="sprout-spending-keys" class="footnote">
<table id="protocol-sproutspendingkeyencoding" class="footnote">
<tbody>
<tr>
<th>15</th>
<td><a href="protocol/protocol.pdf#sproutspendingkeyencoding">Zcash Protocol Specification, Section 5.6.8 Sprout Spending Keys</a></td>
<td><a href="protocol/protocol.pdf#sproutspendingkeyencoding">Zcash Protocol Specification, Version 2020.1.15. Section 5.6.8: Sprout Spending Keys</a></td>
</tr>
</tbody>
</table>
@ -868,7 +868,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>16</th>
<td><a href="https://dx.doi.org/10.6028/NIST.SP.800-38G">NIST Special Publication 800-38G -- Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption</a></td>
<td><a href="https://dx.doi.org/10.6028/NIST.SP.800-38G">NIST Special Publication 800-38G — Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption</a></td>
</tr>
</tbody>
</table>

43
zip-0032.rst
View File

@ -20,7 +20,7 @@ Terminology
The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119.
[#RFC2119]_
"Jubjub" refers to the elliptic curve defined in [#sapling-jubjub]_.
"Jubjub" refers to the elliptic curve defined in [#protocol-jubjub]_.
Abstract
@ -64,7 +64,7 @@ Conventions
===========
Most of the notation and functions used in this ZIP are defined in the Sapling protocol specification
[#sapling-spec]_. They are reproduced here for convenience:
[#protocol]_. They are reproduced here for convenience:
- :math:`\mathsf{truncate}_k(S)` means the sequence formed from the first :math:`k` elements of :math:`S`.
@ -83,7 +83,7 @@ Most of the notation and functions used in this ZIP are defined in the Sapling p
concatenate the resulting bytes in the same order as the groups.
- :math:`\mathsf{repr}_\mathbb{J}(P)` is the representation of the Jubjub elliptic curve point :math:`P`
as a bit sequence, defined in [#sapling-jubjub]_.
as a bit sequence, defined in [#protocol-jubjub]_.
- :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)` refers to unkeyed BLAKE2b-256 in sequential mode,
with an output digest length of 32 bytes, 16-byte personalization string :math:`p`, and input :math:`x`.
@ -98,7 +98,7 @@ Most of the notation and functions used in this ZIP are defined in the Sapling p
- :math:`\mathsf{ToScalar}(x) :=`:math:`\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{J}}`.
- :math:`\mathsf{DiversifyHash}(d)` maps a diversifier :math:`d` to a base point on the Jubjub elliptic
curve, or to :math:`\bot` if the diversifier is invalid. It is instantiated in [#sapling-diversifyhash]_.
curve, or to :math:`\bot` if the diversifier is invalid. It is instantiated in [#protocol-concretediversifyhash]_.
The following algorithm standardized in [#NIST-SP-800-38G]_ is used:
@ -169,7 +169,7 @@ Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least
- Use :math:`I_L` as the master spending key :math:`\mathsf{sk}_m`, and :math:`I_R` as the master chain code
:math:`\mathsf{c}_m`.
- Calculate :math:`\mathsf{ask}_m`, :math:`\mathsf{nsk}_m`, and :math:`\mathsf{ovk}_m` via the standard
Sapling derivation [#sapling-key-components]_:
Sapling derivation [#protocol-saplingkeycomponents]_:
- :math:`\mathsf{ask}_m = \mathsf{ToScalar}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))`
- :math:`\mathsf{nsk}_m = \mathsf{ToScalar}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x01}]))`
@ -200,7 +200,7 @@ Deriving a child extended spending key
- If not (normal child):
let :math:`I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x12}]`:math:`||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})`:math:`||\,\mathsf{I2LEOSP}_{32}(i))`
where :math:`(\mathsf{nk}_{par}, \mathsf{ak}_{par}, \mathsf{ovk}_{par})` is the full viewing key derived from
:math:`(\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par})` as described in [#sapling-key-components]_.
:math:`(\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par})` as described in [#protocol-saplingkeycomponents]_.
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
- Let :math:`I_\mathsf{ask} = \mathsf{ToScalar}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))`.
@ -216,8 +216,8 @@ Deriving a child extended spending key
Deriving a child extended full viewing key
``````````````````````````````````````````
Let :math:`\mathcal{G}` be as defined in [#sapling-spendauthsig]_ and let :math:`\mathcal{H}` be as defined
in [#sapling-key-components]_.
Let :math:`\mathcal{G}` be as defined in [#protocol-concretespendauthsig]_ and let :math:`\mathcal{H}` be as defined
in [#protocol-saplingkeycomponents]_.
:math:`\mathsf{CDKfvk}((\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)`:math:`\rightarrow (\mathsf{ak}_{i}, \mathsf{nk}_{i}, \mathsf{ovk}_{i}, \mathsf{dk}_{i}, \mathsf{c}_{i})`
@ -278,7 +278,7 @@ Sprout helper functions
-----------------------
Let :math:`\mathsf{EncodeASK}(\mathsf{a_{sk}})` be the 32-byte encoding of :math:`\mathsf{a_{sk}}` in the
raw encoding of a Sprout spending key (excluding lead bytes) as specified in [#sprout-spending-keys]_.
raw encoding of a Sprout spending key (excluding lead bytes) as specified in [#protocol-sproutspendingkeyencoding]_.
Let :math:`\mathsf{DecodeASK}(ASK)` be the result of clearing the 4 most significant bits of the first byte
of :math:`ASK`, and decoding the 32-byte result according to the inverse of :math:`\mathsf{EncodeASK}`.
@ -381,7 +381,7 @@ Sapling Full Viewing Key Fingerprints and Tags
----------------------------------------------
A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding :math:`FVK` (as specified
in [#sapling-full-viewing-keys]_) is given by:
in [#protocol-saplingfullviewingkeyencoding]_) is given by:
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, FVK)`.
@ -395,7 +395,7 @@ Sprout Address Fingerprints and Tags
------------------------------------
A "Sprout address fingerprint" of a Sprout payment address with raw encoding :math:`ADDR` (as specified in
[#sprout-shielded-addresses]_, including the lead bytes) is given by:
[#protocol-sproutpaymentaddrencoding]_, including the lead bytes) is given by:
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, ADDR)`.
@ -494,20 +494,19 @@ Reference Implementation
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#bip-0032] `BIP 32: Hierarchical Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>`_
.. [#bip-0039] `BIP 39: Mnemonic code for generating deterministic keys <https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki>`_
.. [#bip-0043] `BIP 43: Purpose Field for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki>`_
.. [#bip-0044] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki>`_
.. [#slip-0044] `SLIP 44: Registered coin types for BIP-0044 <https://github.com/satoshilabs/slips/blob/master/slip-0044.md>`_
.. [#bip-0173] `BIP 173: Base32 address format for native v0-16 witness outputs <https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki>`_
.. [#sapling-spec] `Zcash Protocol Specification, Version 2019.0.8 or later [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_
.. [#sapling-key-components] `Zcash Protocol Specification, Section 4.2.2 Sapling Key Components <protocol/protocol.pdf#saplingkeycomponents>`_
.. [#sapling-diversifyhash] `Zcash Protocol Specification, Section 5.4.1.6 DiversifyHash Hash Function <protocol/protocol.pdf#concretediversifyhash>`_
.. [#sapling-spendauthsig] `Zcash Protocol Specification, Section 5.4.6.1 Spend Authorization Signature <protocol/protocol.pdf#concretespendauthsig>`_
.. [#sapling-jubjub] `Zcash Protocol Specification, Section 5.4.8.3 Jubjub <protocol/protocol.pdf#jubjub>`_
.. [#sprout-shielded-addresses] `Zcash Protocol Specification, Section 5.6.3 Sprout Shielded Payment Addresses <protocol/protocol.pdf#sproutpaymentaddrencoding>`_
.. [#sapling-full-viewing-keys] `Zcash Protocol Specification, Section 5.6.7 Sapling Full Viewing Keys <protocol/protocol.pdf#saplingfullviewingkeyencoding>`_
.. [#sprout-spending-keys] `Zcash Protocol Specification, Section 5.6.8 Sprout Spending Keys <protocol/protocol.pdf#sproutspendingkeyencoding>`_
.. [#NIST-SP-800-38G] `NIST Special Publication 800-38G -- Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption <https://dx.doi.org/10.6028/NIST.SP.800-38G>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2020.1.15. Section 4.2.2: Sapling Key Components <protocol/protocol.pdf#saplingkeycomponents>`_
.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.6: DiversifyHash Hash Function <protocol/protocol.pdf#concretediversifyhash>`_
.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature <protocol/protocol.pdf#concretespendauthsig>`_
.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.8.3: Jubjub <protocol/protocol.pdf#jubjub>`_
.. [#protocol-sproutpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 5.6.3: Sprout Shielded Payment Addresses <protocol/protocol.pdf#sproutpaymentaddrencoding>`_
.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 5.6.7: Sapling Full Viewing Keys <protocol/protocol.pdf#saplingfullviewingkeyencoding>`_
.. [#protocol-sproutspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 5.6.8: Sprout Spending Keys <protocol/protocol.pdf#sproutspendingkeyencoding>`_
.. [#NIST-SP-800-38G] `NIST Special Publication 800-38G — Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption <https://dx.doi.org/10.6028/NIST.SP.800-38G>`_

24
zip-0143.html
View File

@ -26,7 +26,7 @@ License: MIT</pre>
<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" 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">2</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="#zcash-protocol">3</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="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>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>
@ -64,7 +64,7 @@ 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" 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">2</a></p>
<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>
<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" 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>
</section>
@ -351,23 +351,23 @@ sighash: 23652e76cb13b85a0e3363bb5fca061fa791c40c533eccee899364e6e60bb4f7</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol-sproutsend" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#sproutsend">Zcash Protocol Specification, Version 2020.1.15. Section 4.6: Sending Notes (Sprout)</a></td>
</tr>
</tbody>
</table>
<table id="wiki-checksig" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://en.bitcoin.it/wiki/OP_CHECKSIG">https://en.bitcoin.it/wiki/OP_CHECKSIG</a></td>
</tr>
</tbody>
</table>
<table id="zcash-protocol" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#send">Zcash Protocol Specification, Section 4.6 Sending Notes</a></td>
<td><a href="https://en.bitcoin.it/wiki/OP_CHECKSIG">OP_CHECKSIG. Bitcoin Wiki</a></td>
</tr>
</tbody>
</table>

8
zip-0143.rst
View File

@ -41,7 +41,7 @@ There are 4 ECDSA signature validation operations in the original Zcash script s
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. [#wiki-checksig]_
The transaction digest is additionally used for the JoinSplit signature (solely with sighash type ``ALL``).
[#zcash-protocol]_
[#protocol-sproutsend]_
Unfortunately, there are at least 2 weaknesses in the original SignatureHash transaction digest algorithm:
@ -453,9 +453,9 @@ https://github.com/zcash/zcash/pull/2903
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#wiki-checksig] https://en.bitcoin.it/wiki/OP_CHECKSIG
.. [#zcash-protocol] `Zcash Protocol Specification, Section 4.6 Sending Notes <protocol/protocol.pdf#send>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-sproutsend] `Zcash Protocol Specification, Version 2020.1.15. Section 4.6: Sending Notes (Sprout) <protocol/protocol.pdf#sproutsend>`_
.. [#wiki-checksig] `OP\_CHECKSIG. Bitcoin Wiki <https://en.bitcoin.it/wiki/OP_CHECKSIG>`_
.. [#quadratic]
* `CVE-2013-2292 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2292>`_
* `New Bitcoin vulnerability: A transaction that takes at least 3 minutes to verify <https://bitcointalk.org/?topic=140078>`_

4
zip-0173.html
View File

@ -354,7 +354,7 @@ def bech32_verify_checksum(hrp, data):
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -362,7 +362,7 @@ def bech32_verify_checksum(hrp, data):
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2018.0-beta-37 [Overwinter+Sapling]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>

4
zip-0173.rst
View File

@ -461,8 +461,8 @@ Eric Lombrozo, Peter Todd, and various other reviewers.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 [Overwinter+Sapling] <protocol/protocol.pdf>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_

8
zip-0200.html
View File

@ -121,7 +121,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -129,7 +129,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="https://electriccoin.co/blog/consensual-currency/">https://electriccoin.co/blog/consensual-currency/</a></td>
<td><a href="https://electriccoin.co/blog/consensual-currency/">Consensual Currency. Electric Coin Company blog</a></td>
</tr>
</tbody>
</table>
@ -139,8 +139,8 @@ License: MIT</pre>
<th>3</th>
<td>
<ul>
<li><a href="https://electriccoin.co/blog/release-cycle-and-lifetimes/">https://electriccoin.co/blog/release-cycle-and-lifetimes/</a></li>
<li><a href="https://electriccoin.co/blog/release-cycle-update/">https://electriccoin.co/blog/release-cycle-update/</a></li>
<li><a href="https://electriccoin.co/blog/release-cycle-and-lifetimes/">Release Cycle and Lifetimes. Electric Coin Company blog</a></li>
<li><a href="https://electriccoin.co/blog/release-cycle-update/">Release Cycle Update. Electric Coin Company blog</a></li>
</ul>
</td>
</tr>

8
zip-0200.rst
View File

@ -223,11 +223,11 @@ https://github.com/zcash/zcash/pull/2898
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#consensual-currency] https://electriccoin.co/blog/consensual-currency/
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#consensual-currency] `Consensual Currency. Electric Coin Company blog <https://electriccoin.co/blog/consensual-currency/>`_
.. [#release-lifecycle]
- https://electriccoin.co/blog/release-cycle-and-lifetimes/
- https://electriccoin.co/blog/release-cycle-update/
- `Release Cycle and Lifetimes. Electric Coin Company blog <https://electriccoin.co/blog/release-cycle-and-lifetimes/>`_
- `Release Cycle Update. Electric Coin Company blog <https://electriccoin.co/blog/release-cycle-update/>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <zip-0202.rst>`_

2
zip-0201.html
View File

@ -189,7 +189,7 @@ if (nActivationHeight &gt; 0 &amp;&amp;
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-0201.rst
View File

@ -248,7 +248,7 @@ https://github.com/zcash/zcash/pull/2919
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <zip-0202.rst>`_

2
zip-0202.html
View File

@ -335,7 +335,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-0202.rst
View File

@ -275,7 +275,7 @@ https://github.com/zcash/zcash/pull/2925
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Handshaking for Overwinter <zip-0201.rst>`_

26
zip-0205.html
View File

@ -15,7 +15,7 @@ Category: Consensus
Created: 2018-10-08
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">2</a></p>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
@ -30,7 +30,7 @@ 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" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The primary sources of information about Sapling consensus protocol changes are:</p>
<ul>
<li>The Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol">1</a>.</li>
<li>The Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol">2</a>.</li>
<li>Transaction Signature Validation for Sapling <a id="id4" class="footnote_reference" href="#zip-0243">5</a>.</li>
<li>Network Upgrade Activation Mechanism <a id="id5" class="footnote_reference" href="#zip-0200">3</a>.</li>
</ul>
@ -59,8 +59,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" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Section 7.6.3 of <a id="id9" class="footnote_reference" href="#protocol">1</a> describes the algorithm used to adjust the difficulty of a block (defined in terms of a "target threshold") based on the <code>nTime</code> and <code>nBits</code> fields of preceding blocks.</p>
<p>This algorithm changed on testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is at least 15 minutes after that of the preceding block, then the block is a minimum-difficulty block, and its target threshold is set to the value of PoWLimit for testnet (see <a id="id10" class="footnote_reference" href="#protocol">1</a> section 5.3). However, its <code>nBits</code> field is still computed according to the original difficulty adjustment algorithm.</p>
<p>Section 7.6.3 of <a id="id9" class="footnote_reference" href="#protocol">2</a> describes the algorithm used to adjust the difficulty of a block (defined in terms of a "target threshold") based on the <code>nTime</code> and <code>nBits</code> fields of preceding blocks.</p>
<p>This algorithm changed on testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is at least 15 minutes after that of the preceding block, then the block is a minimum-difficulty block, and its target threshold is set to the value of PoWLimit for testnet (see <a id="id10" class="footnote_reference" href="#protocol">2</a> section 5.3). However, its <code>nBits</code> field is still computed according to the original difficulty adjustment algorithm.</p>
<p>This does not affect how the minimum-difficulty block is treated for subsequent difficulty adjustments. In particular, only the <code>nBits</code> field computed by the original algorithm is used for the purpose of computing the MeanTarget values from which subsequent difficulty changes are calculated.</p>
<p>This change does not affect mainnet.</p>
</section>
@ -73,19 +73,19 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<p>Support for Sapling consensus rules was implemented in zcashd version 2.0.0. The majority of support for RPC calls and persistence of Sapling z-addresses was implemented in version 2.0.1. Both of these versions advertise protocol version 170007.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2018.0-beta-37 [Overwinter+Sapling]</a></td>
</tr>
</tbody>
</table>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>

4
zip-0205.rst
View File

@ -139,8 +139,8 @@ version 170007.
References
==========
.. [#protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 [Overwinter+Sapling] <protocol/protocol.pdf>`_
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling <zip-0243.rst>`_

28
zip-0206.html
View File

@ -15,16 +15,16 @@ Category: Consensus
Created: 2019-07-29
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">2</a></p>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
<p>The terms below are to be interpreted as follows:</p>
<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">1</a>.</dd>
<dd>The Zcash test network, as defined in <a id="id3" 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">1</a>.</dd>
<dd>The Zcash production network, as defined in <a id="id4" class="footnote_reference" href="#protocol">2</a>.</dd>
</dl>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -34,7 +34,7 @@ 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" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The primary sources of information about Blossom consensus protocol changes are:</p>
<ul>
<li>The Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol">1</a>.</li>
<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 Activation Mechanism <a id="id7" class="footnote_reference" href="#zip-0200">3</a>.</li>
</ul>
@ -65,25 +65,25 @@ 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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Prior to the network upgrade activating on each network, Blossom and pre-Blossom nodes are compatible and can connect to each other. However, Blossom nodes will have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will gradually be disconnected in the run up to activation.</p>
<p>Once the network upgrades, even though pre-Blossom nodes can still accept the numerically larger protocol version used by Blossom as being valid, Blossom nodes will always disconnect peers using lower protocol versions.</p>
<p>Unlike Overwinter and Sapling, Blossom does not define a new transaction version. Blossom transactions are therefore in the same v4 format as Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as defined in <a id="id11" class="footnote_reference" href="#protocol">1</a> section 7.1. This does not imply that transactions are valid across the Blossom activation, since signatures MUST use the appropriate consensus branch ID.</p>
<p>Unlike Overwinter and Sapling, Blossom does not define a new transaction version. Blossom transactions are therefore in the same v4 format as Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as defined in <a id="id11" class="footnote_reference" href="#protocol">2</a> section 7.1. This does not imply that transactions are valid across the Blossom activation, since signatures MUST use the appropriate consensus branch ID.</p>
</section>
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Support for Blossom on testnet is implemented in <code>zcashd</code> version 2.0.7, which advertises protocol version 170008. Support for Blossom on mainnet is implemented in <code>zcashd</code> version 2.1.0, which advertises protocol version 170009.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom]</a></td>
</tr>
</tbody>
</table>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>

4
zip-0206.rst
View File

@ -121,8 +121,8 @@ in ``zcashd`` version 2.1.0, which advertises protocol version 170009.
References
==========
.. [#protocol] `Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_

16
zip-0207.html
View File

@ -384,7 +384,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -392,7 +392,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/canopy.pdf">Zcash Protocol Specification, Version 2020.1.9 or later [Canopy]</a></td>
<td><a href="protocol/canopy.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>
@ -400,7 +400,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/canopy.pdf#networks">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/canopy.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
@ -408,7 +408,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/canopy.pdf#subsidyconcepts">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.9: Block Subsidy and Founders' Reward</a></td>
<td><a href="protocol/canopy.pdf#subsidyconcepts">Zcash Protocol Specification, Version 2020.1.15. Section 3.9: Block Subsidy and Founders' Reward</a></td>
</tr>
</tbody>
</table>
@ -416,7 +416,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/canopy.pdf#constants">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 5.3: Constants</a></td>
<td><a href="protocol/canopy.pdf#constants">Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants</a></td>
</tr>
</tbody>
</table>
@ -424,7 +424,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/canopy.pdf#diffadjustment">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.6.3: Difficulty adjustment</a></td>
<td><a href="protocol/canopy.pdf#diffadjustment">Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment</a></td>
</tr>
</tbody>
</table>
@ -432,7 +432,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/canopy.pdf#subsidies">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.7: Calculation of Block Subsidy and Founders' Reward</a></td>
<td><a href="protocol/canopy.pdf#subsidies">Zcash Protocol Specification, Version 2020.1.15. Section 7.7: Calculation of Block Subsidy and Founders' Reward</a></td>
</tr>
</tbody>
</table>
@ -440,7 +440,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/canopy.pdf#foundersreward">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.8: Payment of Founders' Reward</a></td>
<td><a href="protocol/canopy.pdf#foundersreward">Zcash Protocol Specification, Version 2020.1.15. Section 7.8: Payment of Founders' Reward</a></td>
</tr>
</tbody>
</table>

16
zip-0207.rst
View File

@ -397,14 +397,14 @@ TBC
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.9 or later [Canopy] <protocol/canopy.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet <protocol/canopy.pdf#networks>`_
.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.9: Block Subsidy and Founders' Reward <protocol/canopy.pdf#subsidyconcepts>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 5.3: Constants <protocol/canopy.pdf#constants>`_
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.6.3: Difficulty adjustment <protocol/canopy.pdf#diffadjustment>`_
.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.7: Calculation of Block Subsidy and Founders' Reward <protocol/canopy.pdf#subsidies>`_
.. [#protocol-foundersreward] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.8: Payment of Founders' Reward <protocol/canopy.pdf#foundersreward>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/canopy.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet <protocol/canopy.pdf#networks>`_
.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2020.1.15. Section 3.9: Block Subsidy and Founders' Reward <protocol/canopy.pdf#subsidyconcepts>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants <protocol/canopy.pdf#constants>`_
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment <protocol/canopy.pdf#diffadjustment>`_
.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2020.1.15. Section 7.7: Calculation of Block Subsidy and Founders' Reward <protocol/canopy.pdf#subsidies>`_
.. [#protocol-foundersreward] `Zcash Protocol Specification, Version 2020.1.15. Section 7.8: Payment of Founders' Reward <protocol/canopy.pdf#foundersreward>`_
.. [#zip-0000] `ZIP 0: ZIP Process <zip-0000.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_

86
zip-0208.html
View File

@ -17,12 +17,12 @@ Created: 2019-01-10
License: MIT
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://github.com/zcash/zips/pull/237</a>&gt;</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">3</a></p>
<p>The terms "block chain", "consensus rule change", "consensus branch", and "network upgrade" are to be interpreted as defined in <a id="id2" class="footnote_reference" href="#zip-0200">4</a>.</p>
<p>The term "block target spacing" means the time interval between blocks targeted by the difficulty adjustment algorithm in a given consensus branch. It is normally measured in seconds. (This is also sometimes called the "target block time", but "block target spacing" is the term used in <a id="id3" class="footnote_reference" href="#latest-protocol">1</a>.)</p>
<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 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">7</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">5</a>.)</p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal specifies a change in the block target spacing, to take effect in the Blossom network upgrade <a id="id4" class="footnote_reference" href="#zip-0206">6</a>.</p>
<p>This proposal specifies a change in the block target spacing, to take effect in the Blossom network upgrade <a id="id4" class="footnote_reference" href="#zip-0206">9</a>.</p>
<p>The emission schedule of mined ZEC will be approximately the same in terms of time, but this requires the emission per block to be adjusted to take account of the changed block target spacing.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -32,15 +32,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="id5" class="footnote_reference" href="#slowfastblocks">8</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="id5" class="footnote_reference" href="#slowfastblocks">11</a> for further analysis in various attack models.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The changes described in this section are to be made in <a id="id6" class="footnote_reference" href="#latest-protocol">1</a>, relative to the pre-Blossom specification in [#preblossom-protocol].</p>
<p>The changes described in this section are to be made in the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol">3</a>, relative to the pre-Blossom specification in [#preblossom-protocol].</p>
<section id="consensus-changes"><h3><span class="section-heading">Consensus changes</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-changes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Throughout the specification, rename HalvingInterval to PreBlossomHalvingInterval, and rename PoWTargetSpacing to PreBlossomTargetSpacing. These constants retain their values from <a id="id7" class="footnote_reference" href="#preblossom-protocol">2</a> of 840000 (blocks) and 150 (seconds) respectively.</p>
<p>In section 2 (Notation), add BlossomActivationHeight and PostBlossomPoWTargetSpacing to the list of integer constants.</p>
<p>In section 5.3 (Constants), define PostBlossomPoWTargetSpacing := 75 seconds.</p>
<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="id8" class="footnote_reference" href="#zip-0206">6</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="id8" class="footnote_reference" href="#zip-0206">9</a>.</p>
<p>In section 7.6.3 (Difficulty adjustment), 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>
@ -63,7 +63,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<li>add a <em>height</em> parameter to each of these functions that does not already have one;</li>
<li>ensure that each reference to any of these values, or to PoWTargetSpacing, are replaced with a function call passing the <em>height</em> parameter.</li>
</ul>
<p>In <a id="id9" class="footnote_reference" href="#latest-protocol">1</a> section 7.7 (Calculation of Block Subsidy and Founders’ Reward), redefine the Halving and BlockSubsidy functions as follows:</p>
<p>In section 7.7 (Calculation of Block Subsidy and Founders’ Reward), redefine the Halving and BlockSubsidy functions as follows:</p>
<ul>
<li>Halving(<em>height</em>) :=
<ul>
@ -85,7 +85,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<li>(BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (<em>height</em> - BlossomActivationHeight) / PostBlossomHalvingInterval) is exactly 1 for some integer <em>height</em>.</li>
<li>MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2<sup>Halving(*height*)</sup>) is an integer for the next few periods.</li>
</ul>
<p>In <a id="id10" class="footnote_reference" href="#latest-protocol">1</a> section 7.8 (Payment of Founders’ Reward), define:</p>
<p>In section 7.8 (Payment of Founders’ Reward), define:</p>
<ul>
<li>FounderAddressAdjustedHeight(<em>height</em>) :=
<ul>
@ -110,8 +110,8 @@ 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-the-test-network"><h4><span class="section-heading">Minimum difficulty blocks on the test network</span><span class="section-anchor"> <a rel="bookmark" href="#minimum-difficulty-blocks-on-the-test-network"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>On the test network from block height 299188 onward, the difficulty adjustment algorithm allows minimum-difficulty blocks, as described in <a id="id11" class="footnote_reference" href="#zip-0205">5</a>, when the block time exceeds a given threshold. This specification changes this threshold to be proportional to the block target spacing.</p>
<p>That is, if the block time of a block at height <em>height</em> ≥ 299188 is at least 6 · PoWTargetSpacing(<em>height</em>) seconds after that of the preceding block, then the block is a minimum-difficulty block, and its target threshold is set to the value of PoWLimit for testnet (see <a id="id12" class="footnote_reference" href="#latest-protocol">1</a> section 5.3).</p>
<p>On the test network from block height 299188 onward, the difficulty adjustment algorithm allows minimum-difficulty blocks, as described in <a id="id9" class="footnote_reference" href="#zip-0205">8</a>, when the block time exceeds a given threshold. This specification changes this threshold to be proportional to the block target spacing.</p>
<p>That is, if the block time of a block at height <em>height</em> ≥ 299188 is at least 6 · PoWTargetSpacing(<em>height</em>) seconds after that of the preceding block, then the block is a minimum-difficulty block, and its target threshold is set to the value of PoWLimit for testnet (see section 5.3 of the Zcash Protocol Specification <a id="id10" class="footnote_reference" href="#protocol-constants">4</a>).</p>
<p>As before, the <code>nBits</code> field of a minimum-difficulty block is still computed according to the original difficulty adjustment algorithm, and only this field is used for the purpose of computing the MeanTarget values from which subsequent difficulty changes are calculated.</p>
</section>
</section>
@ -120,22 +120,22 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<p><cite>zcashd</cite> implements an "End-of-Service halt" behaviour that halts the node at a block height that corresponds approximately to a given time after release. This interval SHOULD be adjusted in releases where the End-of-Service halt time will follow Blossom activation.</p>
</section>
<section id="default-expiry-delta"><h4><span class="section-heading">Default expiry delta</span><span class="section-anchor"> <a rel="bookmark" href="#default-expiry-delta"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>When not overridden by the <cite>-txexpirydelta</cite> option, <cite>zcashd</cite> RPC calls that create transactions use a default value for the number of blocks after which a transaction will expire. The default in recent versions of <cite>zcashd</cite> is 20 blocks, which at the pre-Blossom block target spacing corresponds to roughly 50 minutes.</p>
<p>When not overridden by the <code>-txexpirydelta</code> option, <cite>zcashd</cite> RPC calls that create transactions use a default value for the number of blocks after which a transaction will expire. The default in recent versions of <cite>zcashd</cite> is 20 blocks, which at the pre-Blossom block target spacing corresponds to roughly 50 minutes.</p>
<p>This default SHOULD change to BlossomPoWTargetSpacingRatio · 20 blocks after Blossom activation, to maintain the approximate expiry time of 50 minutes.</p>
<p>If the <cite>-txexpirydelta</cite> option is set, then the set value SHOULD be used both before and after Blossom activation.</p>
<p>If the <code>-txexpirydelta</code> option is set, then the set value SHOULD be used both before and after Blossom activation.</p>
</section>
<section id="sprout-to-sapling-migration"><h4><span class="section-heading">Sprout to Sapling migration</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-to-sapling-migration"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>ZIP 308 <a id="id13" class="footnote_reference" href="#zip-0308">7</a> defines a procedure for migrating funds from Sprout to Sapling z-addresses. In that procedure, migration transactions are sent every 500 blocks, which corresponded to roughly 20.83 hours before Blossom.</p>
<p>ZIP 308 <a id="id11" class="footnote_reference" href="#zip-0308">10</a> defines a procedure for migrating funds from Sprout to Sapling z-addresses. In that procedure, migration transactions are sent every 500 blocks, which corresponded to roughly 20.83 hours before Blossom.</p>
<p>The 500-block constant has not been changed. Therefore, migration transactions are now sent roughly every 10.42 hours after Blossom activation. This has been noted in the ZIP, and a table showing the expected time to complete migration has been updated accordingly.</p>
</section>
<section id="fingerprinting-mitigation"><h4><span class="section-heading">Fingerprinting mitigation</span><span class="section-anchor"> <a rel="bookmark" href="#fingerprinting-mitigation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A "fingerprinting attack" is a network analysis technique in which nodes are identified across network sessions, for example using information about which blocks they request or send.</p>
<p><code>zcashd</code> inherits from Bitcoin Core the following behaviour, described in a comment in <code>main.cpp</code>, intended as a fingerprinting mitigation:</p>
<p><cite>zcashd</cite> inherits from Bitcoin Core the following behaviour, described in a comment in <code>main.cpp</code>, intended as a fingerprinting mitigation:</p>
<pre>// To prevent fingerprinting attacks, only send blocks outside of the active
// 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 <a id="id14" class="footnote_reference" href="#latest-protocol">1</a> section 7.6.5, divide by the work of the block at the active tip, and multiply by the target block spacing of that block.</p>
<p>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.6.5 of the Zcash Protocol Specification <a id="id12" class="footnote_reference" href="#protocol-workdef">6</a>, divide by the work of the block at the active tip, and multiply by the target block spacing of that block.</p>
<p>It is not a requirement of the Zcash protocol that this fingerprinting mitigation is used; however, if it is used, then it SHOULD use the target block spacing at the same block height that is used for the current work estimate.</p>
</section>
<section id="monitoring-for-quicker-or-slower-than-expected-blocks"><h4><span class="section-heading">Monitoring for quicker- or slower-than-expected blocks</span><span class="section-anchor"> <a rel="bookmark" href="#monitoring-for-quicker-or-slower-than-expected-blocks"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
@ -145,7 +145,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<p>The timeout for a requested block is calculated as the target block time, multiplied by 2 + (the number of queued validated headers)/2.</p>
</section>
<section id="latency-optimization-when-requesting-blocks"><h4><span class="section-heading">Latency optimization when requesting blocks</span><span class="section-anchor"> <a rel="bookmark" href="#latency-optimization-when-requesting-blocks"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>When <code>zcashd</code> sees an announced block that chains from headers that it does not already have, it will first ask for the headers, and then the block itself. A latency optimization is performed only if the chain is "nearly synced":</p>
<p>When <cite>zcashd</cite> sees an announced block that chains from headers that it does not already have, it will first ask for the headers, and then the block itself. A latency optimization is performed only if the chain is "nearly synced":</p>
<pre>// First request the headers preceding the announced block. In the normal fully-synced
// case where a new block is announced that succeeds the current tip (no reorganization),
// there are no such headers.
@ -154,16 +154,16 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
// time the block arrives, the header chain leading up to it is already validated. Not
// doing this will result in the received block being rejected as an orphan in case it is
// not a direct successor.</pre>
<p>The heuristic for "nearly synced" is that the timestamp of the block at the active tip is no more than 20 block times before the current "adjusted time". In <code>zcashd</code> this calculation uses the block target spacing as of the best known header. Around Blossom activation when the block target spacing changes, this could cause the heuristic to be based on the pre-Blossom block target spacing until the node has synced headers past the activation block, but this is not anticipated to cause any problem.</p>
<p>The heuristic for "nearly synced" is that the timestamp of the block at the active tip is no more than 20 block times before the current "adjusted time". In <cite>zcashd</cite> this calculation uses the block target spacing as of the best known header. Around Blossom activation when the block target spacing changes, this could cause the heuristic to be based on the pre-Blossom block target spacing until the node has synced headers past the activation block, but this is not anticipated to cause any problem.</p>
</section>
<section id="response-to-getblocks-message-when-pruning"><h4><span class="section-heading">Response to getblocks message when pruning</span><span class="section-anchor"> <a rel="bookmark" href="#response-to-getblocks-message-when-pruning"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>If pruning is enabled, when <code>zcashd</code> responds to an "getblocks" peer-to-peer message, it will only include blocks that it has on disk, and is likely to still have on disk an hour after responding to the message:</p>
<p>If pruning is enabled, when <cite>zcashd</cite> responds to an "getblocks" peer-to-peer message, it will only include blocks that it has on disk, and is likely to still have on disk an hour after responding to the message:</p>
<pre>// If pruning, don't inv blocks unless we have on disk and are likely to still have
// for some reasonable time window (1 hour) that block relay might require.</pre>
<p>For each block, when estimating whether it will still be on disk after an hour, we take MIN_BLOCKS_TO_KEEP = 288 blocks, minus approximately the number of blocks expected in one hour at the target block spacing as of that block. Around Blossom activation, this might underestimate the number of blocks in the next hour, but given the value of MIN_BLOCKS_TO_KEEP, this is not anticipated to cause any problem.</p>
</section>
<section id="estimation-of-fully-synced-chain-height"><h4><span class="section-heading">Estimation of fully synced chain height</span><span class="section-anchor"> <a rel="bookmark" href="#estimation-of-fully-synced-chain-height"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p><code>zcashd</code> uses the <code>EstimateNetHeight</code> function to estimate the approximate height of the fully synced chain, so that the progress of block download can be displayed to the node operator. This function has been rewritten, simplified, and changed to take account of cases where the time period that needs to be estimated crosses Blossom activation.</p>
<p><cite>zcashd</cite> uses the <code>EstimateNetHeight</code> function to estimate the approximate height of the fully synced chain, so that the progress of block download can be displayed to the node operator. This function has been rewritten, simplified, and changed to take account of cases where the time period that needs to be estimated crosses Blossom activation.</p>
</section>
<section id="other-block-related-constants"><h4><span class="section-heading">Other block-related constants</span><span class="section-anchor"> <a rel="bookmark" href="#other-block-related-constants"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The following constants, measured in number of blocks, were reviewed and a decision was made not to change them:</p>
@ -192,7 +192,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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal will be deployed with the Blossom network upgrade. <a id="id15" class="footnote_reference" href="#zip-0206">6</a></p>
<p>This proposal will be deployed with the Blossom network upgrade. <a id="id13" class="footnote_reference" href="#zip-0206">9</a></p>
</section>
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<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>
@ -201,11 +201,11 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<p><a href="https://github.com/zcash/zcash/pull/4025">https://github.com/zcash/zcash/pull/4025</a></p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="latest-protocol" class="footnote">
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="protocol/blossom.pdf">Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom]</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -213,22 +213,46 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="https://github.com/zcash/zips/blob/9515d73aac0aea3494f77bcd634e1e4fbd744b97/protocol/protocol.pdf">Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) [Overwinter+Sapling]</a></td>
<td><a href="https://github.com/zcash/zips/blob/9515d73aac0aea3494f77bcd634e1e4fbd744b97/protocol/protocol.pdf">Zcash Protocol Specification, Version 2018.0-beta-37 (exactly)</a></td>
</tr>
</tbody>
</table>
<table id="rfc2119" class="footnote">
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-constants" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants</a></td>
</tr>
</tbody>
</table>
<table id="protocol-diffadjustment" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#diffadjustment">Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment</a></td>
</tr>
</tbody>
</table>
<table id="protocol-workdef" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/protocol.pdf#workdef">Zcash Protocol Specification, Version 2020.1.15. Section 7.6.5: Definition of Work</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>4</th>
<th>7</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
@ -236,7 +260,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-0205" class="footnote">
<tbody>
<tr>
<th>5</th>
<th>8</th>
<td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td>
</tr>
</tbody>
@ -244,7 +268,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-0206" class="footnote">
<tbody>
<tr>
<th>6</th>
<th>9</th>
<td><a href="zip-0206">ZIP 206: Deployment of the Blossom Network Upgrade</a></td>
</tr>
</tbody>
@ -252,7 +276,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-0308" class="footnote">
<tbody>
<tr>
<th>7</th>
<th>10</th>
<td><a href="zip-0308">ZIP 308: Sprout to Sapling Migration</a></td>
</tr>
</tbody>
@ -260,7 +284,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="slowfastblocks" class="footnote">
<tbody>
<tr>
<th>8</th>
<th>11</th>
<td><a href="https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/">On Slow and Fast Block Times</a></td>
</tr>
</tbody>

44
zip-0208.rst
View File

@ -24,7 +24,8 @@ The terms "block chain", "consensus rule change", "consensus branch", and
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 [#latest-protocol]_.)
but "block target spacing" is the term used in the Zcash Protocol Specification
[#protocol-diffadjustment]_.)
Abstract
@ -61,8 +62,8 @@ See [#slowfastblocks]_ for further analysis in various attack models.
Specification
=============
The changes described in this section are to be made in [#latest-protocol]_,
relative to the pre-Blossom specification in [#preblossom-protocol].
The changes described in this section are to be made in the Zcash Protocol Specification
[#protocol]_, relative to the pre-Blossom specification in [#preblossom-protocol].
Consensus changes
-----------------
@ -108,8 +109,8 @@ ActualTimespanDamped, ActualTimespanBounded, and Threshold as follows:
- ensure that each reference to any of these values, or to PoWTargetSpacing,
are replaced with a function call passing the *height* parameter.
In [#latest-protocol]_ section 7.7 (Calculation of Block Subsidy and Founders’
Reward), redefine the Halving and BlockSubsidy functions as follows:
In section 7.7 (Calculation of Block Subsidy and Founders’ Reward), redefine the
Halving and BlockSubsidy functions as follows:
- Halving(*height*) :=
@ -130,7 +131,7 @@ Note: BlossomActivationHeight, PostBlossomHalvingInterval, and PostBlossomTarget
- MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(*height*)`\ )
is an integer for the next few periods.
In [#latest-protocol]_ section 7.8 (Payment of Founders’ Reward), define:
In section 7.8 (Payment of Founders’ Reward), define:
- FounderAddressAdjustedHeight(*height*) :=
@ -186,7 +187,8 @@ threshold to be proportional to the block target spacing.
That is, if the block time of a block at height *height* ≥ 299188 is at least
6 · PoWTargetSpacing(*height*) seconds after that of the preceding block,
then the block is a minimum-difficulty block, and its target threshold is set
to the value of PoWLimit for testnet (see [#latest-protocol]_ section 5.3).
to the value of PoWLimit for testnet (see section 5.3 of the Zcash Protocol
Specification [#protocol-constants]_).
As before, the ``nBits`` field of a minimum-difficulty block is still computed
according to the original difficulty adjustment algorithm, and only this field
@ -209,7 +211,7 @@ follow Blossom activation.
Default expiry delta
''''''''''''''''''''
When not overridden by the `-txexpirydelta` option, `zcashd` RPC calls that
When not overridden by the ``-txexpirydelta`` option, `zcashd` RPC calls that
create transactions use a default value for the number of blocks after which a
transaction will expire. The default in recent versions of `zcashd` is
20 blocks, which at the pre-Blossom block target spacing corresponds to roughly
@ -218,7 +220,7 @@ transaction will expire. The default in recent versions of `zcashd` is
This default SHOULD change to BlossomPoWTargetSpacingRatio · 20 blocks after
Blossom activation, to maintain the approximate expiry time of 50 minutes.
If the `-txexpirydelta` option is set, then the set value SHOULD be used both
If the ``-txexpirydelta`` option is set, then the set value SHOULD be used both
before and after Blossom activation.
@ -242,7 +244,7 @@ A "fingerprinting attack" is a network analysis technique in which nodes are
identified across network sessions, for example using information about which
blocks they request or send.
``zcashd`` inherits from Bitcoin Core the following behaviour, described in a
`zcashd` inherits from Bitcoin Core the following behaviour, described in a
comment in ``main.cpp``, intended as a fingerprinting mitigation::
// To prevent fingerprinting attacks, only send blocks outside of the active
@ -255,8 +257,9 @@ effectiveness of this mitigation.
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 [#latest-protocol]_ section 7.6.5, divide by the work of the
block at the active tip, and multiply by the target block spacing of that block.
defined in section 7.6.5 of the Zcash Protocol Specification [#protocol-workdef]_,
divide by the work of the block at the active tip, and multiply by the target
block spacing of that block.
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
@ -281,7 +284,7 @@ multiplied by 2 + (the number of queued validated headers)/2.
Latency optimization when requesting blocks
'''''''''''''''''''''''''''''''''''''''''''
When ``zcashd`` sees an announced block that chains from headers that it does
When `zcashd` sees an announced block that chains from headers that it does
not already have, it will first ask for the headers, and then the block itself.
A latency optimization is performed only if the chain is "nearly synced"::
@ -295,7 +298,7 @@ A latency optimization is performed only if the chain is "nearly synced"::
// not a direct successor.
The heuristic for "nearly synced" is that the timestamp of the block at the active tip
is no more than 20 block times before the current "adjusted time". In ``zcashd`` this
is no more than 20 block times before the current "adjusted time". In `zcashd` this
calculation uses the block target spacing as of the best known header. Around Blossom
activation when the block target spacing changes, this could cause the heuristic to be
based on the pre-Blossom block target spacing until the node has synced headers past the
@ -305,7 +308,7 @@ activation block, but this is not anticipated to cause any problem.
Response to getblocks message when pruning
''''''''''''''''''''''''''''''''''''''''''
If pruning is enabled, when ``zcashd`` responds to an "getblocks" peer-to-peer message,
If pruning is enabled, when `zcashd` responds to an "getblocks" peer-to-peer message,
it will only include blocks that it has on disk, and is likely to still have on disk
an hour after responding to the message::
@ -322,7 +325,7 @@ of MIN_BLOCKS_TO_KEEP, this is not anticipated to cause any problem.
Estimation of fully synced chain height
'''''''''''''''''''''''''''''''''''''''
``zcashd`` uses the ``EstimateNetHeight`` function to estimate the approximate height
`zcashd` uses the ``EstimateNetHeight`` function to estimate the approximate height
of the fully synced chain, so that the progress of block download can be displayed to
the node operator. This function has been rewritten, simplified, and changed to take
account of cases where the time period that needs to be estimated crosses Blossom
@ -383,9 +386,12 @@ https://github.com/zcash/zcash/pull/4025
References
==========
.. [#latest-protocol] `Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom] <protocol/blossom.pdf>`_
.. [#preblossom-protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) [Overwinter+Sapling] <https://github.com/zcash/zips/blob/9515d73aac0aea3494f77bcd634e1e4fbd744b97/protocol/protocol.pdf>`_
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#preblossom-protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) <https://github.com/zcash/zips/blob/9515d73aac0aea3494f77bcd634e1e4fbd744b97/protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment <protocol/protocol.pdf#diffadjustment>`_
.. [#protocol-workdef] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.5: Definition of Work <protocol/protocol.pdf#workdef>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <zip-0206.rst>`_

2
zip-0209.html
View File

@ -41,7 +41,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-0209.rst
View File

@ -76,6 +76,6 @@ This specification was deployed in zcashd v2.0.4 for Testnet, and in zcashd v2.0
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15 or later. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_

30
zip-0210.html
View File

@ -15,15 +15,15 @@ Created: 2019-03-27
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<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 term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">3</a>.</p>
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205 <a id="id3" class="footnote_reference" href="#zip-0205">4</a>.</p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a modification to the transaction format whereby a single Sapling anchor is used for all Sapling spends. This change removes a potential implementation fingerprint, and reduces the size of Sapling transactions within the block chain.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The Sapling network upgrade <a id="id4" class="footnote_reference" href="#zip-0205">3</a> introduced new shielded inputs (spends) and outputs. Each spend proves the existence of the note being spent by including the anchor of a Merkle tree that contains the note's commitment, and proving in zero knowledge the existence of a path from the commitment to the anchor (a witness). Valid anchors correspond to the state of the Sapling commitment tree after each block in the chain.</p>
<p>The choice of anchor leaks information about the note being spent, namely that the note was created no later than the anchor's block height. This is an unavoidable outcome of the Zcash design, and the least information it is possible to leak about a note being spent. However, the Sapling v4 transaction format <a id="id5" class="footnote_reference" href="#v4-tx">4</a> includes a separate anchor for each Sapling spend, and thus it is possible to leak additional information by using different anchors for different notes. The anchor selection choices could also be used as a fingerprint to identify transactions created by particular wallet implementations, reducing the privacy set.</p>
<p>The Sapling network upgrade <a id="id4" 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="id5" class="footnote_reference" href="#protocol-txnencodingandconsensus">2</a> includes a separate anchor for each Sapling spend, and thus it is possible to leak additional information by using different anchors for different notes. The anchor selection choices could also be used as a fingerprint to identify transactions created by particular wallet implementations, reducing the privacy set.</p>
<p>Modifying the transaction format to have a single Sapling anchor field, instead of one field per Sapling spend, removes the ability (within the new transaction format version) to create transactions with this fingerprint. It also reduces the size of the transaction, costing 32 bytes per transaction instead of 32 bytes per spend.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -51,31 +51,31 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnencodingandconsensus" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>2</th>
<th>3</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Activation Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0205" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="v4-tx" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf">Section 7.1: Encoding of Transactions. Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling]</a></td>
<td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td>
</tr>
</tbody>
</table>

15
zip-0210.rst
View File

@ -21,6 +21,7 @@ The term "network upgrade" in this document is to be interpreted as described in
The term "Sapling" in this document is to be interpreted as described in ZIP 205
[#zip-0205]_.
Abstract
========
@ -41,11 +42,11 @@ correspond to the state of the Sapling commitment tree after each block in the c
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 [#v4-tx]_ 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.
However, the Sapling v4 transaction format [#protocol-txnencodingandconsensus]_ 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.
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)
@ -104,7 +105,7 @@ TBD
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencodingandconsensus>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#v4-tx] `Section 7.1: Encoding of Transactions. Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling] <protocol/protocol.pdf>`_

2
zip-0211.html
View File

@ -66,7 +66,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-0211.rst
View File

@ -143,7 +143,7 @@ https://github.com/zcash/zcash/pull/4489
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#zip-0209] `ZIP 209: Prohibit Negative Shielded Value Pool <zip-0209.rst>`_

38
zip-0212.html
View File

@ -84,7 +84,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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The specification in this ZIP is intended to be aligned with version 2020.1.15 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol">2</a>. See the Change History of that document for relevant corrections.</p>
<p>Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#abstractprfs">4</a>. We will be adapting
<p>Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol-abstractprfs">4</a>. We will be adapting
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
for the purposes of this ZIP. This function is keyed by a 256-bit key
<span class="math">\(\mathsf{sk}\)</span>
@ -92,7 +92,7 @@ License: MIT</pre>
<span class="math">\(64\)</span>
-byte sequence as output.</p>
<section id="changes-to-sapling-note-plaintexts"><h3><span class="section-heading">Changes to Sapling Note plaintexts</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-sapling-note-plaintexts"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#notept">5</a>. Currently, the encoding of a Sapling note plaintext requires that the first byte take the form
<p>Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol-notept">5</a>. Currently, the encoding of a Sapling note plaintext requires that the first byte take the form
<span class="math">\(\textbf{0x01}\)</span>
, indicating the version of the note plaintext. In addition, a
<span class="math">\(256\)</span>
@ -120,12 +120,12 @@ License: MIT</pre>
<span class="math">\(\mathsf{rseed}\)</span>
(previously,
<span class="math">\(\mathsf{rcm}\)</span>
) be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from the description of note plaintexts in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. <a id="id6" class="footnote_reference" href="#saplingdecryptivk">6</a> <a id="id7" class="footnote_reference" href="#saplingdecryptovk">7</a></p>
) be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from the description of note plaintexts in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. <a id="id6" class="footnote_reference" href="#protocol-saplingdecryptivk">6</a> <a id="id7" class="footnote_reference" href="#protocol-saplingdecryptovk">7</a></p>
</section>
<section id="changes-to-the-process-of-sending-sapling-notes"><h3><span class="section-heading">Changes to the process of sending Sapling notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-sending-sapling-notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The process of sending notes in Sapling is described in section 4.6.2 of the Zcash Protocol Specification <a id="id8" class="footnote_reference" href="#saplingsend">8</a>. During this process, the sender samples
<p>The process of sending notes in Sapling is described in section 4.6.2 of the Zcash Protocol Specification <a id="id8" class="footnote_reference" href="#protocol-saplingsend">8</a>. During this process, the sender samples
<span class="math">\(\mathsf{rcm^{new}}\)</span>
uniformly at random. In addition, the process of encrypting a note is described in section 4.17.1 of the Zcash Protocol Specification <a id="id9" class="footnote_reference" href="#saplingencrypt">3</a>. During this process, the sender also samples the ephemeral private key
uniformly at random. In addition, the process of encrypting a note is described in section 4.17.1 of the Zcash Protocol Specification <a id="id9" class="footnote_reference" href="#protocol-saplingencrypt">3</a>. During this process, the sender also samples the ephemeral private key
<span class="math">\(\mathsf{esk}\)</span>
uniformly at random.</p>
<p>After the activation of this ZIP, the sender MUST instead sample a uniformly random
@ -149,7 +149,7 @@ License: MIT</pre>
.</p>
</section>
<section id="changes-to-the-process-of-receiving-sapling-notes"><h3><span class="section-heading">Changes to the process of receiving Sapling notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-receiving-sapling-notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The process of receiving notes in Sapling is described in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. <a id="id10" class="footnote_reference" href="#saplingdecryptivk">6</a> <a id="id11" class="footnote_reference" href="#saplingdecryptovk">7</a></p>
<p>The process of receiving notes in Sapling is described in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. <a id="id10" class="footnote_reference" href="#protocol-saplingdecryptivk">6</a> <a id="id11" class="footnote_reference" href="#protocol-saplingdecryptovk">7</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 0x01 MUST still be accepted.</p>
<p>Let ActivationHeight be the activation height of this ZIP, and let GracePeriodEndHeight be ActivationHeight + 32256.</p>
<p>The height of a transaction in a mined block is defined as the height of that block. An implementation MAY also decrypt mempool transactions, in which case the height used is the height of the next block at the time of the check. An implementation SHOULD NOT attempt to decrypt mempool transactions without having obtained a best-effort view of the current block chain height.</p>
@ -228,7 +228,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -240,51 +240,51 @@ License: MIT</pre>
</tr>
</tbody>
</table>
<table id="saplingencrypt" class="footnote">
<table id="protocol-saplingencrypt" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingencrypt">Section 4.17.1: Encryption (Sapling). Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingencrypt">Zcash Protocol Specification, Version 2020.1.15. Section 4.17.1: Encryption (Sapling)</a></td>
</tr>
</tbody>
</table>
<table id="abstractprfs" class="footnote">
<table id="protocol-abstractprfs" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#abstractprfs">Section 4.1.2: Pseudo Random Functions. Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#abstractprfs">Zcash Protocol Specification, Version 2020.1.15. Section 4.1.2: Pseudo Random Functions</a></td>
</tr>
</tbody>
</table>
<table id="notept" class="footnote">
<table id="protocol-notept" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#notept">Section 5.5: Encodings of Note Plaintexts and Memo Fields. Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#notept">Zcash Protocol Specification, Version 2020.1.15. Section 5.5: Encodings of Note Plaintexts and Memo Fields</a></td>
</tr>
</tbody>
</table>
<table id="saplingdecryptivk" class="footnote">
<table id="protocol-saplingdecryptivk" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingdecryptivk">Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingdecryptivk">Zcash Protocol Specification, Version 2020.1.15. Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling)</a></td>
</tr>
</tbody>
</table>
<table id="saplingdecryptovk" class="footnote">
<table id="protocol-saplingdecryptovk" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingdecryptovk">Section 4.17.3: Decryption using a Full Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingdecryptovk">Zcash Protocol Specification, Version 2020.1.15. Section 4.17.3: Decryption using a Full Viewing Key (Sapling)</a></td>
</tr>
</tbody>
</table>
<table id="saplingsend" class="footnote">
<table id="protocol-saplingsend" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingsend">Section 4.6.2: Sending Notes (Sapling). Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingsend">Zcash Protocol Specification, Version 2020.1.15. Section 4.6.2: Sending Notes (Sapling)</a></td>
</tr>
</tbody>
</table>

33
zip-0212.rst
View File

@ -96,7 +96,7 @@ of the Zcash Protocol Specification [#protocol]_. See the Change History of
that document for relevant corrections.
Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash
Protocol Specification [#abstractprfs]_. We will be adapting
Protocol Specification [#protocol-abstractprfs]_. We will be adapting
:math:`\mathsf{PRF^{expand}}` for the purposes of this ZIP. This function is
keyed by a 256-bit key :math:`\mathsf{sk}` and takes an arbitrary length byte
sequence as input, returning a :math:`64`-byte sequence as output.
@ -105,7 +105,7 @@ Changes to Sapling Note plaintexts
----------------------------------
Note plaintext encodings are specified in section 5.5 of the Zcash Protocol
Specification [#notept]_. Currently, the encoding of a Sapling note plaintext
Specification [#protocol-notept]_. Currently, the encoding of a Sapling note plaintext
requires that the first byte take the form :math:`\textbf{0x01}`, indicating
the version of the note plaintext. In addition, a :math:`256`-bit
:math:`\mathsf{rcm}` field exists within the note plaintext and encoding.
@ -123,17 +123,18 @@ the following new note plaintext format:
The requirement that :math:`\mathsf{rseed}` (previously, :math:`\mathsf{rcm}`)
be a scalar of the Jubjub elliptic curve, when interpreted as a little endian
integer, is removed from the description of note plaintexts in sections 4.17.2
and 4.17.3 of the Zcash Protocol Specification. [#saplingdecryptivk]_ [#saplingdecryptovk]_
and 4.17.3 of the Zcash Protocol Specification. [#protocol-saplingdecryptivk]_
[#protocol-saplingdecryptovk]_
Changes to the process of sending Sapling notes
-----------------------------------------------
The process of sending notes in Sapling is described in section 4.6.2 of the
Zcash Protocol Specification [#saplingsend]_. During this process, the sender
samples :math:`\mathsf{rcm^{new}}` uniformly at random. In addition, the
Zcash Protocol Specification [#protocol-saplingsend]_. During this process, the
sender samples :math:`\mathsf{rcm^{new}}` uniformly at random. In addition, the
process of encrypting a note is described in section 4.17.1 of the Zcash Protocol
Specification [#saplingencrypt]_. During this process, the sender also samples
the ephemeral private key :math:`\mathsf{esk}` uniformly at random.
Specification [#protocol-saplingencrypt]_. During this process, the sender also
samples the ephemeral private key :math:`\mathsf{esk}` uniformly at random.
After the activation of this ZIP, the sender MUST instead sample a uniformly
random :math:`32`-byte sequence :math:`\mathsf{rseed}`. The note plaintext takes
@ -149,8 +150,8 @@ Changes to the process of receiving Sapling notes
-------------------------------------------------
The process of receiving notes in Sapling is described in sections 4.17.2 and
4.17.3 of the Zcash Protocol Specification. [#saplingdecryptivk]_
[#saplingdecryptovk]_
4.17.3 of the Zcash Protocol Specification. [#protocol-saplingdecryptivk]_
[#protocol-saplingdecryptovk]_
There is a "grace period" of 32256 blocks starting from the block at which this
ZIP activates, during which note plaintexts with lead byte 0x01 MUST still be
@ -286,14 +287,14 @@ knowledge assumption was made by Sean Bowe and Zooko Wilcox.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <https://zips.z.cash/protocol/protocol.pdf>`_
.. [#saplingencrypt] `Section 4.17.1: Encryption (Sapling). Zcash Protocol Specification, Version 2020.1.15 or later <https://zips.z.cash/protocol/protocol.pdf#saplingencrypt>`_
.. [#abstractprfs] `Section 4.1.2: Pseudo Random Functions. Zcash Protocol Specification, Version 2020.1.15 or later <https://zips.z.cash/protocol/protocol.pdf#abstractprfs>`_
.. [#notept] `Section 5.5: Encodings of Note Plaintexts and Memo Fields. Zcash Protocol Specification, Version 2020.1.15 or later <https://zips.z.cash/protocol/protocol.pdf#notept>`_
.. [#saplingdecryptivk] `Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.15 or later <https://zips.z.cash/protocol/protocol.pdf#saplingdecryptivk>`_
.. [#saplingdecryptovk] `Section 4.17.3: Decryption using a Full Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.15 or later <https://zips.z.cash/protocol/protocol.pdf#saplingdecryptovk>`_
.. [#saplingsend] `Section 4.6.2: Sending Notes (Sapling). Zcash Protocol Specification, Version 2020.1.15 or later <https://zips.z.cash/protocol/protocol.pdf#saplingsend>`_
.. [#protocol-saplingencrypt] `Zcash Protocol Specification, Version 2020.1.15. Section 4.17.1: Encryption (Sapling) <https://zips.z.cash/protocol/protocol.pdf#saplingencrypt>`_
.. [#protocol-abstractprfs] `Zcash Protocol Specification, Version 2020.1.15. Section 4.1.2: Pseudo Random Functions <https://zips.z.cash/protocol/protocol.pdf#abstractprfs>`_
.. [#protocol-notept] `Zcash Protocol Specification, Version 2020.1.15. Section 5.5: Encodings of Note Plaintexts and Memo Fields <https://zips.z.cash/protocol/protocol.pdf#notept>`_
.. [#protocol-saplingdecryptivk] `Zcash Protocol Specification, Version 2020.1.15. Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling) <https://zips.z.cash/protocol/protocol.pdf#saplingdecryptivk>`_
.. [#protocol-saplingdecryptovk] `Zcash Protocol Specification, Version 2020.1.15. Section 4.17.3: Decryption using a Full Viewing Key (Sapling) <https://zips.z.cash/protocol/protocol.pdf#saplingdecryptovk>`_
.. [#protocol-saplingsend] `Zcash Protocol Specification, Version 2020.1.15. Section 4.6.2: Sending Notes (Sapling) <https://zips.z.cash/protocol/protocol.pdf#saplingsend>`_
.. [#zip-0207] `ZIP 207: Split Founders' Reward <zip-0207.rst>`_
.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_

2
zip-0213.html
View File

@ -76,7 +76,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-0213.rst
View File

@ -189,7 +189,7 @@ https://github.com/zcash/zcash/pull/4256
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#zip-0207] `ZIP 207: Split Founders' Reward <zip-0207.rst>`_

10
zip-0214.html
View File

@ -271,7 +271,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -279,7 +279,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.13 or later [Canopy]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>
@ -287,7 +287,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.13 [Canopy]. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
@ -295,7 +295,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#subsidyconcepts">Zcash Protocol Specification, Version 2020.1.13 [Canopy]. Section 3.9: Block Subsidy and Founders' Reward</a></td>
<td><a href="protocol/protocol.pdf#subsidyconcepts">Zcash Protocol Specification, Version 2020.1.15. Section 3.9: Block Subsidy and Founders' Reward</a></td>
</tr>
</tbody>
</table>
@ -303,7 +303,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#subsidies">Zcash Protocol Specification, Version 2020.1.13 [Canopy]. Section 7.7: Calculation of Block Subsidy and Founders' Reward</a></td>
<td><a href="protocol/protocol.pdf#subsidies">Zcash Protocol Specification, Version 2020.1.15. Section 7.7: Calculation of Block Subsidy and Founders' Reward</a></td>
</tr>
</tbody>
</table>

10
zip-0214.rst
View File

@ -336,11 +336,11 @@ This proposal is intended to be deployed with Canopy. [#zip-0251]_
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.13 or later [Canopy] <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.13 [Canopy]. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2020.1.13 [Canopy]. Section 3.9: Block Subsidy and Founders' Reward <protocol/protocol.pdf#subsidyconcepts>`_
.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2020.1.13 [Canopy]. Section 7.7: Calculation of Block Subsidy and Founders' Reward <protocol/protocol.pdf#subsidies>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2020.1.15. Section 3.9: Block Subsidy and Founders' Reward <protocol/protocol.pdf#subsidyconcepts>`_
.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2020.1.15. Section 7.7: Calculation of Block Subsidy and Founders' Reward <protocol/protocol.pdf#subsidies>`_
.. [#trademark] `Zcash Trademark Donation and License Agreement <https://www.zfnd.org/about/contracts/2019_ECC_ZFND_TM_agreement.pdf>`_
.. [#osd] `The Open Source Definition <https://opensource.org/osd>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_

8
zip-0215.html
View File

@ -84,7 +84,7 @@ License: BSD-2-Clause</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -92,7 +92,7 @@ License: BSD-2-Clause</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc8032.html">Edwards-Curve Digital Signature Algorithm (EdDSA)</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc8032.html">RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)</a></td>
</tr>
</tbody>
</table>
@ -108,7 +108,7 @@ License: BSD-2-Clause</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.13 [Canopy]. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
@ -116,7 +116,7 @@ License: BSD-2-Clause</pre>
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#concreteed25519">Zcash Protocol Specification, Version 2020.1.13 [Canopy]. Section 5.4.5: Ed25519</a></td>
<td><a href="protocol/protocol.pdf#concreteed25519">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.5: Ed25519</a></td>
</tr>
</tbody>
</table>

8
zip-0215.rst
View File

@ -111,9 +111,9 @@ which is scheduled to activate on Mainnet [#protocol-networks]_ at block height
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC8032] `Edwards-Curve Digital Signature Algorithm (EdDSA) <https://www.rfc-editor.org/rfc/rfc8032.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC8032] `RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA) <https://www.rfc-editor.org/rfc/rfc8032.html>`_
.. [#protocol-2020.1.1] `Zcash Protocol Specification, Version 2020.1.1 <https://github.com/zcash/zips/blob/v2020.1.1/protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.13 [Canopy]. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-concreteed25519] `Zcash Protocol Specification, Version 2020.1.13 [Canopy]. Section 5.4.5: Ed25519 <protocol/protocol.pdf#concreteed25519>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-concreteed25519] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.5: Ed25519 <protocol/protocol.pdf#concreteed25519>`_
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_

14
zip-0221.html
View File

@ -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="#block-work">3</a></dd>
. <a id="id8" class="footnote_reference" href="#protocol-workdef">3</a></dd>
<dt>Internal or root node</dt>
<dd>
<p>The sum of the <code>nSubTreeTotalWork</code> fields of both children.</p>
@ -510,7 +510,7 @@ License: MIT</pre>
</section>
<section id="block-header-semantics-and-consensus-rules"><h3><span class="section-heading">Block header semantics and consensus rules</span><span class="section-anchor"> <a rel="bookmark" href="#block-header-semantics-and-consensus-rules"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The <code>hashFinalSaplingRoot</code> block header field (which was named <code>hashReserved</code> prior to the Sapling network upgrade) is renamed to <code>hashLightClientRoot</code>, to reflect its usage by light clients.</p>
<p>Prior to activation of the network upgrade that deploys this ZIP, this existing consensus rule on block headers (adjusted for the renamed field) is enforced: <a id="id10" class="footnote_reference" href="#block-header">4</a></p>
<p>Prior to activation of the network upgrade that deploys this ZIP, this existing consensus rule on block headers (adjusted for the renamed field) is enforced: <a id="id10" class="footnote_reference" href="#protocol-blockheader">4</a></p>
<blockquote>
<p>[Sapling onward] <code>hashLightClientRoot</code> MUST be
<span class="math">\(\mathsf{LEBS2OSP}_{256}(\mathsf{rt})\)</span>
@ -614,7 +614,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -626,19 +626,19 @@ License: MIT</pre>
</tr>
</tbody>
</table>
<table id="block-work" class="footnote">
<table id="protocol-workdef" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#workdef">Section 7.6.5: Definition of Work. Zcash Protocol Specification, Version 2020.1.1 [Overwinter+Sapling+Blossom] or later</a></td>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#workdef">Zcash Protocol Specification, Version 2020.1.15. Section 7.6.5: Definition of Work</a></td>
</tr>
</tbody>
</table>
<table id="block-header" class="footnote">
<table id="protocol-blockheader" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#blockheader">Section 7.5: Block Header. Zcash Protocol Specification, Version 2020.1.1 [Overwinter+Sapling+Blossom] or later</a></td>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#blockheader">Zcash Protocol Specification, Version 2020.1.15. Section 7.5: Block Header</a></td>
</tr>
</tbody>
</table>

11
zip-0221.rst
View File

@ -284,7 +284,7 @@ Each MMR node is defined as follows:
Leaf node
The protocol-defined work of the block:
:math:`\mathsf{floor}(2^{256} / (\mathsf{ToTarget}(\mathsf{nBits}) + 1))`. [#block-work]_
:math:`\mathsf{floor}(2^{256} / (\mathsf{ToTarget}(\mathsf{nBits}) + 1))`. [#protocol-workdef]_
Internal or root node
The sum of the ``nSubTreeTotalWork`` fields of both children.
@ -528,7 +528,7 @@ the Sapling network upgrade) is renamed to ``hashLightClientRoot``, to reflect i
by light clients.
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: [#block-header]_
rule on block headers (adjusted for the renamed field) is enforced: [#protocol-blockheader]_
[Sapling onward] ``hashLightClientRoot`` MUST be :math:`\mathsf{LEBS2OSP}_{256}(\mathsf{rt})`
where :math:`\mathsf{rt}` is the root of the Sapling note commitment tree for the final
@ -759,10 +759,10 @@ Additional Reading
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#FlyClient] `FlyClient protocol <https://eprint.iacr.org/2019/226.pdf>`_
.. [#block-work] `Section 7.6.5: Definition of Work. Zcash Protocol Specification, Version 2020.1.1 [Overwinter+Sapling+Blossom] or later <https://zips.z.cash/protocol/protocol.pdf#workdef>`_
.. [#block-header] `Section 7.5: Block Header. Zcash Protocol Specification, Version 2020.1.1 [Overwinter+Sapling+Blossom] or later <https://zips.z.cash/protocol/protocol.pdf#blockheader>`_
.. [#protocol-workdef] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.5: Definition of Work <https://zips.z.cash/protocol/protocol.pdf#workdef>`_
.. [#protocol-blockheader] `Zcash Protocol Specification, Version 2020.1.15. Section 7.5: Block Header <https://zips.z.cash/protocol/protocol.pdf#blockheader>`_
.. [#zcashBlock] `Zcash block primitive <https://github.com/zcash/zcash/blob/master/src/primitives/block.h>`_
.. [#mimblewimble] `MimbleWimble Grin MMR implementation <https://github.com/mimblewimble/grin/blob/aedac483f5a116b91a8baf6acffd70e5f980b8cc/core/src/core/pmmr/pmmr.rs>`_
.. [#bip-0034] `BIP 34: Block v2, Height in Coinbase <https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki>`_
@ -770,4 +770,3 @@ References
.. [#zip-0250] `ZIP 250: Deployment of the Heartwood Network Upgrade <zip-0250.rst>`_
.. [#zip-0301] `ZIP 301: Zcash Stratum Protocol <https://github.com/zcash/zips/pull/78>`_
.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection <https://github.com/zcash/zips/pull/226>`_

6
zip-0222.html
View File

@ -290,7 +290,7 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
<tbody>
<tr>
<th>1</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -338,7 +338,7 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.11 [Overwinter+Sapling+Blossom+Heartwood]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>
@ -346,7 +346,7 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/protocol.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2020.1.14 [Overwinter+Sapling+Blossom+Heartwood+Canopy]</a></td>
<td><a href="protocol/protocol.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>

6
zip-0222.rst
View File

@ -314,13 +314,13 @@ at Zcon1 that led to the earlier draft version of this ZIP.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0244] `ZIP 244: Transaction Non-Malleability Support <https://github.com/zcash/zips/blob/master/zip-0244.rst>`_
.. [#zip-draft-bolt] `Draft ZIP: Add support for Blind Off-chain Lightweight Transactions (Bolt) protocol <https://github.com/zcash/zips/pull/216>`_
.. [#spec-notation] `Section 2: Notation. Zcash Protocol Specification, Version 2019.0.2 [Overwinter+Sapling] <protocol/protocol.pdf>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <https://github.com/zcash/zips/blob/master/zip-0032.rst>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.11 [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf>`_
.. [#protocol_consensus] `Zcash Protocol Specification, Version 2020.1.14 [Overwinter+Sapling+Blossom+Heartwood+Canopy] <protocol/protocol.pdf#txnencodingandconsensus>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol_consensus] `Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencodingandconsensus>`_
.. [#librustzcash_zip222] `Rust language reference implementation of TZE API <https://github.com/zcash/librustzcash/pull/286>`_
.. [#zcashd_zip222] `zcashd reference implementation of consensus rule changes <https://github.com/zcash/zcash/pull/4480>`_

4
zip-0243.html
View File

@ -447,7 +447,7 @@ vJoinSplit: 00</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -455,7 +455,7 @@ vJoinSplit: 00</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification [Overwinter+Sapling]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>

4
zip-0243.rst
View File

@ -526,8 +526,8 @@ https://github.com/zcash/zcash/pull/3233
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification [Overwinter+Sapling] <protocol/protocol.pdf>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#BLAKE2-personalization] `"BLAKE2: simpler, smaller, fast as MD5", Section 2.8 <https://blake2.net/blake2.pdf>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_

4
zip-0250.html
View File

@ -78,7 +78,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -86,7 +86,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.1 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>

4
zip-0250.rst
View File

@ -127,8 +127,8 @@ be implemented in ``zcashd`` version 3.0.0, which will advertise protocol versio
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.1 or later <protocol/protocol.pdf>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_

12
zip-0251.html
View File

@ -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" 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="id15" class="footnote_reference" href="#protocol-txnencodingandconsensus">4</a>; and use the same transaction digest algorithm as defined in <a id="id16" class="footnote_reference" href="#zip-0243">12</a>. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. <a id="id17" class="footnote_reference" href="#zip-0243">12</a></p>
</section>
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<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>
@ -75,7 +75,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -83,7 +83,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/canopy.pdf">Zcash Protocol Specification, Version 2020.1.9 or later [Canopy]</a></td>
<td><a href="protocol/canopy.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>
@ -91,15 +91,15 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/canopy.pdf#networks">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/canopy.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnencoding" class="footnote">
<table id="protocol-txnencodingandconsensus" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/canopy.pdf#txnencoding">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.1: Encoding of Transactions</a></td>
<td><a href="protocol/canopy.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>

10
zip-0251.rst
View File

@ -110,7 +110,7 @@ will always disconnect peers using lower protocol versions.
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 [#protocol-txnencoding]_; and use the same transaction digest
as defined in [#protocol-txnencodingandconsensus]_; and use the same transaction digest
algorithm as defined in [#zip-0243]_. This does not imply that transactions are
valid across the Canopy activation, since signatures MUST use the appropriate
consensus branch ID. [#zip-0243]_
@ -127,10 +127,10 @@ in ``zcashd`` version 4.0.0, which will advertise protocol version 170013.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.9 or later [Canopy] <protocol/canopy.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet <protocol/canopy.pdf#networks>`_
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.1: Encoding of Transactions <protocol/canopy.pdf#txnencoding>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/canopy.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet <protocol/canopy.pdf#networks>`_
.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus <protocol/canopy.pdf#txnencodingandconsensus>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0207] `ZIP 207: Funding Streams <zip-0207.rst>`_

6
zip-0301.html
View File

@ -346,7 +346,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -354,7 +354,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#blockheader">Section 7.3: Block Headers. Zcash Protocol Specification, Version 2020.1.6</a></td>
<td><a href="protocol/protocol.pdf#blockheader">Zcash Protocol Specification, Version 2020.1.15. Section 7.3: Block Headers</a></td>
</tr>
</tbody>
</table>
@ -362,7 +362,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#difficulty">Section 7.6.2: Difficulty filter. Zcash Protocol Specification, Version 2020.1.6</a></td>
<td><a href="protocol/protocol.pdf#difficulty">Zcash Protocol Specification, Version 2020.1.15. Section 7.6.2: Difficulty filter</a></td>
</tr>
</tbody>
</table>

6
zip-0301.rst
View File

@ -488,9 +488,9 @@ Thanks to:
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-blockheader] `Section 7.3: Block Headers. Zcash Protocol Specification, Version 2020.1.6 <protocol/protocol.pdf#blockheader>`_
.. [#protocol-difficulty] `Section 7.6.2: Difficulty filter. Zcash Protocol Specification, Version 2020.1.6 <protocol/protocol.pdf#difficulty>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-blockheader] `Zcash Protocol Specification, Version 2020.1.15. Section 7.3: Block Headers <protocol/protocol.pdf#blockheader>`_
.. [#protocol-difficulty] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.2: Difficulty filter <protocol/protocol.pdf#difficulty>`_
.. [#Slushpool-Stratum] `Stratum Mining Protocol. Slush Pool <https://slushpool.com/help/stratum-protocol/>`_
.. [#Bitcointalk-Stratum] `Stratum protocol documentation. Bitcoin Forum <https://bitcointalk.org/index.php?topic=557866.0>`_
.. [#P2Pool] `P2Pool. Bitcoin Wiki <https://en.bitcoin.it/wiki/P2Pool>`_

110
zip-0304.html
View File

@ -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" 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-spec">3</a></p>
<p>The following constants and functions used in this ZIP are defined in the Zcash protocol specification: <a id="id2" class="footnote_reference" href="#protocol">3</a></p>
<ul>
<li>
<span class="math">\(\mathsf{MerkleDepth}^\mathsf{Sapling}\)</span>
and
<span class="math">\(\mathsf{Uncommitted}^\mathsf{Sapling}\)</span>
<a id="id3" class="footnote_reference" href="#constants">4</a></li>
<a id="id3" 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="#merkle-crh">5</a></li>
<a id="id4" 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="#diversify-hash">6</a></li>
<a id="id5" 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="#mixing-pedersen-hash">7</a></li>
<a id="id6" 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="#prfs">8</a></li>
<a id="id7" 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="#spend-auth-sig">9</a></li>
<a id="id8" 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="#note-commit">10</a></li>
<a id="id9" 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="#value-commit">11</a></li>
<a id="id10" 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="#jubjub">12</a>.</li>
as a bit sequence, defined in <a id="id11" 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">13</a> coin type, and</li>
<li>The SLIP-44 <a id="id12" 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="#merkle-path">14</a></li>
. <a id="id13" 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="#spend-statement">15</a></li>
. <a id="id14" 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">13</a> coin type,</li>
<li>The SLIP-44 <a id="id15" 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="#merkle-path">14</a></li>
. <a id="id16" 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="#spend-statement">15</a> If verification fails, return false.</li>
. <a id="id17" class="footnote_reference" href="#protocol-spendstatement">5</a> If verification fails, return false.</li>
<li>Return true.</li>
</ul>
</section>
@ -314,7 +314,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<tbody>
<tr>
<th>1</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -322,111 +322,111 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc4648">The Base16, Base32, and Base64 Data Encodings</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc4648">RFC 4648: The Base16, Base32, and Base64 Data Encodings</a></td>
</tr>
</tbody>
</table>
<table id="protocol-spec" class="footnote">
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>
<table id="constants" class="footnote">
<table id="protocol-merklepath" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#merklepath">Section 5.3: Constants. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
<td><a href="protocol/protocol.pdf#merklepath">Zcash Protocol Specification, Version 2020.1.15. Section 4.8: Merkle path validity</a></td>
</tr>
</tbody>
</table>
<table id="merkle-crh" class="footnote">
<table id="protocol-spendstatement" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#saplingmerklecrh">Section 5.4.1.3: Merkle Tree Hash Function. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
<td><a href="protocol/protocol.pdf#spendstatement">Zcash Protocol Specification, Version 2020.1.15. Section 4.15.2: Spend Statement (Sapling)</a></td>
</tr>
</tbody>
</table>
<table id="diversify-hash" class="footnote">
<table id="protocol-constants" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/protocol.pdf#concretediversifyhash">Section 5.4.1.6: DiversifyHash Hash Function. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants</a></td>
</tr>
</tbody>
</table>
<table id="mixing-pedersen-hash" class="footnote">
<table id="protocol-saplingmerklecrh" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/protocol.pdf#concretemixinghash">Section 5.4.1.8: Mixing Pedersen Hash Function. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
<td><a href="protocol/protocol.pdf#saplingmerklecrh">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.3: Merkle Tree Hash Function</a></td>
</tr>
</tbody>
</table>
<table id="prfs" class="footnote">
<table id="protocol-concretediversifyhash" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/protocol.pdf#concreteprfs">Section 5.4.2: Pseudo Random Functions. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.6: DiversifyHash Hash Function</a></td>
</tr>
</tbody>
</table>
<table id="spend-auth-sig" class="footnote">
<table id="protocol-concretemixinghash" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="protocol/protocol.pdf#concretespendauthsig">Section 5.4.6.1: Spend Authorization Signature. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
<td><a href="protocol/protocol.pdf#concretemixinghash">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.8: Mixing Pedersen Hash Function</a></td>
</tr>
</tbody>
</table>
<table id="note-commit" class="footnote">
<table id="protocol-concreteprfs" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="protocol/protocol.pdf#concretewindowedcommit">Section 5.4.7.2: Windowed Pedersen commitments. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
<td><a href="protocol/protocol.pdf#concreteprfs">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.2: Pseudo Random Functions</a></td>
</tr>
</tbody>
</table>
<table id="value-commit" class="footnote">
<table id="protocol-concretespendauthsig" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="protocol/protocol.pdf#concretehomomorphiccommit">Section 5.4.7.3: Homomorphic Pedersen commitments. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
<td><a href="protocol/protocol.pdf#concretespendauthsig">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature</a></td>
</tr>
</tbody>
</table>
<table id="jubjub" class="footnote">
<table id="protocol-concretewindowedcommit" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="protocol/protocol.pdf#jubjub">Section 5.4.8.3: Jubjub. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
<td><a href="protocol/protocol.pdf#concretewindowedcommit">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.7.2: Windowed Pedersen commitments</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concretehomomorphiccommit" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="protocol/protocol.pdf#concretehomomorphiccommit">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.7.3: Homomorphic Pedersen commitments</a></td>
</tr>
</tbody>
</table>
<table id="protocol-jubjub" class="footnote">
<tbody>
<tr>
<th>14</th>
<td><a href="protocol/protocol.pdf#jubjub">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.8.3: Jubjub</a></td>
</tr>
</tbody>
</table>
<table id="slip-0044" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="https://github.com/satoshilabs/slips/blob/master/slip-0044.md">SLIP-0044 : Registered coin types for BIP-0044</a></td>
</tr>
</tbody>
</table>
<table id="merkle-path" class="footnote">
<tbody>
<tr>
<th>14</th>
<td><a href="protocol/protocol.pdf#merklepath">Section 4.8: Merkle path validity. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
</tr>
</tbody>
</table>
<table id="spend-statement" class="footnote">
<tbody>
<tr>
<th>15</th>
<td><a href="protocol/protocol.pdf#spendstatement">Section 4.15.2: Spend Statement (Sapling). Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
<td><a href="https://github.com/satoshilabs/slips/blob/master/slip-0044.md">SLIP-0044 : Registered coin types for BIP-0044</a></td>
</tr>
</tbody>
</table>

56
zip-0304.rst
View File

@ -65,27 +65,27 @@ Conventions
===========
The following constants and functions used in this ZIP are defined in the Zcash protocol
specification: [#protocol-spec]_
specification: [#protocol]_
- :math:`\mathsf{MerkleDepth}^\mathsf{Sapling}` and
:math:`\mathsf{Uncommitted}^\mathsf{Sapling}` [#constants]_
- :math:`\mathsf{MerkleCRH}^\mathsf{Sapling}` [#merkle-crh]_
- :math:`\mathsf{DiversifyHash}(\mathsf{d})` [#diversify-hash]_
- :math:`\mathsf{MixingPedersenHash}(\mathsf{cm}, position)` [#mixing-pedersen-hash]_
- :math:`\mathsf{PRF}^\mathsf{nfSapling}_\mathsf{nk}(ρ)` [#prfs]_
:math:`\mathsf{Uncommitted}^\mathsf{Sapling}` [#protocol-constants]_
- :math:`\mathsf{MerkleCRH}^\mathsf{Sapling}` [#protocol-saplingmerklecrh]_
- :math:`\mathsf{DiversifyHash}(\mathsf{d})` [#protocol-concretediversifyhash]_
- :math:`\mathsf{MixingPedersenHash}(\mathsf{cm}, position)` [#protocol-concretemixinghash]_
- :math:`\mathsf{PRF}^\mathsf{nfSapling}_\mathsf{nk}(ρ)` [#protocol-concreteprfs]_
- :math:`\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})`,
:math:`\mathsf{SpendAuthSig.RandomizePublic}(α, \mathsf{vk})`,
:math:`\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)`, and
:math:`\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)` [#spend-auth-sig]_
- :math:`\mathsf{NoteCommit}^\mathsf{Sapling}_\mathsf{rcm}(\mathsf{g_d}, \mathsf{pk_d}, value)` [#note-commit]_
- :math:`\mathsf{ValueCommit}_\mathsf{rcv}(value)` [#value-commit]_
:math:`\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)` [#protocol-concretespendauthsig]_
- :math:`\mathsf{NoteCommit}^\mathsf{Sapling}_\mathsf{rcm}(\mathsf{g_d}, \mathsf{pk_d}, value)` [#protocol-concretewindowedcommit]_
- :math:`\mathsf{ValueCommit}_\mathsf{rcv}(value)` [#protocol-concretehomomorphiccommit]_
We also reproduce some notation and functions here for convenience:
- :math:`a\,||\,b` means the concatenation of sequences :math:`a` then :math:`b`.
- :math:`\mathsf{repr}_\mathbb{J}(P)` is the representation of the Jubjub elliptic curve
point :math:`P` as a bit sequence, defined in [#jubjub]_.
point :math:`P` as a bit sequence, defined in [#protocol-jubjub]_.
- :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)` refers to unkeyed BLAKE2b-256 in
sequential mode, with an output digest length of 32 bytes, 16-byte personalization
@ -146,7 +146,7 @@ The signature is created as follows:
:math:`\mathsf{MerkleCRH}^\mathsf{Sapling}`, containing :math:`\mathsf{cm}` at position 0, and
:math:`\mathsf{Uncommitted}^\mathsf{Sapling}` at all other positions.
- Let :math:`path` be the Merkle path from position 0 to :math:`\mathsf{rt}`. [#merkle-path]_
- Let :math:`path` be the Merkle path from position 0 to :math:`\mathsf{rt}`. [#protocol-merklepath]_
- Let :math:`\mathsf{cv} = \mathsf{ValueCommit}_0(1)`.
@ -161,7 +161,7 @@ The signature is created as follows:
- Let :math:`zkproof` be the byte sequence representation of a Sapling spend proof with primary input
:math:`(\mathsf{rt}, \mathsf{cv}, \mathsf{nf}, \mathsf{rk})`
and auxiliary input :math:`(path, 0, \mathsf{g_d}, \mathsf{pk_d}, 1, 0, \mathsf{cm}, 0, α, \mathsf{ak}, \mathsf{nsk})`.
[#spend-statement]_
[#protocol-spendstatement]_
- Let :math:`\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{ask})`.
@ -200,14 +200,14 @@ The signature MUST be verified as follows:
:math:`\mathsf{MerkleCRH}^\mathsf{Sapling}`, containing :math:`\mathsf{cm}` at position 0, and
:math:`\mathsf{Uncommitted}^\mathsf{Sapling}` at all other positions.
- Let :math:`path` be the Merkle path from position 0 to :math:`\mathsf{rt}`. [#merkle-path]_
- Let :math:`path` be the Merkle path from position 0 to :math:`\mathsf{rt}`. [#protocol-merklepath]_
- Let :math:`\mathsf{cv} = \mathsf{ValueCommit}_0(1)`.
- This is a constant and may be pre-computed.
- Decode and verify :math:`zkproof` as a Sapling spend proof with primary input
:math:`(\mathsf{rt}, \mathsf{cv}, \mathsf{nf}, \mathsf{rk})`. [#spend-statement]_ If verification fails, return false.
:math:`(\mathsf{rt}, \mathsf{cv}, \mathsf{nf}, \mathsf{rk})`. [#protocol-spendstatement]_ If verification fails, return false.
- Return true.
@ -275,18 +275,18 @@ https://github.com/zcash/librustzcash/pull/210
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#RFC4648] `The Base16, Base32, and Base64 Data Encodings <https://www.rfc-editor.org/rfc/rfc4648>`_
.. [#protocol-spec] `Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf>`_
.. [#constants] `Section 5.3: Constants. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf#merklepath>`_
.. [#merkle-crh] `Section 5.4.1.3: Merkle Tree Hash Function. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf#saplingmerklecrh>`_
.. [#diversify-hash] `Section 5.4.1.6: DiversifyHash Hash Function. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf#concretediversifyhash>`_
.. [#mixing-pedersen-hash] `Section 5.4.1.8: Mixing Pedersen Hash Function. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf#concretemixinghash>`_
.. [#prfs] `Section 5.4.2: Pseudo Random Functions. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf#concreteprfs>`_
.. [#spend-auth-sig] `Section 5.4.6.1: Spend Authorization Signature. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf#concretespendauthsig>`_
.. [#note-commit] `Section 5.4.7.2: Windowed Pedersen commitments. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf#concretewindowedcommit>`_
.. [#value-commit] `Section 5.4.7.3: Homomorphic Pedersen commitments. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf#concretehomomorphiccommit>`_
.. [#jubjub] `Section 5.4.8.3: Jubjub. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf#jubjub>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC4648] `RFC 4648: The Base16, Base32, and Base64 Data Encodings <https://www.rfc-editor.org/rfc/rfc4648>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol-merklepath] `Zcash Protocol Specification, Version 2020.1.15. Section 4.8: Merkle path validity <protocol/protocol.pdf#merklepath>`_
.. [#protocol-spendstatement] `Zcash Protocol Specification, Version 2020.1.15. Section 4.15.2: Spend Statement (Sapling) <protocol/protocol.pdf#spendstatement>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
.. [#protocol-saplingmerklecrh] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.3: Merkle Tree Hash Function <protocol/protocol.pdf#saplingmerklecrh>`_
.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.6: DiversifyHash Hash Function <protocol/protocol.pdf#concretediversifyhash>`_
.. [#protocol-concretemixinghash] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.8: Mixing Pedersen Hash Function <protocol/protocol.pdf#concretemixinghash>`_
.. [#protocol-concreteprfs] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.2: Pseudo Random Functions <protocol/protocol.pdf#concreteprfs>`_
.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature <protocol/protocol.pdf#concretespendauthsig>`_
.. [#protocol-concretewindowedcommit] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.7.2: Windowed Pedersen commitments <protocol/protocol.pdf#concretewindowedcommit>`_
.. [#protocol-concretehomomorphiccommit] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.7.3: Homomorphic Pedersen commitments <protocol/protocol.pdf#concretehomomorphiccommit>`_
.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.8.3: Jubjub <protocol/protocol.pdf#jubjub>`_
.. [#slip-0044] `SLIP-0044 : Registered coin types for BIP-0044 <https://github.com/satoshilabs/slips/blob/master/slip-0044.md>`_
.. [#merkle-path] `Section 4.8: Merkle path validity. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf#merklepath>`_
.. [#spend-statement] `Section 4.15.2: Spend Statement (Sapling). Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf#spendstatement>`_

14
zip-0307.html
View File

@ -519,7 +519,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://tools.ietf.org/html/rfc2119">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -527,7 +527,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#merkletree">Section 3.7: Note Commitment Trees. Zcash Protocol Specification, Version 2020.1.14 or later</a></td>
<td><a href="protocol/protocol.pdf#merkletree">Zcash Protocol Specification, Version 2020.1.15. Section 3.7: Note Commitment Trees</a></td>
</tr>
</tbody>
</table>
@ -535,7 +535,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#merklepath">Section 4.8: Merkle Path Validity. Zcash Protocol Specification, Version 2020.1.14 or later</a></td>
<td><a href="protocol/protocol.pdf#merklepath">Zcash Protocol Specification, Version 2020.1.15. Section 4.8: Merkle Path Validity</a></td>
</tr>
</tbody>
</table>
@ -543,7 +543,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#saplingdecryptivk">Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.14 or later</a></td>
<td><a href="protocol/protocol.pdf#saplingdecryptivk">Zcash Protocol Specification, Version 2020.1.15. Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling)</a></td>
</tr>
</tbody>
</table>
@ -551,7 +551,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#notept">Section 5.5: Encodings of Note Plaintexts and Memo Fields. Zcash Protocol Specification, Version 2020.1.14 or later</a></td>
<td><a href="protocol/protocol.pdf#notept">Zcash Protocol Specification, Version 2020.1.15. Section 5.5: Encodings of Note Plaintexts and Memo Fields</a></td>
</tr>
</tbody>
</table>
@ -559,7 +559,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/protocol.pdf#spendencoding">Section 7.3: Encoding of Spend Descriptions. Zcash Protocol Specification, Version 2020.1.14 or later</a></td>
<td><a href="protocol/protocol.pdf#spendencoding">Zcash Protocol Specification, Version 2020.1.15. Section 7.3: Encoding of Spend Descriptions</a></td>
</tr>
</tbody>
</table>
@ -567,7 +567,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/protocol.pdf#outputencoding">Section 7.4: Encoding of Output Descriptions. Zcash Protocol Specification, Version 2020.1.14 or later</a></td>
<td><a href="protocol/protocol.pdf#outputencoding">Zcash Protocol Specification, Version 2020.1.15. Section 7.4: Encoding of Output Descriptions</a></td>
</tr>
</tbody>
</table>

14
zip-0307.rst
View File

@ -605,13 +605,13 @@ Electric Coin Company.
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#protocol-merkletree] `Section 3.7: Note Commitment Trees. Zcash Protocol Specification, Version 2020.1.14 or later <protocol/protocol.pdf#merkletree>`_
.. [#protocol-merklepath] `Section 4.8: Merkle Path Validity. Zcash Protocol Specification, Version 2020.1.14 or later <protocol/protocol.pdf#merklepath>`_
.. [#protocol-saplingdecryptivk] `Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.14 or later <protocol/protocol.pdf#saplingdecryptivk>`_
.. [#protocol-notept] `Section 5.5: Encodings of Note Plaintexts and Memo Fields. Zcash Protocol Specification, Version 2020.1.14 or later <protocol/protocol.pdf#notept>`_
.. [#protocol-spendencoding] `Section 7.3: Encoding of Spend Descriptions. Zcash Protocol Specification, Version 2020.1.14 or later <protocol/protocol.pdf#spendencoding>`_
.. [#protocol-outputencoding] `Section 7.4: Encoding of Output Descriptions. Zcash Protocol Specification, Version 2020.1.14 or later <protocol/protocol.pdf#outputencoding>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-merkletree] `Zcash Protocol Specification, Version 2020.1.15. Section 3.7: Note Commitment Trees <protocol/protocol.pdf#merkletree>`_
.. [#protocol-merklepath] `Zcash Protocol Specification, Version 2020.1.15. Section 4.8: Merkle Path Validity <protocol/protocol.pdf#merklepath>`_
.. [#protocol-saplingdecryptivk] `Zcash Protocol Specification, Version 2020.1.15. Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling) <protocol/protocol.pdf#saplingdecryptivk>`_
.. [#protocol-notept] `Zcash Protocol Specification, Version 2020.1.15. Section 5.5: Encodings of Note Plaintexts and Memo Fields <protocol/protocol.pdf#notept>`_
.. [#protocol-spendencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 7.3: Encoding of Spend Descriptions <protocol/protocol.pdf#spendencoding>`_
.. [#protocol-outputencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 7.4: Encoding of Output Descriptions <protocol/protocol.pdf#outputencoding>`_
.. [#zip-0212] `ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <zip-0212.rst>`_
.. [#protocolbuffers] `Protocol Buffers documentation <https://developers.google.com/protocol-buffers/>`_
.. [#incremental-witness] `zcash_primitives Rust crate — merkle_tree.rs <https://github.com/zcash/librustzcash/blob/master/zcash_primitives/src/merkle_tree.rs>`_

22
zip-0308.html
View File

@ -16,7 +16,7 @@ Category: RPC/Wallet
Created: 2018-11-27
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">2</a></p>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Sprout protocol</dt>
@ -31,7 +31,7 @@ License: MIT</pre>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Zcash Sapling <a id="id2" class="footnote_reference" href="#zip-0205">4</a> introduces significant efficiency improvements relative to the previous iteration of the Zcash shielded protocol, Sprout. These improvements will pave the way for broad mobile, exchange and vendor adoption of shielded addresses.</p>
<p>Therefore, we anticipate that users will want to migrate all their shielded funds from Sprout to Sapling.</p>
<p>The Zcash consensus rules prohibit direct transfers from Sprout to Sapling z-addresses, unless the amount is revealed by sending it through the "transparent value pool" <a id="id3" class="footnote_reference" href="#transparent-value-pool">1</a>. The primary motivation for this is to allow detection of any overall inflation of the Zcash monetary base, due to exploitation of possible vulnerabilities in the shielded protocols or their implementation, or a compromise of the Sprout multi-party computation. (It is not necessary for Sprout -&gt; Sapling transfers to go via a t-address.)</p>
<p>The Zcash consensus rules prohibit direct transfers from Sprout to Sapling z-addresses, unless the amount is revealed by sending it through the "transparent value pool" <a id="id3" class="footnote_reference" href="#transparent-value-pool">2</a>. The primary motivation for this is to allow detection of any overall inflation of the Zcash monetary base, due to exploitation of possible vulnerabilities in the shielded protocols or their implementation, or a compromise of the Sprout multi-party computation. (It is not necessary for Sprout -&gt; Sapling transfers to go via a t-address.)</p>
<p>Since the exposure of the migrated amount potentially compromises the privacy of users, we wish to define a way to perform the migration that mitigates this privacy leak as far as possible. This can be done by hiding individual migration transactions among those of all users that are doing the migration at around the same time.</p>
<p>The security analysis of migration strategies is quite subtle; the more obvious potential strategies can leak a lot of information.</p>
</section>
@ -226,19 +226,19 @@ License: MIT</pre>
</ul>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="transparent-value-pool" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2018.0-beta-33 [Overwinter+Sapling]; sections 3.4, 4.11 and 4.12</a></td>
</tr>
</tbody>
</table>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="transparent-value-pool" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15. Sections 3.4, 4.11 and 4.12</a></td>
</tr>
</tbody>
</table>

4
zip-0308.rst
View File

@ -408,8 +408,8 @@ The following PRs implement this specification:
References
==========
.. [#transparent-value-pool] `Zcash Protocol Specification, Version 2018.0-beta-33 [Overwinter+Sapling]; sections 3.4, 4.11 and 4.12 <protocol/protocol.pdf>`_
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#transparent-value-pool] `Zcash Protocol Specification, Version 2020.1.15. Sections 3.4, 4.11 and 4.12 <protocol/protocol.pdf>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_

16
zip-0310.html
View File

@ -17,7 +17,7 @@ License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<dl>
<dt>Sapling FVK</dt>
<dd>A Sapling full viewing key as described in <a id="id1" class="footnote_reference" href="#protocol">1</a>, or a Sapling extended full viewing key as described in <a id="id2" class="footnote_reference" href="#zip-0032">2</a>.</dd>
<dd>A Sapling full viewing key as described in <a id="id1" class="footnote_reference" href="#protocol">1</a>, or a Sapling extended full viewing key as described in <a id="id2" class="footnote_reference" href="#zip-0032">3</a>.</dd>
<dt>GUARANTEED</dt>
<dd>Information that can be learned by the holder of a Sapling FVK, and ensured to be correct by the Sapling protocol, given the cryptographic assumptions underlying that protocol.</dd>
<dt>UNVERIFIED</dt>
@ -115,7 +115,7 @@ License: MIT</pre>
<p>The balance of a tally after a particular block is defined as the sum of note values that are spendable, according to the Sapling protocol, using the extended spending key associated with the tally, in a block chain that extends from that block.</p>
<p>Ian can attempt to keep track of a given tally’s balance as of a given block. This would be done as follows:</p>
<ul>
<li>Scan the chain from Sapling activation up to and including the specified block, collecting all of the Sapling spends and Sapling outputs up to and including that block that are relevant to the FVK, as specified in section 4.19 of the Protocol Specification. This produces a ReceivedSet of notes that were received by that tally, and a SpentSet of notes that were spent from it.</li>
<li>Scan the chain from Sapling activation up to and including the specified block, collecting all of the Sapling spends and Sapling outputs up to and including that block that are relevant to the FVK, as specified in section 4.19 of the Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-saplingscan">2</a>. This produces a ReceivedSet of notes that were received by that tally, and a SpentSet of notes that were spent from it.</li>
<li>Compute the balance as the sum of the values of all notes appearing in ReceivedSet but not in SpentSet.</li>
</ul>
<p>The following inaccuracies may occur in balance accounting:</p>
@ -159,14 +159,22 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.1 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-saplingscan" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#saplingscan">Zcash Protocol Specification, Version 2020.1.15. Section 4.19: Block Chain Scanning (Sapling)</a></td>
</tr>
</tbody>
</table>
<table id="zip-0032" class="footnote">
<tbody>
<tr>
<th>2</th>
<th>3</th>
<td><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td>
</tr>
</tbody>

10
zip-0310.rst
View File

@ -183,9 +183,9 @@ This would be done as follows:
* Scan the chain from Sapling activation up to and including the specified
block, collecting all of the Sapling spends and Sapling outputs up to and
including that block that are relevant to the FVK, as specified in section
4.19 of the Protocol Specification. This produces a ReceivedSet of notes
that were received by that tally, and a SpentSet of notes that were spent
from it.
4.19 of the Protocol Specification [#protocol-saplingscan]_. This produces
a ReceivedSet of notes that were received by that tally, and a SpentSet of
notes that were spent from it.
* Compute the balance as the sum of the values of all notes appearing in
ReceivedSet but not in SpentSet.
@ -253,6 +253,6 @@ In addition to information learned from each individual FVK, Ian can infer:
References
==========
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.1 or later <protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol-saplingscan] `Zcash Protocol Specification, Version 2020.1.15. Section 4.19: Block Chain Scanning (Sapling) <protocol/protocol.pdf#saplingscan>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_

8
zip-0321.html
View File

@ -213,7 +213,7 @@ zcash:%74mEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1</pre>
<tbody>
<tr>
<th>10</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.14 or later. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
@ -221,7 +221,7 @@ zcash:%74mEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1</pre>
<tbody>
<tr>
<th>11</th>
<td><a href="protocol/protocol.pdf#saplingbalance">Zcash Protocol Specification, Version 2020.1.14 or later. Section 4.12: Balance and Binding Signature (Sapling)</a></td>
<td><a href="protocol/protocol.pdf#saplingbalance">Zcash Protocol Specification, Version 2020.1.15. Section 4.12: Balance and Binding Signature (Sapling)</a></td>
</tr>
</tbody>
</table>
@ -229,7 +229,7 @@ zcash:%74mEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1</pre>
<tbody>
<tr>
<th>12</th>
<td><a href="protocol/protocol.pdf#transparentaddrencoding">Zcash Protocol Specification, Version 2020.1.14 or later. Section 5.6.1: Transparent Addresses</a></td>
<td><a href="protocol/protocol.pdf#transparentaddrencoding">Zcash Protocol Specification, Version 2020.1.15. Section 5.6.1: Transparent Addresses</a></td>
</tr>
</tbody>
</table>
@ -237,7 +237,7 @@ zcash:%74mEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1</pre>
<tbody>
<tr>
<th>13</th>
<td><a href="protocol/protocol.pdf#saplingpaymentaddrencoding">Zcash Protocol Specification, Version 2020.1.14 or later. Section 5.6.4: Sapling Payment Addresses</a></td>
<td><a href="protocol/protocol.pdf#saplingpaymentaddrencoding">Zcash Protocol Specification, Version 2020.1.15. Section 5.6.4: Sapling Payment Addresses</a></td>
</tr>
</tbody>
</table>

8
zip-0321.rst
View File

@ -306,7 +306,7 @@ References
.. [#base58check] `Bitcoin Wiki: Base58Check encoding <https://en.bitcoin.it/wiki/Base58Check_encoding>`_
.. [#zip-0173] `ZIP 173: Bech32 Format <zip-0173.rst>`_
.. [#zip-0211] `ZIP 211: Disabling Addition of New Value to the Sprout Value Pool <zip-0211.rst>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.14 or later. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-saplingbalance] `Zcash Protocol Specification, Version 2020.1.14 or later. Section 4.12: Balance and Binding Signature (Sapling) <protocol/protocol.pdf#saplingbalance>`_
.. [#protocol-transparentaddrencoding] `Zcash Protocol Specification, Version 2020.1.14 or later. Section 5.6.1: Transparent Addresses <protocol/protocol.pdf#transparentaddrencoding>`_
.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.14 or later. Section 5.6.4: Sapling Payment Addresses <protocol/protocol.pdf#saplingpaymentaddrencoding>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-saplingbalance] `Zcash Protocol Specification, Version 2020.1.15. Section 4.12: Balance and Binding Signature (Sapling) <protocol/protocol.pdf#saplingbalance>`_
.. [#protocol-transparentaddrencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 5.6.1: Transparent Addresses <protocol/protocol.pdf#transparentaddrencoding>`_
.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 5.6.4: Sapling Payment Addresses <protocol/protocol.pdf#saplingpaymentaddrencoding>`_

2
zip-0400.html
View File

@ -473,7 +473,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-0400.rst
View File

@ -141,7 +141,7 @@ For a deeper understanding of the current encryption mechanism please refer to [
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#BDB] `Oracle Berkeley Database <https://www.oracle.com/database/berkeley-db/db.html>`_
.. [#ZIP400Issue] `ZIP 400 issue <https://github.com/zcash/zips/issues/350>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_

4
zip-0401.html
View File

@ -81,7 +81,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -89,7 +89,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="https://zips.z.cash/zip-0208">Shorter Block Target Spacing</a></td>
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
</tr>
</tbody>
</table>

4
zip-0401.rst
View File

@ -202,6 +202,6 @@ Reference implementation
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-0208] `Shorter Block Target Spacing <https://zips.z.cash/zip-0208>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
.. [#BitcoinCore-PR6722] `Bitcoin Core PR 6722: Limit mempool by throwing away the cheapest txn and setting min relay fee to it <https://github.com/bitcoin/bitcoin/pull/6722>`_

2
zip-1001.html
View File

@ -80,7 +80,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-kee
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-1001.rst
View File

@ -107,7 +107,7 @@ This ZIP requires no changes to current consensus implementations.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#funding] `Zcash blog: Funding, Incentives, and Governance. February 1, 2016 <https://electriccoin.co/blog/funding/>`_
.. [#spec-subsidies] `Zcash Protocol Specification, Version 2019.0.8 exactly. Section 7.7: Calculation of Block Subsidy and Founders Reward <protocol/protocol.pdf#subsidies>`_
.. [#spec-foundersreward] `Zcash Protocol Specification, Version 2019.0.8 exactly. Section 7.8: Payment of Founders’ Reward <protocol/protocol.pdf#foundersreward>`_

2
zip-1002.html
View File

@ -133,7 +133,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-g
<tbody>
<tr>
<th>3</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-1002.rst
View File

@ -196,5 +196,5 @@ Stuff that is already implemented in some form or another:
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zfnd-guidance] `Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. <https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/>`_

2
zip-1003.html
View File

@ -83,7 +83,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-1003.rst
View File

@ -153,7 +153,7 @@ development fund’ should instead not be minted.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zfnd-state] `The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019. <https://www.zfnd.org/blog/foundation-in-2019/>`_
.. [#zfnd-guidance] `Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. <https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/>`_

2
zip-1004.html
View File

@ -87,7 +87,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-1004.rst
View File

@ -166,7 +166,7 @@ Raised objections and issues so far:
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#amiller-notes] `Notes on reaching agreement about a potential Zcash development fund. Andrew Miller, June 3, 2019. <https://medium.com/@socrates1024/here-are-a-couple-of-points-on-framing-the-discussion-of-a-potential-new-dev-fund-in-zcash-c13bcbf4ed5b>`_
.. [#acityinohio-comment] `Comment on a post “The future of Zcash in the year 2020” in the Zcash Community Forum. Josh Cincinnati, June 3, 2019. <https://forum.zcashcommunity.com/t/the-future-of-zcash-in-the-year-2020/32372/267>`_
.. [#blocktown-summary] `Executive Summary: Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 15, 2019. <https://medium.com/blocktown/executive-summary-blocktown-proposal-for-zcash-2020-network-upgrade-84ff20997502>`_

2
zip-1006.html
View File

@ -126,7 +126,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/blocktown-develo
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-1006.rst
View File

@ -365,7 +365,7 @@ in Placeholder’s dev fund proposal from August 22, 2019 [#placeholder-proposal
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zfnd-guidance] `Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. <https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/>`_
.. [#ecc-assessment] `ECC Initial Assessment of Community Proposals. Electric Coin Company blog, August 26, 2019. <https://electriccoin.co/blog/ecc-initial-assessment-of-community-proposals/>`_
.. [#blocktown-proposal] `Proposal for the Zcash 2020 Network Upgrade (topic on the Zcash community forum). <https://forum.zcashcommunity.com/t/proposal-for-the-zcash-2020-network-upgrade/34503>`_

4
zip-1007.html
View File

@ -86,7 +86,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-supplem
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -94,7 +94,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-supplem
<tbody>
<tr>
<th>2</th>
<td><a href="zip-1006">Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity</a></td>
<td><a href="zip-1006">ZIP 1006: Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity</a></td>
</tr>
</tbody>
</table>

4
zip-1007.rst
View File

@ -184,5 +184,5 @@ Raised Concerns
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-1006] `Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity <zip-1006.rst>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-1006] `ZIP 1006: Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity <zip-1006.rst>`_

2
zip-1008.html
View File

@ -70,7 +70,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/kek-s-proposal-f
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-1008.rst
View File

@ -117,6 +117,6 @@ Implications to other users
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <zip-0206.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_

2
zip-1010.html
View File

@ -127,7 +127,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/a-grand-compromi
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-1010.rst
View File

@ -342,7 +342,7 @@ Issues and further discussion
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zfnd-guidance] `Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. <https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/>`_
.. [#tromer-comment] `Comment on a post “How to hire ECC” in the Zcash Community Forum. Eran Tromer, August 11, 2019. <https://forum.zcashcommunity.com/t/how-to-hire-ecc/34379/55>`_

2
zip-1013.html
View File

@ -72,7 +72,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/293">https://githu
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>

2
zip-1013.rst
View File

@ -133,4 +133,4 @@ continuing any prior proportions.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_

4
zip-1014.html
View File

@ -146,7 +146,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">https://githu
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -154,7 +154,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">https://githu
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification [Overwinter+Sapling+Blossom]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>

4
zip-1014.rst
View File

@ -373,8 +373,8 @@ and *@dontbeevil* for valuable initial comments on ZIP 1012.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#trademark] `Zcash Trademark Donation and License Agreement <https://www.zfnd.org/about/contracts/2019_ECC_ZFND_TM_agreement.pdf>`_
.. [#osd] `The Open Source Definition <https://opensource.org/osd>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_

16
zip-guide.html
View File

@ -34,7 +34,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/253">https://githu
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>{Describe what this proposal does, typically in a few paragraphs.</p>
<p>The Abstract should only provide a summary of the ZIP; the ZIP should remain complete without the Abstract.</p>
<p>Use links where applicable, e.g. <a id="id2" class="footnote_reference" href="#protocol">2</a>.}</p>
<p>Use links where applicable, e.g. <a id="id2" class="footnote_reference" href="#protocol">2</a> <a id="id3" class="footnote_reference" href="#protocol-introduction">3</a>.}</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>{Why is this proposal needed?</p>
@ -78,7 +78,7 @@ sudo pip3 install rst2html5</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
@ -86,14 +86,22 @@ sudo pip3 install rst2html5</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version {...} or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-introduction" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#introduction">Zcash Protocol Specification, Version 2020.1.15. Section 1: Introduction</a></td>
</tr>
</tbody>
</table>
<table id="zip-xxxx" class="footnote">
<tbody>
<tr>
<th>3</th>
<th>4</th>
<td><a href="zip-xxxx">ZIP xxxx: Title</a></td>
</tr>
</tbody>

7
zip-guide.rst
View File

@ -48,7 +48,7 @@ Abstract
The Abstract should only provide a summary of the ZIP; the ZIP should remain
complete without the Abstract.
Use links where applicable, e.g. [#protocol]_.}
Use links where applicable, e.g. [#protocol]_ [#protocol-introduction]_.}
Motivation
@ -138,6 +138,7 @@ zebrad PRs.}
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version {...} or later <protocol/protocol.pdf>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol-introduction] `Zcash Protocol Specification, Version 2020.1.15. Section 1: Introduction <protocol/protocol.pdf#introduction>`_
.. [#zip-xxxx] `ZIP xxxx: Title <zip-xxxx.rst>`_