zec
/
zips
mirror of https://github.com/zcash/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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -255,7 +255,7 @@ Updates:</pre>
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -287,7 +287,7 @@ Updates:</pre>
<tbody> <tbody>
<tr> <tr>
<th>6</th> <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> </tr>
</tbody> </tbody>
</table> </table>

6
zip-0000.rst
View File

@ -612,10 +612,10 @@ See Also
References 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>`_
.. [#RFC3552] `Guidelines for Writing RFC Text on Security Considerations <https://www.rfc-editor.org/rfc/rfc3552.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>`_ .. [#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>`_ .. [#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>`_ .. [#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> </p>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p> <p>The 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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 <a id="id3" class="footnote_reference" href="#bip-0032">2</a>, to support Zcash's shielded addresses.</p> <p>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> <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>
<section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#conventions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#conventions"><img width="24" height="24" 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> <ul>
<li> <li>
<span class="math">\(\mathsf{truncate}_k(S)\)</span> <span class="math">\(\mathsf{truncate}_k(S)\)</span>
@ -93,7 +93,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{repr}_\mathbb{J}(P)\)</span> <span class="math">\(\mathsf{repr}_\mathbb{J}(P)\)</span>
is the representation of the Jubjub elliptic curve point is the representation of the Jubjub elliptic curve point
<span class="math">\(P\)</span> <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> <li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\)</span> <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 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> <span class="math">\(d\)</span>
to a base point on the Jubjub elliptic curve, or to to a base point on the Jubjub elliptic curve, or to
<span class="math">\(\bot\)</span> <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> </ul>
<p>The following algorithm standardized in <a id="id11" class="footnote_reference" href="#nist-sp-800-38g">16</a> is used:</p> <p>The following algorithm standardized in <a id="id11" class="footnote_reference" href="#nist-sp-800-38g">16</a> is used:</p>
<ul> <ul>
@ -256,7 +256,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{nsk}_m\)</span> <span class="math">\(\mathsf{nsk}_m\)</span>
, and , and
<span class="math">\(\mathsf{ovk}_m\)</span> <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> <ul>
<li> <li>
<span class="math">\(\mathsf{ask}_m = \mathsf{ToScalar}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))\)</span> <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> <span class="math">\((\mathsf{nk}_{par}, \mathsf{ak}_{par}, \mathsf{ovk}_{par})\)</span>
is the full viewing key derived from is the full viewing key derived from
<span class="math">\((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par})\)</span> <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> </ul>
</li> </li>
<li>Split <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> <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 <p>Let
<span class="math">\(\mathcal{G}\)</span> <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> <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> <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">\(\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> <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> <span class="math">\(\mathsf{EncodeASK}(\mathsf{a_{sk}})\)</span>
be the 32-byte encoding of be the 32-byte encoding of
<span class="math">\(\mathsf{a_{sk}}\)</span> <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 <p>Let
<span class="math">\(\mathsf{DecodeASK}(ASK)\)</span> <span class="math">\(\mathsf{DecodeASK}(ASK)\)</span>
be the result of clearing the 4 most significant bits of the first byte of 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> <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 <p>A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding
<span class="math">\(FVK\)</span> <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> <ul>
<li> <li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, FVK)\)</span> <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> <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 <p>A "Sprout address fingerprint" of a Sprout payment address with raw encoding
<span class="math">\(ADDR\)</span> <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> <ul>
<li> <li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, ADDR)\)</span> <span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, ADDR)\)</span>
@ -748,7 +748,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -800,67 +800,67 @@ License: MIT</pre>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<table id="sapling-spec" class="footnote"> <table id="protocol" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>8</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="sapling-key-components" class="footnote"> <table id="protocol-saplingkeycomponents" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>9</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="sapling-diversifyhash" class="footnote"> <table id="protocol-concretediversifyhash" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>10</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="sapling-spendauthsig" class="footnote"> <table id="protocol-concretespendauthsig" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>11</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="sapling-jubjub" class="footnote"> <table id="protocol-jubjub" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>12</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="sprout-shielded-addresses" class="footnote"> <table id="protocol-sproutpaymentaddrencoding" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>13</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="sapling-full-viewing-keys" class="footnote"> <table id="protocol-saplingfullviewingkeyencoding" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>14</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="sprout-spending-keys" class="footnote"> <table id="protocol-sproutspendingkeyencoding" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>15</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -868,7 +868,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>16</th> <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> </tr>
</tbody> </tbody>
</table> </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. The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119.
[#RFC2119]_ [#RFC2119]_
"Jubjub" refers to the elliptic curve defined in [#sapling-jubjub]_. "Jubjub" refers to the elliptic curve defined in [#protocol-jubjub]_.
Abstract Abstract
@ -64,7 +64,7 @@ Conventions
=========== ===========
Most of the notation and functions used in this ZIP are defined in the Sapling protocol specification 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`. - :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. 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` - :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, - :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`. 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{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 - :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: 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 - 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`. :math:`\mathsf{c}_m`.
- Calculate :math:`\mathsf{ask}_m`, :math:`\mathsf{nsk}_m`, and :math:`\mathsf{ovk}_m` via the standard - 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{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}]))` - :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): - 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))` 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 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`. - 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}]))`. - 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 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 Let :math:`\mathcal{G}` be as defined in [#protocol-concretespendauthsig]_ and let :math:`\mathcal{H}` be as defined
in [#sapling-key-components]_. 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})` :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 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 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}`. 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 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)`. * :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 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)`. * :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, ADDR)`.
@ -494,20 +494,19 @@ Reference Implementation
References 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-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-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-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>`_ .. [#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>`_ .. [#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>`_ .. [#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>`_ .. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#sapling-key-components] `Zcash Protocol Specification, Section 4.2.2 Sapling Key Components <protocol/protocol.pdf#saplingkeycomponents>`_ .. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2020.1.15. 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>`_ .. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2020.1.15. 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>`_ .. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2020.1.15. 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>`_ .. [#protocol-jubjub] `Zcash Protocol Specification, Version 2020.1.15. 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>`_ .. [#protocol-sproutpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.15. 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>`_ .. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.15. 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>`_ .. [#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>`_ .. [#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> <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>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" 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> <p>Unfortunately, there are at least 2 weaknesses in the original SignatureHash transaction digest algorithm:</p>
<ul> <ul>
<li>For the validation of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n<sup>2</sup>) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to validate with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to validate. This could be fixed by optimizing the digest algorithm by introducing some reusable "midstate", so the time complexity becomes O(n). <a id="id6" class="footnote_reference" href="#quadratic">4</a></li> <li>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> <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> </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> <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> <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> <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> </section>
@ -351,23 +351,23 @@ sighash: 23652e76cb13b85a0e3363bb5fca061fa791c40c533eccee899364e6e60bb4f7</pre>
<tbody> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="wiki-checksig" class="footnote"> <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> <tbody>
<tr> <tr>
<th>3</th> <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> </tr>
</tbody> </tbody>
</table> </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 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]_ 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``). 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: 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 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>`_
.. [#wiki-checksig] https://en.bitcoin.it/wiki/OP_CHECKSIG .. [#protocol-sproutsend] `Zcash Protocol Specification, Version 2020.1.15. Section 4.6: Sending Notes (Sprout) <protocol/protocol.pdf#sproutsend>`_
.. [#zcash-protocol] `Zcash Protocol Specification, Section 4.6 Sending Notes <protocol/protocol.pdf#send>`_ .. [#wiki-checksig] `OP\_CHECKSIG. Bitcoin Wiki <https://en.bitcoin.it/wiki/OP_CHECKSIG>`_
.. [#quadratic] .. [#quadratic]
* `CVE-2013-2292 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2292>`_ * `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>`_ * `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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -362,7 +362,7 @@ def bech32_verify_checksum(hrp, data):
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>

4
zip-0173.rst
View File

@ -461,8 +461,8 @@ Eric Lombrozo, Peter Todd, and various other reviewers.
References 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 2018.0-beta-37 [Overwinter+Sapling] <protocol/protocol.pdf>`_ .. [#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-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -129,7 +129,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -139,8 +139,8 @@ License: MIT</pre>
<th>3</th> <th>3</th>
<td> <td>
<ul> <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-and-lifetimes/">Release Cycle and Lifetimes. Electric Coin Company blog</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-update/">Release Cycle Update. Electric Coin Company blog</a></li>
</ul> </ul>
</td> </td>
</tr> </tr>

8
zip-0200.rst
View File

@ -223,11 +223,11 @@ https://github.com/zcash/zcash/pull/2898
References 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>`_
.. [#consensual-currency] https://electriccoin.co/blog/consensual-currency/ .. [#consensual-currency] `Consensual Currency. Electric Coin Company blog <https://electriccoin.co/blog/consensual-currency/>`_
.. [#release-lifecycle] .. [#release-lifecycle]
- https://electriccoin.co/blog/release-cycle-and-lifetimes/ - `Release Cycle and Lifetimes. Electric Coin Company blog <https://electriccoin.co/blog/release-cycle-and-lifetimes/>`_
- https://electriccoin.co/blog/release-cycle-update/ - `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-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.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>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-0201.rst
View File

@ -248,7 +248,7 @@ https://github.com/zcash/zcash/pull/2919
References 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-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.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>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-0202.rst
View File

@ -275,7 +275,7 @@ https://github.com/zcash/zcash/pull/2925
References 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-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_ .. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Handshaking for Overwinter <zip-0201.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 Created: 2018-10-08
License: MIT</pre> License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" 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 "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> <p>The terms below are to be interpreted as follows:</p>
<dl> <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> <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> <p>The primary sources of information about Sapling consensus protocol changes are:</p>
<ul> <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>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> <li>Network Upgrade Activation Mechanism <a id="id5" class="footnote_reference" href="#zip-0200">3</a>.</li>
</ul> </ul>
@ -59,8 +59,8 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
</ul> </ul>
</section> </section>
<section id="change-to-difficulty-adjustment-on-testnet"><h3><span class="section-heading">Change to difficulty adjustment on testnet</span><span class="section-anchor"> <a rel="bookmark" href="#change-to-difficulty-adjustment-on-testnet"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3> <section id="change-to-difficulty-adjustment-on-testnet"><h3><span class="section-heading">Change to difficulty adjustment on testnet</span><span class="section-anchor"> <a rel="bookmark" href="#change-to-difficulty-adjustment-on-testnet"><img width="24" height="24" 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>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">1</a> section 5.3). However, its <code>nBits</code> field is still computed according to the original difficulty adjustment algorithm.</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 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> <p>This change does not affect mainnet.</p>
</section> </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> <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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" 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"> <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> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>

4
zip-0205.rst
View File

@ -139,8 +139,8 @@ version 170007.
References References
========== ==========
.. [#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>`_
.. [#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.15 or later <protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_ .. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.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>`_ .. [#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 Created: 2019-07-29
License: MIT</pre> License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" 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 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> <p>The terms below are to be interpreted as follows:</p>
<dl> <dl>
<dt>Blossom</dt> <dt>Blossom</dt>
<dd>Code-name for the third Zcash network upgrade, also known as Network Upgrade 2.</dd> <dd>Code-name for the third Zcash network upgrade, also known as Network Upgrade 2.</dd>
<dt>Testnet</dt> <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> <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> </dl>
</section> </section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" 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> <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> <p>The primary sources of information about Blossom consensus protocol changes are:</p>
<ul> <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>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> <li>Network Upgrade Activation Mechanism <a id="id7" class="footnote_reference" href="#zip-0200">3</a>.</li>
</ul> </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> <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>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>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>
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" 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> <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>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" 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"> <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> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>

4
zip-0206.rst
View File

@ -121,8 +121,8 @@ in ``zcashd`` version 2.1.0, which advertises protocol version 170009.
References References
========== ==========
.. [#protocol] `Zcash Protocol Specification, Version 2019.0.4 or later [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>`_
.. [#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.15 or later <protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_ .. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_ .. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -392,7 +392,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -400,7 +400,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>3</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -408,7 +408,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>4</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -416,7 +416,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>5</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -424,7 +424,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>6</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -432,7 +432,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>7</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -440,7 +440,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>8</th> <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> </tr>
</tbody> </tbody>
</table> </table>

16
zip-0207.rst
View File

@ -397,14 +397,14 @@ TBC
References 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.9 or later [Canopy] <protocol/canopy.pdf>`_ .. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/canopy.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet <protocol/canopy.pdf#networks>`_ .. [#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.9 [Canopy]. Section 3.9: Block Subsidy and Founders' Reward <protocol/canopy.pdf#subsidyconcepts>`_ .. [#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.9 [Canopy]. Section 5.3: Constants <protocol/canopy.pdf#constants>`_ .. [#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.9 [Canopy]. Section 7.6.3: Difficulty adjustment <protocol/canopy.pdf#diffadjustment>`_ .. [#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.9 [Canopy]. Section 7.7: Calculation of Block Subsidy and Founders' Reward <protocol/canopy.pdf#subsidies>`_ .. [#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.9 [Canopy]. Section 7.8: Payment of Founders' Reward <protocol/canopy.pdf#foundersreward>`_ .. [#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-0000] `ZIP 0: ZIP Process <zip-0000.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.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 License: MIT
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://github.com/zcash/zips/pull/237</a>&gt;</pre> Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://github.com/zcash/zips/pull/237</a>&gt;</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" 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 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">4</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 <a id="id3" class="footnote_reference" href="#latest-protocol">1</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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" 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> <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>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" 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> <li>Greater throughput of transactions in unit time.</li>
</ul> </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>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>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" 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> <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>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 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>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>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>Define IsBlossomActivated(<em>height</em>) to return true if <em>height</em> ≥ BlossomActivationHeight, otherwise false.</p>
<p>This specification assumes that BlossomActivationHeight ≥ SlowStartInterval.</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>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> <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> </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> <ul>
<li>Halving(<em>height</em>) := <li>Halving(<em>height</em>) :=
<ul> <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>(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> <li>MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2<sup>Halving(*height*)</sup>) is an integer for the next few periods.</li>
</ul> </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> <ul>
<li>FounderAddressAdjustedHeight(<em>height</em>) := <li>FounderAddressAdjustedHeight(<em>height</em>) :=
<ul> <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>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> <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> <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>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 <a id="id12" class="footnote_reference" href="#latest-protocol">1</a> section 5.3).</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> <p>As before, the <code>nBits</code> field of a minimum-difficulty block is still computed according to the original difficulty adjustment algorithm, and only this field is used for the purpose of computing the MeanTarget values from which subsequent difficulty changes are calculated.</p>
</section> </section>
</section> </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> <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>
<section id="default-expiry-delta"><h4><span class="section-heading">Default expiry delta</span><span class="section-anchor"> <a rel="bookmark" href="#default-expiry-delta"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4> <section id="default-expiry-delta"><h4><span class="section-heading">Default expiry delta</span><span class="section-anchor"> <a rel="bookmark" href="#default-expiry-delta"><img width="24" height="24" 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>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>
<section id="sprout-to-sapling-migration"><h4><span class="section-heading">Sprout to Sapling migration</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-to-sapling-migration"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4> <section id="sprout-to-sapling-migration"><h4><span class="section-heading">Sprout to Sapling migration</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-to-sapling-migration"><img width="24" height="24" 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> <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>
<section id="fingerprinting-mitigation"><h4><span class="section-heading">Fingerprinting mitigation</span><span class="section-anchor"> <a rel="bookmark" href="#fingerprinting-mitigation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4> <section id="fingerprinting-mitigation"><h4><span class="section-heading">Fingerprinting mitigation</span><span class="section-anchor"> <a rel="bookmark" href="#fingerprinting-mitigation"><img width="24" height="24" 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>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 <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 // 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> // 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>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> <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>
<section id="monitoring-for-quicker-or-slower-than-expected-blocks"><h4><span class="section-heading">Monitoring for quicker- or slower-than-expected blocks</span><span class="section-anchor"> <a rel="bookmark" href="#monitoring-for-quicker-or-slower-than-expected-blocks"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4> <section id="monitoring-for-quicker-or-slower-than-expected-blocks"><h4><span class="section-heading">Monitoring for quicker- or slower-than-expected blocks</span><span class="section-anchor"> <a rel="bookmark" href="#monitoring-for-quicker-or-slower-than-expected-blocks"><img width="24" height="24" 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> <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>
<section id="latency-optimization-when-requesting-blocks"><h4><span class="section-heading">Latency optimization when requesting blocks</span><span class="section-anchor"> <a rel="bookmark" href="#latency-optimization-when-requesting-blocks"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4> <section id="latency-optimization-when-requesting-blocks"><h4><span class="section-heading">Latency optimization when requesting blocks</span><span class="section-anchor"> <a rel="bookmark" href="#latency-optimization-when-requesting-blocks"><img width="24" height="24" 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 <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), // case where a new block is announced that succeeds the current tip (no reorganization),
// there are no such headers. // 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 // 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 // doing this will result in the received block being rejected as an orphan in case it is
// not a direct successor.</pre> // not a direct successor.</pre>
<p>The heuristic for "nearly synced" is that the timestamp of the block at the active tip is no more than 20 block times before the current "adjusted time". In <code>zcashd</code> this calculation uses the block target spacing as of the best known header. Around Blossom activation when the block target spacing changes, this could cause the heuristic to be based on the pre-Blossom block target spacing until the node has synced headers past the activation block, but this is not anticipated to cause any problem.</p> <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>
<section id="response-to-getblocks-message-when-pruning"><h4><span class="section-heading">Response to getblocks message when pruning</span><span class="section-anchor"> <a rel="bookmark" href="#response-to-getblocks-message-when-pruning"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4> <section id="response-to-getblocks-message-when-pruning"><h4><span class="section-heading">Response to getblocks message when pruning</span><span class="section-anchor"> <a rel="bookmark" href="#response-to-getblocks-message-when-pruning"><img width="24" height="24" 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 <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> // 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> <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>
<section id="estimation-of-fully-synced-chain-height"><h4><span class="section-heading">Estimation of fully synced chain height</span><span class="section-anchor"> <a rel="bookmark" href="#estimation-of-fully-synced-chain-height"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4> <section id="estimation-of-fully-synced-chain-height"><h4><span class="section-heading">Estimation of fully synced chain height</span><span class="section-anchor"> <a rel="bookmark" href="#estimation-of-fully-synced-chain-height"><img width="24" height="24" 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>
<section id="other-block-related-constants"><h4><span class="section-heading">Other block-related constants</span><span class="section-anchor"> <a rel="bookmark" href="#other-block-related-constants"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4> <section id="other-block-related-constants"><h4><span class="section-heading">Other block-related constants</span><span class="section-anchor"> <a rel="bookmark" href="#other-block-related-constants"><img width="24" height="24" 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> <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> </section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" 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>
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" 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> <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> <p><a href="https://github.com/zcash/zcash/pull/4025">https://github.com/zcash/zcash/pull/4025</a></p>
</section> </section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="latest-protocol" class="footnote"> <table id="rfc2119" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -213,22 +213,46 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="rfc2119" class="footnote"> <table id="protocol" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>3</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="zip-0200" class="footnote"> <table id="zip-0200" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>4</th> <th>7</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td> <td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr> </tr>
</tbody> </tbody>
@ -236,7 +260,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-0205" class="footnote"> <table id="zip-0205" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>5</th> <th>8</th>
<td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td> <td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td>
</tr> </tr>
</tbody> </tbody>
@ -244,7 +268,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-0206" class="footnote"> <table id="zip-0206" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>6</th> <th>9</th>
<td><a href="zip-0206">ZIP 206: Deployment of the Blossom Network Upgrade</a></td> <td><a href="zip-0206">ZIP 206: Deployment of the Blossom Network Upgrade</a></td>
</tr> </tr>
</tbody> </tbody>
@ -252,7 +276,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-0308" class="footnote"> <table id="zip-0308" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>7</th> <th>10</th>
<td><a href="zip-0308">ZIP 308: Sprout to Sapling Migration</a></td> <td><a href="zip-0308">ZIP 308: Sprout to Sapling Migration</a></td>
</tr> </tr>
</tbody> </tbody>
@ -260,7 +284,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="slowfastblocks" class="footnote"> <table id="slowfastblocks" class="footnote">
<tbody> <tbody>
<tr> <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> <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> </tr>
</tbody> </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 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 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", 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 Abstract
@ -61,8 +62,8 @@ See [#slowfastblocks]_ for further analysis in various attack models.
Specification Specification
============= =============
The changes described in this section are to be made in [#latest-protocol]_, The changes described in this section are to be made in the Zcash Protocol Specification
relative to the pre-Blossom specification in [#preblossom-protocol]. [#protocol]_, relative to the pre-Blossom specification in [#preblossom-protocol].
Consensus changes Consensus changes
----------------- -----------------
@ -108,8 +109,8 @@ ActualTimespanDamped, ActualTimespanBounded, and Threshold as follows:
- ensure that each reference to any of these values, or to PoWTargetSpacing, - ensure that each reference to any of these values, or to PoWTargetSpacing,
are replaced with a function call passing the *height* parameter. are replaced with a function call passing the *height* parameter.
In [#latest-protocol]_ section 7.7 (Calculation of Block Subsidy and Founders’ In section 7.7 (Calculation of Block Subsidy and Founders’ Reward), redefine the
Reward), redefine the Halving and BlockSubsidy functions as follows: Halving and BlockSubsidy functions as follows:
- Halving(*height*) := - Halving(*height*) :=
@ -130,7 +131,7 @@ Note: BlossomActivationHeight, PostBlossomHalvingInterval, and PostBlossomTarget
- MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(*height*)`\ ) - MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(*height*)`\ )
is an integer for the next few periods. 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*) := - 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 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, 6 · PoWTargetSpacing(*height*) seconds after that of the preceding block,
then the block is a minimum-difficulty block, and its target threshold is set 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 As before, the ``nBits`` field of a minimum-difficulty block is still computed
according to the original difficulty adjustment algorithm, and only this field according to the original difficulty adjustment algorithm, and only this field
@ -209,7 +211,7 @@ follow Blossom activation.
Default expiry delta 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 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 transaction will expire. The default in recent versions of `zcashd` is
20 blocks, which at the pre-Blossom block target spacing corresponds to roughly 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 This default SHOULD change to BlossomPoWTargetSpacingRatio · 20 blocks after
Blossom activation, to maintain the approximate expiry time of 50 minutes. 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. 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 identified across network sessions, for example using information about which
blocks they request or send. 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:: comment in ``main.cpp``, intended as a fingerprinting mitigation::
// To prevent fingerprinting attacks, only send blocks outside of the active // 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 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 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 defined in section 7.6.5 of the Zcash Protocol Specification [#protocol-workdef]_,
block at the active tip, and multiply by the target block spacing of that block. 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 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 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 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. 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":: 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. // not a direct successor.
The heuristic for "nearly synced" is that the timestamp of the block at the active tip 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 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 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 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 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 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:: 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 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 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 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 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 References
========== ==========
.. [#latest-protocol] `Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom] <protocol/blossom.pdf>`_ .. [#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) [Overwinter+Sapling] <https://github.com/zcash/zips/blob/9515d73aac0aea3494f77bcd634e1e4fbd744b97/protocol/protocol.pdf>`_ .. [#preblossom-protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) <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>`_ .. [#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-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.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>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </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 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>`_ .. [#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>`_ .. [#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> License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" 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 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 "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">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>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" 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> <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>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" 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 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="#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 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> <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>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -51,31 +51,31 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="zip-0200" class="footnote"> <table id="zip-0200" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>2</th> <th>3</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Activation Mechanism</a></td> <td><a href="zip-0200">ZIP 200: Network Upgrade Activation Mechanism</a></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<table id="zip-0205" class="footnote"> <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> <tbody>
<tr> <tr>
<th>4</th> <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> </tr>
</tbody> </tbody>
</table> </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 The term "Sapling" in this document is to be interpreted as described in ZIP 205
[#zip-0205]_. [#zip-0205]_.
Abstract 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 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 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. 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 However, the Sapling v4 transaction format [#protocol-txnencodingandconsensus]_ includes
Sapling spend, and thus it is possible to leak additional information by using different a separate anchor for each Sapling spend, and thus it is possible to leak additional
anchors for different notes. The anchor selection choices could also be used as a information by using different anchors for different notes. The anchor selection choices
fingerprint to identify transactions created by particular wallet implementations, could also be used as a fingerprint to identify transactions created by particular wallet
reducing the privacy set. implementations, reducing the privacy set.
Modifying the transaction format to have a single Sapling anchor field, instead of one 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) field per Sapling spend, removes the ability (within the new transaction format version)
@ -104,7 +105,7 @@ TBD
References 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-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-0211.rst
View File

@ -143,7 +143,7 @@ https://github.com/zcash/zcash/pull/4489
References 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-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.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>`_ .. [#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>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" 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>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> <span class="math">\(\mathsf{PRF^{expand}}\)</span>
for the purposes of this ZIP. This function is keyed by a 256-bit key for the purposes of this ZIP. This function is keyed by a 256-bit key
<span class="math">\(\mathsf{sk}\)</span> <span class="math">\(\mathsf{sk}\)</span>
@ -92,7 +92,7 @@ License: MIT</pre>
<span class="math">\(64\)</span> <span class="math">\(64\)</span>
-byte sequence as output.</p> -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> <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> <span class="math">\(\textbf{0x01}\)</span>
, indicating the version of the note plaintext. In addition, a , indicating the version of the note plaintext. In addition, a
<span class="math">\(256\)</span> <span class="math">\(256\)</span>
@ -120,12 +120,12 @@ License: MIT</pre>
<span class="math">\(\mathsf{rseed}\)</span> <span class="math">\(\mathsf{rseed}\)</span>
(previously, (previously,
<span class="math">\(\mathsf{rcm}\)</span> <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>
<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> <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> <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> <span class="math">\(\mathsf{esk}\)</span>
uniformly at random.</p> uniformly at random.</p>
<p>After the activation of this ZIP, the sender MUST instead sample a uniformly random <p>After the activation of this ZIP, the sender MUST instead sample a uniformly random
@ -149,7 +149,7 @@ License: MIT</pre>
.</p> .</p>
</section> </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> <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>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>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> <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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -240,51 +240,51 @@ License: MIT</pre>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<table id="saplingencrypt" class="footnote"> <table id="protocol-saplingencrypt" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>3</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="abstractprfs" class="footnote"> <table id="protocol-abstractprfs" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>4</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="notept" class="footnote"> <table id="protocol-notept" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>5</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="saplingdecryptivk" class="footnote"> <table id="protocol-saplingdecryptivk" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>6</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="saplingdecryptovk" class="footnote"> <table id="protocol-saplingdecryptovk" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>7</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="saplingsend" class="footnote"> <table id="protocol-saplingsend" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>8</th> <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> </tr>
</tbody> </tbody>
</table> </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. that document for relevant corrections.
Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash 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 :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 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. 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 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 requires that the first byte take the form :math:`\textbf{0x01}`, indicating
the version of the note plaintext. In addition, a :math:`256`-bit the version of the note plaintext. In addition, a :math:`256`-bit
:math:`\mathsf{rcm}` field exists within the note plaintext and encoding. :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}`) The requirement that :math:`\mathsf{rseed}` (previously, :math:`\mathsf{rcm}`)
be a scalar of the Jubjub elliptic curve, when interpreted as a little endian 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 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 Changes to the process of sending Sapling notes
----------------------------------------------- -----------------------------------------------
The process of sending notes in Sapling is described in section 4.6.2 of the 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 Zcash Protocol Specification [#protocol-saplingsend]_. During this process, the
samples :math:`\mathsf{rcm^{new}}` uniformly at random. In addition, 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 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 Specification [#protocol-saplingencrypt]_. During this process, the sender also
the ephemeral private key :math:`\mathsf{esk}` uniformly at random. samples the ephemeral private key :math:`\mathsf{esk}` uniformly at random.
After the activation of this ZIP, the sender MUST instead sample a uniformly 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 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 The process of receiving notes in Sapling is described in sections 4.17.2 and
4.17.3 of the Zcash Protocol Specification. [#saplingdecryptivk]_ 4.17.3 of the Zcash Protocol Specification. [#protocol-saplingdecryptivk]_
[#saplingdecryptovk]_ [#protocol-saplingdecryptovk]_
There is a "grace period" of 32256 blocks starting from the block at which this 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 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 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>`_ .. [#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>`_ .. [#protocol-saplingencrypt] `Zcash Protocol Specification, Version 2020.1.15. Section 4.17.1: Encryption (Sapling) <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>`_ .. [#protocol-abstractprfs] `Zcash Protocol Specification, Version 2020.1.15. Section 4.1.2: Pseudo Random Functions <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>`_ .. [#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>`_
.. [#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>`_ .. [#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>`_
.. [#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>`_ .. [#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>`_
.. [#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-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-0207] `ZIP 207: Split Founders' Reward <zip-0207.rst>`_
.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_ .. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-0213.rst
View File

@ -189,7 +189,7 @@ https://github.com/zcash/zcash/pull/4256
References 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-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_ .. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#zip-0207] `ZIP 207: Split Founders' Reward <zip-0207.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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -279,7 +279,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -287,7 +287,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
<tbody> <tbody>
<tr> <tr>
<th>3</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -295,7 +295,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
<tbody> <tbody>
<tr> <tr>
<th>4</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -303,7 +303,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
<tbody> <tbody>
<tr> <tr>
<th>5</th> <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> </tr>
</tbody> </tbody>
</table> </table>

10
zip-0214.rst
View File

@ -336,11 +336,11 @@ This proposal is intended to be deployed with Canopy. [#zip-0251]_
References 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.13 or later [Canopy] <protocol/protocol.pdf>`_ .. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.13 [Canopy]. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_ .. [#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.13 [Canopy]. Section 3.9: Block Subsidy and Founders' Reward <protocol/protocol.pdf#subsidyconcepts>`_ .. [#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.13 [Canopy]. Section 7.7: Calculation of Block Subsidy and Founders' Reward <protocol/protocol.pdf#subsidies>`_ .. [#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>`_ .. [#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>`_ .. [#osd] `The Open Source Definition <https://opensource.org/osd>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -92,7 +92,7 @@ License: BSD-2-Clause</pre>
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -108,7 +108,7 @@ License: BSD-2-Clause</pre>
<tbody> <tbody>
<tr> <tr>
<th>4</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -116,7 +116,7 @@ License: BSD-2-Clause</pre>
<tbody> <tbody>
<tr> <tr>
<th>5</th> <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> </tr>
</tbody> </tbody>
</table> </table>

8
zip-0215.rst
View File

@ -111,9 +111,9 @@ which is scheduled to activate on Mainnet [#protocol-networks]_ at block height
References 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>`_
.. [#RFC8032] `Edwards-Curve Digital Signature Algorithm (EdDSA) <https://www.rfc-editor.org/rfc/rfc8032.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-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-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.13 [Canopy]. Section 5.4.5: Ed25519 <protocol/protocol.pdf#concreteed25519>`_ .. [#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>`_ .. [#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> <dt>Leaf node</dt>
<dd>The protocol-defined work of the block: <dd>The protocol-defined work of the block:
<span class="math">\(\mathsf{floor}(2^{256} / (\mathsf{ToTarget}(\mathsf{nBits}) + 1))\)</span> <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> <dt>Internal or root node</dt>
<dd> <dd>
<p>The sum of the <code>nSubTreeTotalWork</code> fields of both children.</p> <p>The sum of the <code>nSubTreeTotalWork</code> fields of both children.</p>
@ -510,7 +510,7 @@ License: MIT</pre>
</section> </section>
<section id="block-header-semantics-and-consensus-rules"><h3><span class="section-heading">Block header semantics and consensus rules</span><span class="section-anchor"> <a rel="bookmark" href="#block-header-semantics-and-consensus-rules"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3> <section id="block-header-semantics-and-consensus-rules"><h3><span class="section-heading">Block header semantics and consensus rules</span><span class="section-anchor"> <a rel="bookmark" href="#block-header-semantics-and-consensus-rules"><img width="24" height="24" 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>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> <blockquote>
<p>[Sapling onward] <code>hashLightClientRoot</code> MUST be <p>[Sapling onward] <code>hashLightClientRoot</code> MUST be
<span class="math">\(\mathsf{LEBS2OSP}_{256}(\mathsf{rt})\)</span> <span class="math">\(\mathsf{LEBS2OSP}_{256}(\mathsf{rt})\)</span>
@ -614,7 +614,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -626,19 +626,19 @@ License: MIT</pre>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<table id="block-work" class="footnote"> <table id="protocol-workdef" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>3</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="block-header" class="footnote"> <table id="protocol-blockheader" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>4</th> <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> </tr>
</tbody> </tbody>
</table> </table>

11
zip-0221.rst
View File

@ -284,7 +284,7 @@ Each MMR node is defined as follows:
Leaf node Leaf node
The protocol-defined work of the block: 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 Internal or root node
The sum of the ``nSubTreeTotalWork`` fields of both children. 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. by light clients.
Prior to activation of the network upgrade that deploys this ZIP, this existing consensus 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})` [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 where :math:`\mathsf{rt}` is the root of the Sapling note commitment tree for the final
@ -759,10 +759,10 @@ Additional Reading
References 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>`_ .. [#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>`_ .. [#protocol-workdef] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.5: Definition of Work <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-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>`_ .. [#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>`_ .. [#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>`_ .. [#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-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-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>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -338,7 +338,7 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
<tbody> <tbody>
<tr> <tr>
<th>7</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -346,7 +346,7 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
<tbody> <tbody>
<tr> <tr>
<th>8</th> <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> </tr>
</tbody> </tbody>
</table> </table>

6
zip-0222.rst
View File

@ -314,13 +314,13 @@ at Zcon1 that led to the earlier draft version of this ZIP.
References 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-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-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>`_ .. [#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>`_ .. [#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>`_ .. [#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] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol_consensus] `Zcash Protocol Specification, Version 2020.1.14 [Overwinter+Sapling+Blossom+Heartwood+Canopy] <protocol/protocol.pdf#txnencodingandconsensus>`_ .. [#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>`_ .. [#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>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -455,7 +455,7 @@ vJoinSplit: 00</pre>
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>

4
zip-0243.rst
View File

@ -526,8 +526,8 @@ https://github.com/zcash/zcash/pull/3233
References 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 [Overwinter+Sapling] <protocol/protocol.pdf>`_ .. [#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>`_ .. [#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-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -86,7 +86,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </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 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.1 or later <protocol/protocol.pdf>`_ .. [#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-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_ .. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.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> <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>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>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>
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" 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> <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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -83,7 +83,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -91,15 +91,15 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody> <tbody>
<tr> <tr>
<th>3</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="protocol-txnencoding" class="footnote"> <table id="protocol-txnencodingandconsensus" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>4</th> <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> </tr>
</tbody> </tbody>
</table> </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 Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not
define a new transaction version. Canopy transactions are therefore in the same 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 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 algorithm as defined in [#zip-0243]_. This does not imply that transactions are
valid across the Canopy activation, since signatures MUST use the appropriate valid across the Canopy activation, since signatures MUST use the appropriate
consensus branch ID. [#zip-0243]_ consensus branch ID. [#zip-0243]_
@ -127,10 +127,10 @@ in ``zcashd`` version 4.0.0, which will advertise protocol version 170013.
References 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.9 or later [Canopy] <protocol/canopy.pdf>`_ .. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/canopy.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet <protocol/canopy.pdf#networks>`_ .. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. 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>`_ .. [#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-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_ .. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0207] `ZIP 207: Funding Streams <zip-0207.rst>`_ .. [#zip-0207] `ZIP 207: Funding Streams <zip-0207.rst>`_

6
zip-0301.html
View File

@ -346,7 +346,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -354,7 +354,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -362,7 +362,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>3</th> <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> </tr>
</tbody> </tbody>
</table> </table>

6
zip-0301.rst
View File

@ -488,9 +488,9 @@ Thanks to:
References 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-blockheader] `Section 7.3: Block Headers. Zcash Protocol Specification, Version 2020.1.6 <protocol/protocol.pdf#blockheader>`_ .. [#protocol-blockheader] `Zcash Protocol Specification, Version 2020.1.15. Section 7.3: Block Headers <protocol/protocol.pdf#blockheader>`_
.. [#protocol-difficulty] `Section 7.6.2: Difficulty filter. Zcash Protocol Specification, Version 2020.1.6 <protocol/protocol.pdf#difficulty>`_ .. [#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/>`_ .. [#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>`_ .. [#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>`_ .. [#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> <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>
<section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#conventions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#conventions"><img width="24" height="24" 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> <ul>
<li> <li>
<span class="math">\(\mathsf{MerkleDepth}^\mathsf{Sapling}\)</span> <span class="math">\(\mathsf{MerkleDepth}^\mathsf{Sapling}\)</span>
and and
<span class="math">\(\mathsf{Uncommitted}^\mathsf{Sapling}\)</span> <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> <li>
<span class="math">\(\mathsf{MerkleCRH}^\mathsf{Sapling}\)</span> <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> <li>
<span class="math">\(\mathsf{DiversifyHash}(\mathsf{d})\)</span> <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> <li>
<span class="math">\(\mathsf{MixingPedersenHash}(\mathsf{cm}, position)\)</span> <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> <li>
<span class="math">\(\mathsf{PRF}^\mathsf{nfSapling}_\mathsf{nk}(ρ)\)</span> <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> <li>
<span class="math">\(\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})\)</span> <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> <span class="math">\(\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)\)</span>
, and , and
<span class="math">\(\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)\)</span> <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> <li>
<span class="math">\(\mathsf{NoteCommit}^\mathsf{Sapling}_\mathsf{rcm}(\mathsf{g_d}, \mathsf{pk_d}, value)\)</span> <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> <li>
<span class="math">\(\mathsf{ValueCommit}_\mathsf{rcv}(value)\)</span> <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> </ul>
<p>We also reproduce some notation and functions here for convenience:</p> <p>We also reproduce some notation and functions here for convenience:</p>
<ul> <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> <span class="math">\(\mathsf{repr}_\mathbb{J}(P)\)</span>
is the representation of the Jubjub elliptic curve point is the representation of the Jubjub elliptic curve point
<span class="math">\(P\)</span> <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> <li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\)</span> <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 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 <li>Its corresponding expanded spending key
<span class="math">\((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk})\)</span> <span class="math">\((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk})\)</span>
,</li> ,</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 <li>The message
<span class="math">\(msg\)</span> <span class="math">\(msg\)</span>
to be signed.</li> 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> <span class="math">\(path\)</span>
be the Merkle path from position 0 to be the Merkle path from position 0 to
<span class="math">\(\mathsf{rt}\)</span> <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 <li>Let
<span class="math">\(\mathsf{cv} = \mathsf{ValueCommit}_0(1)\)</span> <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> <span class="math">\((\mathsf{rt}, \mathsf{cv}, \mathsf{nf}, \mathsf{rk})\)</span>
and auxiliary input and auxiliary input
<span class="math">\((path, 0, \mathsf{g_d}, \mathsf{pk_d}, 1, 0, \mathsf{cm}, 0, α, \mathsf{ak}, \mathsf{nsk})\)</span> <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 <li>Let
<span class="math">\(\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{ask})\)</span> <span class="math">\(\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{ask})\)</span>
.</li> .</li>
@ -198,7 +198,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<li>The payment address <li>The payment address
<span class="math">\((\mathsf{d}, \mathsf{pk_d})\)</span> <span class="math">\((\mathsf{d}, \mathsf{pk_d})\)</span>
,</li> ,</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 <li>The message
<span class="math">\(msg\)</span> <span class="math">\(msg\)</span>
that is claimed to be signed, and</li> 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> <span class="math">\(path\)</span>
be the Merkle path from position 0 to be the Merkle path from position 0 to
<span class="math">\(\mathsf{rt}\)</span> <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 <li>Let
<span class="math">\(\mathsf{cv} = \mathsf{ValueCommit}_0(1)\)</span> <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> <span class="math">\(zkproof\)</span>
as a Sapling spend proof with primary input as a Sapling spend proof with primary input
<span class="math">\((\mathsf{rt}, \mathsf{cv}, \mathsf{nf}, \mathsf{rk})\)</span> <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> <li>Return true.</li>
</ul> </ul>
</section> </section>
@ -314,7 +314,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<tbody> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -322,111 +322,111 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/376">https://githu
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="protocol-spec" class="footnote"> <table id="protocol" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>3</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="constants" class="footnote"> <table id="protocol-merklepath" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>4</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="merkle-crh" class="footnote"> <table id="protocol-spendstatement" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>5</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="diversify-hash" class="footnote"> <table id="protocol-constants" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>6</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="mixing-pedersen-hash" class="footnote"> <table id="protocol-saplingmerklecrh" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>7</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="prfs" class="footnote"> <table id="protocol-concretediversifyhash" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>8</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="spend-auth-sig" class="footnote"> <table id="protocol-concretemixinghash" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>9</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="note-commit" class="footnote"> <table id="protocol-concreteprfs" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>10</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="value-commit" class="footnote"> <table id="protocol-concretespendauthsig" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>11</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="jubjub" class="footnote"> <table id="protocol-concretewindowedcommit" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>12</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="slip-0044" class="footnote"> <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> <tbody>
<tr> <tr>
<th>15</th> <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> </tr>
</tbody> </tbody>
</table> </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 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{MerkleDepth}^\mathsf{Sapling}` and
:math:`\mathsf{Uncommitted}^\mathsf{Sapling}` [#constants]_ :math:`\mathsf{Uncommitted}^\mathsf{Sapling}` [#protocol-constants]_
- :math:`\mathsf{MerkleCRH}^\mathsf{Sapling}` [#merkle-crh]_ - :math:`\mathsf{MerkleCRH}^\mathsf{Sapling}` [#protocol-saplingmerklecrh]_
- :math:`\mathsf{DiversifyHash}(\mathsf{d})` [#diversify-hash]_ - :math:`\mathsf{DiversifyHash}(\mathsf{d})` [#protocol-concretediversifyhash]_
- :math:`\mathsf{MixingPedersenHash}(\mathsf{cm}, position)` [#mixing-pedersen-hash]_ - :math:`\mathsf{MixingPedersenHash}(\mathsf{cm}, position)` [#protocol-concretemixinghash]_
- :math:`\mathsf{PRF}^\mathsf{nfSapling}_\mathsf{nk}(ρ)` [#prfs]_ - :math:`\mathsf{PRF}^\mathsf{nfSapling}_\mathsf{nk}(ρ)` [#protocol-concreteprfs]_
- :math:`\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})`, - :math:`\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})`,
:math:`\mathsf{SpendAuthSig.RandomizePublic}(α, \mathsf{vk})`, :math:`\mathsf{SpendAuthSig.RandomizePublic}(α, \mathsf{vk})`,
:math:`\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)`, and :math:`\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)`, and
:math:`\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)` [#spend-auth-sig]_ :math:`\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)` [#protocol-concretespendauthsig]_
- :math:`\mathsf{NoteCommit}^\mathsf{Sapling}_\mathsf{rcm}(\mathsf{g_d}, \mathsf{pk_d}, value)` [#note-commit]_ - :math:`\mathsf{NoteCommit}^\mathsf{Sapling}_\mathsf{rcm}(\mathsf{g_d}, \mathsf{pk_d}, value)` [#protocol-concretewindowedcommit]_
- :math:`\mathsf{ValueCommit}_\mathsf{rcv}(value)` [#value-commit]_ - :math:`\mathsf{ValueCommit}_\mathsf{rcv}(value)` [#protocol-concretehomomorphiccommit]_
We also reproduce some notation and functions here for convenience: We also reproduce some notation and functions here for convenience:
- :math:`a\,||\,b` means the concatenation of sequences :math:`a` then :math:`b`. - :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 - :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 - :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 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{MerkleCRH}^\mathsf{Sapling}`, containing :math:`\mathsf{cm}` at position 0, and
:math:`\mathsf{Uncommitted}^\mathsf{Sapling}` at all other positions. :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)`. - 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 - 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})` :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})`. 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})`. - 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{MerkleCRH}^\mathsf{Sapling}`, containing :math:`\mathsf{cm}` at position 0, and
:math:`\mathsf{Uncommitted}^\mathsf{Sapling}` at all other positions. :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)`. - Let :math:`\mathsf{cv} = \mathsf{ValueCommit}_0(1)`.
- This is a constant and may be pre-computed. - This is a constant and may be pre-computed.
- Decode and verify :math:`zkproof` as a Sapling spend proof with primary input - 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. - Return true.
@ -275,18 +275,18 @@ https://github.com/zcash/librustzcash/pull/210
References 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>`_
.. [#RFC4648] `The Base16, Base32, and Base64 Data Encodings <https://www.rfc-editor.org/rfc/rfc4648>`_ .. [#RFC4648] `RFC 4648: 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>`_ .. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <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>`_ .. [#protocol-merklepath] `Zcash Protocol Specification, Version 2020.1.15. Section 4.8: Merkle path validity <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>`_ .. [#protocol-spendstatement] `Zcash Protocol Specification, Version 2020.1.15. Section 4.15.2: Spend Statement (Sapling) <protocol/protocol.pdf#spendstatement>`_
.. [#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>`_ .. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
.. [#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>`_ .. [#protocol-saplingmerklecrh] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.3: Merkle Tree Hash Function <protocol/protocol.pdf#saplingmerklecrh>`_
.. [#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>`_ .. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.6: DiversifyHash Hash Function <protocol/protocol.pdf#concretediversifyhash>`_
.. [#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>`_ .. [#protocol-concretemixinghash] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.8: Mixing Pedersen Hash Function <protocol/protocol.pdf#concretemixinghash>`_
.. [#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>`_ .. [#protocol-concreteprfs] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.2: Pseudo Random Functions <protocol/protocol.pdf#concreteprfs>`_
.. [#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>`_ .. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature <protocol/protocol.pdf#concretespendauthsig>`_
.. [#jubjub] `Section 5.4.8.3: Jubjub. Zcash Protocol Specification, Version 2020.1.4 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf#jubjub>`_ .. [#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>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -527,7 +527,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -535,7 +535,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>3</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -543,7 +543,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>4</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -551,7 +551,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>5</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -559,7 +559,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>6</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -567,7 +567,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>7</th> <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> </tr>
</tbody> </tbody>
</table> </table>

14
zip-0307.rst
View File

@ -605,13 +605,13 @@ Electric Coin Company.
References References
========== ==========
.. [#RFC2119] `RFC 2119: 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>`_
.. [#protocol-merkletree] `Section 3.7: Note Commitment Trees. Zcash Protocol Specification, Version 2020.1.14 or later <protocol/protocol.pdf#merkletree>`_ .. [#protocol-merkletree] `Zcash Protocol Specification, Version 2020.1.15. Section 3.7: Note Commitment Trees <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-merklepath] `Zcash Protocol Specification, Version 2020.1.15. Section 4.8: Merkle Path Validity <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-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] `Section 5.5: Encodings of Note Plaintexts and Memo Fields. Zcash Protocol Specification, Version 2020.1.14 or later <protocol/protocol.pdf#notept>`_ .. [#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] `Section 7.3: Encoding of Spend Descriptions. Zcash Protocol Specification, Version 2020.1.14 or later <protocol/protocol.pdf#spendencoding>`_ .. [#protocol-spendencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 7.3: Encoding of Spend Descriptions <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>`_ .. [#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>`_ .. [#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/>`_ .. [#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>`_ .. [#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 Created: 2018-11-27
License: MIT</pre> License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" 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> <p>The terms below are to be interpreted as follows:</p>
<dl> <dl>
<dt>Sprout protocol</dt> <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> <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>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>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>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> <p>The security analysis of migration strategies is quite subtle; the more obvious potential strategies can leak a lot of information.</p>
</section> </section>
@ -226,19 +226,19 @@ License: MIT</pre>
</ul> </ul>
</section> </section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" 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"> <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> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>

4
zip-0308.rst
View File

@ -408,8 +408,8 @@ The following PRs implement this specification:
References 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] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC2119] `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-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.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>`_ .. [#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> <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> <dl>
<dt>Sapling FVK</dt> <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> <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> <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> <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>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> <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> <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> <li>Compute the balance as the sum of the values of all notes appearing in ReceivedSet but not in SpentSet.</li>
</ul> </ul>
<p>The following inaccuracies may occur in balance accounting:</p> <p>The following inaccuracies may occur in balance accounting:</p>
@ -159,14 +159,22 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="zip-0032" class="footnote"> <table id="zip-0032" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>2</th> <th>3</th>
<td><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td> <td><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td>
</tr> </tr>
</tbody> </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 * 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 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 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 4.19 of the Protocol Specification [#protocol-saplingscan]_. This produces
that were received by that tally, and a SpentSet of notes that were spent a ReceivedSet of notes that were received by that tally, and a SpentSet of
from it. notes that were spent from it.
* Compute the balance as the sum of the values of all notes appearing in * Compute the balance as the sum of the values of all notes appearing in
ReceivedSet but not in SpentSet. ReceivedSet but not in SpentSet.
@ -253,6 +253,6 @@ In addition to information learned from each individual FVK, Ian can infer:
References 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>`_ .. [#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> <tbody>
<tr> <tr>
<th>10</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -221,7 +221,7 @@ zcash:%74mEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1</pre>
<tbody> <tbody>
<tr> <tr>
<th>11</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -229,7 +229,7 @@ zcash:%74mEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1</pre>
<tbody> <tbody>
<tr> <tr>
<th>12</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -237,7 +237,7 @@ zcash:%74mEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1</pre>
<tbody> <tbody>
<tr> <tr>
<th>13</th> <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> </tr>
</tbody> </tbody>
</table> </table>

8
zip-0321.rst
View File

@ -306,7 +306,7 @@ References
.. [#base58check] `Bitcoin Wiki: Base58Check encoding <https://en.bitcoin.it/wiki/Base58Check_encoding>`_ .. [#base58check] `Bitcoin Wiki: Base58Check encoding <https://en.bitcoin.it/wiki/Base58Check_encoding>`_
.. [#zip-0173] `ZIP 173: Bech32 Format <zip-0173.rst>`_ .. [#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>`_ .. [#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-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.14 or later. Section 4.12: Balance and Binding Signature (Sapling) <protocol/protocol.pdf#saplingbalance>`_ .. [#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.14 or later. Section 5.6.1: Transparent Addresses <protocol/protocol.pdf#transparentaddrencoding>`_ .. [#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.14 or later. Section 5.6.4: Sapling Payment Addresses <protocol/protocol.pdf#saplingpaymentaddrencoding>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-0400.rst
View File

@ -141,7 +141,7 @@ For a deeper understanding of the current encryption mechanism please refer to [
References 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>`_ .. [#BDB] `Oracle Berkeley Database <https://www.oracle.com/database/berkeley-db/db.html>`_
.. [#ZIP400Issue] `ZIP 400 issue <https://github.com/zcash/zips/issues/350>`_ .. [#ZIP400Issue] `ZIP 400 issue <https://github.com/zcash/zips/issues/350>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -89,7 +89,7 @@ License: MIT</pre>
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>

4
zip-0401.rst
View File

@ -202,6 +202,6 @@ Reference implementation
References 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-0208] `Shorter Block Target Spacing <https://zips.z.cash/zip-0208>`_ .. [#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>`_ .. [#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> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-1001.rst
View File

@ -107,7 +107,7 @@ This ZIP requires no changes to current consensus implementations.
References 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/>`_ .. [#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-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>`_ .. [#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> <tbody>
<tr> <tr>
<th>3</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-1002.rst
View File

@ -196,5 +196,5 @@ Stuff that is already implemented in some form or another:
References 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/>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-1003.rst
View File

@ -153,7 +153,7 @@ development fund’ should instead not be minted.
References 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-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/>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-1004.rst
View File

@ -166,7 +166,7 @@ Raised objections and issues so far:
References 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>`_ .. [#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>`_ .. [#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>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-1006.rst
View File

@ -365,7 +365,7 @@ in Placeholder’s dev fund proposal from August 22, 2019 [#placeholder-proposal
References 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/>`_ .. [#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/>`_ .. [#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>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -94,7 +94,7 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/dev-fund-supplem
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>

4
zip-1007.rst
View File

@ -184,5 +184,5 @@ Raised Concerns
References 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-1006] `Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity <zip-1006.rst>`_ .. [#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> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-1008.rst
View File

@ -117,6 +117,6 @@ Implications to other users
References 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-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <zip-0206.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-1010.rst
View File

@ -342,7 +342,7 @@ Issues and further discussion
References 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>`_ .. [#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/>`_ .. [#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>`_ .. [#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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>

2
zip-1013.rst
View File

@ -133,4 +133,4 @@ continuing any prior proportions.
References 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> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -154,7 +154,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">https://githu
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>

4
zip-1014.rst
View File

@ -373,8 +373,8 @@ and *@dontbeevil* for valuable initial comments on ZIP 1012.
References 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 [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_ .. [#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>`_ .. [#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>`_ .. [#osd] `The Open Source Definition <https://opensource.org/osd>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_ .. [#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> <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>{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>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>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2> <section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>{Why is this proposal needed?</p> <p>{Why is this proposal needed?</p>
@ -78,7 +78,7 @@ sudo pip3 install rst2html5</pre>
<tbody> <tbody>
<tr> <tr>
<th>1</th> <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> </tr>
</tbody> </tbody>
</table> </table>
@ -86,14 +86,22 @@ sudo pip3 install rst2html5</pre>
<tbody> <tbody>
<tr> <tr>
<th>2</th> <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> </tr>
</tbody> </tbody>
</table> </table>
<table id="zip-xxxx" class="footnote"> <table id="zip-xxxx" class="footnote">
<tbody> <tbody>
<tr> <tr>
<th>3</th> <th>4</th>
<td><a href="zip-xxxx">ZIP xxxx: Title</a></td> <td><a href="zip-xxxx">ZIP xxxx: Title</a></td>
</tr> </tr>
</tbody> </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 The Abstract should only provide a summary of the ZIP; the ZIP should remain
complete without the Abstract. complete without the Abstract.
Use links where applicable, e.g. [#protocol]_.} Use links where applicable, e.g. [#protocol]_ [#protocol-introduction]_.}
Motivation Motivation
@ -138,6 +138,7 @@ zebrad PRs.}
References 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 {...} or later <protocol/protocol.pdf>`_ .. [#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>`_ .. [#zip-xxxx] `ZIP xxxx: Title <zip-xxxx.rst>`_