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

ZIP 214: add rationale section. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-03-13 17:19:26 +00:00
parent 4fd8f06bc1
commit 0bd85486fe
2 changed files with 30 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
zip-0214.html
View File

@ -121,8 +121,14 @@ Discussions-To: &lt;https://forum.zcashcommunity.com/t/community-sentiment-polli
<p>TODO</p>
</section>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The rationale for ZF generating the addresses for the <code>ZF_MG</code> funding stream is that ZF is the financial recipient of the <strong>MG slice</strong> as specified in ZIP 1014. <a id="id15" class="footnote_reference" href="#zip-1014">9</a></p>
<p>Generation of recipient addresses for Testnet is specified to be done by the same parties as on Mainnet, in order to allow practicing each party's security procedures.</p>
<p>Since Testnet is ahead of Mainnet in terms of block height (by ~77000 blocks at the time of writing, which is the equivalent of ~67 days at the post-Blossom block target spacing), the activation height and the start heights of the funding streams could have also been set to 1046400 on Testnet. However, 67 days is arguably too short a testing period, and the block rate on Testnet is less predictable than on Mainnet.</p>
<p>It was judged to be unnecessary to have a mechanism to update funding stream definitions (in case of security breach or changes to direct grant recipients) other than at network upgrades.</p>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal is intended to be deployed with ${NU4}. <a id="id15" class="footnote_reference" href="#zip-0251">8</a></p>
<p>This proposal is intended to be deployed with ${NU4}. <a id="id16" class="footnote_reference" href="#zip-0251">8</a></p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">

23
zip-0214.rst
View File

@ -322,6 +322,29 @@ Testnet Recipient Addresses
TODO
Rationale
=========
The rationale for ZF generating the addresses for the ``ZF_MG`` funding
stream is that ZF is the financial recipient of the **MG slice** as specified
in ZIP 1014. [#zip-1014]_
Generation of recipient addresses for Testnet is specified to be done by the
same parties as on Mainnet, in order to allow practicing each party's security
procedures.
Since Testnet is ahead of Mainnet in terms of block height (by ~77000 blocks
at the time of writing, which is the equivalent of ~67 days at the post-Blossom
block target spacing), the activation height and the start heights of the
funding streams could have also been set to 1046400 on Testnet. However,
67 days is arguably too short a testing period, and the block rate on Testnet
is less predictable than on Mainnet.
It was judged to be unnecessary to have a mechanism to update funding stream
definitions (in case of security breach or changes to direct grant recipients)
other than at network upgrades.
Deployment
==========