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

ZIP 214: allow addresses within a funding stream to be repeated. 

Remove definitions of unused RFC 2119 keywords.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-03-24 23:07:45 +00:00
parent d3784f64c4
commit 27accd4cc3
2 changed files with 11 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
zip-0214.html
View File

@ -15,7 +15,7 @@ Created: 2020-02-28
License: MIT
Discussions-To: &lt;https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560&gt;</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The key words "MUST", "SHALL", and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (<a id="id2" class="footnote_reference" href="#trademark">3</a> or successor agreement).</p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id3" class="footnote_reference" href="#zip-0200">5</a> and the Zcash Trademark Donation and License Agreement (<a id="id4" class="footnote_reference" href="#trademark">3</a> or successor agreement).</p>
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="id5" class="footnote_reference" href="#protocol">2</a></p>
@ -92,11 +92,12 @@ Discussions-To: &lt;https://forum.zcashcommunity.com/t/community-sentiment-polli
<p>The funding streams are defined for Testnet are identical except that the start height of each stream is the activation height of ${NU4} on Testnet, i.e. xxxxxxx.</p>
<p>Note: on Testnet, the activation height of ${NU4} will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1046400) be double the number of currency units as the corresponding initial amount on Mainnet. This reduces to the same number of currency units as on Mainnet, from Testnet block heights 1046400 (inclusive) to 2726400 (exclusive).</p>
<section id="dev-fund-recipient-addresses"><h3><span class="section-heading">Dev Fund Recipient Addresses</span><span class="section-anchor"> <a href="#dev-fund-recipient-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC and ZF) SHALL generate sequences of independent recipient addresses to be used for each stream in each funding period:</p>
<p>For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC and ZF) SHALL generate sequences of recipient addresses to be used for each stream in each funding period:</p>
<ul>
<li>ECC SHALL generate the addresses for the <code>FS_ECC</code> funding stream, which on Mainnet corresponds to the <strong>ECC slice</strong>;</li>
<li>ZF SHALL generate the addresses for the <code>FS_ZF</code> and <code>FS_MG</code> funding streams, which on Mainnet correspond to the <strong>ZF slice</strong> and <strong>MG slice</strong> respectively.</li>
</ul>
<p>Within each stream, the addresses MAY be independent, or MAY be repeated between funding periods. Each party SHOULD take account of operational security issues associated with potential compromise of the associated spending keys.</p>
<p>Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 <a id="id13" class="footnote_reference" href="#zip-1014">9</a>.</p>
<p>No requirements are imposed on the use of funds sent to Testnet funding streams.</p>
<section id="direct-grant-option"><h4><span class="section-heading">Direct-grant option</span><span class="section-anchor"> <a href="#direct-grant-option"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>

12
zip-0214.rst
View File

@ -13,8 +13,8 @@
Terminology
===========
The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY"
in this document are to be interpreted as described in RFC 2119. [#RFC2119]_
The key words "MUST", "SHALL", and "SHOULD" in this document are to be
interpreted as described in RFC 2119. [#RFC2119]_
The term "Zcash" in this document is to be interpreted as described in the
Zcash Trademark Donation and License Agreement ([#trademark]_ or successor
@ -132,14 +132,18 @@ Dev Fund Recipient Addresses
For each of Testnet and Mainnet, before deploying this ZIP in a node implementation
with the activation height set for that network, each of the parties (ECC and ZF)
SHALL generate sequences of independent recipient addresses to be used for each
stream in each funding period:
SHALL generate sequences of recipient addresses to be used for each stream in each
funding period:
* ECC SHALL generate the addresses for the ``FS_ECC`` funding stream, which on
Mainnet corresponds to the **ECC slice**;
* ZF SHALL generate the addresses for the ``FS_ZF`` and ``FS_MG`` funding streams,
which on Mainnet correspond to the **ZF slice** and **MG slice** respectively.
Within each stream, the addresses MAY be independent, or MAY be repeated between
funding periods. Each party SHOULD take account of operational security issues
associated with potential compromise of the associated spending keys.
Funds sent to each Mainnet funding stream SHALL be governed by all requirements on
the corresponding slice specified in ZIP 1014 [#zip-1014]_.