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

Merge branch 'master' of github.com:zcash/zips into dev-fund-to-ecc-zfnd-mg

This commit is contained in:
Daira Hopwood 2019-11-29 02:10:05 +00:00
parent 3ce38d841f 4c3d52b342
commit 9400bfea47
65 changed files with 5009 additions and 140 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Makefile
View File

@ -11,13 +11,15 @@ index.html: README.rst
$(eval TITLE::=$(shell echo '$(basename $<)' | sed -r 's|zip-0{0,3}|ZIP |'): $(shell grep -E '^(\.\.)?\s*Title:' $< |sed 's|.*Title:\s*||'))
rst2html5 -v --title="$(TITLE)" $< >$@
sed -i 's|</head>|<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>|' $@
sed -i 's|<a href="\([^":]*\).rst">|<a href="\1">|' $@
%.html: %.rst
$(eval TITLE::=$(shell echo '$(basename $<)' | sed -r 's|zip-0{0,3}|ZIP |'): $(shell grep -E '^(\.\.)?\s*Title:' $< |sed 's|.*Title:\s*||'))
rst2html5 -v --title="$(TITLE)" $< >$@
sed -i 's|</head>|<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>|' $@
sed -i 's|<a href="\([^":]*\).rst">|<a href="\1">|' $@
README.rst: makeindex.sh README.template
README.rst: makeindex.sh README.template $(filter-out README.rst,$(wildcard *.rst))
./makeindex.sh | cat README.template - >README.rst
.PHONY: clean

48
README.rst
View File

@ -9,6 +9,9 @@ cryptocurrency <https://z.cash/>`__.
Participation in the Zcash project is subject to a `Code of
Conduct <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`__.
The ZIP process is documented in `ZIP 0 <zip-0000.rst>`__.
NU3 ZIPs for consideration
--------------------------
@ -63,20 +66,33 @@ Index of ZIPs
<embed><table>
<tr> <th>ZIP</th> <th>Title</th> <th>Status</th> </tr>
<tr> <td>0</td> <td class="left"><a href="zip-0000">ZIP Process</a></td> <td>Active</td>
<tr> <td>32</td> <td class="left"><a href="zip-0032">Shielded Hierarchical Deterministic Wallets</a></td> <td>Final</td>
<tr> <td>143</td> <td class="left"><a href="zip-0143">Transaction Signature Verification for Overwinter</a></td> <td>Final</td>
<tr> <td>200</td> <td class="left"><a href="zip-0200">Network Upgrade Mechanism</a></td> <td>Final</td>
<tr> <td>201</td> <td class="left"><a href="zip-0201">Network Peer Management for Overwinter</a></td> <td>Final</td>
<tr> <td>202</td> <td class="left"><a href="zip-0202">Version 3 Transaction Format for Overwinter</a></td> <td>Final</td>
<tr> <td>203</td> <td class="left"><a href="zip-0203">Transaction Expiry</a></td> <td>Final</td>
<tr> <td>205</td> <td class="left"><a href="zip-0205">Deployment of the Sapling Network Upgrade</a></td> <td>Final</td>
<tr> <td>206</td> <td class="left"><a href="zip-0206">Deployment of the Blossom Network Upgrade</a></td> <td>Draft</td>
<tr> <td><strike>207</strike></td> <td class="left"><strike><a href="zip-0207">Split Founders' Reward</a></strike></td> <td>Withdrawn</td>
<tr> <td>208</td> <td class="left"><a href="zip-0208">Shorter Block Target Spacing</a></td> <td>Implemented</td>
<tr> <td>209</td> <td class="left"><a href="zip-0209">Prohibit Negative Shielded Value Pool</a></td> <td>Final</td>
<tr> <td>210</td> <td class="left"><a href="zip-0210">Sapling Anchor Deduplication within Transactions</a></td> <td>Draft</td>
<tr> <td>243</td> <td class="left"><a href="zip-0243">Transaction Signature Verification for Sapling</a></td> <td>Final</td>
<tr> <td>308</td> <td class="left"><a href="zip-0308">Sprout to Sapling Migration</a></td> <td>Final</td>
<tr> <td>guide</td> <td class="left"><a href="zip-guide">{Something Short and To the Point}</a></td> <td>Draft</td>
<tr> <td>0</td> <td class="left"><a href="zip-0000.rst">ZIP Process</a></td> <td>Active</td>
<tr> <td>32</td> <td class="left"><a href="zip-0032.rst">Shielded Hierarchical Deterministic Wallets</a></td> <td>Final</td>
<tr> <td>143</td> <td class="left"><a href="zip-0143.rst">Transaction Signature Verification for Overwinter</a></td> <td>Final</td>
<tr> <td>200</td> <td class="left"><a href="zip-0200.rst">Network Upgrade Mechanism</a></td> <td>Final</td>
<tr> <td>201</td> <td class="left"><a href="zip-0201.rst">Network Peer Management for Overwinter</a></td> <td>Final</td>
<tr> <td>202</td> <td class="left"><a href="zip-0202.rst">Version 3 Transaction Format for Overwinter</a></td> <td>Final</td>
<tr> <td>203</td> <td class="left"><a href="zip-0203.rst">Transaction Expiry</a></td> <td>Final</td>
<tr> <td>205</td> <td class="left"><a href="zip-0205.rst">Deployment of the Sapling Network Upgrade</a></td> <td>Final</td>
<tr> <td>206</td> <td class="left"><a href="zip-0206.rst">Deployment of the Blossom Network Upgrade</a></td> <td>Draft</td>
<tr> <td><strike>207</strike></td> <td class="left"><strike><a href="zip-0207.rst">Split Founders' Reward</a></strike></td> <td>Withdrawn</td>
<tr> <td>208</td> <td class="left"><a href="zip-0208.rst">Shorter Block Target Spacing</a></td> <td>Implemented</td>
<tr> <td>209</td> <td class="left"><a href="zip-0209.rst">Prohibit Negative Shielded Value Pool</a></td> <td>Final</td>
<tr> <td>210</td> <td class="left"><a href="zip-0210.rst">Sapling Anchor Deduplication within Transactions</a></td> <td>Draft</td>
<tr> <td>243</td> <td class="left"><a href="zip-0243.rst">Transaction Signature Verification for Sapling</a></td> <td>Final</td>
<tr> <td>308</td> <td class="left"><a href="zip-0308.rst">Sprout to Sapling Migration</a></td> <td>Final</td>
<tr> <td>401</td> <td class="left"><a href="zip-0401.rst">Addressing mempool denial-of-service</a></td> <td>Final</td>
<tr> <td>1001</td> <td class="left"><a href="zip-1001.rst">Keep the Block Distribution as Initially Defined — 90% to Miners</a></td> <td>Draft</td>
<tr> <td>1002</td> <td class="left"><a href="zip-1002.rst">Opt-in Donation Feature</a></td> <td>Draft</td>
<tr> <td>1003</td> <td class="left"><a href="zip-1003.rst">20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</a></td> <td>Draft</td>
<tr> <td>1004</td> <td class="left"><a href="zip-1004.rst">Miner-Directed Dev Fund</a></td> <td>Draft</td>
<tr> <td>1005</td> <td class="left"><a href="zip-1005.rst">Zcash Community Funding System</a></td> <td>Draft</td>
<tr> <td>1006</td> <td class="left"><a href="zip-1006.rst">Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity</a></td> <td>Draft</td>
<tr> <td>1007</td> <td class="left"><a href="zip-1007.rst">Enforce Development Fund Commitments with a Legal Charter</a></td> <td>Draft</td>
<tr> <td>1008</td> <td class="left"><a href="zip-1008.rst">Fund ECC for Two More Years</a></td> <td>Draft</td>
<tr> <td>1009</td> <td class="left"><a href="zip-1009.rst">Five-Entity Strategic Council</a></td> <td>Draft</td>
<tr> <td>1010</td> <td class="left"><a href="zip-1010.rst">Compromise Dev Fund Proposal With Diverse Funding Streams</a></td> <td>Draft</td>
<tr> <td>1011</td> <td class="left"><a href="zip-1011.rst">Decentralize the Dev Fee</a></td> <td>Draft</td>
<tr> <td>1013</td> <td class="left"><a href="zip-1013.rst">Keep It Simple, Zcashers: 10% to ECC, 10% to ZF</a></td> <td>Draft</td>
<tr> <td>guide</td> <td class="left"><a href="zip-guide.rst">{Something Short and To the Point}</a></td> <td>Draft</td>
</table></embed>

3
README.template
View File

@ -9,6 +9,9 @@ cryptocurrency <https://z.cash/>`__.
Participation in the Zcash project is subject to a `Code of
Conduct <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`__.
The ZIP process is documented in `ZIP 0 <zip-0000.rst>`__.
NU3 ZIPs for consideration
--------------------------

2
assets/css/style.css
View File

File diff suppressed because one or more lines are too long

3
css/zip-style.css
View File

@ -18,3 +18,6 @@ tr:hover { background-color: #f5f5f5; }
#references th::before { content: "["; }
#references th::after { content: "]"; }
#references td { text-align: left !important; padding: 0 !important; border: 0 !important; }
.editor-note { color: #800000; }
.editor-note::before { content: "[Editor note: "; }
.editor-note::after { content: "]"; }

14
index.html
View File

@ -10,6 +10,7 @@
<!-- Title: Specifications and Zcash Improvement Proposals -->
<p>Specifications and Zcash Improvement Proposals for the <a href="https://z.cash/">Zcash cryptocurrency</a>.</p>
<p>Participation in the Zcash project is subject to a <a href="https://github.com/zcash/zcash/blob/master/code_of_conduct.md">Code of Conduct</a>.</p>
<p>The ZIP process is documented in <a href="zip-0000">ZIP 0</a>.</p>
<section id="nu3-zips-for-consideration">
<h2>NU3 ZIPs for consideration</h2>
<p>This is the list of ZIPs that were under consideration for the NU3 upgrade (around ~April 2020).</p>
@ -80,6 +81,19 @@
<tr> <td>210</td> <td class="left"><a href="zip-0210">Sapling Anchor Deduplication within Transactions</a></td> <td>Draft</td>
<tr> <td>243</td> <td class="left"><a href="zip-0243">Transaction Signature Verification for Sapling</a></td> <td>Final</td>
<tr> <td>308</td> <td class="left"><a href="zip-0308">Sprout to Sapling Migration</a></td> <td>Final</td>
<tr> <td>401</td> <td class="left"><a href="zip-0401">Addressing mempool denial-of-service</a></td> <td>Final</td>
<tr> <td>1001</td> <td class="left"><a href="zip-1001">Keep the Block Distribution as Initially Defined — 90% to Miners</a></td> <td>Draft</td>
<tr> <td>1002</td> <td class="left"><a href="zip-1002">Opt-in Donation Feature</a></td> <td>Draft</td>
<tr> <td>1003</td> <td class="left"><a href="zip-1003">20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</a></td> <td>Draft</td>
<tr> <td>1004</td> <td class="left"><a href="zip-1004">Miner-Directed Dev Fund</a></td> <td>Draft</td>
<tr> <td>1005</td> <td class="left"><a href="zip-1005">Zcash Community Funding System</a></td> <td>Draft</td>
<tr> <td>1006</td> <td class="left"><a href="zip-1006">Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity</a></td> <td>Draft</td>
<tr> <td>1007</td> <td class="left"><a href="zip-1007">Enforce Development Fund Commitments with a Legal Charter</a></td> <td>Draft</td>
<tr> <td>1008</td> <td class="left"><a href="zip-1008">Fund ECC for Two More Years</a></td> <td>Draft</td>
<tr> <td>1009</td> <td class="left"><a href="zip-1009">Five-Entity Strategic Council</a></td> <td>Draft</td>
<tr> <td>1010</td> <td class="left"><a href="zip-1010">Compromise Dev Fund Proposal With Diverse Funding Streams</a></td> <td>Draft</td>
<tr> <td>1011</td> <td class="left"><a href="zip-1011">Decentralize the Dev Fee</a></td> <td>Draft</td>
<tr> <td>1013</td> <td class="left"><a href="zip-1013">Keep It Simple, Zcashers: 10% to ECC, 10% to ZF</a></td> <td>Draft</td>
<tr> <td>guide</td> <td class="left"><a href="zip-guide">{Something Short and To the Point}</a></td> <td>Draft</td>
</table></embed></section>
</section>

5
makeindex.sh
View File

@ -11,10 +11,11 @@ Index of ZIPs
<tr> <th>ZIP</th> <th>Title</th> <th>Status</th> </tr>
EndOfHeader
for zipfile in zip-*.rst; do
echo Adding $zipfile to index. >/dev/stderr
if grep -E '^\s*Status:\s*(Withdrawn|Rejected|Obsolete)' $zipfile >/dev/null; then
echo " <tr> <td><strike>`basename $zipfile .rst | sed -r 's@zip-0{0,3}@@'`</strike></td> <td class=\"left\"><strike><a href=\"`basename $zipfile .rst`\">`grep '^\s*Title:' $zipfile | sed 's@\s*Title:\s*@@'`</a></strike></td> <td>`grep '^\s*Status:' $zipfile | sed 's@\s*Status:\s*@@'`</td>"
echo " <tr> <td><strike>`basename $zipfile .rst | sed -r 's@zip-0{0,3}@@'`</strike></td> <td class=\"left\"><strike><a href=\"`echo $zipfile`\">`grep '^\s*Title:' $zipfile | sed 's@\s*Title:\s*@@'`</a></strike></td> <td>`grep '^\s*Status:' $zipfile | sed 's@\s*Status:\s*@@'`</td>"
else
echo " <tr> <td>`basename $zipfile .rst | sed -r 's@zip-0{0,3}@@'`</td> <td class=\"left\"><a href=\"`basename $zipfile .rst`\">`grep '^\s*Title:' $zipfile | sed 's@\s*Title:\s*@@'`</a></td> <td>`grep '^\s*Status:' $zipfile | sed 's@\s*Status:\s*@@'`</td>"
echo " <tr> <td>`basename $zipfile .rst | sed -r 's@zip-0{0,3}@@'`</td> <td class=\"left\"><a href=\"`echo $zipfile`\">`grep '^\s*Title:' $zipfile | sed 's@\s*Title:\s*@@'`</a></td> <td>`grep '^\s*Status:' $zipfile | sed 's@\s*Status:\s*@@'`</td>"
fi
done
echo " </table></embed>"

6
zip-0000.html
View File

@ -9,7 +9,9 @@
<pre>ZIP: 0
Title: ZIP Process
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Josh Cincinnati &lt;josh@zfnd.org&gt;
George Tankersley &lt;george@zfnd.org&gt;
Original-Authors: Daira Hopwood &lt;daira@electriccoin.co&gt;
Josh Cincinnati &lt;josh@zfnd.org&gt;
Credits: Luke Dashjr
Status: Active
Category: Process
@ -268,7 +270,7 @@ Updates:</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0200.rst">ZIP 200: Network Upgrade Activation Mechanism</a></td>
<td><a href="zip-0200">ZIP 200: Network Upgrade Activation Mechanism</a></td>
</tr>
</tbody>
</table>

6
zip-0000.rst
View File

@ -3,7 +3,9 @@
ZIP: 0
Title: ZIP Process
Owners: Daira Hopwood <daira@electriccoin.co>
Josh Cincinnati <josh@zfnd.org>
George Tankersley <george@zfnd.org>
Original-Authors: Daira Hopwood <daira@electriccoin.co>
Josh Cincinnati <josh@zfnd.org>
Credits: Luke Dashjr
Status: Active
Category: Process
@ -596,7 +598,7 @@ References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#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 <zip-0200.rst>`_
.. [#conduct] `Zcash Code of Conduct <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`_
.. [#rst] `reStructuredText documentation <http://docutils.sourceforge.net/rst.html>`_
.. [#latex] `LaTeX -- a document preparation system <https://www.latex-project.org/>`_

70
zip-0032.html
View File

@ -20,7 +20,7 @@ License: MIT</pre>
<section id="terminology">
<h2>Terminology</h2>
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">1</a></p>
<p>"Jubjub" refers to the elliptic curve defined in <a href="#sapling-spec" id="id2" class="footnote_reference">8</a> section 5.4.8.3.</p>
<p>"Jubjub" refers to the elliptic curve defined in <a href="#sapling-jubjub" id="id2" class="footnote_reference">12</a>.</p>
</section>
<section id="abstract">
<h2>Abstract</h2>
@ -49,14 +49,14 @@ License: MIT</pre>
<li>LEOS2IP<sub>l</sub>(<em>S</em>) is the integer in range {0..2<sup>l</sup>-1} represented in little-endian order by the byte sequence <em>S</em> of length <em>l</em>/8.</li>
<li>I2LEBSP<sub>l</sub>(<em>k</em>) is the sequence of <em>l</em> bits representing <em>k</em> in little-endian order.</li>
<li>LEBS2OSP<sub>l</sub>(<em>B</em>) is defined as follows when <em>l</em> is a multiple of 8: convert each group of 8 bits in <em>B</em> to a byte value with the least significant bit first, and concatenate the resulting bytes in the same order as the groups.</li>
<li>repr<sub>𝕁</sub>(<em>P</em>) is the representation of the Jubjub elliptic curve point <em>P</em> as a bit sequence, defined in <a href="#sapling-spec" id="id9" class="footnote_reference">8</a> section 5.4.8.3.</li>
<li>repr<sub>𝕁</sub>(<em>P</em>) is the representation of the Jubjub elliptic curve point <em>P</em> as a bit sequence, defined in <a href="#sapling-jubjub" id="id9" class="footnote_reference">12</a>.</li>
<li>BLAKE2b-256(<em>p</em>, <em>x</em>) refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string <em>p</em>, and input <em>x</em>.</li>
<li>BLAKE2b-512(<em>p</em>, <em>x</em>) refers to unkeyed BLAKE2b-512 in sequential mode, with an output digest length of 64 bytes, 16-byte personalization string <em>p</em>, and input <em>x</em>.</li>
<li>PRF<sup>expand</sup>(<em>sk</em>, <em>t</em>) := BLAKE2b-512("Zcash_ExpandSeed", <em>sk</em> || <em>t</em>)</li>
<li>ToScalar(<em>x</em>) := LEOS2IP<sub>512</sub>(<em>x</em>) (mod <em>r</em><sub>𝕁</sub>), where <em>r</em><sub>𝕁</sub> is the order of the Jubjub large prime subgroup.</li>
<li>DiversifyHash(<em>d</em>) maps a diversifier <em>d</em> to a base point on the Jubjub elliptic curve, or to ⊥ if the diversifier is invalid. It is instantiated in <a href="#sapling-spec" id="id10" class="footnote_reference">8</a> section 5.4.1.6.</li>
<li>DiversifyHash(<em>d</em>) maps a diversifier <em>d</em> to a base point on the Jubjub elliptic curve, or to ⊥ if the diversifier is invalid. It is instantiated in <a href="#sapling-diversifyhash" id="id10" class="footnote_reference">10</a>.</li>
</ul>
<p>The following algorithm standardized in <a href="#nist-sp-800-38g" id="id11" class="footnote_reference">10</a> is used:</p>
<p>The following algorithm standardized in <a href="#nist-sp-800-38g" id="id11" class="footnote_reference">16</a> is used:</p>
<ul>
<li>FF1-AES256.Encrypt(<em>key</em>, <em>tweak</em>, <em>x</em>) refers to the FF1 encryption algorithm using AES with a 256-bit <em>key</em>, and parameters <em>radix</em> = 2, <em>minlen</em> = 88, <em>maxlen</em> = 88. It will be used only with the empty string "" as the <em>tweak</em>. <em>x</em> is a sequence of 88 bits, as is the output.</li>
</ul>
@ -139,7 +139,7 @@ License: MIT</pre>
</section>
<section id="deriving-a-child-extended-full-viewing-key">
<h4>Deriving a child extended full viewing key</h4>
<p>Let 𝓖 be as defined in <a href="#sapling-spec" id="id16" class="footnote_reference">8</a> section 5.4.6.1 and let 𝓗 be as defined in <a href="#sapling-key-components" id="id17" class="footnote_reference">9</a>.</p>
<p>Let 𝓖 be as defined in <a href="#sapling-spendauthsig" id="id16" class="footnote_reference">11</a> and let 𝓗 be as defined in <a href="#sapling-key-components" id="id17" class="footnote_reference">9</a>.</p>
<p>CDKfvk((<em>ak</em><sub>par</sub>, <em>nk</em><sub>par</sub>, <em>ovk</em><sub>par</sub>, <em>dk</em><sub>par</sub>, <em>c</em><sub>par</sub>), <em>i</em>) → (<em>ak</em><sub>i</sub>, <em>nk</em><sub>i</sub>, <em>ovk</em><sub>i</sub>, <em>dk</em><sub>i</sub>, <em>c</em><sub>i</sub>)</p>
<ul>
<li>Check whether <em>i</em> ≥ 2<sup>31</sup> (whether the child is a hardened key).
@ -184,7 +184,7 @@ License: MIT</pre>
</section>
<section id="sprout-helper-functions">
<h3>Sprout helper functions</h3>
<p>Let EncodeASK(<em>a</em><sub>sk</sub>) be the 32-byte encoding of <em>a</em><sub>sk</sub> in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in <a href="#sapling-spec" id="id18" class="footnote_reference">8</a> section 5.6.8.</p>
<p>Let EncodeASK(<em>a</em><sub>sk</sub>) be the 32-byte encoding of <em>a</em><sub>sk</sub> in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in <a href="#sprout-spending-keys" id="id18" class="footnote_reference">15</a>.</p>
<p>Let DecodeASK(<em>ASK</em>) be the result of clearing the 4 most significant bits of the first byte of <em>ASK</em>, and decoding the 32-byte result according to the inverse of EncodeASK.</p>
</section>
<section id="sprout-master-key-generation">
@ -246,7 +246,7 @@ License: MIT</pre>
<h2>Specification: Fingerprints and Tags</h2>
<section id="sapling-full-viewing-key-fingerprints-and-tags">
<h3>Sapling Full Viewing Key Fingerprints and Tags</h3>
<p>A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding <em>FVK</em> (as specified in <a href="#sapling-spec" id="id23" class="footnote_reference">8</a> section 5.6.7) is given by:</p>
<p>A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding <em>FVK</em> (as specified in <a href="#sapling-full-viewing-keys" id="id23" class="footnote_reference">14</a>) is given by:</p>
<blockquote>
<p>BLAKE2b-256("ZcashSaplingFVFP", <em>FVK</em>)</p>
</blockquote>
@ -255,7 +255,7 @@ License: MIT</pre>
</section>
<section id="sprout-address-fingerprints-and-tags">
<h3>Sprout Address Fingerprints and Tags</h3>
<p>A "Sprout address fingerprint" of a Sprout payment address with raw encoding <em>ADDR</em> (as specified in <a href="#sapling-spec" id="id24" class="footnote_reference">8</a> section 5.6.3, including the lead bytes) is given by:</p>
<p>A "Sprout address fingerprint" of a Sprout payment address with raw encoding <em>ADDR</em> (as specified in <a href="#sprout-shielded-addresses" id="id24" class="footnote_reference">13</a>, including the lead bytes) is given by:</p>
<blockquote>
<p>BLAKE2b-256("Zcash_Sprout_AFP", <em>ADDR</em>)</p>
</blockquote>
@ -378,7 +378,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>8</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Zcash Protocol Specification, Version 2018.0-beta-25 or later [Overwinter+Sapling]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2019.0.8 or later [Overwinter+Sapling+Blossom]</a></td>
</tr>
</tbody>
</table>
@ -386,14 +386,62 @@ License: MIT</pre>
<tbody>
<tr>
<th>9</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Section 4.2.2: Sapling Key Components. Zcash Protocol Specification, Version 2018.0-beta-25 or later [Overwinter+Sapling]</a></td>
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Section 4.2.2 Sapling Key Components</a></td>
</tr>
</tbody>
</table>
<table id="sapling-diversifyhash" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Section 5.4.1.6 DiversifyHash Hash Function</a></td>
</tr>
</tbody>
</table>
<table id="sapling-spendauthsig" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="protocol/protocol.pdf#concretespendauthsig">Zcash Protocol Specification, Section 5.4.6.1 Spend Authorization Signature</a></td>
</tr>
</tbody>
</table>
<table id="sapling-jubjub" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="protocol/protocol.pdf#jubjub">Zcash Protocol Specification, Section 5.4.8.3 Jubjub</a></td>
</tr>
</tbody>
</table>
<table id="sprout-shielded-addresses" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="protocol/protocol.pdf#sproutpaymentaddrencoding">Zcash Protocol Specification, Section 5.6.3 Sprout Shielded Payment Addresses</a></td>
</tr>
</tbody>
</table>
<table id="sapling-full-viewing-keys" class="footnote">
<tbody>
<tr>
<th>14</th>
<td><a href="protocol/protocol.pdf#saplingfullviewingkeyencoding">Zcash Protocol Specification, Section 5.6.7 Sapling Full Viewing Keys</a></td>
</tr>
</tbody>
</table>
<table id="sprout-spending-keys" class="footnote">
<tbody>
<tr>
<th>15</th>
<td><a href="protocol/protocol.pdf#sproutspendingkeyencoding">Zcash Protocol Specification, Section 5.6.8 Sprout Spending Keys</a></td>
</tr>
</tbody>
</table>
<table id="nist-sp-800-38g" class="footnote">
<tbody>
<tr>
<th>10</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>
</tr>
</tbody>

24
zip-0032.rst
View File

@ -19,7 +19,7 @@ Terminology
The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119.
[#RFC2119]_
"Jubjub" refers to the elliptic curve defined in [#sapling-spec]_ section 5.4.8.3.
"Jubjub" refers to the elliptic curve defined in [#sapling-jubjub]_.
Abstract
@ -81,7 +81,7 @@ Most of the notation and functions used in this ZIP are defined in the Sapling p
same order as the groups.
- repr\ :sub:`𝕁`\ (*P*) is the representation of the Jubjub elliptic curve point *P* as a bit sequence,
defined in [#sapling-spec]_ section 5.4.8.3.
defined in [#sapling-jubjub]_.
- BLAKE2b-256(*p*, *x*) refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of
32 bytes, 16-byte personalization string *p*, and input *x*.
@ -95,7 +95,7 @@ Most of the notation and functions used in this ZIP are defined in the Sapling p
of the Jubjub large prime subgroup.
- DiversifyHash(*d*) maps a diversifier *d* to a base point on the Jubjub elliptic curve, or to ⊥ if the
diversifier is invalid. It is instantiated in [#sapling-spec]_ section 5.4.1.6.
diversifier is invalid. It is instantiated in [#sapling-diversifyhash]_.
The following algorithm standardized in [#NIST-SP-800-38G]_ is used:
@ -205,7 +205,7 @@ CDKsk((*ask*\ :sub:`par`\ , *nsk*\ :sub:`par`\ , *ovk*\ :sub:`par`\ , *dk*\ :sub
Deriving a child extended full viewing key
``````````````````````````````````````````
Let 𝓖 be as defined in [#sapling-spec]_ section 5.4.6.1 and let 𝓗 be as defined in [#sapling-key-components]_.
Let 𝓖 be as defined in [#sapling-spendauthsig]_ and let 𝓗 be as defined in [#sapling-key-components]_.
CDKfvk((*ak*\ :sub:`par`\ , *nk*\ :sub:`par`\ , *ovk*\ :sub:`par`\ , *dk*\ :sub:`par`\ , *c*\ :sub:`par`\ ), *i*) →
(*ak*\ :sub:`i`\ , *nk*\ :sub:`i`\ , *ovk*\ :sub:`i`\ , *dk*\ :sub:`i`\ , *c*\ :sub:`i`\ )
@ -265,7 +265,7 @@ Sprout helper functions
-----------------------
Let EncodeASK(*a*\ :sub:`sk`) be the 32-byte encoding of *a*\ :sub:`sk` in the raw encoding of a Sprout
spending key (excluding lead bytes) as specified in [#sapling-spec]_ section 5.6.8.
spending key (excluding lead bytes) as specified in [#sprout-spending-keys]_.
Let DecodeASK(*ASK*) be the result of clearing the 4 most significant bits of the first byte of *ASK*,
and decoding the 32-byte result according to the inverse of EncodeASK.
@ -364,7 +364,7 @@ Sapling Full Viewing Key Fingerprints and Tags
----------------------------------------------
A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding *FVK* (as specified
in [#sapling-spec]_ section 5.6.7) is given by:
in [#sapling-full-viewing-keys]_) is given by:
BLAKE2b-256("ZcashSaplingFVFP", *FVK*)
@ -378,7 +378,7 @@ Sprout Address Fingerprints and Tags
------------------------------------
A "Sprout address fingerprint" of a Sprout payment address with raw encoding *ADDR* (as specified in
[#sapling-spec]_ section 5.6.3, including the lead bytes) is given by:
[#sprout-shielded-addresses]_, including the lead bytes) is given by:
BLAKE2b-256("Zcash_Sprout_AFP", *ADDR*)
@ -481,7 +481,13 @@ References
.. [#bip-0044] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki>`_
.. [#slip-0044] `SLIP 44: Registered coin types for BIP-0044 <https://github.com/satoshilabs/slips/blob/master/slip-0044.md>`_
.. [#bip-0173] `BIP 173: Base32 address format for native v0-16 witness outputs <https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki>`_
.. [#sapling-spec] `Zcash Protocol Specification, Version 2018.0-beta-25 or later [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#sapling-key-components] `Section 4.2.2: Sapling Key Components. Zcash Protocol Specification, Version 2018.0-beta-25 or later [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#sapling-spec] `Zcash Protocol Specification, Version 2019.0.8 or later [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_
.. [#sapling-key-components] `Zcash Protocol Specification, Section 4.2.2 Sapling Key Components <protocol/protocol.pdf#saplingkeycomponents>`_
.. [#sapling-diversifyhash] `Zcash Protocol Specification, Section 5.4.1.6 DiversifyHash Hash Function <protocol/protocol.pdf#concretediversifyhash>`_
.. [#sapling-spendauthsig] `Zcash Protocol Specification, Section 5.4.6.1 Spend Authorization Signature <protocol/protocol.pdf#concretespendauthsig>`_
.. [#sapling-jubjub] `Zcash Protocol Specification, Section 5.4.8.3 Jubjub <protocol/protocol.pdf#jubjub>`_
.. [#sprout-shielded-addresses] `Zcash Protocol Specification, Section 5.6.3 Sprout Shielded Payment Addresses <protocol/protocol.pdf#sproutpaymentaddrencoding>`_
.. [#sapling-full-viewing-keys] `Zcash Protocol Specification, Section 5.6.7 Sapling Full Viewing Keys <protocol/protocol.pdf#saplingfullviewingkeyencoding>`_
.. [#sprout-spending-keys] `Zcash Protocol Specification, Section 5.6.8 Sprout Spending Keys <protocol/protocol.pdf#sproutspendingkeyencoding>`_
.. [#NIST-SP-800-38G] `NIST Special Publication 800-38G -- Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption <https://dx.doi.org/10.6028/NIST.SP.800-38G>`_

10
zip-0143.html
View File

@ -388,7 +388,7 @@ sighash: 23652e76cb13b85a0e3363bb5fca061fa791c40c533eccee899364e6e60bb4f7</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Zcash Protocol Specification, Section 4.6</a></td>
<td><a href="protocol/protocol.pdf#send">Zcash Protocol Specification, Section 4.6 Sending Notes</a></td>
</tr>
</tbody>
</table>
@ -450,7 +450,7 @@ sighash: 23652e76cb13b85a0e3363bb5fca061fa791c40c533eccee899364e6e60bb4f7</pre>
<tbody>
<tr>
<th>10</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0200.rst">ZIP 200: Network Upgrade Mechanism</a></td>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
@ -458,7 +458,7 @@ sighash: 23652e76cb13b85a0e3363bb5fca061fa791c40c533eccee899364e6e60bb4f7</pre>
<tbody>
<tr>
<th>11</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0201.rst">ZIP 201: Network Peer Management for Overwinter</a></td>
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
</tr>
</tbody>
</table>
@ -466,7 +466,7 @@ sighash: 23652e76cb13b85a0e3363bb5fca061fa791c40c533eccee899364e6e60bb4f7</pre>
<tbody>
<tr>
<th>12</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0202.rst">ZIP 202: Version 3 Transaction Format for Overwinter</a></td>
<td><a href="zip-0202">ZIP 202: Version 3 Transaction Format for Overwinter</a></td>
</tr>
</tbody>
</table>
@ -474,7 +474,7 @@ sighash: 23652e76cb13b85a0e3363bb5fca061fa791c40c533eccee899364e6e60bb4f7</pre>
<tbody>
<tr>
<th>13</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0203.rst">ZIP 203: Transaction Expiry</a></td>
<td><a href="zip-0203">ZIP 203: Transaction Expiry</a></td>
</tr>
</tbody>
</table>

10
zip-0143.rst
View File

@ -451,7 +451,7 @@ References
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#wiki-checksig] https://en.bitcoin.it/wiki/OP_CHECKSIG
.. [#zcash-protocol] `Zcash Protocol Specification, Section 4.6 <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#zcash-protocol] `Zcash Protocol Specification, Section 4.6 Sending Notes <protocol/protocol.pdf#send>`_
.. [#quadratic]
* `CVE-2013-2292 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2292>`_
* `New Bitcoin vulnerability: A transaction that takes at least 3 minutes to verify <https://bitcointalk.org/?topic=140078>`_
@ -463,9 +463,9 @@ References
.. [#01-change] In the original algorithm, a ``uint256`` of ``0x0000......0001`` is committed if the input
index for a ``SINGLE`` signature is greater than or equal to the number of outputs. In this ZIP a
``0x0000......0000`` is commited, without changing the semantics.
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/blob/master/zip-0202.rst>`_
.. [#zip-0203] `ZIP 203: Transaction Expiry <https://github.com/zcash/zips/blob/master/zip-0203.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.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-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_
.. [#test-vectors] `ZIP 143 Test Vectors <https://github.com/zcash-hackworks/zcash-test-vectors/blob/master/zip_0143.py>`_
.. [#sighash-tests] `SignatureHash Test Vectors <https://github.com/zcash/zcash/blob/master/src/test/data/sighash.json>`_

6
zip-0200.html
View File

@ -165,7 +165,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0143.rst">ZIP 143: Transaction Signature Verification for Overwinter</a></td>
<td><a href="zip-0143">ZIP 143: Transaction Signature Verification for Overwinter</a></td>
</tr>
</tbody>
</table>
@ -173,7 +173,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>5</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0201.rst">ZIP 201: Network Peer Management for Overwinter</a></td>
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
</tr>
</tbody>
</table>
@ -181,7 +181,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>6</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0202.rst">ZIP 202: Version 3 Transaction Format for Overwinter</a></td>
<td><a href="zip-0202">ZIP 202: Version 3 Transaction Format for Overwinter</a></td>
</tr>
</tbody>
</table>

6
zip-0200.rst
View File

@ -224,6 +224,6 @@ References
.. [#release-lifecycle]
- https://electriccoin.co/blog/release-cycle-and-lifetimes/
- https://electriccoin.co/blog/release-cycle-update/
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/blob/master/zip-0202.rst>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <zip-0143.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <zip-0202.rst>`_

8
zip-0201.html
View File

@ -208,7 +208,7 @@ if (nActivationHeight &gt; 0 &amp;&amp;
<tbody>
<tr>
<th>2</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0143.rst">ZIP 143: Transaction Signature Verification for Overwinter</a></td>
<td><a href="zip-0143">ZIP 143: Transaction Signature Verification for Overwinter</a></td>
</tr>
</tbody>
</table>
@ -216,7 +216,7 @@ if (nActivationHeight &gt; 0 &amp;&amp;
<tbody>
<tr>
<th>3</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0200.rst">ZIP 200: Network Upgrade Activation Mechanism</a></td>
<td><a href="zip-0200">ZIP 200: Network Upgrade Activation Mechanism</a></td>
</tr>
</tbody>
</table>
@ -224,7 +224,7 @@ if (nActivationHeight &gt; 0 &amp;&amp;
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0202.rst">ZIP 202: Version 3 Transaction Format for Overwinter</a></td>
<td><a href="zip-0202">ZIP 202: Version 3 Transaction Format for Overwinter</a></td>
</tr>
</tbody>
</table>
@ -232,7 +232,7 @@ if (nActivationHeight &gt; 0 &amp;&amp;
<tbody>
<tr>
<th>5</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0203.rst">ZIP 203: Transaction Expiry</a></td>
<td><a href="zip-0203">ZIP 203: Transaction Expiry</a></td>
</tr>
</tbody>
</table>

8
zip-0201.rst
View File

@ -244,10 +244,10 @@ References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/blob/master/zip-0202.rst>`_
.. [#zip-0203] `ZIP 203: Transaction Expiry <https://github.com/zcash/zips/blob/master/zip-0203.rst>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <zip-0202.rst>`_
.. [#zip-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_
.. [#bip-0111] `BIP 111: NODE_BLOOM service bit <https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki>`_
.. [#bitcoin-verson] https://en.bitcoin.it/wiki/Protocol_documentation#version
.. [#bitcoin-version-handshake] https://en.bitcoin.it/wiki/Version_Handshake

8
zip-0202.html
View File

@ -359,7 +359,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0143.rst">ZIP 143: Transaction Signature Verification for Overwinter</a></td>
<td><a href="zip-0143">ZIP 143: Transaction Signature Verification for Overwinter</a></td>
</tr>
</tbody>
</table>
@ -367,7 +367,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0200.rst">ZIP 200: Network Upgrade Activation Mechanism</a></td>
<td><a href="zip-0200">ZIP 200: Network Upgrade Activation Mechanism</a></td>
</tr>
</tbody>
</table>
@ -375,7 +375,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0201.rst">ZIP 201: Network Handshaking for Overwinter</a></td>
<td><a href="zip-0201">ZIP 201: Network Handshaking for Overwinter</a></td>
</tr>
</tbody>
</table>
@ -383,7 +383,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>5</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0203.rst">ZIP 203: Transaction Expiry</a></td>
<td><a href="zip-0203">ZIP 203: Transaction Expiry</a></td>
</tr>
</tbody>
</table>

8
zip-0202.rst
View File

@ -255,8 +255,8 @@ References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Handshaking for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
.. [#zip-0203] `ZIP 203: Transaction Expiry <https://github.com/zcash/zips/blob/master/zip-0203.rst>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Handshaking for Overwinter <zip-0201.rst>`_
.. [#zip-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_
.. [#versiongroupid] `OVERWINTER_VERSION_GROUP_ID <https://github.com/zcash/zcash/pull/2925/files#diff-5cb8d9decaa15620a8f98b0c6c44da9bR311>`_

2
zip-0203.html
View File

@ -70,7 +70,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0201.rst">ZIP 201: Network Peer Management for Overwinter</a></td>
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
</tr>
</tbody>
</table>

2
zip-0203.rst
View File

@ -94,4 +94,4 @@ https://github.com/zcash/zcash/pull/2874
References
==========
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_

8
zip-0205.html
View File

@ -85,7 +85,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>1</th>
<td><a href="https://github.com/zcash/zips/blob/master/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 2018.0-beta-37 [Overwinter+Sapling]</a></td>
</tr>
</tbody>
</table>
@ -101,7 +101,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>3</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0200.rst">ZIP 200: Network Upgrade Activation Mechanism</a></td>
<td><a href="zip-0200">ZIP 200: Network Upgrade Activation Mechanism</a></td>
</tr>
</tbody>
</table>
@ -109,7 +109,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0201.rst">ZIP 201: Network Peer Management for Overwinter</a></td>
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
</tr>
</tbody>
</table>
@ -117,7 +117,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>5</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0243.rst">ZIP 243: Transaction Signature Verification for Sapling</a></td>
<td><a href="zip-0243">ZIP 243: Transaction Signature Verification for Sapling</a></td>
</tr>
</tbody>
</table>

8
zip-0205.rst
View File

@ -140,8 +140,8 @@ version 170007.
References
==========
.. [#protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 [Overwinter+Sapling] <protocol/protocol.pdf>`_
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
.. [#zip-0243] `ZIP 243: Transaction Signature Verification for Sapling <https://github.com/zcash/zips/blob/master/zip-0243.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-0243] `ZIP 243: Transaction Signature Verification for Sapling <zip-0243.rst>`_

8
zip-0206.html
View File

@ -82,7 +82,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>1</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom]</a></td>
</tr>
</tbody>
</table>
@ -98,7 +98,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>3</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0200.rst">ZIP 200: Network Upgrade Activation Mechanism</a></td>
<td><a href="zip-0200">ZIP 200: Network Upgrade Activation Mechanism</a></td>
</tr>
</tbody>
</table>
@ -106,7 +106,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0201.rst">ZIP 201: Network Peer Management for Overwinter</a></td>
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
</tr>
</tbody>
</table>
@ -114,7 +114,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>5</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0208.rst">ZIP 208: Shorter Block Target Spacing</a></td>
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
</tr>
</tbody>
</table>

8
zip-0206.rst
View File

@ -121,8 +121,8 @@ implemented in ``zcashd`` version 2.1.0, which will advertise protocol version 1
References
==========
.. [#protocol] `Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <https://github.com/zcash/zips/blob/master/zip-0208.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-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_

10
zip-0207.html
View File

@ -562,7 +562,7 @@ Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex
<tbody>
<tr>
<th>2</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Section 7.7: Calculation of Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling]</a></td>
<td><a href="protocol/protocol.pdf">Section 7.7: Calculation of Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling]</a></td>
</tr>
</tbody>
</table>
@ -578,7 +578,7 @@ Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0208.rst">ZIP 208: Shorter Block Target Spacing</a></td>
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
</tr>
</tbody>
</table>
@ -586,7 +586,7 @@ Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex
<tbody>
<tr>
<th>5</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Section 7.8: Payment of Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling]</a></td>
<td><a href="protocol/protocol.pdf">Section 7.8: Payment of Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling]</a></td>
</tr>
</tbody>
</table>
@ -594,7 +594,7 @@ Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex
<tbody>
<tr>
<th>6</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Section 5.3: Constants. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling]</a></td>
<td><a href="protocol/protocol.pdf">Section 5.3: Constants. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling]</a></td>
</tr>
</tbody>
</table>
@ -602,7 +602,7 @@ Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex
<tbody>
<tr>
<th>7</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0206.rst">ZIP 206: Blossom Network Upgrade</a></td>
<td><a href="zip-0206">ZIP 206: Blossom Network Upgrade</a></td>
</tr>
</tbody>
</table>

10
zip-0207.rst
View File

@ -485,9 +485,9 @@ References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#block-subsidy] `Section 7.7: Calculation of Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#block-subsidy] `Section 7.7: Calculation of Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling] <protocol/protocol.pdf>`_
.. [#continued-funding] `Continued Funding and Transparency <https://electriccoin.co/blog/continued-funding-and-transparency/>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <https://github.com/zcash/zips/blob/master/zip-0208.rst>`_
.. [#original-fr-consensus-rule] `Section 7.8: Payment of Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#protocol-constants] `Section 5.3: Constants. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#zip-0206] `ZIP 206: Blossom Network Upgrade <https://github.com/zcash/zips/blob/master/zip-0206.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
.. [#original-fr-consensus-rule] `Section 7.8: Payment of Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling] <protocol/protocol.pdf>`_
.. [#protocol-constants] `Section 5.3: Constants. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling] <protocol/protocol.pdf>`_
.. [#zip-0206] `ZIP 206: Blossom Network Upgrade <zip-0206.rst>`_

8
zip-0208.html
View File

@ -215,7 +215,7 @@ static const unsigned int MIN_BLOCKS_TO_KEEP = 288;</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/blossom.pdf">Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom]</a></td>
<td><a href="protocol/blossom.pdf">Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom]</a></td>
</tr>
</tbody>
</table>
@ -239,7 +239,7 @@ static const unsigned int MIN_BLOCKS_TO_KEEP = 288;</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0200.rst">ZIP 200: Network Upgrade Mechanism</a></td>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
@ -247,7 +247,7 @@ static const unsigned int MIN_BLOCKS_TO_KEEP = 288;</pre>
<tbody>
<tr>
<th>5</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0205.rst">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>
</tbody>
</table>
@ -255,7 +255,7 @@ static const unsigned int MIN_BLOCKS_TO_KEEP = 288;</pre>
<tbody>
<tr>
<th>6</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0206.rst">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>
</tbody>
</table>

8
zip-0208.rst
View File

@ -364,11 +364,11 @@ https://github.com/zcash/zcash/pull/4025
References
==========
.. [#latest-protocol] `Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom] <https://github.com/zcash/zips/blob/master/protocol/blossom.pdf>`_
.. [#latest-protocol] `Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom] <protocol/blossom.pdf>`_
.. [#preblossom-protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) [Overwinter+Sapling] <https://github.com/zcash/zips/blob/9515d73aac0aea3494f77bcd634e1e4fbd744b97/protocol/protocol.pdf>`_
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <https://github.com/zcash/zips/blob/master/zip-0205.rst>`_
.. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <https://github.com/zcash/zips/blob/master/zip-0206.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-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <zip-0206.rst>`_
.. [#slowfastblocks] `On Slow and Fast Block Times <https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/>`_

4
zip-0209.html
View File

@ -53,7 +53,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling]</a></td>
</tr>
</tbody>
</table>
@ -61,7 +61,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0200.rst">ZIP 200: Network Upgrade Mechanism</a></td>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>

4
zip-0209.rst
View File

@ -60,5 +60,5 @@ References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#protocol] `Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#protocol] `Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling] <protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_

6
zip-0210.html
View File

@ -67,7 +67,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0200.rst">ZIP 200: Network Upgrade Activation Mechanism</a></td>
<td><a href="zip-0200">ZIP 200: Network Upgrade Activation Mechanism</a></td>
</tr>
</tbody>
</table>
@ -75,7 +75,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0205.rst">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>
</tbody>
</table>
@ -83,7 +83,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Section 7.1: Encoding of Transactions. Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling]</a></td>
<td><a href="protocol/protocol.pdf">Section 7.1: Encoding of Transactions. Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling]</a></td>
</tr>
</tbody>
</table>

6
zip-0210.rst
View File

@ -105,6 +105,6 @@ References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <https://github.com/zcash/zips/blob/master/zip-0205.rst>`_
.. [#v4-tx] `Section 7.1: Encoding of Transactions. Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#v4-tx] `Section 7.1: Encoding of Transactions. Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling] <protocol/protocol.pdf>`_

8
zip-0243.html
View File

@ -473,7 +473,7 @@ vJoinSplit: 00</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Zcash Protocol Specification, Version 2018.0-beta-37 [Overwinter+Sapling]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification [Overwinter+Sapling]</a></td>
</tr>
</tbody>
</table>
@ -489,7 +489,7 @@ vJoinSplit: 00</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0143.rst">ZIP 143: Transaction Signature Verification for Overwinter</a></td>
<td><a href="zip-0143">ZIP 143: Transaction Signature Verification for Overwinter</a></td>
</tr>
</tbody>
</table>
@ -497,7 +497,7 @@ vJoinSplit: 00</pre>
<tbody>
<tr>
<th>5</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0200.rst">ZIP 200: Network Upgrade Mechanism</a></td>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
@ -505,7 +505,7 @@ vJoinSplit: 00</pre>
<tbody>
<tr>
<th>6</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0205.rst">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>
</tbody>
</table>

8
zip-0243.rst
View File

@ -525,10 +525,10 @@ References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification [Overwinter+Sapling] <protocol/protocol.pdf>`_
.. [#BLAKE2-personalization] `"BLAKE2: simpler, smaller, fast as MD5", Section 2.8 <https://blake2.net/blake2.pdf>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <https://github.com/zcash/zips/blob/master/zip-0205.rst>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#test-vectors] `ZIP 243 Test Vectors <https://github.com/zcash-hackworks/zcash-test-vectors/blob/master/zip_0243.py>`_
.. [#sighash-tests] `SignatureHash Test Vectors <https://github.com/zcash/zcash/blob/master/src/test/data/sighash.json>`_

6
zip-0308.html
View File

@ -243,7 +243,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>1</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Zcash Protocol Specification, Version 2018.0-beta-33 [Overwinter+Sapling]; sections 3.4, 4.11 and 4.12</a></td>
<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>
@ -259,7 +259,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0032.rst">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td>
<td><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td>
</tr>
</tbody>
</table>
@ -267,7 +267,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-0205.rst">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>
</tbody>
</table>

6
zip-0308.rst
View File

@ -401,8 +401,8 @@ The following PRs implement this specification:
References
==========
.. [#transparent-value-pool] `Zcash Protocol Specification, Version 2018.0-beta-33 [Overwinter+Sapling]; sections 3.4, 4.11 and 4.12 <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#transparent-value-pool] `Zcash Protocol Specification, Version 2018.0-beta-33 [Overwinter+Sapling]; sections 3.4, 4.11 and 4.12 <protocol/protocol.pdf>`_
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <https://github.com/zcash/zips/blob/master/zip-0032.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <https://github.com/zcash/zips/blob/master/zip-0205.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>`_
.. [#migration-simulator] `Sprout -> Sapling migration simulation <https://github.com/daira/zcash-migration>`_

117
zip-0401.html Normal file
View File

@ -0,0 +1,117 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 401: Addressing mempool denial-of-service</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 401
Title: Addressing mempool denial-of-service
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Status: Final
Category: Network
Created: 2019-09-09
License: MIT</pre>
<section id="terminology">
<h2>Terminology</h2>
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">1</a></p>
</section>
<section id="abstract">
<h2>Abstract</h2>
<p>This proposal specifies a change to the behaviour of <code>zcashd</code> nodes intended to mitigate denial-of-service from transaction flooding.</p>
</section>
<section id="motivation">
<h2>Motivation</h2>
<p>Adoption of this proposal would increase robustness of Zcash nodes against denial-of-service attack, in particular attacks that attempt to exhaust node memory.</p>
<p>Bitcoin Core added size limitation for the mempool in version 0.12 <a href="#bitcoincore-pr6722" id="id2" class="footnote_reference">3</a>, defaulting to 300 MB. This was after Zcash forked from Bitcoin Core.</p>
</section>
<section id="requirements">
<h2>Requirements</h2>
<p>The memory usage of a node’s mempool should be bounded.</p>
<p>The eviction policy should as far as possible not be “gameable” by an adversary, i.e. an adversary should not be able to cause legitimate transactions (that do not themselves present any denial-of-service problem) to be preferentially evicted relative to its own transactions.</p>
<p>Any configuration options should have reasonable defaults, i.e. without changing relevant configuration, a node should be adequately protected from denial-of-service via mempool memory exhaustion.</p>
</section>
<section id="non-requirements">
<h2>Non-requirements</h2>
<p>The current architecture of Zcash imposes fundamental limits on scaling of transaction throughput. This proposal does not increase the aggregate transaction capacity of the network. (The Blossom upgrade does increase transaction capacity, by a factor of two <a href="#zip-0208" id="id3" class="footnote_reference">2</a>.)</p>
<p>Denial-of-service issues in the messaging layer of the peer-to-peer protocol are out of scope for this proposal.</p>
<p>This proposal is focused primarily on memory exhaustion attacks. It does not attempt to use fees to make denial-of-service economically prohibitive, since that is unlikely to be feasible while maintaining low fees for legitimate users. It does not preclude changes in fee policy.</p>
</section>
<section id="specification">
<h2>Specification</h2>
<p>This specification describes the intended behaviour of <code>zcashd</code> nodes. Other node implementations MAY implement the same or similar behaviour, but this is not a requirement of the network protocol. Thus, RFC 2119 conformance keywords below are to be interpreted only as placing requirements on the <code>zcashd</code> implementation (and potentially other implementations that have adopted this specification in full).</p>
<p>The mempool of a node holds a set of transactions. Each transaction has a <em>cost</em>, which is an integer defined as:</p>
<blockquote>
<p>max(serialized transaction size in bytes, 4000)</p>
</blockquote>
<p>Each transaction also has an <em>eviction weight</em>, which is <em>cost</em> + <em>low_fee_penalty</em>, where <em>low_fee_penalty</em> is 16000 if the transaction pays a fee less than 10000 zatoshi, otherwise 0.</p>
<p>Each node also MUST hold a FIFO queue RecentlyEvicted of pairs (txid, time), where the time indicates when the given txid was evicted. This SHOULD be empty on node startup. The size of RecentlyEvicted SHOULD never exceed <code>eviction_memory_entries</code> entries, which is the constant 40000.</p>
<p>There MUST be a configuration option <code>mempooltxcostlimit</code>, which SHOULD default to 80000000.</p>
<p>There MUST be a configuration option <code>mempoolevictionmemoryminutes</code>, which SHOULD default to 60.</p>
<p>On receiving a transaction:</p>
<ul>
<li>If it is in RecentlyEvicted, the transaction MUST be dropped.</li>
<li>Calculate its cost. If the total cost of transactions in the mempool including this one would exceed <code>mempooltxcostlimit</code>, then the node MUST repeatedly call EvictTransaction (with the new transaction included as a candidate to evict) until the total cost does not exceed <code>mempooltxcostlimit</code>.</li>
</ul>
<p>EvictTransaction MUST do the following:</p>
<ul>
<li>Select a random transaction to evict, with probability in direct proportion to eviction weight.</li>
<li>Add the txid and the current time to RecentlyEvicted, dropping the oldest entry in RecentlyEvicted if necessary to keep it to at most <code>eviction_memory_entries</code> entries.</li>
<li>Remove it from the mempool.</li>
</ul>
<p>Nodes SHOULD remove transactions from RecentlyEvicted that were evicted more than <code>mempoolevictionmemoryminutes</code> minutes ago. This MAY be done periodically, and/or just before RecentlyEvicted is accessed when receiving a transaction.</p>
</section>
<section id="rationale">
<h2>Rationale</h2>
<p>The accounting for transaction size should include some overhead per transaction, to reflect the cost to the network of processing them (proof and signature verification; networking overheads; size of in-memory data structures). The implication of not including overhead is that a denial-of-service attacker would be likely to use minimum-size transactions so that more of them would fit in a block, increasing the unaccounted-for overhead. A possible counterargument would be that the complexity of accounting for this overhead is unwarranted given that the format of a transaction already imposes a minimum size. However, the proposed cost function is almost as simple as using transaction size directly.</p>
<p>The threshold 4000 for the cost function is chosen so that the size in bytes of a typical fully shielded Sapling transaction (with, say, 2 shielded outputs and up to 5 shielded inputs) will fall below the threshold. This has the effect of ensuring that such transactions are not evicted preferentially to typical transparent transactions because of their size.</p>
<p>The proposed eviction policy differs significantly from that of Bitcoin Core <a href="#bitcoincore-pr6722" id="id4" class="footnote_reference">3</a>, which is primarily fee-based. This reflects differing philosophies about the motivation for fees and the level of fee that legitimate users can reasonably be expected to pay. The proposed eviction weight function does involve a penalty for transactions with a fee lower than the standard (0.0001 ZEC) value, but since there is no further benefit to increasing the fee above the standard value, it creates no pressure toward escalating fees. For transactions up to 4000 bytes, this penalty makes a transaction that pays less than the standard fee value five times as likely to be chosen for eviction (because 4000 + 16000 = 20000 = 4000 * 5).</p>
<p>The fee penalty is not included in the cost that determines whether the mempool is considered full. This ensures that a DoS attacker does not have an incentive to pay less than the standard fee in order to cause the mempool to be considered full sooner.</p>
<p>The default value of 80000000 for <code>mempooltxcostlimit</code> represents no more than 40 blocks’ worth of transactions in the worst case, which is the default expiration height after the Blossom network upgrade <a href="#zip-0208" id="id5" class="footnote_reference">2</a>. It would serve no purpose to make it larger.</p>
<p>The <code>mempooltxcostlimit</code> is a per-node configurable parameter in order to provide flexibility for node operators to change it either in response to attempted denial-of-service attacks, or if needed to handle spikes in transaction demand. It may also be useful for nodes running in memory-constrained environments to reduce this parameter.</p>
<p>The limit of <code>eviction_memory_entries</code> = 40000 entries in RecentlyEvicted bounds the memory needed for this data structure. Since a txid is 32 bytes and a timestamp 8 bytes, 40000 entries can be stored in ~1.6 MB, which is small compared to other node memory usage (in particular, small compared to the maximum memory usage of the mempool itself under the default <code>mempooltxcostlimit</code>). <code>eviction_memory_entries</code> entries should be sufficient to mitigate any performance loss caused by re-accepting transactions that were previously evicted. In particular, since a transaction has a minimum cost of 4000, and the default <code>mempooltxcostlimit</code> is 80000000, at most 20000 transactions can be in the mempool of a node using the default parameters. While the number of transactions “in flight” or across the mempools of all nodes in the network could exceed this number, we believe that is unlikely to be a problem in practice.</p>
<p>Note that the RecentlyEvicted queue is intended as a performance optimization under certain conditions, rather than as a DoS-mitigation measure in itself.</p>
<p>The default expiry of 40 blocks after Blossom activation represents an expected time of 50 minutes. Therefore (even if some blocks are slow), most legitimate transactions are expected to expire within 60 minutes. Note however that an attacker’s transactions cannot be relied on to expire.</p>
</section>
<section id="deployment">
<h2>Deployment</h2>
<p>This specification is proposed to be implemented in <code>zcashd</code> v2.1.0. It is independent of the Blossom network upgrade.</p>
</section>
<section id="reference-implementation">
<h2>Reference implementation</h2>
<ul>
<li><a href="https://github.com/zcash/zcash/pull/4145">PR 4145: Implementation</a></li>
<li><a href="https://github.com/zcash/zcash/pull/4166">PR 4166: macOS compliation fix</a></li>
</ul>
</section>
<section id="references">
<h2>References</h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="zip-0208" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://zips.z.cash/zip-0208">Shorter Block Target Spacing</a></td>
</tr>
</tbody>
</table>
<table id="bitcoincore-pr6722" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://github.com/bitcoin/bitcoin/pull/6722">Bitcoin Core PR 6722: Limit mempool by throwing away the cheapest txn and setting min relay fee to it</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

207
zip-0401.rst Normal file
View File

@ -0,0 +1,207 @@
::
ZIP: 401
Title: Addressing mempool denial-of-service
Owners: Daira Hopwood <daira@electriccoin.co>
Status: Final
Category: Network
Created: 2019-09-09
License: MIT
Terminology
===========
The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted
as described in RFC 2119. [#RFC2119]_
Abstract
========
This proposal specifies a change to the behaviour of ``zcashd`` nodes intended to
mitigate denial-of-service from transaction flooding.
Motivation
==========
Adoption of this proposal would increase robustness of Zcash nodes against
denial-of-service attack, in particular attacks that attempt to exhaust node
memory.
Bitcoin Core added size limitation for the mempool in version 0.12
[#BitcoinCore-PR6722]_, defaulting to 300 MB. This was after Zcash forked from
Bitcoin Core.
Requirements
============
The memory usage of a node’s mempool should be bounded.
The eviction policy should as far as possible not be “gameable” by an adversary,
i.e. an adversary should not be able to cause legitimate transactions (that do not
themselves present any denial-of-service problem) to be preferentially evicted
relative to its own transactions.
Any configuration options should have reasonable defaults, i.e. without changing
relevant configuration, a node should be adequately protected from denial-of-service
via mempool memory exhaustion.
Non-requirements
================
The current architecture of Zcash imposes fundamental limits on scaling of
transaction throughput. This proposal does not increase the aggregate transaction
capacity of the network. (The Blossom upgrade does increase transaction capacity,
by a factor of two [#zip-0208]_.)
Denial-of-service issues in the messaging layer of the peer-to-peer protocol are
out of scope for this proposal.
This proposal is focused primarily on memory exhaustion attacks. It does not
attempt to use fees to make denial-of-service economically prohibitive, since that
is unlikely to be feasible while maintaining low fees for legitimate users. It
does not preclude changes in fee policy.
Specification
=============
This specification describes the intended behaviour of ``zcashd`` nodes. Other node
implementations MAY implement the same or similar behaviour, but this is not a
requirement of the network protocol. Thus, RFC 2119 conformance keywords below are
to be interpreted only as placing requirements on the ``zcashd`` implementation (and
potentially other implementations that have adopted this specification in full).
The mempool of a node holds a set of transactions. Each transaction has a *cost*,
which is an integer defined as:
max(serialized transaction size in bytes, 4000)
Each transaction also has an *eviction weight*, which is *cost* + *low_fee_penalty*,
where *low_fee_penalty* is 16000 if the transaction pays a fee less than
10000 zatoshi, otherwise 0.
Each node also MUST hold a FIFO queue RecentlyEvicted of pairs (txid, time), where
the time indicates when the given txid was evicted. This SHOULD be empty on node
startup. The size of RecentlyEvicted SHOULD never exceed ``eviction_memory_entries``
entries, which is the constant 40000.
There MUST be a configuration option ``mempooltxcostlimit``, which SHOULD default
to 80000000.
There MUST be a configuration option ``mempoolevictionmemoryminutes``, which
SHOULD default to 60.
On receiving a transaction:
* If it is in RecentlyEvicted, the transaction MUST be dropped.
* Calculate its cost. If the total cost of transactions in the mempool including
this one would exceed ``mempooltxcostlimit``, then the node MUST repeatedly
call EvictTransaction (with the new transaction included as a candidate to evict)
until the total cost does not exceed ``mempooltxcostlimit``.
EvictTransaction MUST do the following:
* Select a random transaction to evict, with probability in direct proportion to
eviction weight.
* Add the txid and the current time to RecentlyEvicted, dropping the oldest entry
in RecentlyEvicted if necessary to keep it to at most ``eviction_memory_entries``
entries.
* Remove it from the mempool.
Nodes SHOULD remove transactions from RecentlyEvicted that were evicted more than
``mempoolevictionmemoryminutes`` minutes ago. This MAY be done periodically,
and/or just before RecentlyEvicted is accessed when receiving a transaction.
Rationale
=========
The accounting for transaction size should include some overhead per transaction,
to reflect the cost to the network of processing them (proof and signature
verification; networking overheads; size of in-memory data structures). The
implication of not including overhead is that a denial-of-service attacker would
be likely to use minimum-size transactions so that more of them would fit in a
block, increasing the unaccounted-for overhead. A possible counterargument would
be that the complexity of accounting for this overhead is unwarranted given that
the format of a transaction already imposes a minimum size. However, the proposed
cost function is almost as simple as using transaction size directly.
The threshold 4000 for the cost function is chosen so that the size in bytes of a
typical fully shielded Sapling transaction (with, say, 2 shielded outputs and up
to 5 shielded inputs) will fall below the threshold. This has the effect of
ensuring that such transactions are not evicted preferentially to typical
transparent transactions because of their size.
The proposed eviction policy differs significantly from that of Bitcoin Core
[#BitcoinCore-PR6722]_, which is primarily fee-based. This reflects differing
philosophies about the motivation for fees and the level of fee that legitimate
users can reasonably be expected to pay. The proposed eviction weight function
does involve a penalty for transactions with a fee lower than the standard
(0.0001 ZEC) value, but since there is no further benefit to increasing the fee
above the standard value, it creates no pressure toward escalating fees. For
transactions up to 4000 bytes, this penalty makes a transaction that pays less
than the standard fee value five times as likely to be chosen for eviction
(because 4000 + 16000 = 20000 = 4000 \* 5).
The fee penalty is not included in the cost that determines whether the mempool
is considered full. This ensures that a DoS attacker does not have an incentive
to pay less than the standard fee in order to cause the mempool to be considered
full sooner.
The default value of 80000000 for ``mempooltxcostlimit`` represents no more
than 40 blocks’ worth of transactions in the worst case, which is the default
expiration height after the Blossom network upgrade [#zip-0208]_. It would serve
no purpose to make it larger.
The ``mempooltxcostlimit`` is a per-node configurable parameter in order to
provide flexibility for node operators to change it either in response to
attempted denial-of-service attacks, or if needed to handle spikes in transaction
demand. It may also be useful for nodes running in memory-constrained environments
to reduce this parameter.
The limit of ``eviction_memory_entries`` = 40000 entries in RecentlyEvicted bounds
the memory needed for this data structure. Since a txid is 32 bytes and a
timestamp 8 bytes, 40000 entries can be stored in ~1.6 MB, which is small compared
to other node memory usage (in particular, small compared to the maximum memory
usage of the mempool itself under the default ``mempooltxcostlimit``).
``eviction_memory_entries`` entries should be sufficient to mitigate any
performance loss caused by re-accepting transactions that were previously evicted.
In particular, since a transaction has a minimum cost of 4000, and the default
``mempooltxcostlimit`` is 80000000, at most 20000 transactions can be in the
mempool of a node using the default parameters. While the number of transactions
“in flight” or across the mempools of all nodes in the network could exceed this
number, we believe that is unlikely to be a problem in practice.
Note that the RecentlyEvicted queue is intended as a performance optimization
under certain conditions, rather than as a DoS-mitigation measure in itself.
The default expiry of 40 blocks after Blossom activation represents an expected
time of 50 minutes. Therefore (even if some blocks are slow), most legitimate
transactions are expected to expire within 60 minutes. Note however that an
attacker’s transactions cannot be relied on to expire.
Deployment
==========
This specification is proposed to be implemented in ``zcashd`` v2.1.0. It is
independent of the Blossom network upgrade.
Reference implementation
========================
* `PR 4145: Implementation <https://github.com/zcash/zcash/pull/4145>`_
* `PR 4166: macOS compliation fix <https://github.com/zcash/zcash/pull/4166>`_
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0208] `Shorter Block Target Spacing <https://zips.z.cash/zip-0208>`_
.. [#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>`_

123
zip-1001.html Normal file
View File

@ -0,0 +1,123 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1001: Keep the Block Distribution as Initially Defined — 90% to Miners</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1001
Title: Keep the Block Distribution as Initially Defined — 90% to Miners
Owner: mistfpga (zcash forums) &lt;steve@mistfpga.net&gt;
Status: Draft
Category: Consensus
Created: 2019-08-01
License: CC BY-SA 4.0 &lt;https://creativecommons.org/licenses/by-sa/4.0/&gt;
Discussions-To: &lt;https://forum.zcashcommunity.com/t/zip-proposal-keep-the-block-distribution-as-initaly-defined-90-to-miners/33843&gt;</pre>
<section id="terminology">
<h2>Terminology</h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">2</a></p>
<p>For clarity this ZIP defines these terms:</p>
<ul>
<li>Mining software in the context of this ZIP refers to pool software, local mining software, or staking software.</li>
<li>Mining is defined as the action of processing transactions, so this would include proof of stake, if Zcash would switch to that.</li>
<li>Mining coins transferred via fees are considered rewards (infinite), coins generated via block generation are considered distribution (finite).</li>
<li>Block distribution is defined as the block reward minus transaction fees. <span class="editor-note">the protocol specification uses "block subsidy".</span></li>
<li>Spirit is defined as what is the intended outcome of the ZIP. <a href="#spirit" id="id2" class="footnote_reference">1</a></li>
<li>Initial promise is non-neutral language referencing the block distribution rules as initially set out. <a href="#funding" id="id3" class="footnote_reference">3</a></li>
</ul>
<table id="spirit" class="footnote">
<tbody>
<tr>
<th>1</th>
<td>If there is contradiction between Spirit and any other part of the proposal that needs to be addressed, in the event it is not addressed Spirit is assumed to overrule all.</td>
</tr>
</tbody>
</table>
</section>
<section id="abstract">
<h2>Abstract</h2>
<p>The spirit of this ZIP is to is to ensure that the Founders’ Reward ends. It is not the intention of this ZIP to stop protocol-based donations.</p>
<p>It is a simple short ZIP.</p>
<p>Hopefully it will be compatible with a number of other ZIPs and can be worked into them.</p>
</section>
<section id="out-of-scope-for-this-proposal">
<h2>Out of Scope for this Proposal</h2>
<ul>
<li>Governance on how decisions are made; this ZIP is not meant to be used as a form of governance.</li>
<li>Future funding.</li>
<li>It does not cover other donations or revenue streams.</li>
</ul>
</section>
<section id="motivation">
<h2>Motivation</h2>
<ul>
<li>The Founders’ Reward is set to expire in 2020.</li>
<li>To honour the initial promise of giving 90% of total block distribution to miners. Therefore the protocol will give them 100% of the block distribution after the first halving.</li>
</ul>
</section>
<section id="requirements">
<h2>Requirements</h2>
<ul>
<li>The Founders’ Reward MUST end at the first halving in October 2020.</li>
<li>This ZIP does not preclude the Electric Coin Company from sourcing funding elsewhere, or from donations.</li>
</ul>
</section>
<section id="specification">
<h2>Specification</h2>
<ul>
<li>The existing Founders’ Reward consensus rules <a href="#spec-subsidies" id="id4" class="footnote_reference">4</a> <a href="#spec-foundersreward" id="id5" class="footnote_reference">5</a> MUST be preserved.</li>
<li>Specifically, <code>FoundersReward(height)</code> MUST equal <code>0</code> if <code>Halving(height) &gt;= 1</code>. (For clarity once the halving happens the Founders’ Reward stops, as per the rules outlined in <a href="#spec-subsidies" id="id6" class="footnote_reference">4</a> and <a href="#spec-foundersreward" id="id7" class="footnote_reference">5</a>.)</li>
<li>This specification is only meant to stop the Founders’ Reward, not protocol-based donations.</li>
<li>Enforcing some kind of mandatory donation via whatever mechanism would be seen as continuation of the Founders’ Reward.</li>
</ul>
</section>
<section id="implications-to-other-users">
<h2>Implications to other users</h2>
<ul>
<li>Block distribution payouts to Founders’ Reward addresses will cease at the first halving.</li>
<li>Pools and other software need to take this into account.</li>
</ul>
</section>
<section id="technical-implementation">
<h2>Technical implementation</h2>
<p>This ZIP requires no changes to current consensus implementations.</p>
</section>
<section id="references">
<h2>References</h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="funding" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://electriccoin.co/blog/funding/">Zcash blog: Funding, Incentives, and Governance. February 1, 2016</a></td>
</tr>
</tbody>
</table>
<table id="spec-subsidies" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#subsidies">Zcash Protocol Specification, Version 2019.0.8 exactly. Section 7.7: Calculation of Block Subsidy and Founders Reward</a></td>
</tr>
</tbody>
</table>
<table id="spec-foundersreward" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#foundersreward">Zcash Protocol Specification, Version 2019.0.8 exactly. Section 7.8: Payment of Founders’ Reward</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

113
zip-1001.rst Normal file
View File

@ -0,0 +1,113 @@
::
ZIP: 1001
Title: Keep the Block Distribution as Initially Defined — 90% to Miners
Owner: mistfpga (zcash forums) <steve@mistfpga.net>
Status: Draft
Category: Consensus
Created: 2019-08-01
License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/>
Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-keep-the-block-distribution-as-initaly-defined-90-to-miners/33843>
Terminology
===========
.. role:: editor-note
The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document
are to be interpreted as described in RFC 2119. [#RFC2119]_
For clarity this ZIP defines these terms:
* Mining software in the context of this ZIP refers to pool software, local
mining software, or staking software.
* Mining is defined as the action of processing transactions, so this would
include proof of stake, if Zcash would switch to that.
* Mining coins transferred via fees are considered rewards (infinite), coins
generated via block generation are considered distribution (finite).
* Block distribution is defined as the block reward minus transaction fees.
:editor-note:`the protocol specification uses "block subsidy".`
* Spirit is defined as what is the intended outcome of the ZIP. [#spirit]_
* Initial promise is non-neutral language referencing the block distribution
rules as initially set out. [#funding]_
.. [#spirit] If there is contradiction between Spirit and any other part of
the proposal that needs to be addressed, in the event it is not addressed
Spirit is assumed to overrule all.
Abstract
========
The spirit of this ZIP is to is to ensure that the Founders’ Reward ends.
It is not the intention of this ZIP to stop protocol-based donations.
It is a simple short ZIP.
Hopefully it will be compatible with a number of other ZIPs and can be
worked into them.
Out of Scope for this Proposal
==============================
* Governance on how decisions are made; this ZIP is not meant to be used as
a form of governance.
* Future funding.
* It does not cover other donations or revenue streams.
Motivation
==========
* The Founders’ Reward is set to expire in 2020.
* To honour the initial promise of giving 90% of total block distribution to
miners. Therefore the protocol will give them 100% of the block distribution
after the first halving.
Requirements
============
* The Founders’ Reward MUST end at the first halving in October 2020.
* This ZIP does not preclude the Electric Coin Company from sourcing funding
elsewhere, or from donations.
Specification
=============
* The existing Founders’ Reward consensus rules [#spec-subsidies]_
[#spec-foundersreward]_ MUST be preserved.
* Specifically, ``FoundersReward(height)`` MUST equal ``0`` if
``Halving(height) >= 1``. (For clarity once the halving happens the
Founders’ Reward stops, as per the rules outlined in [#spec-subsidies]_
and [#spec-foundersreward]_.)
* This specification is only meant to stop the Founders’ Reward, not
protocol-based donations.
* Enforcing some kind of mandatory donation via whatever mechanism would
be seen as continuation of the Founders’ Reward.
Implications to other users
===========================
* Block distribution payouts to Founders’ Reward addresses will cease at
the first halving.
* Pools and other software need to take this into account.
Technical implementation
========================
This ZIP requires no changes to current consensus implementations.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#funding] `Zcash blog: Funding, Incentives, and Governance. February 1, 2016 <https://electriccoin.co/blog/funding/>`_
.. [#spec-subsidies] `Zcash Protocol Specification, Version 2019.0.8 exactly. Section 7.7: Calculation of Block Subsidy and Founders Reward <protocol/protocol.pdf#subsidies>`_
.. [#spec-foundersreward] `Zcash Protocol Specification, Version 2019.0.8 exactly. Section 7.8: Payment of Founders’ Reward <protocol/protocol.pdf#foundersreward>`_

161
zip-1002.html Normal file
View File

@ -0,0 +1,161 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1002: Opt-in Donation Feature</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1002
Title: Opt-in Donation Feature
Owner: mistfpga (zcash forums) &lt;steve@mistfpga.net&gt;
Status: Draft
Category: Standards Track
Created: 2019-07-17
License: CC BY-SA 4.0 &lt;https://creativecommons.org/licenses/by-sa/4.0/&gt;
Discussions-To: &lt;https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-opt-in-protocol-level-development-donation-option/33846&gt;</pre>
<section id="terminology">
<h2>Terminology</h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">3</a></p>
<p>This ZIP defines these terms:</p>
<ul>
<li>Signalling is defined as expressing a voice through whatever mechanism is implemented or sought for that decision. In the context of this ZIP it primarily refers to signalling what to do with funds. This could be done by miners, straw poll, coinbase, proof of value, some internet poll thing, etc.</li>
<li>Mining software in the context of this ZIP refers to pool software, local mining software, or staking software.</li>
<li>Custodial services include any service in which a party controls the private keys of another party; mining pools and online wallets are examples.</li>
<li>Mining is defined as the action of processing transactions, so this would include proof of stake, if Zcash would switch to that.</li>
<li>User is defined as anyone that uses ZEC or another coin that adopts this ZIP.</li>
<li>Mining coins transferred via fees are considered rewards (infinite), coins generated via block generation are considered distribution (finite).</li>
<li>Opt-in vs opt-out - Opting out is a purely selfish act in the context of this ZIP. They do not burn the coins therefore giving everyone value. They keep them.</li>
<li>Burning coins is purposefully taking them out of circulation forever at the protocol block distribution level.</li>
<li>Initial promise is defined as complete honour of distributing all rewards to the miner. - This is a non neutral phrase. I accept that.</li>
<li>Transaction sender is defined as anyone who sends a transaction across the Zcash network, be it t-t, z-z, t-z, z-t.</li>
<li>Fee is the standard transaction fee that a sender puts on a transaction to get it included into a block and that is collected by the miner of that block.</li>
<li>Transaction donation is an optional signalling string that creates a payment to the coins base donations.</li>
<li>Block Reward is defined as block distribution plus mining fees.</li>
<li>Spirit is defined as what is the intended outcome of the ZIP. <a href="#spirit" id="id2" class="footnote_reference">1</a></li>
</ul>
<table id="spirit" class="footnote">
<tbody>
<tr>
<th>1</th>
<td>If there is contradiction between Spirit and any other part of the proposal that needs to be addressed, in the event it is not addressed Spirit is assumed to overrule all.</td>
</tr>
</tbody>
</table>
</section>
<section id="out-of-scope-for-this-proposal">
<h2>Out of Scope for this Proposal</h2>
<p>Governance on how decisions are made. This ZIP is not meant to be used as a form of governance. It is a protocol-level opt-in for supporting the Zcash network development (like the Founders’ Reward, just with opt-out).</p>
<p>Signalling. Whilst a lot of the ZIP relies on the ability to signal intent in one way or another, it does not put forward such a mechanism and is designed to work with various form of signalling, or potentially without signalling at all.</p>
</section>
<section id="abstract">
<h2>Abstract</h2>
<p>The spirit of this ZIP is:</p>
<ul>
<li>To allow continual funding of the Electric Coin Company, the Zcash Foundation, or some combination of these should a user choose to do so.</li>
<li>To add a genuine opt-in feature, which is done at the user's choice.</li>
</ul>
</section>
<section id="motivation">
<h2>Motivation</h2>
<p>Technology changes, and it changes fast. What works now, may be easily breakable in 10 years, 20 years and certainly 50 years.</p>
<p>To help ensure ZEC can keep up with these changes, now and in 50 or 500 years' time, there needs to be a continual funding for research into new technology and financial stability in order to attract new talent.</p>
<p>The only source of indefinite wealth transfer is transaction fees or donations. This ZIP is specifically about voluntary donations (including via mining fees).</p>
</section>
<section id="requirements">
<h2>Requirements</h2>
<ul>
<li>An additional opt-in mechanism, baked into the protocol. This is a condition of the Zcash Foundation too. <a href="#foundation" id="id3" class="footnote_reference">2</a></li>
<li>Give an alterative to redistribution of either the current block distribution structure or the emission curve.</li>
<li>The funding received by the Electric Coin Company and/or Zcash Foundation under this proposal MUST only be used to fund ZEC development for the lifetime of their receipt of it.</li>
<li>To give a strong indication to the community and users that they have freedom to decide what they do with their coins and donations.</li>
<li>Bake the addresses into the node codebase, in order that the wallet software or pool software does not need to keep track of donation addresses.</li>
<li>Prevent users from sending donations to old addresses.</li>
<li>Make it easier for pools to add support and prove that they are actually donating the percentage they say they are.</li>
<li>Users MUST NOT be forced to signal.</li>
</ul>
<table id="foundation" class="footnote">
<tbody>
<tr>
<th>2</th>
<td>The Zcash Foundation has stated (later clarified in <a href="#zfnd-guidance" id="id4" class="footnote_reference">4</a>) that the Foundation would only support proposals that: a) don’t rely on the Foundation being a single gatekeeper of funds; b) don’t change the upper bound of ZEC supply; and c) have some kind of opt-in mechanism for choosing to disburse funds (from miners and/or users).</td>
</tr>
</tbody>
</table>
</section>
<section id="specification">
<h2>Specification</h2>
<ul>
<li>This ZIP MUST enforce the initial promise as defined by default.</li>
<li>The official client MUST default to be counted as initial promise.</li>
<li>No signal MUST be counted as whatever the pool is signalling for, when using a pool.</li>
<li>Security MUST NOT be lessened.</li>
<li>This ZIP MAY be set to opt-in via a user set flag.</li>
<li>This ZIP MUST contain donation addresses in the coinbase, in a similar fashion to the current FR.</li>
<li>When sending transactions the sender MAY signal their donation.</li>
<li>A signal from a transaction sender MUST NOT override the default transaction processor signal for that transaction.</li>
<li>A transaction sender MAY elect to include separate donation fees which MUST NOT be overridden by the transaction processor if this used or not.</li>
</ul>
<p><span class="editor-note">this proposal is being published as a ZIP for the purpose of discussion and for the Zcash Foundation's sentiment collection process, despite significant issues with lack of clarity in the above specification.</span></p>
</section>
<section id="raised-objections-and-issues-so-far">
<h2>Raised objections and issues so far</h2>
<ul>
<li>This adds complexity to the protocol, which is technically not needed and generally a bad idea.</li>
<li>This does not add anything that cannot already be done under the current protocol by users manually, although not to the same extent.</li>
<li>Block sizes, this may impact the motivation to increase block sizes should that need arise.</li>
<li>Signalling from shielded addresses to donations at taddresses?</li>
<li>Once zcash goes full z address, how will transparency of donations be proven?</li>
<li>ZEC is designed to not have high transaction fees or a secondary transaction fee market. <em>Is this a core principle?</em></li>
<li>A similar goal can be achieved without initial promise and just burn - mistfpga: I dislike taking coins out of circulation intentionally - it is an attempt to avoid that.</li>
<li>Further note: If burn must be an option I would like to use something like the "rolling burn" option. <span class="editor-note">this is not defined; it was intended that another ZIP be written to define it, but that has not been done.</span></li>
</ul>
</section>
<section id="implications-to-other-users">
<h2>Implications to other users</h2>
<ul>
<li>Wallet development will need to be considered. Hopefully the requirements will lessen this impact after the first initial change.</li>
<li>What happens if the Electric Coin Company and/or the Zcash Foundation close down, will the donations:
<ul>
<li>go to into the mining fee</li>
<li>get burnt</li>
<li>get sent as change to the original sender</li>
<li>be distributed via some other mechanism?</li>
</ul>
</li>
</ul>
</section>
<section id="technical-implementation">
<h2>Technical implementation</h2>
<p>Stuff that is already implemented in some form or another:</p>
<ul>
<li>Optional fees are already implemented in some wallet software.</li>
<li>Optional fees already cannot be overridden by miners.</li>
<li>Hardcoded donation addresses are already baked into the protocol so it should be minor work to adjust them to the signalling addresses.</li>
<li>Hardcoded donation address already cannot be changed by pools or software.</li>
<li>Signalling could be handled at the pool level</li>
<li>Pools already add their own addresses to the coinbase, including donations.</li>
</ul>
</section>
<section id="references">
<h2>References</h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="zfnd-guidance" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/">Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019.</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

200
zip-1002.rst Normal file
View File

@ -0,0 +1,200 @@
::
ZIP: 1002
Title: Opt-in Donation Feature
Owner: mistfpga (zcash forums) <steve@mistfpga.net>
Status: Draft
Category: Standards Track
Created: 2019-07-17
License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/>
Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-opt-in-protocol-level-development-donation-option/33846>
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this
document are to be interpreted as described in RFC 2119. [#RFC2119]_
This ZIP defines these terms:
* Signalling is defined as expressing a voice through whatever mechanism is
implemented or sought for that decision. In the context of this ZIP it
primarily refers to signalling what to do with funds. This could be done
by miners, straw poll, coinbase, proof of value, some internet poll thing,
etc.
* Mining software in the context of this ZIP refers to pool software, local
mining software, or staking software.
* Custodial services include any service in which a party controls the
private keys of another party; mining pools and online wallets are examples.
* Mining is defined as the action of processing transactions, so this would
include proof of stake, if Zcash would switch to that.
* User is defined as anyone that uses ZEC or another coin that adopts this
ZIP.
* Mining coins transferred via fees are considered rewards (infinite), coins
generated via block generation are considered distribution (finite).
* Opt-in vs opt-out - Opting out is a purely selfish act in the context of
this ZIP. They do not burn the coins therefore giving everyone value. They
keep them.
* Burning coins is purposefully taking them out of circulation forever at the
protocol block distribution level.
* Initial promise is defined as complete honour of distributing all rewards to
the miner. - This is a non neutral phrase. I accept that.
* Transaction sender is defined as anyone who sends a transaction across the
Zcash network, be it t-t, z-z, t-z, z-t.
* Fee is the standard transaction fee that a sender puts on a transaction to
get it included into a block and that is collected by the miner of that
block.
* Transaction donation is an optional signalling string that creates a payment
to the coins base donations.
* Block Reward is defined as block distribution plus mining fees.
* Spirit is defined as what is the intended outcome of the ZIP. [#spirit]_
.. [#spirit] If there is contradiction between Spirit and any other part of
the proposal that needs to be addressed, in the event it is not addressed
Spirit is assumed to overrule all.
Out of Scope for this Proposal
==============================
Governance on how decisions are made. This ZIP is not meant to be used as a
form of governance. It is a protocol-level opt-in for supporting the Zcash
network development (like the Founders’ Reward, just with opt-out).
Signalling. Whilst a lot of the ZIP relies on the ability to signal intent in
one way or another, it does not put forward such a mechanism and is designed
to work with various form of signalling, or potentially without signalling at
all.
Abstract
========
The spirit of this ZIP is:
* To allow continual funding of the Electric Coin Company, the Zcash Foundation,
or some combination of these should a user choose to do so.
* To add a genuine opt-in feature, which is done at the user's choice.
Motivation
==========
Technology changes, and it changes fast. What works now, may be easily breakable
in 10 years, 20 years and certainly 50 years.
To help ensure ZEC can keep up with these changes, now and in 50 or 500 years'
time, there needs to be a continual funding for research into new technology and
financial stability in order to attract new talent.
The only source of indefinite wealth transfer is transaction fees or donations.
This ZIP is specifically about voluntary donations (including via mining fees).
Requirements
============
.. role:: editor-note
* An additional opt-in mechanism, baked into the protocol. This is a condition
of the Zcash Foundation too. [#foundation]_
* Give an alterative to redistribution of either the current block distribution
structure or the emission curve.
* The funding received by the Electric Coin Company and/or Zcash Foundation under
this proposal MUST only be used to fund ZEC development for the lifetime of
their receipt of it.
* To give a strong indication to the community and users that they have freedom
to decide what they do with their coins and donations.
* Bake the addresses into the node codebase, in order that the wallet software
or pool software does not need to keep track of donation addresses.
* Prevent users from sending donations to old addresses.
* Make it easier for pools to add support and prove that they are actually
donating the percentage they say they are.
* Users MUST NOT be forced to signal.
.. [#foundation] The Zcash Foundation has stated (later clarified in
[#zfnd-guidance]_) that the Foundation would only support proposals that:
a) don’t rely on the Foundation being a single gatekeeper of funds;
b) don’t change the upper bound of ZEC supply; and
c) have some kind of opt-in mechanism for choosing to disburse funds
(from miners and/or users).
Specification
=============
* This ZIP MUST enforce the initial promise as defined by default.
* The official client MUST default to be counted as initial promise.
* No signal MUST be counted as whatever the pool is signalling for, when using
a pool.
* Security MUST NOT be lessened.
* This ZIP MAY be set to opt-in via a user set flag.
* This ZIP MUST contain donation addresses in the coinbase, in a similar fashion
to the current FR.
* When sending transactions the sender MAY signal their donation.
* A signal from a transaction sender MUST NOT override the default transaction
processor signal for that transaction.
* A transaction sender MAY elect to include separate donation fees which MUST NOT
be overridden by the transaction processor if this used or not.
:editor-note:`this proposal is being published as a ZIP for the purpose of
discussion and for the Zcash Foundation's sentiment collection process,
despite significant issues with lack of clarity in the above specification.`
Raised objections and issues so far
===================================
* This adds complexity to the protocol, which is technically not needed
and generally a bad idea.
* This does not add anything that cannot already be done under the current protocol
by users manually, although not to the same extent.
* Block sizes, this may impact the motivation to increase block sizes should that
need arise.
* Signalling from shielded addresses to donations at taddresses?
* Once zcash goes full z address, how will transparency of donations be proven?
* ZEC is designed to not have high transaction fees or a secondary transaction fee
market. *Is this a core principle?*
* A similar goal can be achieved without initial promise and just burn -
mistfpga: I dislike taking coins out of circulation intentionally - it is an
attempt to avoid that.
* Further note: If burn must be an option I would like to use something like the
"rolling burn" option. :editor-note:`this is not defined; it was intended that
another ZIP be written to define it, but that has not been done.`
Implications to other users
===========================
* Wallet development will need to be considered. Hopefully the requirements will
lessen this impact after the first initial change.
* What happens if the Electric Coin Company and/or the Zcash Foundation close down,
will the donations:
- go to into the mining fee
- get burnt
- get sent as change to the original sender
- be distributed via some other mechanism?
Technical implementation
========================
Stuff that is already implemented in some form or another:
* Optional fees are already implemented in some wallet software.
* Optional fees already cannot be overridden by miners.
* Hardcoded donation addresses are already baked into the protocol so it
should be minor work to adjust them to the signalling addresses.
* Hardcoded donation address already cannot be changed by pools or software.
* Signalling could be handled at the pool level
* Pools already add their own addresses to the coinbase, including donations.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#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/>`_

127
zip-1003.html Normal file
View File

@ -0,0 +1,127 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1003
Title: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate
Owner: aristarchus (zcash forums)
Status: Draft
Category: Consensus / Process
Created: 2019-06-19
License: MIT
Discussions-To: &lt;https://forum.zcashcommunity.com/t/dev-fund-proposal-20-split-between-the-ecc-and-the-foundation/33862&gt;</pre>
<section id="terminology">
<h2>Terminology</h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">1</a></p>
<p>For clarity in this ZIP I define these terms:</p>
<dl>
<dt>2nd Halvening period</dt>
<dd>the 4-year period of time, roughly from October 2020 to October 2024, during which at most 5,250,000 ZEC will be minted.</dd>
<dt>3rd Halvening period</dt>
<dd>the 4-year period of time roughly from October 2024 to October 2028.</dd>
<dt>DF%</dt>
<dd>Dev Fund Percentage, the portion of newly minted ZEC in each block reserved for a development fund.</dd>
</dl>
</section>
<section id="abstract">
<h2>Abstract</h2>
<p>This proposal would allocate a 20% Dev Fund Percentage to be split evenly between the Electric Coin Company (ECC) and the Zcash Foundation during the 2nd Halvening period. This proposal aims to be simple to implement, without a single point of failure, and comes with mandates for transparency, accountability and a mandate to build a development fund voting mechanism to be used during the 3rd Halvening period. This proposal is designed to strike a balance between ensuring that high quality development work can continue uninterrupted, with the need to further decentralize Zcash development funding as soon as possible.</p>
</section>
<section id="motivation">
<h2>Motivation</h2>
<p>Strengths of this proposal:</p>
<ol type="1">
<li>Simple to implement. I would rather developers spend time scaling Zcash rather than implementing the development funding mechanism.</li>
<li>Developers will have several years to work on a great decentralized development funding voting mechanism.</li>
<li>20% is a large enough percentage that there should be enough development funding for many different ZEC price scenarios. To those who want to decrease this percentage: Overpaying for security is a gift to miners, to the detriment of every other stakeholder in the Zcash community. I will even make the strong statement that intentionally overpaying the miners for security is stealing from the other stakeholders.</li>
<li>With two entities receiving funds there is no single point of failure.</li>
</ol>
</section>
<section id="requirements-and-specification">
<h2>Requirements and Specification</h2>
<ol type="1">
<li>DF% MUST be 20 percent, split evenly between ECC and the Zcash Foundation during the 2nd Halvening period.</li>
<li>The Dev Fund MUST only be spent on research, development and adoption of Zcash.</li>
<li>A voting system for development funding MUST be built and implemented in order to be used during the 3rd Halvening period.</li>
</ol>
<section id="voting-system-requirements">
<h3>Voting System Requirements</h3>
<p>Here are the general properties of the mandated voting mechanism. I don’t want to specify the technical implementation details, since I believe this is a job suited for the engineers building this system.</p>
<ol type="1">
<li>Voting SHOULD be private.</li>
<li>Only ZEC holders can vote.</li>
<li>Voting should happen on-chain.</li>
<li>In order to vote, you must lock your ZEC so it cannot be spent for a period of time. This is to force the voters to have ‘skin in the game’ and prevent someone nefarious from buying a lot of ZEC just before an election and then dumping it immediately after.</li>
<li>Voters can choose how long to lock their ZEC, and their voting power is proportional to the time that the ZEC is locked. For example, someone who votes with 10 ZEC and locks it for 6 months would have the same voting power as someone who votes with 20 ZEC and locks it for 3 months. Of course there must be a maximum lock time, perhaps a year, to prevent anyone from getting ‘infinite’ voting power by locking their ZEC permanently.</li>
<li>The final results of the vote should be transparent to and verifiable by everyone.</li>
<li>The system should be totally open and allow anyone/any organization to compete for funding to develop Zcash.</li>
</ol>
</section>
<section id="transparency-and-accountability-for-the-ecc-and-the-zcash-foundation">
<h3>Transparency and Accountability for the ECC and the Zcash Foundation</h3>
<p>These requirements would apply to both ECC and the Zcash Foundation. The mandate is to adhere to these accountability requirements originally put forward by the Foundation:</p>
<ul>
<li>Monthly public developer calls, detailing current technical roadmap and updates.</li>
<li>Quarterly technology roadmap reports and updates.</li>
<li>Quarterly financial reports, detailing spending levels/burn rate and cash/ZEC on hand.</li>
<li>A yearly, audited financial report akin to the Form 990 for US-based nonprofits.</li>
<li>Yearly reviews of organization performance, along the lines of the State of the Zcash Foundation report <a href="#zfnd-state" id="id2" class="footnote_reference">2</a>.</li>
</ul>
</section>
<section id="requirements-specifically-for-the-ecc">
<h3>Requirements Specifically for the ECC</h3>
<p>Motivated by the Zcash Foundation’s proposal that the ECC become a non-profit <a href="#zfnd-guidance" id="id3" class="footnote_reference">3</a>, I am going to list general requirements for the ECC to abide by if they choose to receive funds and work on behalf of ZEC holders.</p>
<ol type="1">
<li>Because I share the Foundation’s concern that the ECC could be “beholden to its shareholders”, I am mandating that the ECC should be working in the service of the Zcash community and <strong>shall serve no other masters</strong>. The original investors/founders who are not still working in the service of the Zcash community SHOULD NOT have control over the use of the new development funds.</li>
<li>The revenue received from the Dev Fund SHOULD NOT be used to give further rewards to, even indirectly, the investors, founders, or shareholders of the ECC, who are not working on Zcash after the first halving. <strong>They have already received the Founders’ Reward and this new development fund is not supposed to further benefit them.</strong></li>
<li>The ECC SHOULD offer competitive pay and <strong>a stake in upside of the success of Zcash as a way to attract the best and brightest</strong>. I do want the ECC be able to <strong>maintain a world class team</strong> capable of competing with the tech giants of the world (Google, Apple etc.).</li>
<li>The ECC SHOULD <strong>continue to engage with regulators</strong> and advocate for privacy preserving technology. The <strong>legal structure of the ECC must not hamper these critical efforts</strong> in any way.</li>
</ol>
<p>I am not mandating non-profit status for the ECC. Maybe that is the best legal structure, maybe something else is better.</p>
<p>Finally, in the event that the voting system isn’t implemented by the start of the 3rd Halvening period, the 20% of funds intended to go to the ‘voting development fund’ should instead not be minted.</p>
</section>
</section>
<section id="references">
<h2>References</h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="zfnd-state" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.zfnd.org/blog/foundation-in-2019/">The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="zfnd-guidance" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/">Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019.</a></td>
</tr>
</tbody>
</table>
<br></section>
<section id="change-log">
<h2>Change Log</h2>
<ul>
<li>2019-06-19 Initial post</li>
<li>2019-26-07 Listed three strengths of this proposal</li>
<li>2019-08-13 Voting System Requirements</li>
<li>2019-08-20 Requirements Specifically for the ECC</li>
<li>2019-08-29 Update to be more like a ZIP draft.</li>
</ul>
</section>
</section>
</body>
</html>

171
zip-1003.rst Normal file
View File

@ -0,0 +1,171 @@
::
ZIP: 1003
Title: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate
Owner: aristarchus (zcash forums)
Status: Draft
Category: Consensus / Process
Created: 2019-06-19
License: MIT
Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-20-split-between-the-ecc-and-the-foundation/33862>
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document
are to be interpreted as described in RFC 2119. [#RFC2119]_
For clarity in this ZIP I define these terms:
2nd Halvening period
the 4-year period of time, roughly from October 2020 to October 2024,
during which at most 5,250,000 ZEC will be minted.
3rd Halvening period
the 4-year period of time roughly from October 2024 to October 2028.
DF%
Dev Fund Percentage, the portion of newly minted ZEC in each block
reserved for a development fund.
Abstract
========
This proposal would allocate a 20% Dev Fund Percentage to be split evenly
between the Electric Coin Company (ECC) and the Zcash Foundation during the
2nd Halvening period. This proposal aims to be simple to implement, without
a single point of failure, and comes with mandates for transparency,
accountability and a mandate to build a development fund voting mechanism
to be used during the 3rd Halvening period. This proposal is designed to
strike a balance between ensuring that high quality development work can
continue uninterrupted, with the need to further decentralize Zcash
development funding as soon as possible.
Motivation
==========
Strengths of this proposal:
1. Simple to implement. I would rather developers spend time scaling Zcash
rather than implementing the development funding mechanism.
2. Developers will have several years to work on a great decentralized
development funding voting mechanism.
3. 20% is a large enough percentage that there should be enough development
funding for many different ZEC price scenarios. To those who want to
decrease this percentage: Overpaying for security is a gift to miners,
to the detriment of every other stakeholder in the Zcash community.
I will even make the strong statement that intentionally overpaying the
miners for security is stealing from the other stakeholders.
4. With two entities receiving funds there is no single point of failure.
Requirements and Specification
==============================
1. DF% MUST be 20 percent, split evenly between ECC and the Zcash Foundation
during the 2nd Halvening period.
2. The Dev Fund MUST only be spent on research, development and adoption of
Zcash.
3. A voting system for development funding MUST be built and implemented in
order to be used during the 3rd Halvening period.
Voting System Requirements
--------------------------
Here are the general properties of the mandated voting mechanism. I don’t
want to specify the technical implementation details, since I believe this
is a job suited for the engineers building this system.
1. Voting SHOULD be private.
2. Only ZEC holders can vote.
3. Voting should happen on-chain.
4. In order to vote, you must lock your ZEC so it cannot be spent for a
period of time. This is to force the voters to have ‘skin in the game’
and prevent someone nefarious from buying a lot of ZEC just before an
election and then dumping it immediately after.
5. Voters can choose how long to lock their ZEC, and their voting power is
proportional to the time that the ZEC is locked. For example, someone
who votes with 10 ZEC and locks it for 6 months would have the same
voting power as someone who votes with 20 ZEC and locks it for 3 months.
Of course there must be a maximum lock time, perhaps a year, to prevent
anyone from getting ‘infinite’ voting power by locking their ZEC
permanently.
6. The final results of the vote should be transparent to and verifiable by
everyone.
7. The system should be totally open and allow anyone/any organization to
compete for funding to develop Zcash.
Transparency and Accountability for the ECC and the Zcash Foundation
--------------------------------------------------------------------
These requirements would apply to both ECC and the Zcash Foundation. The
mandate is to adhere to these accountability requirements originally put
forward by the Foundation:
* Monthly public developer calls, detailing current technical roadmap and
updates.
* Quarterly technology roadmap reports and updates.
* Quarterly financial reports, detailing spending levels/burn rate and
cash/ZEC on hand.
* A yearly, audited financial report akin to the Form 990 for US-based
nonprofits.
* Yearly reviews of organization performance, along the lines of the
State of the Zcash Foundation report [#zfnd-state]_.
Requirements Specifically for the ECC
-------------------------------------
Motivated by the Zcash Foundation’s proposal that the ECC become a non-profit
[#zfnd-guidance]_, I am going to list general requirements for the ECC to
abide by if they choose to receive funds and work on behalf of ZEC holders.
1. Because I share the Foundation’s concern that the ECC could be “beholden
to its shareholders”, I am mandating that the ECC should be working in
the service of the Zcash community and **shall serve no other masters**.
The original investors/founders who are not still working in the service
of the Zcash community SHOULD NOT have control over the use of the new
development funds.
2. The revenue received from the Dev Fund SHOULD NOT be used to give further
rewards to, even indirectly, the investors, founders, or shareholders of
the ECC, who are not working on Zcash after the first halving.
**They have already received the Founders’ Reward and this new development
fund is not supposed to further benefit them.**
3. The ECC SHOULD offer competitive pay and **a stake in upside of the
success of Zcash as a way to attract the best and brightest**. I do want
the ECC be able to **maintain a world class team** capable of competing
with the tech giants of the world (Google, Apple etc.).
4. The ECC SHOULD **continue to engage with regulators** and advocate for
privacy preserving technology. The **legal structure of the ECC must not
hamper these critical efforts** in any way.
I am not mandating non-profit status for the ECC. Maybe that is the best
legal structure, maybe something else is better.
Finally, in the event that the voting system isn’t implemented by the start
of the 3rd Halvening period, the 20% of funds intended to go to the ‘voting
development fund’ should instead not be minted.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#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/>`_
.. raw:: html
<br>
Change Log
==========
* 2019-06-19 Initial post
* 2019-26-07 Listed three strengths of this proposal
* 2019-08-13 Voting System Requirements
* 2019-08-20 Requirements Specifically for the ECC
* 2019-08-29 Update to be more like a ZIP draft.

158
zip-1004.html Normal file
View File

@ -0,0 +1,158 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1004: Miner-Directed Dev Fund</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1004
Title: Miner-Directed Dev Fund
Owner: Andrew Miller (@amiller on zcash forums)
Status: Draft
Category: Consensus
Created: 2019-06-19
License: public domain
Discussions-To: &lt;https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-directed-dev-fund-was-20-to-any-combination-of-ecc-zfnd-parity-or-burn/33864&gt;</pre>
<section id="terminology">
<h2>Terminology</h2>
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">1</a></p>
<p>For clarity, this ZIP defines these terms:</p>
<dl>
<dt>2nd Halvening Period</dt>
<dd>the 4-year period of time, roughly from October 2020 - October 2024, during which at most 5,250,000 ZEC will be minted.</dd>
<dt>DF%</dt>
<dd>Dev Fund Percentage, the portion of newly minted ZEC in each block reserved for a development fund.</dd>
<dt>MR%</dt>
<dd>Miner Reward Percentage, the portion of newly minted ZEC in each block given to miners (so that DF% + MR% = 100%).</dd>
</dl>
</section>
<section id="abstract">
<h2>Abstract</h2>
<p>This proposal reserves a portion (20%) of the newly minted coins in each block for the development fund. A fixed set of developer entities would be eligible to receive these funds. The fund would be miner-directed in the sense that the miner of each block can determine how to allocate these funds to eligible developers.</p>
</section>
<section id="out-of-scope-for-this-proposal">
<h2>Out of Scope for this proposal</h2>
<ul>
<li>This proposal does not (currently) specify any process for reaching agreement on or modifying the fixed set of development entities.</li>
<li>This proposal does not specify how miners should reach a decision on how to direct the development fund, or how developers should appeal to miners to do so. Other development fund proposals include specific processes for accountability and to support community decision making, such as monthly developer calls, lists of planned features and goals, etc. Any of these can be compatible with this proposal as well, by providing non-binding advice to miners, by reaching agreement on implementation defaults, by guiding the choice of the fixed set of developers, etc.</li>
<li>This proposal only provides a guideline for the 2nd Halvening Period.</li>
</ul>
</section>
<section id="motivation">
<h2>Motivation</h2>
<p>Like most development fund proposals, this is motivated by the potential value to the Zcash community of using newly minted coins to hire developers to continue improving Zcash. <a href="#amiller-notes" id="id2" class="footnote_reference">2</a></p>
<p>Unlike most other development fund proposals, this proposal is distinct in providing a fine-grained “opt-in” <a href="#acityinohio-comment" id="id3" class="footnote_reference">3</a> feature, since miners have the choice to provide a small amount of development funding or none at all.</p>
</section>
<section id="requirements">
<h2>Requirements</h2>
<ul>
<li>Simplicity: A design goal of this proposal is to be simple to define and implement, without specifying much process for on-chain or off-chain governance.</li>
<li>Opt-in: The proposed development fund is not mandatory, since miners can decide not to allocate any funds at all to the developer entities.</li>
<li>Incentive-compatible: Miners cannot directly pay the development fund to themselves.</li>
</ul>
</section>
<section id="specification">
<h2>Specification</h2>
<p>During the 2nd Halvening Period, a fixed portion (DF% = 20%) of the newly minted coins in each block are reserved for a Miner-Directed Dev Fund (MDDF). A hardcoded set of developer entities (e.g., Electric Coin Company, Zcash Foundation, Parity, or others), represented in the code by their t-address or z-address public keys, are eligible to receive funding from the MDDF. The fund is “miner-directed” in the sense that the miner in each block chooses how to allocate the MDDF coins among the developer entities, simply by creating outputs in the coinbase transaction. The DF% is a maximum — miners can also “opt out” by minting a lower number of coins for the MDDF, or none at all.</p>
<p>This proposal is explicitly limited in scope to the 2nd Halvening Period. After the end of this period, the entire block reward in each block is awarded to the miner. The upper bound on the rate of newly minted coins MUST remain the same as before this proposal (i.e., at most 25 ZEC minted per 10 minutes during the 2nd Halvening Period).</p>
<p>Implementations MAY define a default opt-in allocation (e.g., DF%/2 to the Electric Coin Company and DF%/2 to the Zcash Foundation).</p>
<p>Implementations SHOULD support changing the allocation (overriding any such default) through a configuration option.</p>
<section id="examples">
<h3>Examples</h3>
<p>The following examples illustrate how miners can build the outputs of the coinbase transactions to allocate the MDDF to eligible developers. Assume <code>Dev1</code>, <code>Dev2</code> are the hardcoded addresses of eligible developers, and <code>Miner</code> is the address of the mining pool mining this block. Assume that the total newly minted coins are 3.125 ZEC per block during the 2nd Halvening Period (this takes into account the change to a 75-second block target spacing after the Blossom Network Upgrade <a href="#zip-0208" id="id4" class="footnote_reference">5</a>), and that DF% = 20%, MR% = 80%.</p>
<p><strong>Example 1: Split equally between two developers</strong></p>
<p>The transaction outputs of the coinbase transaction are as follows:</p>
<ul>
<li>2.5 ZEC to <code>Miner</code></li>
<li>0.3125 ZEC to <code>Dev1</code></li>
<li>0.3125 ZEC to <code>Dev2</code>.</li>
</ul>
<p><strong>Example 2: Opt-out of the development fund</strong></p>
<p>The transaction outputs of the coinbase transaction are as follows:</p>
<ul>
<li>2.5 ZEC to <code>Miner</code>.</li>
</ul>
</section>
</section>
<section id="issues-and-further-discussion">
<h2>Issues and Further Discussion</h2>
<p>Raised objections and issues so far:</p>
<ul>
<li>Miners may have adverse incentives, such as:
<ul>
<li>Stonewalling any development of Proof-of-Work alternatives, such as GPU-friendly variants or Proof-of-Stake.</li>
<li>Extortion for more funds. To illustrate: "We’ll direct all 20% of the development fund to DeveloperX, but only if they promise to keep just 5% and pass 15% back to the mining pool.”</li>
<li>Blocking the development fund out of greed.</li>
</ul>
</li>
<li>This proposal modifies the terms of what some may consider a social contract: given the original code in Zcash implementations, by the end of the issuance schedule when all 21 million ZEC have been minted, a total of 90% of all minted coins would have originally been awarded to miners. Under this proposal, less reward would be available to miners, than would be available to them according to the original minting schedule.</li>
<li>Several others, notably the Blocktown Capital proposal <a href="#blocktown-summary" id="id5" class="footnote_reference">4</a>, have suggested that a 20% development fund would set a precedent for a perpetual 20% development fund. This proposal is explicitly limited in scope to the 2nd Halvening Period. Thus adopting this proposal on its own, if there are no further updates, would result in the the development fund ending in 2024.</li>
</ul>
</section>
<section id="references">
<h2>References</h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="amiller-notes" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://medium.com/@socrates1024/here-are-a-couple-of-points-on-framing-the-discussion-of-a-potential-new-dev-fund-in-zcash-c13bcbf4ed5b">Notes on reaching agreement about a potential Zcash development fund. Andrew Miller, June 3, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="acityinohio-comment" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://forum.zcashcommunity.com/t/the-future-of-zcash-in-the-year-2020/32372/267">Comment on a post “The future of Zcash in the year 2020” in the Zcash Community Forum. Josh Cincinnati, June 3, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="blocktown-summary" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="https://medium.com/blocktown/executive-summary-blocktown-proposal-for-zcash-2020-network-upgrade-84ff20997502">Executive Summary: Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 15, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="zip-0208" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
</tr>
</tbody>
</table>
<br></section>
<section id="change-log">
<h2>Change Log</h2>
<ul>
<li>2019-06-19 Initial post</li>
<li>2019-08-28
<ul>
<li>Update to be more like a ZIP draft</li>
<li>Renamed to Miner-Directed Dev Fund</li>
<li>Removed references to “Burn”, instead opt-out is in terms of coins never being minted in the first place</li>
</ul>
</li>
<li>2019-08-29
<ul>
<li>Address informal pre-ZIP feedback</li>
<li>Add example, requirements, fix incomplete sentence about default allocations</li>
</ul>
</li>
<li>2019-09-15 Move to GitHub</li>
</ul>
</section>
</section>
</body>
</html>

194
zip-1004.rst Normal file
View File

@ -0,0 +1,194 @@
::
ZIP: 1004
Title: Miner-Directed Dev Fund
Owner: Andrew Miller (@amiller on zcash forums)
Status: Draft
Category: Consensus
Created: 2019-06-19
License: public domain
Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-directed-dev-fund-was-20-to-any-combination-of-ecc-zfnd-parity-or-burn/33864>
Terminology
===========
The key words "MUST", "SHOULD", and "MAY" in this document are to be
interpreted as described in RFC 2119. [#RFC2119]_
For clarity, this ZIP defines these terms:
2nd Halvening Period
the 4-year period of time, roughly from October 2020 - October 2024,
during which at most 5,250,000 ZEC will be minted.
DF%
Dev Fund Percentage, the portion of newly minted ZEC in each block
reserved for a development fund.
MR%
Miner Reward Percentage, the portion of newly minted ZEC in each block
given to miners (so that DF% + MR% = 100%).
Abstract
========
This proposal reserves a portion (20%) of the newly minted coins in each
block for the development fund. A fixed set of developer entities would be
eligible to receive these funds. The fund would be miner-directed in the
sense that the miner of each block can determine how to allocate these funds
to eligible developers.
Out of Scope for this proposal
==============================
* This proposal does not (currently) specify any process for reaching
agreement on or modifying the fixed set of development entities.
* This proposal does not specify how miners should reach a decision on how
to direct the development fund, or how developers should appeal to miners
to do so. Other development fund proposals include specific processes for
accountability and to support community decision making, such as monthly
developer calls, lists of planned features and goals, etc. Any of these
can be compatible with this proposal as well, by providing non-binding
advice to miners, by reaching agreement on implementation defaults, by
guiding the choice of the fixed set of developers, etc.
* This proposal only provides a guideline for the 2nd Halvening Period.
Motivation
==========
Like most development fund proposals, this is motivated by the potential
value to the Zcash community of using newly minted coins to hire developers
to continue improving Zcash. [#amiller-notes]_
Unlike most other development fund proposals, this proposal is distinct in
providing a fine-grained “opt-in” [#acityinohio-comment]_ feature, since
miners have the choice to provide a small amount of development funding or
none at all.
Requirements
============
* Simplicity: A design goal of this proposal is to be simple to define and
implement, without specifying much process for on-chain or off-chain
governance.
* Opt-in: The proposed development fund is not mandatory, since miners can
decide not to allocate any funds at all to the developer entities.
* Incentive-compatible: Miners cannot directly pay the development fund to
themselves.
Specification
=============
During the 2nd Halvening Period, a fixed portion (DF% = 20%) of the newly
minted coins in each block are reserved for a Miner-Directed Dev Fund (MDDF).
A hardcoded set of developer entities (e.g., Electric Coin Company, Zcash
Foundation, Parity, or others), represented in the code by their t-address
or z-address public keys, are eligible to receive funding from the MDDF.
The fund is “miner-directed” in the sense that the miner in each block
chooses how to allocate the MDDF coins among the developer entities, simply
by creating outputs in the coinbase transaction. The DF% is a maximum —
miners can also “opt out” by minting a lower number of coins for the MDDF,
or none at all.
This proposal is explicitly limited in scope to the 2nd Halvening Period.
After the end of this period, the entire block reward in each block is
awarded to the miner. The upper bound on the rate of newly minted coins MUST
remain the same as before this proposal (i.e., at most 25 ZEC minted per
10 minutes during the 2nd Halvening Period).
Implementations MAY define a default opt-in allocation (e.g., DF%/2 to the
Electric Coin Company and DF%/2 to the Zcash Foundation).
Implementations SHOULD support changing the allocation (overriding any such
default) through a configuration option.
Examples
--------
The following examples illustrate how miners can build the outputs of the
coinbase transactions to allocate the MDDF to eligible developers. Assume
``Dev1``, ``Dev2`` are the hardcoded addresses of eligible developers, and
``Miner`` is the address of the mining pool mining this block. Assume that
the total newly minted coins are 3.125 ZEC per block during the 2nd Halvening
Period (this takes into account the change to a 75-second block target
spacing after the Blossom Network Upgrade [#zip-0208]_), and that DF% = 20%,
MR% = 80%.
**Example 1: Split equally between two developers**
The transaction outputs of the coinbase transaction are as follows:
* 2.5 ZEC to ``Miner``
* 0.3125 ZEC to ``Dev1``
* 0.3125 ZEC to ``Dev2``.
**Example 2: Opt-out of the development fund**
The transaction outputs of the coinbase transaction are as follows:
* 2.5 ZEC to ``Miner``.
Issues and Further Discussion
=============================
Raised objections and issues so far:
* Miners may have adverse incentives, such as:
- Stonewalling any development of Proof-of-Work alternatives, such as
GPU-friendly variants or Proof-of-Stake.
- Extortion for more funds. To illustrate: "We’ll direct all 20% of the
development fund to DeveloperX, but only if they promise to keep just
5% and pass 15% back to the mining pool.”
- Blocking the development fund out of greed.
* This proposal modifies the terms of what some may consider a social
contract: given the original code in Zcash implementations, by the end
of the issuance schedule when all 21 million ZEC have been minted, a
total of 90% of all minted coins would have originally been awarded to
miners. Under this proposal, less reward would be available to miners,
than would be available to them according to the original minting schedule.
* Several others, notably the Blocktown Capital proposal [#blocktown-summary]_,
have suggested that a 20% development fund would set a precedent for a
perpetual 20% development fund. This proposal is explicitly limited in
scope to the 2nd Halvening Period. Thus adopting this proposal on its
own, if there are no further updates, would result in the the development
fund ending in 2024.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#amiller-notes] `Notes on reaching agreement about a potential Zcash development fund. Andrew Miller, June 3, 2019. <https://medium.com/@socrates1024/here-are-a-couple-of-points-on-framing-the-discussion-of-a-potential-new-dev-fund-in-zcash-c13bcbf4ed5b>`_
.. [#acityinohio-comment] `Comment on a post “The future of Zcash in the year 2020” in the Zcash Community Forum. Josh Cincinnati, June 3, 2019. <https://forum.zcashcommunity.com/t/the-future-of-zcash-in-the-year-2020/32372/267>`_
.. [#blocktown-summary] `Executive Summary: Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 15, 2019. <https://medium.com/blocktown/executive-summary-blocktown-proposal-for-zcash-2020-network-upgrade-84ff20997502>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
.. raw:: html
<br>
Change Log
==========
* 2019-06-19 Initial post
* 2019-08-28
- Update to be more like a ZIP draft
- Renamed to Miner-Directed Dev Fund
- Removed references to “Burn”, instead opt-out is in terms of coins never being minted in the first place
* 2019-08-29
- Address informal pre-ZIP feedback
- Add example, requirements, fix incomplete sentence about default allocations
* 2019-09-15 Move to GitHub

75
zip-1005.html Normal file
View File

@ -0,0 +1,75 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1005: Zcash Community Funding System</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1005
Title: Zcash Community Funding System
Owner: Dimitris Apostolou &lt;dimitris.apostolou@icloud.com&gt;
Status: Draft
Category: Consensus
Created: 2019-06-23
License: MIT
Discussions-To: &lt;https://forum.zcashcommunity.com/t/zip-proposal-zcfs-zcash-community-funding-system/33898&gt;</pre>
<section id="abstract">
<h2>Abstract</h2>
<p>This proposal introduces a new funding mechanism called the Zcash Community Funding System (ZCFS).</p>
</section>
<section id="motivation">
<h2>Motivation</h2>
<p>The motivations for ZCFS are:</p>
<ul>
<li>The Founders’ Reward is set to expire in 2020.</li>
<li>The Founders’ Reward has caused significant friction in the Zcash community and sparked forks due to disagreement with its very existence.</li>
<li>There needs to be a more fair and decentralized funding mechanism.</li>
</ul>
</section>
<section id="specification">
<h2>Specification</h2>
<p>This specification is a modification of the Monero Community Crowdfunding System (CCS) and is defined as follows:</p>
<ol type="1">
<li>The Founders’ Reward ends in October 2020 as specified by the current consensus rules.</li>
<li>An individual, team or company (for-profit or non-profit), henceforth ‘proposer’, has an idea to improve the Zcash ecosystem that requires funds.</li>
<li>The proposer creates a ZCFS proposal in a modified version of the existing <a href="https://www.zfnd.org/grants/">ZF Grants website</a>, to be called the ZCFS website. The ZF Grants website already has the basic infrastructure for this mechanism and needs to be tweaked in order to facilitate this specification. The ZF Grants website will continue to operate in its current form.</li>
<li>Upon activation of this proposal, the Zcash Foundation is put in charge of the ZCFS.</li>
<li>The Zcash Foundation is required to make ZCFS proposals for its own funding. If the community decides not to fund it, then the ownership of the ZCFS is transferred to the proposer who is instead funded by the community for that matter. <span class="editor-note">the meaning of "the proposer" here is unclear.</span></li>
<li>After a ZCFS proposal has been created, the community discusses the pros and cons of the proposal, and offers feedback and critique.</li>
<li>The proposer changes the proposal (if necessary), utilizing the feedback and critique of the community.</li>
<li>Repeat steps 6 and 7 as needed.</li>
<li>After the Zcash Foundation (or whoever has ownership of the ZCFS at the time) has determined that the community has reached loose consensus, the funding begins by ZEC holders who wish to donate.</li>
<li>Once fully funded (not guaranteed), the proposer begins on the work, if they haven’t already.</li>
<li>Milestones are completed and funds are disbursed upon their completion.</li>
<li>After all milestones are completed, the proposal is locked and all information is retained for posterity.</li>
</ol>
</section>
<section id="rules-and-expectations">
<h2>Rules and Expectations</h2>
<p>The ZCFS is intentionally left as informal as possible. This allows for flexibility of the system, and keeps things from being red-taped into oblivion. However, there are some things you should understand, things that will be expected of you, as either a proposer or a donor, and a recommended way of structuring a proposal for maximum likelihood that your project will be funded.</p>
<section id="for-donors">
<h3>For Donors</h3>
<ol type="1">
<li>The ZCFS is escrowed by the Zcash Foundation (or whoever has ownership of the ZCFS at the time). When you make a donation, you are releasing funds to them to disburse when they deem the community agrees that a milestone is complete. They do not do the work to verify donors, and the final decision for all disputes falls with them, although they do their best to follow community sentiment.</li>
<li>In the event that a proposal is overfunded, unable to be completed, or otherwise put in a state where donated money will not be disbursed to the proposer, the default is that the remaining ZEC will be put in the ZF Grants fund.</li>
<li>Refunds are extraordinarily rare. Donate accordingly.</li>
<li>If the proposer disappears, no problem, someone else can pick up from their last milestone.</li>
<li>Milestone and payout structures vary per proposal based on the proposer’s wishes. It is up to the donor to do their due diligence in whether or not they support the proposal in its entirety.</li>
</ol>
</section>
<section id="for-proposers">
<h3>For Proposers</h3>
<ol type="1">
<li>There is no guarantee that your project will get past the community feedback stage, and if it does, there is no guarantee that it will be funded.</li>
<li>You have to drum up support for your proposal during the feedback and funding stages. Do not expect others (especially the Zcash Foundation or other trusted members of the community) to do it for you. Others may share and support if they are excited about your project, but ultimately it is nobody’s responsibility but your own.</li>
<li>It is expected that you provide updates on the progress of your proposal to the community. For every milestone completed there should be a written report put into your ZCFS proposal announcing its completion and the work done, but depending on the timeline of your project, it may be wise to update the community more frequently.</li>
<li>All work must be licensed permissively at all stages of the proposal. There is no time where your work can be licensed under a restrictive license (even as you’re working on it). Your proposal will be terminated if this is not remedied.</li>
<li>You may NOT under any circumstances include a donation address directly in your proposal. This circumvents the ZCFS, and can lead to scams.</li>
<li>Your work on the project can begin before the proposal is fully funded but disbursement of funds is done only upon completion of milestones and only if the proposal is fully funded.</li>
</ol>
</section>
</section>
</section>
</body>
</html>

125
zip-1005.rst Normal file
View File

@ -0,0 +1,125 @@
::
ZIP: 1005
Title: Zcash Community Funding System
Owner: Dimitris Apostolou <dimitris.apostolou@icloud.com>
Status: Draft
Category: Consensus
Created: 2019-06-23
License: MIT
Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-zcfs-zcash-community-funding-system/33898>
Abstract
========
This proposal introduces a new funding mechanism called the Zcash Community
Funding System (ZCFS).
Motivation
==========
The motivations for ZCFS are:
* The Founders’ Reward is set to expire in 2020.
* The Founders’ Reward has caused significant friction in the Zcash community
and sparked forks due to disagreement with its very existence.
* There needs to be a more fair and decentralized funding mechanism.
Specification
=============
.. role:: editor-note
This specification is a modification of the Monero Community Crowdfunding
System (CCS) and is defined as follows:
1. The Founders’ Reward ends in October 2020 as specified by the current
consensus rules.
2. An individual, team or company (for-profit or non-profit), henceforth
‘proposer’, has an idea to improve the Zcash ecosystem that requires funds.
3. The proposer creates a ZCFS proposal in a modified version of the existing
`ZF Grants website <https://www.zfnd.org/grants/>`_, to be called the ZCFS
website. The ZF Grants website already has the basic infrastructure for
this mechanism and needs to be tweaked in order to facilitate this
specification. The ZF Grants website will continue to operate in its
current form.
4. Upon activation of this proposal, the Zcash Foundation is put in charge of
the ZCFS.
5. The Zcash Foundation is required to make ZCFS proposals for its own
funding. If the community decides not to fund it, then the ownership of
the ZCFS is transferred to the proposer who is instead funded by the
community for that matter. :editor-note:`the meaning of "the proposer"
here is unclear.`
6. After a ZCFS proposal has been created, the community discusses the pros
and cons of the proposal, and offers feedback and critique.
7. The proposer changes the proposal (if necessary), utilizing the feedback
and critique of the community.
8. Repeat steps 6 and 7 as needed.
9. After the Zcash Foundation (or whoever has ownership of the ZCFS at the
time) has determined that the community has reached loose consensus, the
funding begins by ZEC holders who wish to donate.
10. Once fully funded (not guaranteed), the proposer begins on the work, if
they haven’t already.
11. Milestones are completed and funds are disbursed upon their completion.
12. After all milestones are completed, the proposal is locked and all
information is retained for posterity.
Rules and Expectations
======================
The ZCFS is intentionally left as informal as possible. This allows for
flexibility of the system, and keeps things from being red-taped into
oblivion. However, there are some things you should understand, things that
will be expected of you, as either a proposer or a donor, and a recommended
way of structuring a proposal for maximum likelihood that your project will
be funded.
For Donors
----------
1. The ZCFS is escrowed by the Zcash Foundation (or whoever has ownership of
the ZCFS at the time). When you make a donation, you are releasing funds
to them to disburse when they deem the community agrees that a milestone
is complete. They do not do the work to verify donors, and the final
decision for all disputes falls with them, although they do their best to
follow community sentiment.
2. In the event that a proposal is overfunded, unable to be completed, or
otherwise put in a state where donated money will not be disbursed to the
proposer, the default is that the remaining ZEC will be put in the
ZF Grants fund.
3. Refunds are extraordinarily rare. Donate accordingly.
4. If the proposer disappears, no problem, someone else can pick up from
their last milestone.
5. Milestone and payout structures vary per proposal based on the proposer’s
wishes. It is up to the donor to do their due diligence in whether or not
they support the proposal in its entirety.
For Proposers
-------------
1. There is no guarantee that your project will get past the community
feedback stage, and if it does, there is no guarantee that it will be
funded.
2. You have to drum up support for your proposal during the feedback and
funding stages. Do not expect others (especially the Zcash Foundation
or other trusted members of the community) to do it for you. Others may
share and support if they are excited about your project, but ultimately
it is nobody’s responsibility but your own.
3. It is expected that you provide updates on the progress of your proposal
to the community. For every milestone completed there should be a written
report put into your ZCFS proposal announcing its completion and the work
done, but depending on the timeline of your project, it may be wise to
update the community more frequently.
4. All work must be licensed permissively at all stages of the proposal.
There is no time where your work can be licensed under a restrictive
license (even as you’re working on it). Your proposal will be terminated
if this is not remedied.
5. You may NOT under any circumstances include a donation address directly
in your proposal. This circumvents the ZCFS, and can lead to scams.
6. Your work on the project can begin before the proposal is fully funded
but disbursement of funds is done only upon completion of milestones and
only if the proposal is fully funded.

211
zip-1006.html Normal file
View File

@ -0,0 +1,211 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1006: Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1006
Title: Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity
Owners: James Todaro &lt;james@blocktown.capital&gt;
Joseph Todaro &lt;joseph@blocktown.capital&gt;
Credits: Mario Laul &lt;mario@placeholder.vc&gt;
Chris Burniske &lt;chris@placeholder.vc&gt;
Status: Draft
Category: Consensus / Process
Created: 2019-08-31
License: MIT
Discussions-To: &lt;https://forum.zcashcommunity.com/t/blocktown-development-fund-proposal-10-to-a-2-of-3-multisig-with-community-involved-third-entity/34782&gt;</pre>
<section id="terminology">
<h2>Terminology</h2>
<p>The key words “MUST”, “SHOULD”, “SHOULD NOT”, and “MAY” in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">1</a></p>
<p>The additional terms below are to be interpreted as follows:</p>
<dl>
<dt>Mining</dt>
<dd>The actions of processing transactions, which include processing transactions in a Proof-of-Stake or Proof-of-Work/Proof-of-Stake hybrid system, in the event Zcash implements either at a future date.</dd>
<dt>Mining software</dt>
<dd>Pool software, local mining software or staking software.</dd>
<dt>Mining rewards / Block rewards</dt>
<dd>Network transaction fees and/or coinbase rewards (e.g. newly issued ZEC associated with block generation).</dd>
<dt>Network Upgrade</dt>
<dd>Any consensus rule change to the Zcash protocol, introduced as part of the standard Zcash Network Upgrade Pipeline <a href="#nu-pipeline" id="id2" class="footnote_reference">9</a> or otherwise.</dd>
<dt>Founder’s Reward</dt>
<dd>The 20% ZEC from mined blocks allocated to the Electric Coin Company (ECC), Zcash Foundation (ZF), employees, investors and/or other entities prior to the expected first halving in October 2020.</dd>
<dt>Zcash Development Fund</dt>
<dd>Transparent address(es) controlled jointly by the Electric Coin Company, Zcash Foundation, and a “Third Entity”. The fund is intended for research, development, maintenance, and other technical work directly connected to the Zcash protocol, as well as non-technical initiatives (including design, marketing, events, regulatory outreach, education, governance, and any other form of business or community development) that contribute to the long-term success of the Zcash network. In the context of this proposal, the Zcash Development Fund consists of 10% of newly issued ZEC from block rewards between the first and second halvings of the Zcash network.</dd>
<dt>Applicant</dt>
<dd>Any individual, group, or entity that seeks funding from the Zcash Development Fund.</dd>
<dt>Recipient</dt>
<dd>Any individual, group, or entity that receives funding from the Zcash Development Fund.</dd>
</dl>
</section>
<section id="abstract">
<h2>Abstract</h2>
<p>This proposal puts forward the financing mechanism and fundamental rules of governance for the creation of a Zcash Development Fund.</p>
</section>
<section id="specification">
<h2>Specification</h2>
<section id="funding-mechanism-of-the-zcash-development-fund">
<h3>Funding mechanism of the Zcash Development Fund</h3>
<ul>
<li>This funding mechanism MUST be hard-coded so that 10% of newly issued ZEC from block rewards are automatically directed to the transparent address(es) of the Zcash Development Fund.</li>
<li>The above requirement MUST be met between the first halving and second halving. Upon the second halving, future governance decisions MAY result in a further decrease of the Zcash Development Fund to 5% of newly issued ZEC from block rewards, or alternatively MAY result in another percent allocation which includes the possibility of a system whereby 100% of block rewards go to miners.</li>
<li>The two aforementioned requirements above MUST remain regardless of any additional Network Upgrades or changes to mining or mining software prior to the second halving.</li>
<li>The Zcash Development Fund MAY outlive the period of its initial funding mechanism, either through the appreciation in the price of ZEC, or from alternative funding sources upon the second halving in 2024.</li>
<li>The hard-coded transparent address(es) of the Zcash Development Fund MAY be periodically rotated for operational security purposes to decrease the risk of any potential loss of funds associated with the address(es). The ECC, ZF, and/or “Third Entity” described below SHOULD take any possible precautions within the confines of this Specification section to avoid loss of funds.</li>
</ul>
</section>
<section id="governance-of-the-zcash-development-fund">
<h3>Governance of the Zcash Development Fund</h3>
<ul>
<li>Funds allocated to the Zcash Development Fund MUST be used only for their intended purpose as defined in the following Rationale section of this proposal.</li>
<li>The transparent address(es) of the Zcash Development Fund MUST be jointly controlled by the ECC, ZF, and Third Entity, and all funds transferred from the Zcash Development Fund MUST be publicly confirmed in an official manner by a majority decision among the ECC, ZF, and Third Entity–commonly referred to as “2-of-3 multisig”. That is, funding decisions MUST be put to an officially documented vote which MUST NOT pass unless at least 2 of the 3 entities above vote approvingly.</li>
<li>Prior to any movement of funds from the Zcash Development Fund, the ZF and ECC MUST coordinate with each other and the community to establish the Third Entity that will be involved in governance of the Zcash Development Fund. The process of determining the exact initial composition and rules of governance of the Third Entity MUST involve the Zcash community at large in a process similar to that outlined in the section "How the Foundation will select a particular proposal" in the ZF’s August 6, 2019 statement <a href="#zfnd-guidance" id="id3" class="footnote_reference">2</a>.</li>
</ul>
<p>The governance rules of the Third Entity MUST include the following:</p>
<ul>
<li>All decision-making and other governing processes of the Third Entity MUST be independent of the ECC and ZF, and MUST include measures that are necessary to avoid conflicts of interest in relation to the ECC and ZF.</li>
<li>At creation, the Third Entity MUST include an uneven number of at least 5 individuals with independent previous affiliations, each having a single vote. All such decisions MUST have majority support within the Third Entity to result in an overall approving vote by the Third Entity.</li>
<li>Once the Third Entity is established, it MAY decide to change its rules of governance (e.g. simple majority versus supermajority rules), but any such change MUST be preceded by the involvement of the Zcash community at large, similar to the process outlined in the ZF’s August 6, 2019 statement <a href="#zfnd-guidance" id="id4" class="footnote_reference">2</a>.</li>
<li>Once the Third Entity is established as a self-governing body, it SHOULD evolve toward a system whereby ZEC holders have a direct role in determining votes and internal governance of the Third Entity.</li>
<li>The Third Entity MAY apply for funding from the Zcash Development Fund, if deemed appropriate by its governing body. This would be subject to a majority vote by the ECC, ZF and Third Entity.</li>
</ul>
<p>Prior to any transfer of funds from the Zcash Development Fund, the ECC, ZF, and Third Entity MUST specify, approve, and make public the final rules on applying for and receiving funding from the Zcash Development Fund, including the details of the decision-making process for approving or rejecting funding requests. These rules MUST apply equally to all Applicants, including the ECC, ZF, and Third Entity, and MUST include the following:</p>
<ul>
<li>Funding from the Zcash Development Fund MUST be available to not only the ECC, ZF, and Third Entity but also to other individuals, groups, or entities that could make technical and/or non-technical contributions to Zcash as described in the Rationale section of this proposal.</li>
<li>To receive funding from the Zcash Development Fund, all Applicants MUST follow the rules described in the Specification section of this proposal and in final detail by the ECC, ZF, and Third Entity.</li>
<li>As part of an application, each Applicant MUST produce a public overview of the activities and projected costs for which they are seeking funds.</li>
<li>Each funding decision MUST be preceded by a community review period of reasonable length to be determined by the ECC, ZF and Third Entity in which Zcash stakeholders and community members can familiarize themselves with the Applicant’s request and make suggestions, or raise objections.</li>
<li>In situations of overwhelming opposition from Zcash stakeholders and community members to requests from Applicants, the ECC, ZF, and Third Entity SHOULD NOT approve the request before striving to address stakeholders and community concerns, and modifying the request, if appropriate, to assuage concerns.</li>
<li>Each funding decision MUST be accompanied by an easily referenced joint public statement by the ECC, ZF, and Third Entity, which MUST include the final tally of the relevant vote, as well as the votes of the three involved entities. As part of this statement, each of the three entities MUST provide explicit justification for its respective vote.</li>
<li>The ZF MUST ensure that all Zcash Development Fund votes and the accompanying justifications described previously remain archived and easily accessible online by Zcash community members, stakeholders and the general public.</li>
<li>The ECC, ZF, and Third Entity MAY approve funding requests on a rolling basis, but all funding requests MUST be revisited and voted on at a minimum of every 6 months to receive renewed approval.</li>
<li>Recipients MUST publicize at minimum quarterly progress updates on their activities funded from the Zcash Development Fund. In the case of short-term assignments (less than 6 months), a single report upon completion of the project is sufficient. Standard reporting requirements MUST be specified by the ECC, ZF, and Third Entity prior to any approved requests from the Zcash Development Fund and additional requirements MAY be introduced as needed.</li>
<li>Depending on the nature of each request, funds MAY be disbursed in a single payment or incrementally, subject to objective milestones and/or other performance metrics.</li>
</ul>
<p>Any decision to alter the governance of the Zcash Development Fund as described in this proposal and in final detail by the ECC, ZF, and Third Entity MUST involve the Zcash community at large, similar to the process outlined in the ZF’s August 6, 2019 statement <a href="#zfnd-guidance" id="id5" class="footnote_reference">2</a>. All transfers from the Zcash Development Fund MUST be in full accordance with the requirements described in this proposal.</p>
</section>
</section>
<section id="issues-not-addressed-in-this-proposal-out-of-scope">
<h2>Issues not addressed in this proposal/Out-of-Scope</h2>
<ul>
<li>Details of the decision-making process for supporting or rejecting this or other relevant proposals by the ECC, ZF, and/or other Zcash stakeholders. We do maintain, however, that any decision by the ECC and/or the ZF on the issue described in the Motivation section below SHOULD be preceded by the procedures for measuring community sentiment as outlined in the ZF’s August 6, 2019 statement <a href="#zfnd-guidance" id="id6" class="footnote_reference">2</a>.</li>
<li>Additional methods for measuring community sentiment MAY include a way for ZEC holders to signal their support of specific proposals.</li>
<li>The matter of whether the ECC should reorganize itself into a non-profit or remain for-profit, as addressed by the ZF in their August 6, 2019 statement <a href="#zfnd-guidance" id="id7" class="footnote_reference">2</a>. The current proposal is neutral on this matter, and funding from the Development Fund would be available for non-profit and/or for-profit entities. We consider the governance rules of the Development Fund outlined in this Specification section adequate for transparency and accountability.</li>
</ul>
</section>
<section id="motivation">
<h2>Motivation</h2>
<p>The Zcash network is scheduled to undergo its first halving in October 2020, per current protocol specifications. At the time of the first halving, the codebase dictates that the Founder’s Reward, which consists of 20% of the ZEC from every block reward, will be terminated. Without codebase modification, for example in the upcoming NU4 Network Upgrade, 100% of block rewards would be claimed by miners after the first halving.</p>
<p>The two organizations presently leading development and maintenance of the Zcash network receive funds from the Founder’s Reward. These organizations, the ECC and ZF, have recently requested a source of funding after the first halving in order to continue operations for the foreseeable future. The source of funds could theoretically be from either a modification to the codebase dictating a Zcash Development Fund from block rewards or, alternatively, from external sources. The ECC has indicated though that it would “wind down or pivot” rather than accept funding from any sources that would give “special interests” control over the ECC <a href="#ecc-assessment" id="id8" class="footnote_reference">3</a>.</p>
<p>Based on the ECC’s demands, the block reward appears to be the most agreeable source of resources for a Zcash Development Fund.</p>
<p>This proposal, originally published in the Zcash Community Forum on August 14, 2019 <a href="#blocktown-proposal" id="id9" class="footnote_reference">4</a> and formalized further in a blog post on August 23, 2019 <a href="#blocktown-blog" id="id10" class="footnote_reference">5</a>, outlines the funding mechanism and governance of such a Zcash Development Fund. Herein, we propose a feature of NU4 whereby 10% of the ZEC from every new block reward between the first halving and second halving would be directly deposited in a Zcash Development Fund.</p>
<p>For the period between the launch of the Zcash network in 2016 and the first halving, there has been a centralized 20% fee known as the Founder’s Reward taken from the block reward. Other active ZIP drafts advocate a Zcash Development Fund of 20% allocation from the block reward after the first halving. We believe that a cumulative eight years of centralized fees from the block reward at the identical rate of 20% would ultimately result in a narrow community that accepts the likelihood of a perpetual 20% fee on the Zcash network.</p>
<p>With a Zcash Development Fund that is only 10% of the block reward, a precedent will be set that a large centralized fund is not indefinite and will decrease faster than simply the rate of block reward halvings. Although this proposal specifically addresses the period between the first and second halving, this proposed feature may set a precedent whereby the percent fee from block rewards allocated to a Zcash Development Fund continually decreases every halving, e.g. 20% (FR) from 2016-2020, 10% from 2020-2024, 5% from 2024-2028, 2.5% from 2028-2032 (effectively quartering the ZEC allocated to a development fund every four years). We believe that this social contract could restore the community’s faith in the decentralization of Zcash as the network incentives align more closely with that of Bitcoin’s over time. Alternatively, it is not unreasonable for the Zcash governance system to elect a 0% allocation for the Zcash Development Fund upon the second halving. For a more detailed exploration regarding the selection of 10%, please review the blog post ‘Proposal for 10% Dev Fund in Zcash 2020 Network Upgrade’ <a href="#blocktown-10pc" id="id11" class="footnote_reference">6</a>.</p>
<p>Of note, we are not suggesting or implying that the funding from the Founder’s Reward and a Zcash Development Fund would be managed in a similar way or have similar directives. The Zcash Development Fund feature that we propose for NU4 does not allocate any funds to former angel investors, VCs or vested employees. Furthermore, the Zcash Development Fund would be subject to more explicit and transparent rules of governance, as outlined in the Specification section of this proposal.</p>
</section>
<section id="rationale">
<h2>Rationale</h2>
<p>The rationale behind this proposal is as follows:</p>
<ul>
<li>To provide financial resources for research, development, and any other technical work connected to software upgrades/maintenance of the Zcash protocol, as well as non-technical initiatives including marketing, design, events, regulatory outreach, education, governance, and any other form of business that contribute to the success of the Zcash network.</li>
<li>To increase decentralization and network security of the Zcash network.</li>
<li>To increase decentralization through greater community involvement in Zcash governance and resource allocation.</li>
<li>To establish basic rules of governance and accountability regarding the deployment of funds in the Zcash Development Fund.</li>
<li>To encourage transparency and cooperation among Zcash stakeholders and strengthen the community’s governance capabilities moving forward.</li>
</ul>
</section>
<section id="discussion">
<h2>Discussion</h2>
<p>Recognized objections to this proposal include:</p>
<ul>
<li>This proposal is not in accordance with the current Zcash protocol, which is programmed to allocate 100% of the coinbase to miners upon the first halving in 2020. However, at least during the next few years of Zcash’s infancy, we believe it is advantageous to have a funded and dedicated development team.</li>
<li>The funding mechanism in this proposal is a Zcash Development Fund consisting of 10% of newly issued ZEC from block rewards after the first halving. This is in contrast to other proposals that allocate 20% of the mining rewards to the Zcash Development Fund – presumably a popular selection because the original Founder’s Reward was also set at 20%. For reasons we have explored in depth <a href="#blocktown-10pc" id="id12" class="footnote_reference">6</a> and summarized in <a href="#blocktown-summary" id="id13" class="footnote_reference">7</a>, we believe 10% instead of 20% is superior for network security, decentralization, uniting the Zcash community and renewing interest in ZEC.</li>
<li>Various parameters of governance in approving Applicant requests for funding from the Zcash Development Fund.</li>
<li>The inclusion of a Third Entity in governance. One notable objection is the possibility of collusion between Third Entity and either the ECC or ZF that would result in a “usurped” Zcash Development Fund. We believe that the process for a community elected Third Entity, however, will mature over time – giving the community and Zcash stakeholders that important third opinion in deciding the proper allocation of funds. As demonstrated by the resilience of the Bitcoin network and community, well-formed communities tend to resist any collusion with corporations and controlling entities that do not promote the direct success of the network. Moreover, the inclusion of a Third Entity has the advantage of offering a “tie-breaker” in the event of a deadlock vote between the ECC and ZF and/or a situation where one entity holds the other hostage, which is a possible scenario in a 2-of-2 multisig agreement.</li>
<li>This proposal does not have a clause dictating that a Recipient must abstain from voting. If a Recipient must abstain from voting in a 2-of-3 multisig governance system, then this could –as in the case of 2-of-2 multisig– result in an entity holding another hostage. For example, if the ECC refuses to fund the ZF until the ZF complies with the ECC’s demands, then the ECC has the power to deadlock any vote to fund the ZF, which requires the ECC and Third Entity to both vote approvingly.</li>
</ul>
</section>
<section id="acknowledgements">
<h2>Acknowledgements</h2>
<p>Aspects of this proposal, particularly the Terminology and Specification sections, were adapted and expanded definitions and concepts put forth in Placeholder’s dev fund proposal from August 22, 2019 <a href="#placeholder-proposal" id="id14" class="footnote_reference">8</a>.</p>
</section>
<section id="references">
<h2>References</h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="zfnd-guidance" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/">Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="ecc-assessment" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://electriccoin.co/blog/ecc-initial-assessment-of-community-proposals/">ECC Initial Assessment of Community Proposals. Electric Coin Company blog, August 26, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="blocktown-proposal" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="https://forum.zcashcommunity.com/t/proposal-for-the-zcash-2020-network-upgrade/34503">Proposal for the Zcash 2020 Network Upgrade (topic on the Zcash community forum).</a></td>
</tr>
</tbody>
</table>
<table id="blocktown-blog" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="https://medium.com/blocktown/blocktown-proposal-for-zcash-2020-network-upgrade-fdec1e9d507c">Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 23, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="blocktown-10pc" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="https://medium.com/blocktown/proposal-for-the-zcash-2020-network-upgrade-fcd320a5d6f5">Proposal for 10% Dev Fund in Zcash 2020 Network Upgrade. Blocktown Capital, August 14, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="blocktown-summary" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="https://medium.com/blocktown/executive-summary-blocktown-proposal-for-zcash-2020-network-upgrade-84ff20997502">Executive Summary: Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 15, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="placeholder-proposal" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-20-to-a-2-of-3-multisig-with-community-involved-governance/34646">Dev Fund Proposal: 20% to a 2-of-3 multisig with community-involved governance (topic on the Zcash community forum).</a></td>
</tr>
</tbody>
</table>
<table id="nu-pipeline" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="https://electriccoin.co/blog/the-zcash-network-upgrade-pipeline/">The Zcash Network Upgrade Pipeline. Electric Coin Company blog, December 3, 2018.</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

376
zip-1006.rst Normal file
View File

@ -0,0 +1,376 @@
::
ZIP: 1006
Title: Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity
Owners: James Todaro <james@blocktown.capital>
Joseph Todaro <joseph@blocktown.capital>
Credits: Mario Laul <mario@placeholder.vc>
Chris Burniske <chris@placeholder.vc>
Status: Draft
Category: Consensus / Process
Created: 2019-08-31
License: MIT
Discussions-To: <https://forum.zcashcommunity.com/t/blocktown-development-fund-proposal-10-to-a-2-of-3-multisig-with-community-involved-third-entity/34782>
Terminology
===========
The key words “MUST”, “SHOULD”, “SHOULD NOT”, and “MAY” in this document
are to be interpreted as described in RFC 2119. [#RFC2119]_
The additional terms below are to be interpreted as follows:
Mining
The actions of processing transactions, which include processing
transactions in a Proof-of-Stake or Proof-of-Work/Proof-of-Stake
hybrid system, in the event Zcash implements either at a future date.
Mining software
Pool software, local mining software or staking software.
Mining rewards / Block rewards
Network transaction fees and/or coinbase rewards (e.g. newly issued
ZEC associated with block generation).
Network Upgrade
Any consensus rule change to the Zcash protocol, introduced as part
of the standard Zcash Network Upgrade Pipeline [#nu-pipeline]_ or
otherwise.
Founder’s Reward
The 20% ZEC from mined blocks allocated to the Electric Coin Company
(ECC), Zcash Foundation (ZF), employees, investors and/or other
entities prior to the expected first halving in October 2020.
Zcash Development Fund
Transparent address(es) controlled jointly by the Electric Coin
Company, Zcash Foundation, and a “Third Entity”. The fund is intended
for research, development, maintenance, and other technical work
directly connected to the Zcash protocol, as well as non-technical
initiatives (including design, marketing, events, regulatory
outreach, education, governance, and any other form of business or
community development) that contribute to the long-term success of
the Zcash network. In the context of this proposal, the Zcash
Development Fund consists of 10% of newly issued ZEC from block
rewards between the first and second halvings of the Zcash network.
Applicant
Any individual, group, or entity that seeks funding from the Zcash
Development Fund.
Recipient
Any individual, group, or entity that receives funding from the Zcash
Development Fund.
Abstract
========
This proposal puts forward the financing mechanism and fundamental rules
of governance for the creation of a Zcash Development Fund.
Specification
=============
Funding mechanism of the Zcash Development Fund
-----------------------------------------------
* This funding mechanism MUST be hard-coded so that 10% of newly issued
ZEC from block rewards are automatically directed to the transparent
address(es) of the Zcash Development Fund.
* The above requirement MUST be met between the first halving and
second halving. Upon the second halving, future governance decisions
MAY result in a further decrease of the Zcash Development Fund to 5%
of newly issued ZEC from block rewards, or alternatively MAY result
in another percent allocation which includes the possibility of a
system whereby 100% of block rewards go to miners.
* The two aforementioned requirements above MUST remain regardless of
any additional Network Upgrades or changes to mining or mining software
prior to the second halving.
* The Zcash Development Fund MAY outlive the period of its initial
funding mechanism, either through the appreciation in the price of ZEC,
or from alternative funding sources upon the second halving in 2024.
* The hard-coded transparent address(es) of the Zcash Development Fund
MAY be periodically rotated for operational security purposes to
decrease the risk of any potential loss of funds associated with the
address(es). The ECC, ZF, and/or “Third Entity” described below SHOULD
take any possible precautions within the confines of this Specification
section to avoid loss of funds.
Governance of the Zcash Development Fund
----------------------------------------
* Funds allocated to the Zcash Development Fund MUST be used only for
their intended purpose as defined in the following Rationale section of
this proposal.
* The transparent address(es) of the Zcash Development Fund MUST be
jointly controlled by the ECC, ZF, and Third Entity, and all funds
transferred from the Zcash Development Fund MUST be publicly confirmed
in an official manner by a majority decision among the ECC, ZF, and
Third Entity–commonly referred to as “2-of-3 multisig”. That is, funding
decisions MUST be put to an officially documented vote which MUST NOT
pass unless at least 2 of the 3 entities above vote approvingly.
* Prior to any movement of funds from the Zcash Development Fund, the ZF
and ECC MUST coordinate with each other and the community to establish
the Third Entity that will be involved in governance of the Zcash
Development Fund. The process of determining the exact initial
composition and rules of governance of the Third Entity MUST involve the
Zcash community at large in a process similar to that outlined in the
section "How the Foundation will select a particular proposal" in the
ZF’s August 6, 2019 statement [#zfnd-guidance]_.
The governance rules of the Third Entity MUST include the following:
* All decision-making and other governing processes of the Third Entity
MUST be independent of the ECC and ZF, and MUST include measures that
are necessary to avoid conflicts of interest in relation to the ECC and
ZF.
* At creation, the Third Entity MUST include an uneven number of at least
5 individuals with independent previous affiliations, each having a
single vote. All such decisions MUST have majority support within the
Third Entity to result in an overall approving vote by the Third Entity.
* Once the Third Entity is established, it MAY decide to change its rules
of governance (e.g. simple majority versus supermajority rules), but
any such change MUST be preceded by the involvement of the Zcash
community at large, similar to the process outlined in the ZF’s
August 6, 2019 statement [#zfnd-guidance]_.
* Once the Third Entity is established as a self-governing body, it
SHOULD evolve toward a system whereby ZEC holders have a direct role in
determining votes and internal governance of the Third Entity.
* The Third Entity MAY apply for funding from the Zcash Development Fund,
if deemed appropriate by its governing body. This would be subject to a
majority vote by the ECC, ZF and Third Entity.
Prior to any transfer of funds from the Zcash Development Fund, the ECC,
ZF, and Third Entity MUST specify, approve, and make public the final
rules on applying for and receiving funding from the Zcash Development
Fund, including the details of the decision-making process for approving
or rejecting funding requests. These rules MUST apply equally to all
Applicants, including the ECC, ZF, and Third Entity, and MUST include
the following:
* Funding from the Zcash Development Fund MUST be available to not only
the ECC, ZF, and Third Entity but also to other individuals, groups,
or entities that could make technical and/or non-technical
contributions to Zcash as described in the Rationale section of this
proposal.
* To receive funding from the Zcash Development Fund, all Applicants
MUST follow the rules described in the Specification section of this
proposal and in final detail by the ECC, ZF, and Third Entity.
* As part of an application, each Applicant MUST produce a public
overview of the activities and projected costs for which they are
seeking funds.
* Each funding decision MUST be preceded by a community review period
of reasonable length to be determined by the ECC, ZF and Third Entity
in which Zcash stakeholders and community members can familiarize
themselves with the Applicant’s request and make suggestions, or
raise objections.
* In situations of overwhelming opposition from Zcash stakeholders and
community members to requests from Applicants, the ECC, ZF, and Third
Entity SHOULD NOT approve the request before striving to address
stakeholders and community concerns, and modifying the request, if
appropriate, to assuage concerns.
* Each funding decision MUST be accompanied by an easily referenced
joint public statement by the ECC, ZF, and Third Entity, which MUST
include the final tally of the relevant vote, as well as the votes of
the three involved entities. As part of this statement, each of the
three entities MUST provide explicit justification for its respective
vote.
* The ZF MUST ensure that all Zcash Development Fund votes and the
accompanying justifications described previously remain archived and
easily accessible online by Zcash community members, stakeholders and
the general public.
* The ECC, ZF, and Third Entity MAY approve funding requests on a
rolling basis, but all funding requests MUST be revisited and voted
on at a minimum of every 6 months to receive renewed approval.
* Recipients MUST publicize at minimum quarterly progress updates on
their activities funded from the Zcash Development Fund. In the case
of short-term assignments (less than 6 months), a single report upon
completion of the project is sufficient. Standard reporting
requirements MUST be specified by the ECC, ZF, and Third Entity prior
to any approved requests from the Zcash Development Fund and
additional requirements MAY be introduced as needed.
* Depending on the nature of each request, funds MAY be disbursed in a
single payment or incrementally, subject to objective milestones
and/or other performance metrics.
Any decision to alter the governance of the Zcash Development Fund as
described in this proposal and in final detail by the ECC, ZF, and Third
Entity MUST involve the Zcash community at large, similar to the process
outlined in the ZF’s August 6, 2019 statement [#zfnd-guidance]_.
All transfers from the Zcash Development Fund MUST be in full accordance
with the requirements described in this proposal.
Issues not addressed in this proposal/Out-of-Scope
==================================================
* Details of the decision-making process for supporting or rejecting
this or other relevant proposals by the ECC, ZF, and/or other Zcash
stakeholders. We do maintain, however, that any decision by the ECC
and/or the ZF on the issue described in the Motivation section below
SHOULD be preceded by the procedures for measuring community sentiment
as outlined in the ZF’s August 6, 2019 statement [#zfnd-guidance]_.
* Additional methods for measuring community sentiment MAY include a
way for ZEC holders to signal their support of specific proposals.
* The matter of whether the ECC should reorganize itself into a
non-profit or remain for-profit, as addressed by the ZF in their
August 6, 2019 statement [#zfnd-guidance]_. The current proposal is
neutral on this matter, and funding from the Development Fund would be
available for non-profit and/or for-profit entities. We consider the
governance rules of the Development Fund outlined in this Specification
section adequate for transparency and accountability.
Motivation
==========
The Zcash network is scheduled to undergo its first halving in October
2020, per current protocol specifications. At the time of the first
halving, the codebase dictates that the Founder’s Reward, which consists
of 20% of the ZEC from every block reward, will be terminated. Without
codebase modification, for example in the upcoming NU4 Network Upgrade,
100% of block rewards would be claimed by miners after the first halving.
The two organizations presently leading development and maintenance of
the Zcash network receive funds from the Founder’s Reward. These
organizations, the ECC and ZF, have recently requested a source of
funding after the first halving in order to continue operations for the
foreseeable future. The source of funds could theoretically be from
either a modification to the codebase dictating a Zcash Development Fund
from block rewards or, alternatively, from external sources. The ECC has
indicated though that it would “wind down or pivot” rather than accept
funding from any sources that would give “special interests” control
over the ECC [#ecc-assessment]_.
Based on the ECC’s demands, the block reward appears to be the most
agreeable source of resources for a Zcash Development Fund.
This proposal, originally published in the Zcash Community Forum on
August 14, 2019 [#blocktown-proposal]_ and formalized further in a
blog post on August 23, 2019 [#blocktown-blog]_, outlines the funding
mechanism and governance of such a Zcash Development Fund. Herein, we
propose a feature of NU4 whereby 10% of the ZEC from every new block
reward between the first halving and second halving would be directly
deposited in a Zcash Development Fund.
For the period between the launch of the Zcash network in 2016 and the
first halving, there has been a centralized 20% fee known as the
Founder’s Reward taken from the block reward. Other active ZIP drafts
advocate a Zcash Development Fund of 20% allocation from the block
reward after the first halving. We believe that a cumulative eight years
of centralized fees from the block reward at the identical rate of 20%
would ultimately result in a narrow community that accepts the
likelihood of a perpetual 20% fee on the Zcash network.
With a Zcash Development Fund that is only 10% of the block reward, a
precedent will be set that a large centralized fund is not indefinite
and will decrease faster than simply the rate of block reward halvings.
Although this proposal specifically addresses the period between the
first and second halving, this proposed feature may set a precedent
whereby the percent fee from block rewards allocated to a Zcash
Development Fund continually decreases every halving, e.g. 20% (FR) from
2016-2020, 10% from 2020-2024, 5% from 2024-2028, 2.5% from 2028-2032
(effectively quartering the ZEC allocated to a development fund every
four years). We believe that this social contract could restore the
community’s faith in the decentralization of Zcash as the network
incentives align more closely with that of Bitcoin’s over time.
Alternatively, it is not unreasonable for the Zcash governance system to
elect a 0% allocation for the Zcash Development Fund upon the second
halving. For a more detailed exploration regarding the selection of 10%,
please review the blog post ‘Proposal for 10% Dev Fund in Zcash 2020
Network Upgrade’ [#blocktown-10pc]_.
Of note, we are not suggesting or implying that the funding from the
Founder’s Reward and a Zcash Development Fund would be managed in a
similar way or have similar directives. The Zcash Development Fund
feature that we propose for NU4 does not allocate any funds to former
angel investors, VCs or vested employees. Furthermore, the Zcash
Development Fund would be subject to more explicit and transparent
rules of governance, as outlined in the Specification section of this
proposal.
Rationale
=========
The rationale behind this proposal is as follows:
* To provide financial resources for research, development, and any
other technical work connected to software upgrades/maintenance of
the Zcash protocol, as well as non-technical initiatives including
marketing, design, events, regulatory outreach, education,
governance, and any other form of business that contribute to the
success of the Zcash network.
* To increase decentralization and network security of the Zcash
network.
* To increase decentralization through greater community involvement
in Zcash governance and resource allocation.
* To establish basic rules of governance and accountability regarding
the deployment of funds in the Zcash Development Fund.
* To encourage transparency and cooperation among Zcash stakeholders
and strengthen the community’s governance capabilities moving
forward.
Discussion
==========
Recognized objections to this proposal include:
* This proposal is not in accordance with the current Zcash protocol,
which is programmed to allocate 100% of the coinbase to miners upon
the first halving in 2020. However, at least during the next few
years of Zcash’s infancy, we believe it is advantageous to have a
funded and dedicated development team.
* The funding mechanism in this proposal is a Zcash Development Fund
consisting of 10% of newly issued ZEC from block rewards after the
first halving. This is in contrast to other proposals that allocate
20% of the mining rewards to the Zcash Development Fund – presumably
a popular selection because the original Founder’s Reward was also
set at 20%. For reasons we have explored in depth [#blocktown-10pc]_
and summarized in [#blocktown-summary]_, we believe 10% instead of
20% is superior for network security, decentralization, uniting the
Zcash community and renewing interest in ZEC.
* Various parameters of governance in approving Applicant requests for
funding from the Zcash Development Fund.
* The inclusion of a Third Entity in governance. One notable objection
is the possibility of collusion between Third Entity and either the
ECC or ZF that would result in a “usurped” Zcash Development Fund.
We believe that the process for a community elected Third Entity,
however, will mature over time – giving the community and Zcash
stakeholders that important third opinion in deciding the proper
allocation of funds. As demonstrated by the resilience of the Bitcoin
network and community, well-formed communities tend to resist any
collusion with corporations and controlling entities that do not
promote the direct success of the network. Moreover, the inclusion of
a Third Entity has the advantage of offering a “tie-breaker” in the
event of a deadlock vote between the ECC and ZF and/or a situation
where one entity holds the other hostage, which is a possible
scenario in a 2-of-2 multisig agreement.
* This proposal does not have a clause dictating that a Recipient must
abstain from voting. If a Recipient must abstain from voting in a
2-of-3 multisig governance system, then this could –as in the case of
2-of-2 multisig– result in an entity holding another hostage. For
example, if the ECC refuses to fund the ZF until the ZF complies with
the ECC’s demands, then the ECC has the power to deadlock any vote to
fund the ZF, which requires the ECC and Third Entity to both vote
approvingly.
Acknowledgements
================
Aspects of this proposal, particularly the Terminology and Specification
sections, were adapted and expanded definitions and concepts put forth
in Placeholder’s dev fund proposal from August 22, 2019 [#placeholder-proposal]_.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zfnd-guidance] `Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. <https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/>`_
.. [#ecc-assessment] `ECC Initial Assessment of Community Proposals. Electric Coin Company blog, August 26, 2019. <https://electriccoin.co/blog/ecc-initial-assessment-of-community-proposals/>`_
.. [#blocktown-proposal] `Proposal for the Zcash 2020 Network Upgrade (topic on the Zcash community forum). <https://forum.zcashcommunity.com/t/proposal-for-the-zcash-2020-network-upgrade/34503>`_
.. [#blocktown-blog] `Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 23, 2019. <https://medium.com/blocktown/blocktown-proposal-for-zcash-2020-network-upgrade-fdec1e9d507c>`_
.. [#blocktown-10pc] `Proposal for 10% Dev Fund in Zcash 2020 Network Upgrade. Blocktown Capital, August 14, 2019. <https://medium.com/blocktown/proposal-for-the-zcash-2020-network-upgrade-fcd320a5d6f5>`_
.. [#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>`_
.. [#placeholder-proposal] `Dev Fund Proposal: 20% to a 2-of-3 multisig with community-involved governance (topic on the Zcash community forum). <https://forum.zcashcommunity.com/t/dev-fund-proposal-20-to-a-2-of-3-multisig-with-community-involved-governance/34646>`_
.. [#nu-pipeline] `The Zcash Network Upgrade Pipeline. Electric Coin Company blog, December 3, 2018. <https://electriccoin.co/blog/the-zcash-network-upgrade-pipeline/>`_

113
zip-1007.html Normal file
View File

@ -0,0 +1,113 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1007: Enforce Development Fund Commitments with a Legal Charter</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1007
Title: Enforce Development Fund Commitments with a Legal Charter
Owners: @lex-node (zcash forums)
@mistfpga (zcash forums) &lt;steve@mistfpga.net&gt;
Status: Draft
Category: Process
Created: 2019-08-24
License: CC BY-SA 4.0 &lt;https://creativecommons.org/licenses/by-sa/4.0/&gt;
Discussions-To: &lt;https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter/34709&gt;</pre>
<section id="terminology">
<h2>Terminology</h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">1</a></p>
<p>For clarity this ZIP defines these terms:</p>
<ul>
<li>Covenant is defined as a legally binding agreement, upon which a specific aspect of development of the Zcash protocol and/or adoption is scheduled and agreed.</li>
</ul>
</section>
<section id="abstract">
<h2>Abstract</h2>
<p>A supplemental proposal to ensure feature selection and work is community-driven.</p>
<p>Hopefully it will be compatible with a number of other ZIPs and can be worked into them.</p>
</section>
<section id="out-of-scope-for-this-proposal">
<h2>Out of Scope for this Proposal</h2>
<ul>
<li>This proposal does not address the merits, motivations or terms of any particular Development Funding Proposal.</li>
<li>Requirements and Implementation.</li>
</ul>
</section>
<section id="motivation-and-requirements">
<h2>Motivation and Requirements</h2>
<p>This proposal is supplemental to any Development Funding Proposal that places or purports to place conditions on how the Electric Coin Company (ECC) and the Zcash Foundation (ZF) use development funds, or take other related off-chain actions such as requirements and Covenants.</p>
<p>For example, the proposal <a href="#zip-1006" id="id2" class="footnote_reference">2</a> provides that “[f]unds accruing to the Zcash Development Fund MUST be used only for ... technical work directly connected to the various software implementations of the Zcash protocol.” However, once development funding is approved and implemented via a Network Upgrade, there will be no enforcement mechanism to ensure that the ZF and ECC abide by this requirement.</p>
<p>This proposal aims to provide such an enforcement mechanism. If this proposal is adopted, then the ECC and/or ZF, as applicable MUST enter into a legal agreement that would entitle ZEC holders to enforce ECC’s/ZF’s performance of any Covenants. For the purposes of this proposal we will refer to the legal agreement as the “DevFund Charter” or “Charter” for short, but it MAY also be styled in other ways – e.g. as a Constitution, Bylaws, Fund Governance Agreement, etc.</p>
<p>The DevFund Charter SHOULD be used to the benefit of all ZEC users, but the DevFund Charter MAY provide that an enforcement action requires the support of the holders of a plurality, majority or supermajority of ZEC. ZEC held by the ZF, ECC and their officers, directors, employees and/or affiliates SHOULD be excluded from the denominator in calculating the requisite plurality, majority or supermajority of ZEC.</p>
<p><span class="editor-note">a "plurality" in a vote means the option that received more votes than any other single option, but it is unclear how this applies to "a plurality of ZEC". Taking into account experience from stake-weighted voting in other cryptocurrencies, the threshold of a simple majority (50%), or more, of all *issued* ZEC voting for any enforcement action would seem to be an extremely high bar.</span></p>
<p>A quorum of yet-to-be-decided number of representatives from a number of groups specified by the DevFund Charter MAY provide that an enforcement action requires the support of the assigned representatives of each. One such mechanism SHOULD be ZEC balance, however this would require a 66% majority or a 85% supermajority. (These numbers are not binding and are up for discussion)</p>
<p>It is assumed that the Electric Coin Company, Zcash Foundation, or party with a direct conflict of interest SHOULD identify their vote/signal - which MAY be rejected from the vote.</p>
<p>Legal enforcement MAY occur in a court of law, non-binding mediation or binding arbitration. The DevFund Charter MAY also provide rights to other Zcash community constituencies, such as specified miners or the “Third Entity” contemplated by <a href="#zip-1006" id="id3" class="footnote_reference">2</a>.</p>
</section>
<section id="rationale">
<h2>Rationale</h2>
<p>Because ZEC holders do not have specific legal rights against the ECC or ZF, but MAY wish to condition renewed on-chain development funding on the ECC’s or ZF’s agreement to use the development funds in certain ways, ZEC holders should have the legal right to enforce ECC’s/ZF’s compliance with those agreements.</p>
</section>
<section id="specification">
<h2>Specification</h2>
<ul>
<li>If a Development Funding Proposal receives sufficient community support and requires certain Covenants on the part of ECC or ZF, and there is also sufficient community support for using this enforcement mechanism as applied to that proposal, then one or more attorneys MUST be engaged to draft a Charter that reflects those Covenants, and the Charter MUST become legally effective and binding at the same time as the other aspects of the Development Funding Proposal are implemented on-chain (e.g., at the same time as activation of the corresponding Network Upgrade, if a Network Upgrade is is required to implement the Development Funding Proposal).</li>
<li>Each pending Development Funding Proposal SHOULD be amended to specifically describe any Covenants that the ECC, ZF or any other relevant person or entity would be required to agree to as part of such Development Funding Proposal.</li>
</ul>
</section>
<section id="open-issues">
<h2>Open Issues</h2>
<ul>
<li>Whether a plurality, majority or supermajority of ZEC are required to approve an enforcement action against ECC or ZF;</li>
<li>Logistics and technical implementation regarding the Charter, such as on-chain signalling/voting for enforcement;</li>
<li>Remedies under the Charter, such as “specific performance” (getting a court to order ZF or ECC to comply with a Covenant);</li>
<li>Discontinuation or reduction of development funding (which MAY occur by having Covenants that the ZF or ECC will prepare a Network Upgrade that discontinues or reduces development funding if so requested by holders of the requisite plurality, majority or supermajority of ZEC), etc.</li>
</ul>
</section>
<section id="raised-concerns">
<h2>Raised Concerns</h2>
<ul>
<li>“Code is Law; This is Just Law!”
<ul>
<li>Objection: Relying on off-chain legal mechanisms is contrary to the cypherpunk ethos and/or the mission/ethos of Zcash.</li>
<li>Answer: This is a values judgment that some people may reasonably hold. However, one should also consider that “don’t trust, verify” is also a cypherpunk principle and that the off-chain nature of some requirements means that a code-based solution is currently not possible; therefore, a legal enforcement mechanism, while imperfect, may be preferable to no enforcement mechanism.</li>
</ul>
</li>
<li>“Social Coordination Impracticality/Risk”
<ul>
<li>Objection: ZEC holders prize anonymity, but legal enforcement of breached Covenants will require social coordination (people must agree to enforce the action, and someone must actually get a lawyer and go to court). Therefore, this mechanism will not be valuable to ZEC holders and could lead them to compromise their anonymity and thus be worse than useless.</li>
<li>Answer: The community should further discuss how, in practice, ZEC holders might securely coordinate to bring an enforcement action against ECC and the ZF if it were needed. Additionally, it should be considered that the mere possibility of legal enforcement due to the clear terms of a Charter may dissuade ECC and ZF from violating Covenants and thus, paradoxically, having a Charter may also mean that no legal action ever becomes necessary. Additionally, the “class action” legal structure in some jurisdictions may mean that the ZEC holders' community could find a ‘champion’ in the form of a class-action attorney, without ZEC holders being required to personally become involved or ‘out themselves’ as ZEC holders (other than one willing ZEC holder as class representative).</li>
</ul>
</li>
<li>“This Will Just Waste Funding On Lawyers”
<ul>
<li>Objection: This Charter will be novel and bespoke, and lawyers may charge high fees to draft it and give assurances that it is enforceable. This wastes money that otherwise could be spent on Zcash development.</li>
<li>Answer: This is a valid concern. The Zcash community may be able to crowdsource an initial rough draft of the Charter from lawyers in the community or even non-lawyers who may be willing to do research and make an attempt at an initial draft. Lawyers could be involved primarily to issue-spot and formalize the initial draft. ECC and ZF may have law firms on retainer that could perform the work at favorable rates. Lawyers may be willing to work at discounted rates due to the unique opportunity and prestige of developing this innovative blockchain governance mechanism. Additionally, any legal fees may be small as a percentage of the overall value at stake, which may be considerable if a 5-20% development funding block reward is authorized.</li>
</ul>
</li>
</ul>
</section>
<section id="references">
<h2>References</h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="zip-1006" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="zip-1006">Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

188
zip-1007.rst Normal file
View File

@ -0,0 +1,188 @@
::
ZIP: 1007
Title: Enforce Development Fund Commitments with a Legal Charter
Owners: @lex-node (zcash forums)
@mistfpga (zcash forums) <steve@mistfpga.net>
Status: Draft
Category: Process
Created: 2019-08-24
License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/>
Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter/34709>
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this
document are to be interpreted as described in RFC 2119. [#RFC2119]_
For clarity this ZIP defines these terms:
* Covenant is defined as a legally binding agreement, upon which a specific
aspect of development of the Zcash protocol and/or adoption is scheduled and
agreed.
Abstract
========
A supplemental proposal to ensure feature selection and work is community-driven.
Hopefully it will be compatible with a number of other ZIPs and can be worked
into them.
Out of Scope for this Proposal
==============================
* This proposal does not address the merits, motivations or terms of any particular
Development Funding Proposal.
* Requirements and Implementation.
Motivation and Requirements
===========================
.. role:: editor-note
This proposal is supplemental to any Development Funding Proposal that places or
purports to place conditions on how the Electric Coin Company (ECC) and the Zcash
Foundation (ZF) use development funds, or take other related off-chain actions such
as requirements and Covenants.
For example, the proposal [#zip-1006]_ provides that “[f]unds accruing to the
Zcash Development Fund MUST be used only for ... technical work directly connected
to the various software implementations of the Zcash protocol.” However, once
development funding is approved and implemented via a Network Upgrade, there will
be no enforcement mechanism to ensure that the ZF and ECC abide by this requirement.
This proposal aims to provide such an enforcement mechanism. If this proposal is
adopted, then the ECC and/or ZF, as applicable MUST enter into a legal agreement
that would entitle ZEC holders to enforce ECC’s/ZF’s performance of any Covenants.
For the purposes of this proposal we will refer to the legal agreement as the
“DevFund Charter” or “Charter” for short, but it MAY also be styled in other ways –
e.g. as a Constitution, Bylaws, Fund Governance Agreement, etc.
The DevFund Charter SHOULD be used to the benefit of all ZEC users, but the DevFund
Charter MAY provide that an enforcement action requires the support of the holders
of a plurality, majority or supermajority of ZEC. ZEC held by the ZF, ECC and their
officers, directors, employees and/or affiliates SHOULD be excluded from the
denominator in calculating the requisite plurality, majority or supermajority of ZEC.
:editor-note:`a "plurality" in a vote means the option that received more votes than
any other single option, but it is unclear how this applies to "a plurality of ZEC".
Taking into account experience from stake-weighted voting in other cryptocurrencies,
the threshold of a simple majority (50%), or more, of all *issued* ZEC voting for
any enforcement action would seem to be an extremely high bar.`
A quorum of yet-to-be-decided number of representatives from a number of groups
specified by the DevFund Charter MAY provide that an enforcement action requires
the support of the assigned representatives of each. One such mechanism SHOULD be
ZEC balance, however this would require a 66% majority or a 85% supermajority.
(These numbers are not binding and are up for discussion)
It is assumed that the Electric Coin Company, Zcash Foundation, or party with a
direct conflict of interest SHOULD identify their vote/signal - which MAY be rejected
from the vote.
Legal enforcement MAY occur in a court of law, non-binding mediation or binding
arbitration. The DevFund Charter MAY also provide rights to other Zcash community
constituencies, such as specified miners or the “Third Entity” contemplated by
[#zip-1006]_.
Rationale
=========
Because ZEC holders do not have specific legal rights against the ECC or ZF, but
MAY wish to condition renewed on-chain development funding on the ECC’s or ZF’s
agreement to use the development funds in certain ways, ZEC holders should have
the legal right to enforce ECC’s/ZF’s compliance with those agreements.
Specification
=============
* If a Development Funding Proposal receives sufficient community support and
requires certain Covenants on the part of ECC or ZF, and there is also sufficient
community support for using this enforcement mechanism as applied to that proposal,
then one or more attorneys MUST be engaged to draft a Charter that reflects those
Covenants, and the Charter MUST become legally effective and binding at the same
time as the other aspects of the Development Funding Proposal are implemented
on-chain (e.g., at the same time as activation of the corresponding Network Upgrade,
if a Network Upgrade is is required to implement the Development Funding Proposal).
* Each pending Development Funding Proposal SHOULD be amended to specifically
describe any Covenants that the ECC, ZF or any other relevant person or entity
would be required to agree to as part of such Development Funding Proposal.
Open Issues
===========
* Whether a plurality, majority or supermajority of ZEC are required to approve an
enforcement action against ECC or ZF;
* Logistics and technical implementation regarding the Charter, such as on-chain
signalling/voting for enforcement;
* Remedies under the Charter, such as “specific performance” (getting a court to
order ZF or ECC to comply with a Covenant);
* Discontinuation or reduction of development funding (which MAY occur by having
Covenants that the ZF or ECC will prepare a Network Upgrade that discontinues or
reduces development funding if so requested by holders of the requisite plurality,
majority or supermajority of ZEC), etc.
Raised Concerns
===============
* “Code is Law; This is Just Law!”
- Objection: Relying on off-chain legal mechanisms is contrary to the cypherpunk
ethos and/or the mission/ethos of Zcash.
- Answer: This is a values judgment that some people may reasonably hold. However,
one should also consider that “don’t trust, verify” is also a cypherpunk
principle and that the off-chain nature of some requirements means that a
code-based solution is currently not possible; therefore, a legal enforcement
mechanism, while imperfect, may be preferable to no enforcement mechanism.
* “Social Coordination Impracticality/Risk”
- Objection: ZEC holders prize anonymity, but legal enforcement of breached
Covenants will require social coordination (people must agree to enforce the
action, and someone must actually get a lawyer and go to court). Therefore, this
mechanism will not be valuable to ZEC holders and could lead them to compromise
their anonymity and thus be worse than useless.
- Answer: The community should further discuss how, in practice, ZEC holders might
securely coordinate to bring an enforcement action against ECC and the ZF if it
were needed. Additionally, it should be considered that the mere possibility of
legal enforcement due to the clear terms of a Charter may dissuade ECC and ZF
from violating Covenants and thus, paradoxically, having a Charter may also mean
that no legal action ever becomes necessary. Additionally, the “class action”
legal structure in some jurisdictions may mean that the ZEC holders' community
could find a ‘champion’ in the form of a class-action attorney, without ZEC
holders being required to personally become involved or ‘out themselves’ as
ZEC holders (other than one willing ZEC holder as class representative).
* “This Will Just Waste Funding On Lawyers”
- Objection: This Charter will be novel and bespoke, and lawyers may charge high
fees to draft it and give assurances that it is enforceable. This wastes money
that otherwise could be spent on Zcash development.
- Answer: This is a valid concern. The Zcash community may be able to crowdsource
an initial rough draft of the Charter from lawyers in the community or even
non-lawyers who may be willing to do research and make an attempt at an initial
draft. Lawyers could be involved primarily to issue-spot and formalize the
initial draft. ECC and ZF may have law firms on retainer that could perform the
work at favorable rates. Lawyers may be willing to work at discounted rates due
to the unique opportunity and prestige of developing this innovative blockchain
governance mechanism. Additionally, any legal fees may be small as a percentage
of the overall value at stake, which may be considerable if a 5-20% development
funding block reward is authorized.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-1006] `Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity <zip-1006.rst>`_

107
zip-1008.html Normal file
View File

@ -0,0 +1,107 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1008: Fund ECC for Two More Years</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1008
Title: Fund ECC for Two More Years
Owners: @kek (zcash forums)
@mistfpga (zcash forums) &lt;steve@mistfpga.net&gt;
Status: Draft
Category: Consensus
Created: 2019-09-02
License: CC BY-SA 4.0 &lt;https://creativecommons.org/licenses/by-sa/4.0/&gt;
Discussions-To: &lt;https://forum.zcashcommunity.com/t/kek-s-proposal-fund-ecc-for-2-more-years/34778&gt;</pre>
<section id="terminology">
<h2>Terminology</h2>
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">2</a></p>
<p>For clarity this ZIP defines these terms:</p>
<ul>
<li>Spirit is defined as what is the intended outcome of the ZIP. <a href="#spirit" id="id2" class="footnote_reference">1</a></li>
</ul>
<table id="spirit" class="footnote">
<tbody>
<tr>
<th>1</th>
<td>If there is contradiction between Spirit and any other part of the proposal that needs to be addressed, in the event it is not addressed Spirit is assumed to overrule all.</td>
</tr>
</tbody>
</table>
</section>
<section id="out-of-scope-for-this-proposal">
<h2>Out of Scope for this Proposal</h2>
<p>Everything except moving the development fund end date.</p>
</section>
<section id="abstract">
<h2>Abstract</h2>
<p>The spirit of this proposal is to keep to the current structure of the Electric Coin Company (ECC) receiving funding from the block distribution for two years' worth of blocks after the first halving in October 2020.</p>
</section>
<section id="motivation">
<h2>Motivation</h2>
<p>To give more time to work out the full ramifications of any potential pivot / slow down, yet keep "all in on ZEC" for two more years with as little disruption as possible.</p>
</section>
<section id="requirements">
<h2>Requirements</h2>
<p>Nothing about distribution recipients changes.</p>
<p><span class="editor-note">The current distribution of the Founders’ Reward is dependent on arrangements between the participants that will, if not explicitly renewed, expire at the first halving. There are currently direct and indirect recipients other than the ECC and Zcash Foundation. It is unclear whether funding of the ECC and Foundation is intended to continue at the current absolute ZEC rate, or at the same rate relative to the block subsidy which halves in October 2020. Further specification would be needed in order to fulfil and clarify the spirit of the proposal.</span></p>
</section>
<section id="specification">
<h2>Specification</h2>
<ul>
<li>The ECC's portion of block subsidy MUST be capped at their projected 1.1m USD costs a month.</li>
<li>The ECC's portion of block subsidy MUST NOT be greater than 10% of total block subsidy of any one block.</li>
<li>This MUST end at a block height corresponding to two years after the first halving, i.e. October 2022.</li>
</ul>
<p><span class="editor-note">The 1.1m USD cap cannot be specified as a consensus rule since there is no on-chain oracle for the USD price.</span></p>
<section id="rationale">
<h3>Rationale</h3>
<p>Provisions that referred to specific block heights have been revised since they were inconsistent with the change in block target spacing <a href="#zip-0208" id="id3" class="footnote_reference">4</a> that will occur with the Blossom Network Upgrade <a href="#zip-0206" id="id4" class="footnote_reference">3</a>; and even if recalculated, fixed block heights would potentially be inconsistent with future changes in target block spacing.</p>
</section>
</section>
<section id="raised-objections-and-issues-so-far">
<h2>Raised objections and issues so far</h2>
<ul>
<li>This is just kicking the can down the road.</li>
<li>The Zcash Foundation has raised objections to a single point of failure in the ECC.</li>
</ul>
</section>
<section id="implications-to-other-users">
<h2>Implications to other users</h2>
<ul>
<li>The knock-on impact of this ZIP to exchanges and wallet developers may be nontrivial.</li>
<li>The economics of doing this have not been calculated.</li>
</ul>
</section>
<section id="references">
<h2>References</h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="zip-0206" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0206">ZIP 206: Deployment of the Blossom Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="zip-0208" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

112
zip-1008.rst Normal file
View File

@ -0,0 +1,112 @@
::
ZIP: 1008
Title: Fund ECC for Two More Years
Owners: @kek (zcash forums)
@mistfpga (zcash forums) <steve@mistfpga.net>
Status: Draft
Category: Consensus
Created: 2019-09-02
License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/>
Discussions-To: <https://forum.zcashcommunity.com/t/kek-s-proposal-fund-ecc-for-2-more-years/34778>
Terminology
===========
The key words "MUST" and "MUST NOT" in this document are to be interpreted as
described in RFC 2119. [#RFC2119]_
For clarity this ZIP defines these terms:
* Spirit is defined as what is the intended outcome of the ZIP. [#spirit]_
.. [#spirit] If there is contradiction between Spirit and any other part of
the proposal that needs to be addressed, in the event it is not addressed
Spirit is assumed to overrule all.
Out of Scope for this Proposal
==============================
Everything except moving the development fund end date.
Abstract
========
The spirit of this proposal is to keep to the current structure of the
Electric Coin Company (ECC) receiving funding from the block distribution for
two years' worth of blocks after the first halving in October 2020.
Motivation
==========
To give more time to work out the full ramifications of any potential pivot /
slow down, yet keep "all in on ZEC" for two more years with as little
disruption as possible.
Requirements
============
.. role:: editor-note
Nothing about distribution recipients changes.
:editor-note:`The current distribution of the Founders’ Reward is dependent
on arrangements between the participants that will, if not explicitly renewed,
expire at the first halving. There are currently direct and indirect recipients
other than the ECC and Zcash Foundation. It is unclear whether funding of the
ECC and Foundation is intended to continue at the current absolute ZEC rate,
or at the same rate relative to the block subsidy which halves in October 2020.
Further specification would be needed in order to fulfil and clarify the spirit
of the proposal.`
Specification
=============
* The ECC's portion of block subsidy MUST be capped at their projected 1.1m USD
costs a month.
* The ECC's portion of block subsidy MUST NOT be greater than 10% of total block
subsidy of any one block.
* This MUST end at a block height corresponding to two years after the first
halving, i.e. October 2022.
:editor-note:`The 1.1m USD cap cannot be specified as a consensus rule since
there is no on-chain oracle for the USD price.`
Rationale
---------
Provisions that referred to specific block heights have been revised since they
were inconsistent with the change in block target spacing [#zip-0208]_ that will
occur with the Blossom Network Upgrade [#zip-0206]_; and even if recalculated,
fixed block heights would potentially be inconsistent with future changes in
target block spacing.
Raised objections and issues so far
===================================
* This is just kicking the can down the road.
* The Zcash Foundation has raised objections to a single point of failure in the
ECC.
Implications to other users
===========================
* The knock-on impact of this ZIP to exchanges and wallet developers may be
nontrivial.
* The economics of doing this have not been calculated.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <zip-0206.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_

161
zip-1009.html Normal file
View File

@ -0,0 +1,161 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1009: Five-Entity Strategic Council</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1009
Title: Five-Entity Strategic Council
Owner: Avichal Garg &lt;avichalgarg@electriccapital.com&gt;
Status: Draft
Category: Process
Created: 2019-08-28
License: MIT
Discussions-To: &lt;https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entity-strategic-council-approach/34801&gt;</pre>
<section id="terminology">
<h2>Terminology</h2>
<p><em>Key terms</em></p>
<dl>
<dt>Developer Fund</dt>
<dd>20% of the mined ZEC in the four-year period from approximately October 2020 to October 2024, during which at most 5,250,000 ZEC will be minted.</dd>
<dt>Strategic Council</dt>
<dd>A five-person committee that determines how to allocate the Developer Fund. Held accountable to the community via regular elections.</dd>
<dt>Executor</dt>
<dd>An individual, group, company, or other organization that receives funding from the Strategic Council. They are responsible for excellent execution and held accountable by the Strategic Council.</dd>
</dl>
</section>
<section id="abstract">
<h2>Abstract</h2>
<p>This proposal reserves 20% of newly minted coins in each block for a Developer Fund. A five-person Strategic Council would be elected by the community every two years. The Strategic Council would determine the high level strategy, goals, and metrics to evaluate progress for the ecosystem on a six-month cadence. The Strategic Council would be responsible for allocating funding to Executors for the subsequent six months and summarizing the performance of Executors in the prior six months. Executors would submit proposals to the Strategic Council on a six-month cadence, including project plans, funding plans, and how they will measure success on a scale from 1-10. At the end of six months, Executors will grade themselves and the Strategic Council will summarize what was accomplished with a target of 7/10 in every quarter on a roll-up basis (a simple average of all of the outstanding projects for that six months).</p>
</section>
<section id="out-of-scope-for-this-proposal">
<h2>Out of Scope for this Proposal</h2>
<ul>
<li>How to do 1 person = 1 vote (and perhaps we cannot or should not do this).</li>
<li>How to structure the Strategic Council legally, i.e. should it be a Swiss Foundation and what sorts of legally binding responsibilities do the Strategic Council members have?</li>
</ul>
</section>
<section id="motivation-and-requirements">
<h2>Motivation and Requirements</h2>
<p>This is an attempt to put on my startup CEO hat and address the strategic and execution challenges I believe have held back Zcash from realizing its full potential.</p>
<p><strong>Principles &amp; Observations Based on My Experiences (a.k.a. Biases?)</strong></p>
<p>Because layer 1 protocols are network-effect driven, without a quickly growing network-effect in miners, developers, users, and liquidity, a layer 1 protocol will ultimately collapse.</p>
<p>The primary driver of success in a network-effect business is how quickly you grow the network effects.</p>
<p>To grow a network effect, you must have both the correct strategy and excellent execution. If your strategy is not correct, no matter how well you execute, you will fail. If your execution is not excellent, you will not be able to assess whether lack of progress is due to poor execution or poor strategy.</p>
<p>Thus, to build the network effects Zcash needs to succeed, we must answer five questions:</p>
<ol type="1">
<li>Who determines the strategy?</li>
<li>How do they decide on the strategy?</li>
<li>How are they held accountable to having the correct strategy?</li>
<li>Who executes?</li>
<li>How are Executors held accountable to excellent execution?</li>
</ol>
<p><em>1. Who determines the strategy?</em></p>
<ul>
<li>Volunteer-based approaches require the ability for individuals or entities to accumulate significant quantities of the underlying coin. Bitcoin did this through obscurity and Grin is accomplishing this through extremely high inflation in the early years. Zcash has moved beyond this phase and thus I do not believe a volunteer-based approach could be effective. Thus, a developer fund (or similar approach) is the only realistic option for Zcash today.</li>
<li>Independent, high-quality governance enables better decisions and higher quality execution.</li>
<li>We should ideally have the recipients of the funds be different entities than the governance body that allocates funds to avoid conflicts.</li>
<li>Too few people in a decision-making process and people can collude. Too many and nothing gets done.</li>
<li>Good governance and leadership is a significant time commitment and requires significant support/resources.</li>
<li>There are a variety of perspectives that should be represented, including miners, developers, regulators, and users.</li>
</ul>
<p><em>2. How do they decide on the strategy?</em></p>
<ul>
<li>Flexibility in how funds are used is important. Strategies and markets change over time and we should be able to evolve. Thus, we should not constrain how funds are used up front.</li>
<li>There should be no constraint to using all of the funds in any given time frame.</li>
<li>Creating and fostering decentralized ecosystem of miners and developers is important for the long-term health of the ecosystem.</li>
<li>A regular and predictable cadence in planning and goal setting makes it easy for teams to build, ship, and recharge between intense periods of building.</li>
<li>Transparency in the strategy, decision making of fund recipients, and how funds are distributed is paramount.</li>
</ul>
<p><em>3. How are they held accountable to having the correct strategy?</em></p>
<ul>
<li>No organization or individual should have a permanent seat on a decision-making body. Regular elections enforce good behavior.</li>
<li>Third-party audits of financial behavior enforce good behavior and create transparency.</li>
<li>Bad actors should be able to be removed from any decision-making body for egregious violations of trust or misbehavior.</li>
</ul>
<p><em>4. Who executes?</em></p>
<ul>
<li>Anyone should be able to participate in the execution.</li>
<li>Over time the best executors should have reputation accrue and be able to receive more funds.</li>
<li>There is value in having Executors distributed across geographies and across entities.</li>
<li>There is value in identifying Executors who have long-term commitments to Zcash and will be available for long-term support and maintenance of their work.</li>
</ul>
<p><em>5. How are Executors held accountable to excellent execution?</em></p>
<ul>
<li>Excellent execution comes from having verifiable hypotheses, backed up with data, and clear milestones.</li>
<li>Executors need to submit concrete plans, with clear goals and metrics, and be judged according to both whether or not the goals were reasonable and whether they accomplished those goals (ideally in a measurable way using metrics).</li>
<li>Execution is best measured by pre-defining success and failure criteria, prior to having been influenced by the challenges of the task at hand.</li>
</ul>
</section>
<section id="specification">
<h2>Specification</h2>
<p><em>1. Who determines strategy?</em></p>
<ul>
<li>A five-person/entity board -- Five people is better than three to minimize collusion.</li>
<li>Strategic Council should get two-year term so we can pivot people in the middle if necessary. No permanent seats.</li>
<li>For the purposes of voting to determine seats (not having seats vote on issues): one of the five seats should be allocated for miners and signaled through nodes. One of the five should be weighted by ZEC holding so 1 ZEC = 1 vote. Three of the five should be 1 person = 1 vote.</li>
<li>Elections should be open such that any person or entity can run for a seat.</li>
<li>The board is a paid position from Dev Fund emissions. Compensation TBD.</li>
</ul>
<p><em>2. How do they decide?</em></p>
<ul>
<li>20% of block rewards are allocated for the Developer Fund.</li>
<li>There should not be any limit up front on where money can go. Perhaps one year it makes sense to invest entirely in protocol and another year it makes sense to invest in user adoption via content marketing, SEO, SEM, etc.</li>
<li>Every six months, the board has a responsibility to publish an update to the strategy, key metrics that are being tracked, and key metrics to hit as goals in the next six months. This will require feedback from the community but ultimately the board needs to decide on and own the strategy.</li>
<li>Every six months, the board runs a process whereby anyone can submit proposals for how they would best accomplish these strategic objectives and hit those metrics and milestones.</li>
<li>No more than 33% of funds can go to one entity for development purposes. This enforces broad decentralization and encourages the ecosystem to identify new participants.</li>
</ul>
<p><em>How are they held accountable for having the correct strategy?</em></p>
<ul>
<li>Elections every two years from the community.</li>
<li>All decisions and finances are audited by a third-party audit firm.</li>
<li>There is an annual meeting of all stakeholders (perhaps at Zcon?) for feedback, Q and A of the board, and a walk through of what has been accomplished in the last six months and what the proposals are for the next six months for feedback. The other six-month cadence meeting for the Strategic Council to present its plans and receive feedback can be virtual.</li>
</ul>
<p><em>4. Who executes?</em></p>
<ul>
<li>Individuals, teams, or companies from anywhere can submit a proposal that aligns with the strategy (or doesn’t), a budget for what they want to do, and their success criteria on a scale of 1-10 (see below).</li>
<li>Executing Entities can submit plans that may take longer than 6 months to complete as the reality of hiring and funding employees may dictate longer term financing commitment. The Strategic Committee should have discretion to allow for these sorts of investments but should require intermediate milestones and grading on the 6-month time horizon as well.</li>
<li>Companies that have sustainable business models and can support or subsidize engineers to work on Zcash or that have adjacent businesses that would benefit from investment in this technology should be encouraged to participate, i.e. the way Square is supporting Bitcoin we should have companies supporting Zcash.</li>
<li>Ideally the board also encourages non-technical execution such as education, video series, regulatory progress, etc.</li>
</ul>
<p><em>5. How are they held accountable to excellent execution?</em></p>
<ul>
<li>At the end of six months all proposals are graded 1-10. Each team would pre-agree to what would would result in a 0, 3, 7, 10/10 and then they can move it up or down a little once results are due in 6 months. If they pre-agreed to some definition of results that is a 3 and then tried to give themselves an 8, it would look fishy and could impact future funding.</li>
<li>The Strategic Council should target an average score of 7/10 for that six months across all Executors. If we score too high, we are not being ambitious enough in our goals. If we score too low, we were trying to do too much or had a fundamental misunderstanding of our goals.</li>
<li>Over time the Strategic Council decides who gets funds so under-performers will be culled. Thus Executors are held accountable by the board and the board is held accountable by the community.</li>
</ul>
</section>
<section id="issues-further-discussion">
<h2>Issues &amp; Further Discussion</h2>
<p><em>Raised objections, issues, and open questions:</em></p>
<ul>
<li>How might we create a process to amending this process? We may want 4/5 of the Strategic Council to approve changes or 2/3 of ZEC holders to be able to amend the Strategic Council’s charter.</li>
<li>How do we recall or impeach the members of the Strategic Committee prior to the end of their term if necessary?</li>
<li>I’m sure there are many other points of ambiguity and improvements we could make. There may even be critical design flaws or failures in this system. Feedback is appreciated.</li>
</ul>
</section>
<section id="references-background">
<h2>References / Background</h2>
<ul>
<li><a href="https://www.zfnd.org/blog/multisig-governance/">https://www.zfnd.org/blog/multisig-governance/</a></li>
<li><a href="https://forum.zcashcommunity.com/t/placeholder-considerations-resources-governance-and-legitimacy-in-nu4/34045">https://forum.zcashcommunity.com/t/placeholder-considerations-resources-governance-and-legitimacy-in-nu4/34045</a></li>
<li><a href="https://electriccoin.co/blog/ecc-initial-assessment-of-community-proposals/">https://electriccoin.co/blog/ecc-initial-assessment-of-community-proposals/</a></li>
<li><a href="https://medium.com/@socrates1024/here-are-a-couple-of-points-on-framing-the-discussion-of-a-potential-new-dev-fund-in-zcash-c13bcbf4ed5b">https://medium.com/@socrates1024/here-are-a-couple-of-points-on-framing-the-discussion-of-a-potential-new-dev-fund-in-zcash-c13bcbf4ed5b</a></li>
<li><a href="https://www.grin-forum.org/t/solved-early-disappointments/3682">https://www.grin-forum.org/t/solved-early-disappointments/3682</a></li>
<li><a href="https://www.electriccapital.com/">https://www.electriccapital.com/</a> (for disclosure of investments we’ve made).</li>
</ul>
<p><span class="editor-note">these should be made into inline references.</span></p>
</section>
<section id="change-log">
<h2>Change Log</h2>
<ul>
<li>2019-08-27 Initial draft - thanks to @jubos, @puntium, @zooko, @joshs, and Jack Gavigan for helping me more clearly articulating my ideas and helping get them formatted properly for a ZIP. These ideas are solely mine and were not influenced by any of these individuals.</li>
<li>2019-08-28 Updated to be in ZIP format.</li>
<li>2019-09-15 Finally turned in to a pull request on GitHub and incorporated feedback from @daira and @str4d.</li>
</ul>
</section>
</section>
</body>
</html>

272
zip-1009.rst Normal file
View File

@ -0,0 +1,272 @@
::
ZIP: 1009
Title: Five-Entity Strategic Council
Owner: Avichal Garg <avichalgarg@electriccapital.com>
Status: Draft
Category: Process
Created: 2019-08-28
License: MIT
Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entity-strategic-council-approach/34801>
Terminology
===========
*Key terms*
Developer Fund
20% of the mined ZEC in the four-year period from approximately October 2020
to October 2024, during which at most 5,250,000 ZEC will be minted.
Strategic Council
A five-person committee that determines how to allocate the Developer Fund.
Held accountable to the community via regular elections.
Executor
An individual, group, company, or other organization that receives funding
from the Strategic Council. They are responsible for excellent execution
and held accountable by the Strategic Council.
Abstract
========
This proposal reserves 20% of newly minted coins in each block for a Developer
Fund. A five-person Strategic Council would be elected by the community every
two years. The Strategic Council would determine the high level strategy,
goals, and metrics to evaluate progress for the ecosystem on a six-month
cadence. The Strategic Council would be responsible for allocating funding to
Executors for the subsequent six months and summarizing the performance of
Executors in the prior six months. Executors would submit proposals to the
Strategic Council on a six-month cadence, including project plans, funding
plans, and how they will measure success on a scale from 1-10. At the end of
six months, Executors will grade themselves and the Strategic Council will
summarize what was accomplished with a target of 7/10 in every quarter on a
roll-up basis (a simple average of all of the outstanding projects for that
six months).
Out of Scope for this Proposal
==============================
* How to do 1 person = 1 vote (and perhaps we cannot or should not do this).
* How to structure the Strategic Council legally, i.e. should it be a Swiss
Foundation and what sorts of legally binding responsibilities do the
Strategic Council members have?
Motivation and Requirements
===========================
This is an attempt to put on my startup CEO hat and address the strategic and
execution challenges I believe have held back Zcash from realizing its full
potential.
**Principles & Observations Based on My Experiences (a.k.a. Biases?)**
Because layer 1 protocols are network-effect driven, without a quickly growing
network-effect in miners, developers, users, and liquidity, a layer 1 protocol
will ultimately collapse.
The primary driver of success in a network-effect business is how quickly you
grow the network effects.
To grow a network effect, you must have both the correct strategy and
excellent execution. If your strategy is not correct, no matter how well you
execute, you will fail. If your execution is not excellent, you will not be
able to assess whether lack of progress is due to poor execution or poor
strategy.
Thus, to build the network effects Zcash needs to succeed, we must answer five
questions:
1. Who determines the strategy?
2. How do they decide on the strategy?
3. How are they held accountable to having the correct strategy?
4. Who executes?
5. How are Executors held accountable to excellent execution?
*1. Who determines the strategy?*
* Volunteer-based approaches require the ability for individuals or entities
to accumulate significant quantities of the underlying coin. Bitcoin did
this through obscurity and Grin is accomplishing this through extremely
high inflation in the early years. Zcash has moved beyond this phase and
thus I do not believe a volunteer-based approach could be effective. Thus,
a developer fund (or similar approach) is the only realistic option for
Zcash today.
* Independent, high-quality governance enables better decisions and higher
quality execution.
* We should ideally have the recipients of the funds be different entities
than the governance body that allocates funds to avoid conflicts.
* Too few people in a decision-making process and people can collude. Too
many and nothing gets done.
* Good governance and leadership is a significant time commitment and requires
significant support/resources.
* There are a variety of perspectives that should be represented, including
miners, developers, regulators, and users.
*2. How do they decide on the strategy?*
* Flexibility in how funds are used is important. Strategies and markets
change over time and we should be able to evolve. Thus, we should not
constrain how funds are used up front.
* There should be no constraint to using all of the funds in any given time
frame.
* Creating and fostering decentralized ecosystem of miners and developers is
important for the long-term health of the ecosystem.
* A regular and predictable cadence in planning and goal setting makes it
easy for teams to build, ship, and recharge between intense periods of
building.
* Transparency in the strategy, decision making of fund recipients, and how
funds are distributed is paramount.
*3. How are they held accountable to having the correct strategy?*
* No organization or individual should have a permanent seat on a
decision-making body. Regular elections enforce good behavior.
* Third-party audits of financial behavior enforce good behavior and create
transparency.
* Bad actors should be able to be removed from any decision-making body for
egregious violations of trust or misbehavior.
*4. Who executes?*
* Anyone should be able to participate in the execution.
* Over time the best executors should have reputation accrue and be able to
receive more funds.
* There is value in having Executors distributed across geographies and
across entities.
* There is value in identifying Executors who have long-term commitments to
Zcash and will be available for long-term support and maintenance of their
work.
*5. How are Executors held accountable to excellent execution?*
* Excellent execution comes from having verifiable hypotheses, backed up
with data, and clear milestones.
* Executors need to submit concrete plans, with clear goals and metrics, and
be judged according to both whether or not the goals were reasonable and
whether they accomplished those goals (ideally in a measurable way using
metrics).
* Execution is best measured by pre-defining success and failure criteria,
prior to having been influenced by the challenges of the task at hand.
Specification
=============
*1. Who determines strategy?*
* A five-person/entity board -- Five people is better than three to minimize
collusion.
* Strategic Council should get two-year term so we can pivot people in the
middle if necessary. No permanent seats.
* For the purposes of voting to determine seats (not having seats vote on
issues): one of the five seats should be allocated for miners and signaled
through nodes. One of the five should be weighted by ZEC holding so
1 ZEC = 1 vote. Three of the five should be 1 person = 1 vote.
* Elections should be open such that any person or entity can run for a seat.
* The board is a paid position from Dev Fund emissions. Compensation TBD.
*2. How do they decide?*
* 20% of block rewards are allocated for the Developer Fund.
* There should not be any limit up front on where money can go. Perhaps one
year it makes sense to invest entirely in protocol and another year it
makes sense to invest in user adoption via content marketing, SEO, SEM,
etc.
* Every six months, the board has a responsibility to publish an update to
the strategy, key metrics that are being tracked, and key metrics to hit
as goals in the next six months. This will require feedback from the
community but ultimately the board needs to decide on and own the strategy.
* Every six months, the board runs a process whereby anyone can submit
proposals for how they would best accomplish these strategic objectives
and hit those metrics and milestones.
* No more than 33% of funds can go to one entity for development purposes.
This enforces broad decentralization and encourages the ecosystem to
identify new participants.
*How are they held accountable for having the correct strategy?*
* Elections every two years from the community.
* All decisions and finances are audited by a third-party audit firm.
* There is an annual meeting of all stakeholders (perhaps at Zcon?) for
feedback, Q and A of the board, and a walk through of what has been
accomplished in the last six months and what the proposals are for the
next six months for feedback. The other six-month cadence meeting for
the Strategic Council to present its plans and receive feedback can be
virtual.
*4. Who executes?*
* Individuals, teams, or companies from anywhere can submit a proposal that
aligns with the strategy (or doesn’t), a budget for what they want to do,
and their success criteria on a scale of 1-10 (see below).
* Executing Entities can submit plans that may take longer than 6 months
to complete as the reality of hiring and funding employees may dictate
longer term financing commitment. The Strategic Committee should have
discretion to allow for these sorts of investments but should require
intermediate milestones and grading on the 6-month time horizon as well.
* Companies that have sustainable business models and can support or
subsidize engineers to work on Zcash or that have adjacent businesses
that would benefit from investment in this technology should be encouraged
to participate, i.e. the way Square is supporting Bitcoin we should have
companies supporting Zcash.
* Ideally the board also encourages non-technical execution such as education,
video series, regulatory progress, etc.
*5. How are they held accountable to excellent execution?*
* At the end of six months all proposals are graded 1-10. Each team would
pre-agree to what would would result in a 0, 3, 7, 10/10 and then they
can move it up or down a little once results are due in 6 months. If they
pre-agreed to some definition of results that is a 3 and then tried to
give themselves an 8, it would look fishy and could impact future funding.
* The Strategic Council should target an average score of 7/10 for that
six months across all Executors. If we score too high, we are not being
ambitious enough in our goals. If we score too low, we were trying to do
too much or had a fundamental misunderstanding of our goals.
* Over time the Strategic Council decides who gets funds so under-performers
will be culled. Thus Executors are held accountable by the board and the
board is held accountable by the community.
Issues & Further Discussion
===========================
*Raised objections, issues, and open questions:*
* How might we create a process to amending this process? We may want 4/5
of the Strategic Council to approve changes or 2/3 of ZEC holders to be
able to amend the Strategic Council’s charter.
* How do we recall or impeach the members of the Strategic Committee prior
to the end of their term if necessary?
* I’m sure there are many other points of ambiguity and improvements we
could make. There may even be critical design flaws or failures in this
system. Feedback is appreciated.
References / Background
=======================
.. role:: editor-note
* https://www.zfnd.org/blog/multisig-governance/
* https://forum.zcashcommunity.com/t/placeholder-considerations-resources-governance-and-legitimacy-in-nu4/34045
* https://electriccoin.co/blog/ecc-initial-assessment-of-community-proposals/
* https://medium.com/@socrates1024/here-are-a-couple-of-points-on-framing-the-discussion-of-a-potential-new-dev-fund-in-zcash-c13bcbf4ed5b
* https://www.grin-forum.org/t/solved-early-disappointments/3682
* https://www.electriccapital.com/ (for disclosure of investments we’ve made).
:editor-note:`these should be made into inline references.`
Change Log
==========
* 2019-08-27 Initial draft - thanks to @jubos, @puntium, @zooko, @joshs, and
Jack Gavigan for helping me more clearly articulating my ideas and helping
get them formatted properly for a ZIP. These ideas are solely mine and were
not influenced by any of these individuals.
* 2019-08-28 Updated to be in ZIP format.
* 2019-09-15 Finally turned in to a pull request on GitHub and incorporated
feedback from @daira and @str4d.

216
zip-1010.html Normal file
View File

@ -0,0 +1,216 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1010
Title: Compromise Dev Fund Proposal With Diverse Funding Streams
Owner: Josh Cincinnati &lt;josh@zfnd.org&gt;
Credits: Matt Luongo
Eran Tromer
Andrew Miller
mistfpga
lex-node
and many others
Status: Draft
Category: Consensus
Created: 2019-08-31
License: MIT
Discussions-To: &lt;https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812/&gt;</pre>
<section id="terminology">
<h2>Terminology</h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">1</a></p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a href="#zip-0200" id="id2" class="footnote_reference">2</a></p>
</section>
<section id="abstract">
<h2>Abstract</h2>
<p>I try to put the best pieces of various proposals together. A 20% of the block reward for a 4-year development fund that disburses to a trust controlled by both the Electric Coin Company (ECC) and Zcash Foundation (ZF), but with stringent controls on how funds may be allocated. It sidesteps code complexity in implementation by off-loading disbursements to a legal trust; funds the ECC/ZF; ECC stays a for-profit with restrictions; funds external parties through ZF Grants; all while carving out a limited-scoped opportunity for extending governance to more groups than the ECC/ZF.</p>
</section>
<section id="motivation-and-requirements">
<h2>Motivation and Requirements</h2>
<p>Zcash won't thrive without a dev fund. I wish this wasn't true (I really do), and for the longest time I was against the idea. But I've come to fear the alternative without one; I fear the privacy technology pioneered by Zcash may never reach its true potential — not just for our community, but for others interested in novel approaches to private money.</p>
<p>The Foundation, ECC, and broader community has offered many suggestions and guidelines for a potential dev fund, below is my attempt at synthesizing them into a compromise that's greater than the sum of its parts:</p>
<ul>
<li>The ECC and Zcash Foundation shouldn't get a blank check; accountability is a prerequisite for any disbursement, based on the Foundation's statement <a href="#zfnd-guidance" id="id3" class="footnote_reference">3</a> and other proposals being suggested.</li>
<li>It's possible for the ECC to remain a for-profit, but with (legally enforced) restrictions that ensure accountability and add teeth to their claim that no early investors are enriched by a new dev fund / no new investors are beneficiaries.</li>
<li>A nontrivial portion of the funds should be directed to users/organisations outside of the ECC/Zcash Foundation, and the ECC/Zcash Foundation should be in the minority in deciding how these funds are disbursed (e.g. through some process with broader input beyond ECC/Zcash Foundation employees, like a more constrained version of Placeholder or Blocktower's "third party" proposals).</li>
<li>The actual code changes for the NU4 network upgrade should be minimal and the "governance complexity" should be offloaded to legal agreements, not engineering hours. The dev fund would be deposited into a single address for the fund (ideally shielded with a viewing key) controlled through a trust (originally Andrew Miller’s idea), disbursed quarterly based on the accountability requirements and shielded adoption metrics described below. Trustees will be mutually agreed upon by the ECC and Zcash Foundation, and the Zcash Foundation will bear the cost of operating the trust.</li>
<li>The gross amount of the dev fund should still be 20% of the block reward, and it should end in 4 years. (Unless we go through another process like this one to extend it, though I personally hope we don’t.)</li>
</ul>
<p><span class="editor-note">for security reasons, it may be useful to refine the "single address" to a list of rolling addresses as described in section 7.8 of the current protocol specification. Other references to a "single address" in this document have not been changed.</span></p>
<p><em>Please note: a previous version of this proposal included a portion of the funds being tied to shielded adoption, based on ideas brought forward by Eran Tromer in</em> <a href="#tromer-comment" id="id4" class="footnote_reference">4</a>. <em>After many discussions I came to worry about the gameability of the metric and decided to drop it entirely.</em></p>
</section>
<section id="specification">
<h2>Specification</h2>
<p>Upon the NU4 network activation, 20% of the mining reward (post-Blossom / post-halvening = 0.625 ZEC per block) MUST go to a single shielded address with a viewing key widely distributed and known to the community and controlled by a trust established by the ECC and Zcash Foundation. If the trust and associated address aren't established by the NU4 activation deadline, then there MUST NOT be any change to the mining reward. Every quarter-year (105,000 blocks at the post-Blossom rate), until 4 years after NU4 activation (1,680,000 blocks at the post-Blossom rate), the trust SHOULD disburse funds the following way, requiring a public report with every disbursement:</p>
<ul>
<li>30% of the fund to the ECC, if they meet the accountability requirements set by the trust/described below;</li>
<li>30% of the fund to the Zcash Foundation, if they meet the accountability requirements set by the trust/described below;</li>
<li>40% of the fund to the Zcash Foundation as a RESTRICTED donation <a href="#restricted-funds" id="id5" class="footnote_reference">5</a> purely for disbursement through ZF Grants <a href="#zfnd-grants" id="id6" class="footnote_reference">6</a>, with additional restrictions and stipulations described below.</li>
</ul>
<p><span class="editor-note">When this proposal was written it was expected that NU4 activation would correspond exactly to the first (October 2019) halvening. Since that may not be the case, I have resolved a potential ambiguity in the original wording by specifying that the trust disburses funds for 4 years, rather than that it disburses funds until the second (October 2020) halvening.</span></p>
<section id="example-disbursements-by-the-trust-for-a-hypothetical-105000-block-period">
<h3>Example disbursements by the trust for a hypothetical 105000-block period</h3>
<p>0.625 ZEC * 105000 = 65625 ZEC accrued in the trust every quarter. If both the ECC and Zcash Foundation met the accountability requirements set by the trust, then disbursements would look like this:</p>
<ul>
<li>19687.5 ZEC to the ECC for meeting accountability requirements.</li>
<li>19687.5 ZEC to the Zcash Foundation for meeting accountability requirements.</li>
<li>26250 ZEC to ZF Grants to be disbursed to external individuals and organizations (via the Zcash Foundation as a restricted donation, but determined by an independent body to both organizations).</li>
</ul>
<p>This example assumes no change to target block spacing.</p>
</section>
<section id="the-trust-s-accountability-requirements">
<h3>The trust's accountability requirements</h3>
<p>Here I'm borrowing from the Foundation's guidance <a href="#zfnd-guidance" id="id7" class="footnote_reference">3</a> but adding some stipulations to cement the Foundation's independence, prevent the Foundation from hoarding its endowment, and handle the ECC as a for-profit. Before disbursing funds each quarter, the trust MUST validate that both the ECC and Zcash Foundation:</p>
<ul>
<li>Published quarterly technical roadmap reports and financial reports, detailing spending levels/burn rate and cash/ZEC on hand;</li>
<li>(if the first disbursement in a calendar year) Published a yearly review of organization performance, along the lines of the Zcash Foundation's "State of the Foundation" report <a href="#zfnd-state" id="id8" class="footnote_reference">7</a>.</li>
</ul>
<p>For the Zcash Foundation, the trust MUST further require:</p>
<ul>
<li>No board member may have an interest in the ECC (current board members with an interest would need to divest of their ECC holdings prior to the beginning of this dev fund or leave the board);</li>
<li>Excluding money restricted for ZF Grants, the Foundation's total assets MUST stay below $100mm (if its assets ever exceeded this amount from a disbursement, the trust could direct the funds toward an additional restricted ZF Grants donation).</li>
</ul>
<p>Additionally, for the ECC, the trust MUST validate the following before each disbursement:</p>
<ul>
<li>(if the first disbursement in a fiscal year) The ECC published yearly audited financial statements at the same level of detail as a public company (to mirror the Foundation's Form 990 requirement as 501(c)(3));</li>
<li>No outside investment was received while they are obligatory recipients of this dev fund;</li>
<li>No portion of the dev fund went to dividends, profit-sharing, or share/equity buybacks while they are obligatory recipients of this dev fund;</li>
<li>No dilution of ECC's equity except in the case of options/RSUs for new/existing employees while they are obligatory recipients of this dev fund;</li>
<li>There's no change-of-control (majority control changes) at the ECC while they are obligatory recipients of this dev fund;</li>
</ul>
<p>The ECC MUST share necessary information with the trust to ascertain no violations of the above, but the information itself (i.e. cap table and detailed financials) SHOULD remain private between the ECC and the trustees unless there is a violation that is not cured.</p>
</section>
<section id="what-happens-in-the-case-of-a-violation">
<h3>What happens in the case of a violation</h3>
<p>The violating party has 30 days to attempt to cure the violation (if it's possible). If they cannot, future funds MUST be redirected to ZF Grants via a restricted donation to the Zcash Foundation. (That is, not usable by either the Zcash Foundation or ECC, more on that below.)</p>
</section>
<section id="the-zf-grants-portion">
<h3>The ZF Grants portion</h3>
<p>A portion of the dev fund goes to the Foundation but with the express (and restricted) purpose of being distributed via ZF Grants (a restriction that MUST be legally enforced by the trust). The Foundation would continue to administer ZF Grants and distribute funds, but it SHOULD NOT decide where those funds go and would not allowed to be recipients of these funds; instead, the trust MUST demand that the ZF Grants process include broader input in the manner described below. In the discussions around the various "third party" proposals, some have suggested a 3-of-5 approach where the ECC and Zcash Foundation are in the minority; I think that structure would work well for these funds. It's not the full dev fund so we are limiting the downside risk of selecting the "wrong" third parties, which also means we can give those third parties more voice (by making them outnumber the ECC/Zcash Foundation). The Foundation MAY also chose to fund ZF Grants <em>beyond</em> the restricted donations from the trust, but doing so would be at their discretion.</p>
<p>Thanks to the discussion on Matt Luongo's proposal there's a good blueprint for how this group would work. I'm borrowing some comments I made on Matt's proposal thread <a href="#acityinohio-comment" id="id9" class="footnote_reference">8</a> and modifying them to apply to a ZF Grants-specific Grant Review Committee, rather than the Foundation's board.</p>
<p>The ZF Grant Review Committee would be compromised of five members, voted on in the following manner:</p>
<ul>
<li>1 seat for the ECC. Though the appointed member may change, they retain power to choose the seat for 4 years.</li>
<li>1 seat for the Zcash Foundation. Though the appointed member may change, they retain power to choose the seat for 4 years.</li>
<li>2 seats voted on by ZEC holders directly, elected every year. There would be open elections held by the Foundation similar to the 2018 advisory process which resulted in Ian and Amber’s election, except using a ZEC coin-staked vote directly.</li>
<li>1 seat held by a technical member, elected every year. This member would be selected by the combined group (2 coin-staked seats + ZF seat + ECC seat) with an express focus on ability to evaluate technical proposals.</li>
</ul>
<p>The group would meet biweekly to make funding decisions, the results of which will be made public on ZF Grants. Taking a note from Eran Tromer's recent proposal, the group would have a goal of making at least two "Large Grants" every year. A "Large Grant" would have an expected scope of six months and 1/4th to 1/3rd of the total ZF Grants yearly budget, with the goal of getting more dedicated external teams involved.</p>
</section>
</section>
<section id="rationale">
<h2>Rationale</h2>
<p>There are scores of great ideas on the forums, and I took the (subjective, mind you) best parts of each into a proposal that hopefully meets the standards of the ECC, the Zcash Foundation, and the broader community.</p>
<section id="a-word-on-the-enigmatic-third-party-floating-around">
<h3>A word on the enigmatic "third party" floating around</h3>
<p>With all due respect to the proposers behind some variant of a "2-of-3 multisig" decision-making process for <em>all</em> disbursement decisions: I think this is a bad idea. To quote a previous forum post of mine:</p>
<blockquote>
<p>...2-of-3 multisig [is] better if we find the right third party. That in and of itself requires an additional process/mutual agreement between the three parties (which is much more difficult than a bilateral agreement), and as I’ve mentioned before in presentations in the past, 2-of-2 with known entities dedicated to Zcash is better than jumping straight to 2-of-3 with a third party hastily decided or staying with 1-of-1 entity trademarks and software development processes.</p>
<p>As for why 2-of-2 is still strictly better than 1-of-1: in the case of cryptocurrency governance, I believe that inaction in the case of disagreement is a better outcome than one party unilaterally exercising power.</p>
</blockquote>
<p>More to the point, I worry that the "third party" in question is being idolized into some Platonic ideal, and in reality either the ECC or the Zcash Foundation would spend a great deal of their time currying favor in either the process or selection of the party in question in the limited time between now and that party's selection. Given that the Zcash Foundation is charged with representing community interests, I'm not sure why another community-focused representative would really make sense from the ECC's perspective — they'd be constantly outvoted if interests clashed, so from a balance of power perspective I'm not sure why the ECC would find that tenable. And I'm not sure the community would want the "third party" to be another profit-generating enterprise, like a VC or another startup, which would tip power another way.</p>
<p>The crux of this proposal still centers around the idea that the Zcash Foundation and ECC share responsibility for protocol development, which is now bolstered by the 2-of-2 agreement on the trademark. It assumes and expects that both continue developing consensus-compatible node software that interacts with the Zcash network. But it mandates accountability for disbursement of funds to the ECC/Zcash Foundation, and expands outside stakeholder input on funds that <em>wouldn't</em> be earmarked for the ECC/Zcash Foundation (similar to Placeholder's earlier version of their proposal and Matt Luongo's current proposal), while it doesn’t preclude the possibility of migrating to broader "2-of-3" later on future governance decisions.</p>
</section>
<section id="why-a-trust">
<h3>Why a trust?</h3>
<p>The main reason: reducing complexity creep in consensus code. Rather than try to incorporate some complex mechanism for dev fund disbursements on-chain, we can meet the NU4 with the simplest possible code-change and spend more time ironing out the details of the trust "off-chain." Since both the ECC and the Zcash Foundation are based in the US, using a trust with well-specified criteria for disbursements is a reasonable path. This also fits in nicely with lex-node's proposal <a href="#zip-1007" id="id10" class="footnote_reference">9</a> for legal covenants on funding.</p>
</section>
</section>
<section id="security-and-privacy-considerations">
<h2>Security and Privacy Considerations</h2>
<p>The biggest issue is custody of the funds under the trust's control, but I suspect this can be managed with a partnership with a custody partner. There's also the issue that non-public information would need to be verified and validated by the trust, but I view this as a net positive for the community ("transparency for organizations, privacy for individuals").</p>
</section>
<section id="reference-implementation">
<h2>Reference implementation</h2>
<p>TBD, but it should be relatively simple to code in both zebra and zcashd.</p>
</section>
<section id="issues-and-further-discussion">
<h2>Issues and further discussion</h2>
<ul>
<li>What are the tax implications for setting up the trust?</li>
<li>Are the amounts reasonable? Should the dev fund be less than 20% in aggregate?</li>
<li>Should this or other proposals seek to change the ECC and Zcash Foundation's board/makeup, or should we keep those organizations running as they are and sandbox a new process to a specific disbursement of the dev fund? (This proposal assumes the latter via ZF Grants.)</li>
</ul>
</section>
<section id="references">
<h2>References</h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zfnd-guidance" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/">Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="tromer-comment" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="https://forum.zcashcommunity.com/t/how-to-hire-ecc/34379/55">Comment on a post “How to hire ECC” in the Zcash Community Forum. Eran Tromer, August 11, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="restricted-funds" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="https://www.501c3.org/kb/what-are-restricted-funds/">“What Are Restricted Funds?” Foundation Group, last modified December 7, 2018.</a></td>
</tr>
</tbody>
</table>
<table id="zfnd-grants" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="https://grants.zfnd.org/">ZF Grants — Funding for Zcash ecosystem projects</a></td>
</tr>
</tbody>
</table>
<table id="zfnd-state" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="https://www.zfnd.org/blog/foundation-in-2019/">The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="acityinohio-comment" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252/38">Comment on a post “Decentralizing the Dev Fee” in the Zcash Community Forum. Josh Cincinnati, October 27, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="zip-1007" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="zip-1007">ZIP 1007: Enforce Development Fund Commitments with a Legal Charter</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

353
zip-1010.rst Normal file
View File

@ -0,0 +1,353 @@
::
ZIP: 1010
Title: Compromise Dev Fund Proposal With Diverse Funding Streams
Owner: Josh Cincinnati <josh@zfnd.org>
Credits: Matt Luongo
Eran Tromer
Andrew Miller
mistfpga
lex-node
and many others
Status: Draft
Category: Consensus
Created: 2019-08-31
License: MIT
Discussions-To: <https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812/>
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document
are to be interpreted as described in RFC 2119. [#RFC2119]_
The term "network upgrade" in this document is to be interpreted as described
in ZIP 200. [#zip-0200]_
Abstract
========
I try to put the best pieces of various proposals together. A 20% of the block
reward for a 4-year development fund that disburses to a trust controlled by
both the Electric Coin Company (ECC) and Zcash Foundation (ZF), but with
stringent controls on how funds may be allocated. It sidesteps code complexity
in implementation by off-loading disbursements to a legal trust; funds the
ECC/ZF; ECC stays a for-profit with restrictions; funds external parties
through ZF Grants; all while carving out a limited-scoped opportunity for
extending governance to more groups than the ECC/ZF.
Motivation and Requirements
===========================
.. role:: editor-note
Zcash won't thrive without a dev fund. I wish this wasn't true (I really do),
and for the longest time I was against the idea. But I've come to fear the
alternative without one; I fear the privacy technology pioneered by Zcash may
never reach its true potential — not just for our community, but for others
interested in novel approaches to private money.
The Foundation, ECC, and broader community has offered many suggestions and
guidelines for a potential dev fund, below is my attempt at synthesizing them
into a compromise that's greater than the sum of its parts:
* The ECC and Zcash Foundation shouldn't get a blank check; accountability is
a prerequisite for any disbursement, based on the Foundation's statement
[#zfnd-guidance]_ and other proposals being suggested.
* It's possible for the ECC to remain a for-profit, but with (legally
enforced) restrictions that ensure accountability and add teeth to their
claim that no early investors are enriched by a new dev fund / no new
investors are beneficiaries.
* A nontrivial portion of the funds should be directed to users/organisations
outside of the ECC/Zcash Foundation, and the ECC/Zcash Foundation should be
in the minority in deciding how these funds are disbursed (e.g. through some
process with broader input beyond ECC/Zcash Foundation employees, like a
more constrained version of Placeholder or Blocktower's "third party"
proposals).
* The actual code changes for the NU4 network upgrade should be minimal and
the "governance complexity" should be offloaded to legal agreements, not
engineering hours. The dev fund would be deposited into a single address
for the fund (ideally shielded with a viewing key) controlled through a
trust (originally Andrew Miller’s idea), disbursed quarterly based on the
accountability requirements and shielded adoption metrics described below.
Trustees will be mutually agreed upon by the ECC and Zcash Foundation, and
the Zcash Foundation will bear the cost of operating the trust.
* The gross amount of the dev fund should still be 20% of the block reward,
and it should end in 4 years. (Unless we go through another process like
this one to extend it, though I personally hope we don’t.)
:editor-note:`for security reasons, it may be useful to refine the
"single address" to a list of rolling addresses as described in
section 7.8 of the current protocol specification. Other references to
a "single address" in this document have not been changed.`
*Please note: a previous version of this proposal included a portion of the
funds being tied to shielded adoption, based on ideas brought forward by
Eran Tromer in* [#tromer-comment]_. *After many discussions I came to worry
about the gameability of the metric and decided to drop it entirely.*
Specification
=============
Upon the NU4 network activation, 20% of the mining reward (post-Blossom /
post-halvening = 0.625 ZEC per block) MUST go to a single shielded address
with a viewing key widely distributed and known to the community and
controlled by a trust established by the ECC and Zcash Foundation. If the
trust and associated address aren't established by the NU4 activation
deadline, then there MUST NOT be any change to the mining reward. Every
quarter-year (105,000 blocks at the post-Blossom rate), until 4 years after
NU4 activation (1,680,000 blocks at the post-Blossom rate), the trust SHOULD
disburse funds the following way, requiring a public report with every
disbursement:
* 30% of the fund to the ECC, if they meet the accountability requirements
set by the trust/described below;
* 30% of the fund to the Zcash Foundation, if they meet the accountability
requirements set by the trust/described below;
* 40% of the fund to the Zcash Foundation as a RESTRICTED donation
[#restricted-funds]_ purely for disbursement through ZF Grants
[#zfnd-grants]_, with additional restrictions and stipulations described
below.
:editor-note:`When this proposal was written it was expected that NU4
activation would correspond exactly to the first (October 2019) halvening.
Since that may not be the case, I have resolved a potential ambiguity in
the original wording by specifying that the trust disburses funds for
4 years, rather than that it disburses funds until the second (October 2020)
halvening.`
Example disbursements by the trust for a hypothetical 105000-block period
-------------------------------------------------------------------------
0.625 ZEC * 105000 = 65625 ZEC accrued in the trust every quarter. If both
the ECC and Zcash Foundation met the accountability requirements set by the
trust, then disbursements would look like this:
* 19687.5 ZEC to the ECC for meeting accountability requirements.
* 19687.5 ZEC to the Zcash Foundation for meeting accountability requirements.
* 26250 ZEC to ZF Grants to be disbursed to external individuals and
organizations (via the Zcash Foundation as a restricted donation, but
determined by an independent body to both organizations).
This example assumes no change to target block spacing.
The trust's accountability requirements
---------------------------------------
Here I'm borrowing from the Foundation's guidance [#zfnd-guidance]_ but
adding some stipulations to cement the Foundation's independence, prevent
the Foundation from hoarding its endowment, and handle the ECC as a
for-profit. Before disbursing funds each quarter, the trust MUST validate
that both the ECC and Zcash Foundation:
* Published quarterly technical roadmap reports and financial reports,
detailing spending levels/burn rate and cash/ZEC on hand;
* (if the first disbursement in a calendar year) Published a yearly
review of organization performance, along the lines of the Zcash
Foundation's "State of the Foundation" report [#zfnd-state]_.
For the Zcash Foundation, the trust MUST further require:
* No board member may have an interest in the ECC (current board members
with an interest would need to divest of their ECC holdings prior to
the beginning of this dev fund or leave the board);
* Excluding money restricted for ZF Grants, the Foundation's total assets
MUST stay below $100mm (if its assets ever exceeded this amount from a
disbursement, the trust could direct the funds toward an additional
restricted ZF Grants donation).
Additionally, for the ECC, the trust MUST validate the following before
each disbursement:
* (if the first disbursement in a fiscal year) The ECC published yearly
audited financial statements at the same level of detail as a public
company (to mirror the Foundation's Form 990 requirement as 501(c)(3));
* No outside investment was received while they are obligatory recipients
of this dev fund;
* No portion of the dev fund went to dividends, profit-sharing, or
share/equity buybacks while they are obligatory recipients of this dev
fund;
* No dilution of ECC's equity except in the case of options/RSUs for
new/existing employees while they are obligatory recipients of this
dev fund;
* There's no change-of-control (majority control changes) at the ECC
while they are obligatory recipients of this dev fund;
The ECC MUST share necessary information with the trust to ascertain no
violations of the above, but the information itself (i.e. cap table and
detailed financials) SHOULD remain private between the ECC and the
trustees unless there is a violation that is not cured.
What happens in the case of a violation
---------------------------------------
The violating party has 30 days to attempt to cure the violation (if it's
possible). If they cannot, future funds MUST be redirected to ZF Grants via
a restricted donation to the Zcash Foundation. (That is, not usable by either
the Zcash Foundation or ECC, more on that below.)
The ZF Grants portion
---------------------
A portion of the dev fund goes to the Foundation but with the express (and
restricted) purpose of being distributed via ZF Grants (a restriction that
MUST be legally enforced by the trust). The Foundation would continue to
administer ZF Grants and distribute funds, but it SHOULD NOT decide where
those funds go and would not allowed to be recipients of these funds;
instead, the trust MUST demand that the ZF Grants process include broader
input in the manner described below. In the discussions around the various
"third party" proposals, some have suggested a 3-of-5 approach where the ECC
and Zcash Foundation are in the minority; I think that structure would work
well for these funds. It's not the full dev fund so we are limiting the
downside risk of selecting the "wrong" third parties, which also means we
can give those third parties more voice (by making them outnumber the
ECC/Zcash Foundation). The Foundation MAY also chose to fund ZF Grants
*beyond* the restricted donations from the trust, but doing so would be at
their discretion.
Thanks to the discussion on Matt Luongo's proposal there's a good blueprint
for how this group would work. I'm borrowing some comments I made on Matt's
proposal thread [#acityinohio-comment]_ and modifying them to apply to a
ZF Grants-specific Grant Review Committee, rather than the Foundation's
board.
The ZF Grant Review Committee would be compromised of five members, voted on
in the following manner:
* 1 seat for the ECC. Though the appointed member may change, they retain
power to choose the seat for 4 years.
* 1 seat for the Zcash Foundation. Though the appointed member may change,
they retain power to choose the seat for 4 years.
* 2 seats voted on by ZEC holders directly, elected every year. There would
be open elections held by the Foundation similar to the 2018 advisory
process which resulted in Ian and Amber’s election, except using a ZEC
coin-staked vote directly.
* 1 seat held by a technical member, elected every year. This member would
be selected by the combined group (2 coin-staked seats + ZF seat + ECC
seat) with an express focus on ability to evaluate technical proposals.
The group would meet biweekly to make funding decisions, the results of
which will be made public on ZF Grants. Taking a note from Eran Tromer's
recent proposal, the group would have a goal of making at least two
"Large Grants" every year. A "Large Grant" would have an expected scope of
six months and 1/4th to 1/3rd of the total ZF Grants yearly budget, with
the goal of getting more dedicated external teams involved.
Rationale
=========
There are scores of great ideas on the forums, and I took the (subjective,
mind you) best parts of each into a proposal that hopefully meets the
standards of the ECC, the Zcash Foundation, and the broader community.
A word on the enigmatic "third party" floating around
-----------------------------------------------------
With all due respect to the proposers behind some variant of a "2-of-3
multisig" decision-making process for *all* disbursement decisions:
I think this is a bad idea. To quote a previous forum post of mine:
...2-of-3 multisig [is] better if we find the right third party.
That in and of itself requires an additional process/mutual agreement
between the three parties (which is much more difficult than a bilateral
agreement), and as I’ve mentioned before in presentations in the past,
2-of-2 with known entities dedicated to Zcash is better than jumping
straight to 2-of-3 with a third party hastily decided or staying with
1-of-1 entity trademarks and software development processes.
As for why 2-of-2 is still strictly better than 1-of-1: in the case of
cryptocurrency governance, I believe that inaction in the case of
disagreement is a better outcome than one party unilaterally exercising
power.
More to the point, I worry that the "third party" in question is being
idolized into some Platonic ideal, and in reality either the ECC or the
Zcash Foundation would spend a great deal of their time currying favor in
either the process or selection of the party in question in the limited time
between now and that party's selection. Given that the Zcash Foundation is
charged with representing community interests, I'm not sure why another
community-focused representative would really make sense from the ECC's
perspective — they'd be constantly outvoted if interests clashed, so from
a balance of power perspective I'm not sure why the ECC would find that
tenable. And I'm not sure the community would want the "third party" to be
another profit-generating enterprise, like a VC or another startup, which
would tip power another way.
The crux of this proposal still centers around the idea that the Zcash
Foundation and ECC share responsibility for protocol development, which
is now bolstered by the 2-of-2 agreement on the trademark. It assumes and
expects that both continue developing consensus-compatible node software
that interacts with the Zcash network. But it mandates accountability for
disbursement of funds to the ECC/Zcash Foundation, and expands outside
stakeholder input on funds that *wouldn't* be earmarked for the ECC/Zcash
Foundation (similar to Placeholder's earlier version of their proposal and
Matt Luongo's current proposal), while it doesn’t preclude the possibility
of migrating to broader "2-of-3" later on future governance decisions.
Why a trust?
------------
The main reason: reducing complexity creep in consensus code. Rather than try
to incorporate some complex mechanism for dev fund disbursements on-chain, we
can meet the NU4 with the simplest possible code-change and spend more time
ironing out the details of the trust "off-chain." Since both the ECC and the
Zcash Foundation are based in the US, using a trust with well-specified
criteria for disbursements is a reasonable path. This also fits in nicely
with lex-node's proposal [#zip-1007]_ for legal covenants on funding.
Security and Privacy Considerations
===================================
The biggest issue is custody of the funds under the trust's control, but
I suspect this can be managed with a partnership with a custody partner.
There's also the issue that non-public information would need to be verified
and validated by the trust, but I view this as a net positive for the
community ("transparency for organizations, privacy for individuals").
Reference implementation
========================
TBD, but it should be relatively simple to code in both zebra and zcashd.
Issues and further discussion
=============================
* What are the tax implications for setting up the trust?
* Are the amounts reasonable? Should the dev fund be less than 20% in
aggregate?
* Should this or other proposals seek to change the ECC and Zcash
Foundation's board/makeup, or should we keep those organizations running
as they are and sandbox a new process to a specific disbursement of the
dev fund? (This proposal assumes the latter via ZF Grants.)
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zfnd-guidance] `Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. <https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/>`_
.. [#tromer-comment] `Comment on a post “How to hire ECC” in the Zcash Community Forum. Eran Tromer, August 11, 2019. <https://forum.zcashcommunity.com/t/how-to-hire-ecc/34379/55>`_
.. [#restricted-funds] `“What Are Restricted Funds?” Foundation Group, last modified December 7, 2018. <https://www.501c3.org/kb/what-are-restricted-funds/>`_
.. [#zfnd-grants] `ZF Grants — Funding for Zcash ecosystem projects <https://grants.zfnd.org/>`_
.. [#zfnd-state] `The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019. <https://www.zfnd.org/blog/foundation-in-2019/>`_
.. [#acityinohio-comment] `Comment on a post “Decentralizing the Dev Fee” in the Zcash Community Forum. Josh Cincinnati, October 27, 2019. <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252/38>`_
.. [#zip-1007] `ZIP 1007: Enforce Development Fund Commitments with a Legal Charter <zip-1007.rst>`_

201
zip-1011.html Normal file
View File

@ -0,0 +1,201 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1011: Decentralize the Dev Fee</title>
<meta charset="utf-8" />
<script src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1011
Title: Decentralize the Dev Fee
Owner: Matt Luongo &lt;matt@thesis.co&gt;
Status: Draft
Category: Process
Created: 2019-09-27
License: MIT
Discussions-To: &lt;https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252&gt;</pre>
<section id="abstract">
<h2>Abstract</h2>
<p>This proposal describes a structure for Zcash governance, including funding and managing new Zcash development, decentralizing those development efforts, and resolving governance hangups between the Zcash Foundation and the Electric Coin Company.</p>
<p>These goals are accomplished via a 20% dev fee, enacted in NU4 and continuing for one halving period. This fee will fund a diverse group of development teams to ensure Zcash maintains best-in-class research and engineering talent while growing a robust ecosystem, funding the Zcash Foundation with 25% of the dev fee, and a newly established principal developer role with 35% of the dev fee.</p>
</section>
<section id="motivation">
<h2>Motivation</h2>
<section id="who-am-i">
<h3>Who am I?</h3>
<p>My name is Matt Luongo. I'm an entrepreneur who's been full-time in the crypto space since 2014, co-founding Fold, a Bitcoin payments company, and more recently Keep, a private computation startup built on Ethereum. At Keep, we've done some <a href="https://github.com/ethereum/EIPs/pull/2129">work around Zcash</a>, and our parent company, <a href="https://thesis.co">Thesis</a>, is considering investing more heavily in Zcash development for our latest project.</p>
<p>I'm deeply interested in privacy tech. For me, privacy is about consent –consent to share my habits, beliefs, and preferences– and I see privacy as the inevitable next frontier in our pursuit of an economy that respects individual choice.</p>
<p>My perspective is as the founder of a for-profit company focused on building self-sovereign technology who wants to develop on Zcash. We work in this space ideologically, but our work isn't free; attracting and growing talent requires funding.</p>
<p>If you're interested in more on my background, I've introduced myself more <a href="https://forum.zcashcommunity.com/t/introducing-matt-luongo-from-keep/34947">properly on the forum</a>.</p>
</section>
<section id="what-s-this-about">
<h3>What's this about?</h3>
<p>Since Zcon1, I've been looking to fund work to build an Ethereum / Zcash bridge. I've spoken to the ECC, the Zcash Foundation, and a number of early Zcash community members on how best to move forward with this project, and in the process I've learned a lot about how the community works and dev governance has been structured thus far.</p>
<p>Inevitably, I've become interested in the community's proposals for a new dev fee, and thought about how the right structure might support work like ours.</p>
<p>I believe the Zcash community has an opportunity to deploy a new incentive structure that will attract companies like ours to build and improve Zcash, leading to a more resilient network, stronger technology, and wider usage.</p>
</section>
<section id="the-zcash-narrative">
<h3>The Zcash narrative</h3>
<p>We're all here to build a robust, private, decentralized currency. But in the dev fee proposals I've seen so far, the idea of a Zcash narrative that distinguishes it from the competition is absent.</p>
<p>Of the slew of ZIPs addressing Zcash's future, there's only been one strong narrative case — the idea that Zcash exists purely as a hedge against Bitcoin's long-term privacy failure. Put simply, Zcash is "Bitcoin, but private".</p>
<p>Zcash should aim higher. Bitcoin is the only coin that has successfully made a store of value argument, which I like to call "worse is better". Don't upgrade the network –the argument goes– stability is more important than solving today's problems. Bitcoin is chasing the <a href="https://en.wikipedia.org/wiki/Lindy_effect">Lindy effect</a>, where worse is better, and the network becomes stronger every day it survives. That's great for Bitcoin. For the rest of us, though, better is better. Zcash <em>should be better</em>.</p>
<p>Zcash is known for having the best tech in the space, built by one of the best teams in the space. We should lean in to that reputation, nurturing the best research and engineering talent to take Zcash to the next level, and leveraging a Zcash dev fee as a differentiator to build the world's best private medium of exchange.</p>
</section>
<section id="principles-of-cryptocurrency-governance">
<h3>Principles of cryptocurrency governance</h3>
<p>To understand Zcash governance, it's worth reviewing "default" cryptocurrency governance. Most proof-of-work chains today have three major governing roles:</p>
<ol type="1">
<li>Miners validate and secure the chain. They do some work to earn a reward. Miners are the first owners of newly minted coins, and are an integral part of network upgrades.</li>
<li>Users buy, hold, and spend the currency. In networks like Bitcoin, they also run full nodes, strengthening network resilience by decentralizing validation.</li>
<li>Developers maintain clients to power and interact with the network. They typically propose network upgrades.</li>
</ol>
<p>On a chain like Bitcoin, any of these roles can veto a network upgrade.</p>
<ol type="1">
<li>Miners can veto activating a new fork by refusing to build off blocks using new network rules, orphaning a minority effort. They can also attack any fork attempt that doesn't change</li>
<li>Users can veto a fork by refusing to update their full nodes, rejecting blocks as invalid — as demonstrated in the UASF movement successfully countering the SegWit2x attempt to force a Bitcoin hardfork. Users can also vote with their dollars, acting as a fork resolution of last resort via market pressure.</li>
<li>Developers can refuse to update client codebases to follow a fork. While this might not seem like a strong veto, in practice that means any fork will need at least one additional development team, or the agreement of existing client software developers.</li>
</ol>
<p>These roles together form a balance of power that makes contentious forks difficult — any change that a large swath of users disapproves of could split the chain.</p>
</section>
<section id="the-state-of-play">
<h3>The state of play</h3>
<p>In Zcash, the addition of the Electric Coin Company (ECC) and the Zcash Foundation skew this balance.</p>
<p>Both organizations are comprised of Zcash founders, developers, researchers, and privacy proponents who have driven this ecosystem forward and represent its values. Nevertheless, their mode of operation today skews a healthy balance of power in Zcash governance.</p>
<p>The mechanisms of that skew are the Zcash trademark, held jointly by the Foundation and the ECC, and primary client software development, now split between the ECC and the Foundation.</p>
<p>In a disagreement between miners, users, and developers, the Foundation and ECC have the option of enforcing the Zcash trademark, effectively allowing them to choose a winning fork against the will of users, miners, and other developers.</p>
<p>In addition, the Foundation's sole maintenance of the <code>zebrad</code> client allows them to "soft veto" a network upgrade.</p>
<p>Unfortunately, the Foundation and the ECC aren't organized as arms-length entities today.</p>
<p>This situation poses a number of problems for new and existing Zcash users, as well as both entities.</p>
<ul>
<li>The threat of two entangled entities overriding (or being forced to override) the will of users undermines self-sovereignty.</li>
<li>The ECC and Foundation are both put at legal risk. As entangled entities, they're remarkably similar to a single entity when trying to minimize regulatory risk.</li>
</ul>
</section>
<section id="the-crowding-out-problem">
<h3>The "crowding out" problem</h3>
<p>The Zcash ecosystem, as it exists today, leaves little incentive for outside developers to participate.</p>
<p>Zcash development has a high learning curve.</p>
<ul>
<li>The reference client is a fork of the Bitcoin reference implementation, building on a decade of poorly written legacy code.</li>
<li>What Zcash brings to the table involves a greater understanding of applied cryptography than most projects. SNARKs are often still referred to as "moon math", after all.</li>
<li>As the recent network-level attack demonstrates, full-stack privacy is hard.</li>
</ul>
<p>Most outside developers need to see a clear path to longer-term funding before they can commit to the cost of that curve.</p>
<p>Even those developers who already have the expertise to work on this system are frustrated by the lack of longer-term funding. For evidence, look at Parity's exit from Zcash after <code>zebrad</code> development, or Summa's struggles to work on Zcash.</p>
<p>Sustainably attracting talent to Zcash is critical to maintain innovation and build resilience.</p>
</section>
</section>
<section id="requirements">
<h2>Requirements</h2>
<p>The first requirement is a balanced governance structure. Developers should be rewarded, without rewarding governance capture. What's best for the chain and ZEC holders should always come before commercial interests.</p>
<p>The second, and secondary, requirement is funding Zcash development. While the chain shouldn't be run by a commercial entity, it will need to be supported by them.</p>
<p>The third requirement is the support of a more resilient ecosystem by:</p>
<ol type="1">
<li>Ending the "crowding out" problem by paying development teams to work on and for Zcash.</li>
<li>Building a dev fee management structure that's resilient to the loss, capture, or compromise of the Zcash Foundation.</li>
<li>Ensuring the ecosystem can survive the loss, capture, or compromise of the ECC by encouraging developer diversity and strategic input.</li>
</ol>
<p>Finally, avoid introducing unnecessary additional entities into the governance process.</p>
</section>
<section id="non-requirements">
<h2>Non-requirements</h2>
<p>General on-chain governance is outside the scope of this proposal. On-chain governance is an exciting idea -- what if we had an impartial arbiter funding development? My experience with on-chain governance to date, however, leads me to believe it's still a risky direction. Zcash should focus on what it's good at –privacy– and leave proving on-chain governance models to other projects.</p>
<p>While this proposal attempts to outline a long-term structure for Zcash funding and governance, specifying the structure beyond the next 4 years is out of scope. Much will have changed in 4 years. Perhaps this structure will be sufficient; perhaps we'll be battling the Third Crypto War, and need to go back to the drawing table.</p>
</section>
<section id="specification">
<h2>Specification</h2>
<p>The below proposal is an effort to cleanly resolve the problems with Zcash's current governance, while</p>
<ul>
<li>maintaining a balance of power between stakeholders;</li>
<li>removing single points of failure / control;</li>
<li>growing development and usage of Zcash;</li>
<li>and supporting the best interests of miners, users, and developers <em>today</em>.</li>
</ul>
<section id="decentralizing-development">
<h3>Decentralizing development</h3>
<p>A few proposals have suggested the introduction of a mysterious "third entity" to resolve disagreements between the Foundation and the ECC.</p>
<p>I prefer a different approach, refocusing the role of the Foundation and making room for the ECC to work with a robust developer ecosystem.</p>
<p>In this proposal, the Foundation shall support community development through running the forum and events, gathering community sentiment, managing short-term development grants, research and development, and conducting the diligence behind the assignment and disbursement of a development fee. This development fee shall be funded by 20% of the block reward, with as much as half of the fee burned in case of extraordinary growth in the price of ZEC.</p>
<p>The Foundation shall receive 25% of the dev fee. If the volume-weighted average price of ZEC over the month means the foundation would receive greater than $500k that month, the Foundation shall set aside enough ZEC such that their max monthly budget is</p>
<blockquote>
<p>
<span class="math">\(\mathsf{MaxBenefit}(\mathsf{RewardDollarAmount}) = \mathsf{Min}(500000, 500000 * \sqrt{\frac{\mathsf{RewardDollarAmount}}{500000}})\)</span>
</p>
</blockquote>
<p>The excess ZEC should be purpose-restricted to the Foundation grants program, ensuring the funds are earmarked to grow outside community talent and involvement.</p>
<p>Capping the monthly expenses of the Foundation will limit growth, while encouraging fiscal discipline.</p>
<p>The remaining 75% of the dev fee shall be distributed between development teams working to maintain clients.</p>
<ul>
<li>Up to 35% of the total fee shall be reserved for the role of the "principal developer", a developer with assured long-term alignment with the project.</li>
<li>The remaining 40% of the fee, called the "outside development fee", shall be distributed between at least two development teams, chosen semi-annually by the Foundation, coinciding with network upgrades.</li>
</ul>
<p>Prior to each network upgrade, the Foundation shall recommend a list of addresses and a total number of ZEC per block each address is meant to receive from the dev fee. The recommendation will be "ratified" by the miners as the network upgrade activates.</p>
</section>
<section id="the-role-of-dev-fee-recipients">
<h3>The role of dev fee recipients</h3>
<p>Dev fee recipients are distinguished from grant recipients in the scope and timelines of their work, as well as the specificity of direction. The intent is to allow teams to focus on a core competency, while encouraging research and adjacent work.</p>
<p>Dev fee recipients are chosen semi-annually by the Foundation based on their ability to move Zcash forward. Recipients will typically be development teams, though "full stack" teams that can communicate well with the community, expand Zcash usage, and widely share their work should be advantaged.</p>
<p>Recipients shall submit quarterly plans to the community for their efforts, as well as monthly progress updates.</p>
<p>All work funded by the dev fee will be open source, under licenses compatible with the existing Zcash clients.</p>
<p>Though the Foundation shall periodically judge the efficacy of dev fee recipients, deciding on and driving roadmaps for Zcash is the role of dev fee recipients, in partnership with the community. This role is neatly balanced by users running full nodes and miners, either of which can veto a network upgrade.</p>
<p>While dev fee recipients are not required to work exclusively on Zcash, considering the nature of their work, recipients must guarantee they aren't obliged to the interests of competing projects.</p>
</section>
<section id="the-role-of-the-principal-developer">
<h3>The role of the principal developer</h3>
<p>The role of the principal developer is as a "first among equals" amongst the dev fee recipients.</p>
<p>The principal developer shall make a number of guarantees.</p>
<ol type="1">
<li>Zcash shall be their exclusive focus, submitting financials periodically to the Foundation as assurance.</li>
<li>They shall maintain a well-run board and employ a qualified CFO.</li>
<li>In addition to the existing open-source requirements, they shall agree to assign any patents relevant to Zcash to the Foundation.</li>
</ol>
<p>In exchange, the principal developer is granted an indefinite minimum dev fee allocation of 20%, with a maximum allocation of 35% of the total fee, as recommended annually by the Foundation.</p>
<p>The principal developer will have a wide remit to pursue longer-term research relevant to Zcash, though it will submit the same plans required of other recipients. The principal developer will only be recommended for removal by the Foundation in extraordinary circumstances, including reneging on the above guarantees or extreme negligence.</p>
</section>
<section id="minimum-viable-foundation">
<h3>Minimum viable Foundation</h3>
<p>To manage the dev fee and fulfill its community and diligence duties, the Foundation shall maintain a board of 5 independent members. Rather than the structure in the current bylaws, the board will consist of</p>
<ul>
<li>1 seat voted on periodically by ZEC holders directly.</li>
<li>1 seat representing a newly created research advisory board, whose primary role will be technical diligence of potential recipients of the dev fee.</li>
<li>1 seat for a member of the investment community.</li>
<li>2 seats elected by the board, as the board is currently selected according to the bylaws. The board's discretion here means these could be selected via a community election, or via the remaining 3 seats' direct vote.</li>
</ul>
<p>The Foundation requires a professional board. Board member selection should heavily favor candidates with existing formal public or private sector board experience.</p>
<p>Board seats should rotate periodically, while maintaining long enough terms and overlap for consistent governance.</p>
<p>Each board member should bring a unique network and set of skills to bear to increase the impact of the Foundation.</p>
<p>No board members shall have an ongoing commercial interest in any recipients of the dev fee.</p>
<p>Considering their expertise, the Foundation shall deliver a transition plan, including a board election schedule and report on the feasibility of a future coin vote process to determine a board seat.</p>
</section>
<section id="the-ecc-as-the-principal-developer">
<h3>The ECC as the principal developer</h3>
<p>I propose that the ECC be considered as the initial principal developer, receiving an indefinite dev fee allocation in exchange for their exclusive focus on Zcash research and development, and assigning all patents and marks relevant to Zcash to the Foundation.</p>
<p>I believe this arrangement is best for the Zcash ecosystem, and with proper management of funds, should satisfy the ongoing needs of the ECC.</p>
</section>
<section id="the-dev-call">
<h3>The dev call</h3>
<p>The Foundation shall organize a bi-weekly call for all dev fee recipients and other third party developers. The call will be live-streamed for community participation, though the speaking participants will be invite only. At a minimum, a single representative from each dev fee recipient should attend.</p>
<p>The Foundation shall also maintain a simple chat solution for development of the protocol. While the chat logs should be publicly viewable, it need not be open to public participation.</p>
</section>
<section id="moving-forward">
<h3>Moving forward</h3>
<p>I believe this proposal can form the basis for a new way forward for Zcash — a robust, decentralized ecosystem with fair governance. I also hope it can bring together the stakeholders in this discussion, and allow us to get back to why we're all here — to protect the world's financial privacy.</p>
<p>I look forward to feedback on GitHub and the Zcash forum.</p>
</section>
</section>
<section id="disclosures">
<h2>Disclosures</h2>
<p>In the interest of transparency, I'd like to make a few professional disclosures.</p>
<p>I'm the largest shareholder of <a href="https://thesis.co">Thesis</a>, the parent company and studio behind <a href="https://foldapp.com">Fold</a> and <a href="https://keep.network">Keep</a>. Thesis is a for-profit company that might benefit from this proposal as a dev fee recipient. While today I maintain exclusive control of Thesis, the company has taken outside investment in the past.</p>
<p>As far as my financial interest in Zcash, I've held a small amount of ZEC since shortly after launch. I'm in the process of building my personal ZEC position, as well as a position at Thesis.</p>
</section>
<section id="acknowledgements">
<h2>Acknowledgements</h2>
<p>Thanks to my friends and colleagues <a href="https://twitter.com/CReckhow">Carolyn</a>, <a href="https://twitter.com/LauraWallendal">Laura</a>, <a href="https://twitter.com/JoshSRosenblatt">Josh</a>, <a href="https://twitter.com/_prestwich">James</a>, <a href="https://twitter.com/CorbinPon">Corbin</a>, and <a href="https://github.com/shadowfiend">Antonio</a> for early review of the text this proposal.</p>
<p>Thanks to my fellow dev fund ZIP authors, <a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entity-strategic-council-approach/34801">Avichal Garg</a> at Electric Capital, <a href="https://forum.zcashcommunity.com/t/zcash-dev-fund-results-based-financing-equity-proposal-amendment/35052/31">Antoinette Marie</a>, <a href="https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812">Josh Cincinnati, ED</a> at the Zcash Foundation, <a href="https://forum.zcashcommunity.com/t/asp-founders-reward-positioning-support-for-avichal-garg-s-proposal-with-amendments/35184">Jacob Phillips</a> at Autonomous Partners, <a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-directed-dev-fund-was-20-to-any-combination-of-ecc-zfnd-parity-or-burn/33864">Andrew Miller</a>, <a href="https://twitter.com/cburniske">Chris Burniske</a>, <a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fund-to-ecc-zfnd-major-grants/35364/15">Eran Tromer</a>, and the fellows at <a href="https://forum.zcashcommunity.com/t/blocktown-development-fund-proposal-10-to-a-2-of-3-multisig-with-community-involved-third-entity/34782">Blocktown</a>, each of whose ideas influenced this proposal. And of course, thanks to <a href="https://github.com/sonyamann">Sonya Mann</a> and the Foundation for coordinating discussions around these different proposals.</p>
<p>Outside ongoing discussions in the forum and with other ZIP authors, I've spoken with a number of prominent community members while developing this proposal, though none were provided early access to the text of the proposal. I appreciated the thoughtful discussions with <a href="https://twitter.com/acityinohio">Josh Cincinnati</a>, <a href="https://twitter.com/zooko">Zooko Wilcox</a>, <a href="https://twitter.com/jswihart">Josh Swihart</a>, <a href="https://twitter.com/secparam">Ian Miers</a>, and others.</p>
</section>
</section>
</body>
</html>

467
zip-1011.rst Normal file
View File

@ -0,0 +1,467 @@
::
ZIP: 1011
Title: Decentralize the Dev Fee
Owner: Matt Luongo <matt@thesis.co>
Status: Draft
Category: Process
Created: 2019-09-27
License: MIT
Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252>
Abstract
========
This proposal describes a structure for Zcash governance, including funding
and managing new Zcash development, decentralizing those development efforts,
and resolving governance hangups between the Zcash Foundation and the Electric
Coin Company.
These goals are accomplished via a 20% dev fee, enacted in NU4 and continuing
for one halving period. This fee will fund a diverse group of development
teams to ensure Zcash maintains best-in-class research and engineering talent
while growing a robust ecosystem, funding the Zcash Foundation with 25% of
the dev fee, and a newly established principal developer role with 35% of the
dev fee.
Motivation
==========
Who am I?
---------
My name is Matt Luongo. I'm an entrepreneur who's been full-time in the crypto
space since 2014, co-founding Fold, a Bitcoin payments company, and more
recently Keep, a private computation startup built on Ethereum. At Keep, we've
done some `work around Zcash <https://github.com/ethereum/EIPs/pull/2129>`_,
and our parent company, `Thesis`_, is considering investing more heavily in
Zcash development for our latest project.
I'm deeply interested in privacy tech. For me, privacy is about consent
–consent to share my habits, beliefs, and preferences– and I see privacy as
the inevitable next frontier in our pursuit of an economy that respects
individual choice.
My perspective is as the founder of a for-profit company focused on building
self-sovereign technology who wants to develop on Zcash. We work in this space
ideologically, but our work isn't free; attracting and growing talent requires
funding.
If you're interested in more on my background, I've introduced myself more
`properly on the forum
<https://forum.zcashcommunity.com/t/introducing-matt-luongo-from-keep/34947>`_.
What's this about?
------------------
Since Zcon1, I've been looking to fund work to build an Ethereum / Zcash
bridge. I've spoken to the ECC, the Zcash Foundation, and a number of early
Zcash community members on how best to move forward with this project, and in
the process I've learned a lot about how the community works and dev
governance has been structured thus far.
Inevitably, I've become interested in the community's proposals for a new dev
fee, and thought about how the right structure might support work like ours.
I believe the Zcash community has an opportunity to deploy a new incentive
structure that will attract companies like ours to build and improve Zcash,
leading to a more resilient network, stronger technology, and wider usage.
The Zcash narrative
-------------------
We're all here to build a robust, private, decentralized currency. But in the
dev fee proposals I've seen so far, the idea of a Zcash narrative that
distinguishes it from the competition is absent.
Of the slew of ZIPs addressing Zcash's future, there's only been one strong
narrative case — the idea that Zcash exists purely as a hedge against Bitcoin's
long-term privacy failure. Put simply, Zcash is "Bitcoin, but private".
Zcash should aim higher. Bitcoin is the only coin that has successfully made a
store of value argument, which I like to call "worse is better". Don't upgrade
the network –the argument goes– stability is more important than solving
today's problems. Bitcoin is chasing the `Lindy effect
<https://en.wikipedia.org/wiki/Lindy_effect>`_, where worse is better, and the
network becomes stronger every day it survives. That's great for Bitcoin.
For the rest of us, though, better is better. Zcash *should be better*.
Zcash is known for having the best tech in the space, built by one of the best
teams in the space. We should lean in to that reputation, nurturing the best
research and engineering talent to take Zcash to the next level, and
leveraging a Zcash dev fee as a differentiator to build the world's best
private medium of exchange.
Principles of cryptocurrency governance
---------------------------------------
To understand Zcash governance, it's worth reviewing "default" cryptocurrency
governance. Most proof-of-work chains today have three major governing roles:
1. Miners validate and secure the chain. They do some work to earn a reward.
Miners are the first owners of newly minted coins, and are an integral part
of network upgrades.
2. Users buy, hold, and spend the currency. In networks like Bitcoin, they
also run full nodes, strengthening network resilience by decentralizing
validation.
3. Developers maintain clients to power and interact with the network. They
typically propose network upgrades.
On a chain like Bitcoin, any of these roles can veto a network upgrade.
1. Miners can veto activating a new fork by refusing to build off blocks using
new network rules, orphaning a minority effort. They can also attack any
fork attempt that doesn't change
2. Users can veto a fork by refusing to update their full nodes, rejecting
blocks as invalid — as demonstrated in the UASF movement successfully
countering the SegWit2x attempt to force a Bitcoin hardfork. Users can also
vote with their dollars, acting as a fork resolution of last resort via
market pressure.
3. Developers can refuse to update client codebases to follow a fork. While
this might not seem like a strong veto, in practice that means any fork
will need at least one additional development team, or the agreement of
existing client software developers.
These roles together form a balance of power that makes contentious forks
difficult — any change that a large swath of users disapproves of could split
the chain.
The state of play
-----------------
In Zcash, the addition of the Electric Coin Company (ECC) and the Zcash
Foundation skew this balance.
Both organizations are comprised of Zcash founders, developers, researchers,
and privacy proponents who have driven this ecosystem forward and represent
its values. Nevertheless, their mode of operation today skews a healthy
balance of power in Zcash governance.
The mechanisms of that skew are the Zcash trademark, held jointly by the
Foundation and the ECC, and primary client software development, now split
between the ECC and the Foundation.
In a disagreement between miners, users, and developers, the Foundation and
ECC have the option of enforcing the Zcash trademark, effectively allowing
them to choose a winning fork against the will of users, miners, and other
developers.
In addition, the Foundation's sole maintenance of the ``zebrad`` client
allows them to "soft veto" a network upgrade.
Unfortunately, the Foundation and the ECC aren't organized as arms-length
entities today.
This situation poses a number of problems for new and existing Zcash users,
as well as both entities.
* The threat of two entangled entities overriding (or being forced to
override) the will of users undermines self-sovereignty.
* The ECC and Foundation are both put at legal risk. As entangled entities,
they're remarkably similar to a single entity when trying to minimize
regulatory risk.
The "crowding out" problem
--------------------------
The Zcash ecosystem, as it exists today, leaves little incentive for outside
developers to participate.
Zcash development has a high learning curve.
* The reference client is a fork of the Bitcoin reference implementation,
building on a decade of poorly written legacy code.
* What Zcash brings to the table involves a greater understanding of applied
cryptography than most projects. SNARKs are often still referred to as
"moon math", after all.
* As the recent network-level attack demonstrates, full-stack privacy is hard.
Most outside developers need to see a clear path to longer-term funding before
they can commit to the cost of that curve.
Even those developers who already have the expertise to work on this system
are frustrated by the lack of longer-term funding. For evidence, look at
Parity's exit from Zcash after ``zebrad`` development, or Summa's struggles
to work on Zcash.
Sustainably attracting talent to Zcash is critical to maintain innovation and
build resilience.
Requirements
============
The first requirement is a balanced governance structure. Developers should be
rewarded, without rewarding governance capture. What's best for the chain and
ZEC holders should always come before commercial interests.
The second, and secondary, requirement is funding Zcash development. While the
chain shouldn't be run by a commercial entity, it will need to be supported by
them.
The third requirement is the support of a more resilient ecosystem by:
1. Ending the "crowding out" problem by paying development teams to work on
and for Zcash.
2. Building a dev fee management structure that's resilient to the loss,
capture, or compromise of the Zcash Foundation.
3. Ensuring the ecosystem can survive the loss, capture, or compromise of the
ECC by encouraging developer diversity and strategic input.
Finally, avoid introducing unnecessary additional entities into the governance
process.
Non-requirements
================
General on-chain governance is outside the scope of this proposal. On-chain
governance is an exciting idea -- what if we had an impartial arbiter funding
development? My experience with on-chain governance to date, however, leads
me to believe it's still a risky direction. Zcash should focus on what it's
good at –privacy– and leave proving on-chain governance models to other
projects.
While this proposal attempts to outline a long-term structure for Zcash
funding and governance, specifying the structure beyond the next 4 years is
out of scope. Much will have changed in 4 years. Perhaps this structure will
be sufficient; perhaps we'll be battling the Third Crypto War, and need to go
back to the drawing table.
Specification
=============
The below proposal is an effort to cleanly resolve the problems with Zcash's
current governance, while
* maintaining a balance of power between stakeholders;
* removing single points of failure / control;
* growing development and usage of Zcash;
* and supporting the best interests of miners, users, and developers *today*.
Decentralizing development
--------------------------
A few proposals have suggested the introduction of a mysterious "third entity"
to resolve disagreements between the Foundation and the ECC.
I prefer a different approach, refocusing the role of the Foundation and
making room for the ECC to work with a robust developer ecosystem.
In this proposal, the Foundation shall support community development through
running the forum and events, gathering community sentiment, managing
short-term development grants, research and development, and conducting the
diligence behind the assignment and disbursement of a development fee. This
development fee shall be funded by 20% of the block reward, with as much as
half of the fee burned in case of extraordinary growth in the price of ZEC.
The Foundation shall receive 25% of the dev fee. If the volume-weighted
average price of ZEC over the month means the foundation would receive greater
than $500k that month, the Foundation shall set aside enough ZEC such that
their max monthly budget is
:math:`\mathsf{MaxBenefit}(\mathsf{RewardDollarAmount}) = \mathsf{Min}(500000, 500000 * \sqrt{\frac{\mathsf{RewardDollarAmount}}{500000}})`
The excess ZEC should be purpose-restricted to the Foundation grants program,
ensuring the funds are earmarked to grow outside community talent and
involvement.
Capping the monthly expenses of the Foundation will limit growth, while
encouraging fiscal discipline.
The remaining 75% of the dev fee shall be distributed between development
teams working to maintain clients.
* Up to 35% of the total fee shall be reserved for the role of the "principal
developer", a developer with assured long-term alignment with the project.
* The remaining 40% of the fee, called the "outside development fee", shall
be distributed between at least two development teams, chosen semi-annually
by the Foundation, coinciding with network upgrades.
Prior to each network upgrade, the Foundation shall recommend a list of
addresses and a total number of ZEC per block each address is meant to receive
from the dev fee. The recommendation will be "ratified" by the miners as the
network upgrade activates.
The role of dev fee recipients
------------------------------
Dev fee recipients are distinguished from grant recipients in the scope and
timelines of their work, as well as the specificity of direction. The intent
is to allow teams to focus on a core competency, while encouraging research
and adjacent work.
Dev fee recipients are chosen semi-annually by the Foundation based on their
ability to move Zcash forward. Recipients will typically be development teams,
though "full stack" teams that can communicate well with the community, expand
Zcash usage, and widely share their work should be advantaged.
Recipients shall submit quarterly plans to the community for their efforts, as
well as monthly progress updates.
All work funded by the dev fee will be open source, under licenses compatible
with the existing Zcash clients.
Though the Foundation shall periodically judge the efficacy of dev fee
recipients, deciding on and driving roadmaps for Zcash is the role of dev fee
recipients, in partnership with the community. This role is neatly balanced
by users running full nodes and miners, either of which can veto a network
upgrade.
While dev fee recipients are not required to work exclusively on Zcash,
considering the nature of their work, recipients must guarantee they aren't
obliged to the interests of competing projects.
The role of the principal developer
-----------------------------------
The role of the principal developer is as a "first among equals" amongst the
dev fee recipients.
The principal developer shall make a number of guarantees.
1. Zcash shall be their exclusive focus, submitting financials periodically to
the Foundation as assurance.
2. They shall maintain a well-run board and employ a qualified CFO.
3. In addition to the existing open-source requirements, they shall agree to
assign any patents relevant to Zcash to the Foundation.
In exchange, the principal developer is granted an indefinite minimum dev fee
allocation of 20%, with a maximum allocation of 35% of the total fee, as
recommended annually by the Foundation.
The principal developer will have a wide remit to pursue longer-term research
relevant to Zcash, though it will submit the same plans required of other
recipients. The principal developer will only be recommended for removal by
the Foundation in extraordinary circumstances, including reneging on the above
guarantees or extreme negligence.
Minimum viable Foundation
-------------------------
To manage the dev fee and fulfill its community and diligence duties, the
Foundation shall maintain a board of 5 independent members. Rather than the
structure in the current bylaws, the board will consist of
* 1 seat voted on periodically by ZEC holders directly.
* 1 seat representing a newly created research advisory board, whose primary
role will be technical diligence of potential recipients of the dev fee.
* 1 seat for a member of the investment community.
* 2 seats elected by the board, as the board is currently selected according
to the bylaws. The board's discretion here means these could be selected via
a community election, or via the remaining 3 seats' direct vote.
The Foundation requires a professional board. Board member selection should
heavily favor candidates with existing formal public or private sector board
experience.
Board seats should rotate periodically, while maintaining long enough terms
and overlap for consistent governance.
Each board member should bring a unique network and set of skills to bear to
increase the impact of the Foundation.
No board members shall have an ongoing commercial interest in any recipients
of the dev fee.
Considering their expertise, the Foundation shall deliver a transition plan,
including a board election schedule and report on the feasibility of a future
coin vote process to determine a board seat.
The ECC as the principal developer
----------------------------------
I propose that the ECC be considered as the initial principal developer,
receiving an indefinite dev fee allocation in exchange for their exclusive
focus on Zcash research and development, and assigning all patents and marks
relevant to Zcash to the Foundation.
I believe this arrangement is best for the Zcash ecosystem, and with proper
management of funds, should satisfy the ongoing needs of the ECC.
The dev call
------------
The Foundation shall organize a bi-weekly call for all dev fee recipients and
other third party developers. The call will be live-streamed for community
participation, though the speaking participants will be invite only. At a
minimum, a single representative from each dev fee recipient should attend.
The Foundation shall also maintain a simple chat solution for development of
the protocol. While the chat logs should be publicly viewable, it need not be
open to public participation.
Moving forward
--------------
I believe this proposal can form the basis for a new way forward for Zcash —
a robust, decentralized ecosystem with fair governance. I also hope it can
bring together the stakeholders in this discussion, and allow us to get back
to why we're all here — to protect the world's financial privacy.
I look forward to feedback on GitHub and the Zcash forum.
Disclosures
===========
In the interest of transparency, I'd like to make a few professional
disclosures.
I'm the largest shareholder of Thesis_, the parent company and studio behind
Fold_ and Keep_. Thesis is a for-profit company that might benefit from this
proposal as a dev fee recipient. While today I maintain exclusive control of
Thesis, the company has taken outside investment in the past.
As far as my financial interest in Zcash, I've held a small amount of ZEC
since shortly after launch. I'm in the process of building my personal ZEC
position, as well as a position at Thesis.
.. _Thesis: https://thesis.co
.. _Fold: https://foldapp.com
.. _Keep: https://keep.network
Acknowledgements
================
Thanks to my friends and colleagues Carolyn_, Laura_, Josh_, James_, Corbin_,
and Antonio_ for early review of the text this proposal.
.. _Carolyn: https://twitter.com/CReckhow
.. _Laura: https://twitter.com/LauraWallendal
.. _Josh: https://twitter.com/JoshSRosenblatt
.. _James: https://twitter.com/_prestwich
.. _Corbin: https://twitter.com/CorbinPon
.. _Antonio: https://github.com/shadowfiend
Thanks to my fellow dev fund ZIP authors, `Avichal Garg`_ at Electric Capital,
`Antoinette Marie`_, `Josh Cincinnati, ED`_ at the Zcash Foundation,
`Jacob Phillips`_ at Autonomous Partners, `Andrew Miller`_, `Chris Burniske`_,
`Eran Tromer`_, and the fellows at `Blocktown`_, each of whose ideas
influenced this proposal. And of course, thanks to `Sonya Mann`_ and the
Foundation for coordinating discussions around these different proposals.
.. _Avichal Garg: https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entity-strategic-council-approach/34801
.. _Antoinette Marie: https://forum.zcashcommunity.com/t/zcash-dev-fund-results-based-financing-equity-proposal-amendment/35052/31
.. _Josh Cincinnati, ED: https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812
.. _Jacob Phillips: https://forum.zcashcommunity.com/t/asp-founders-reward-positioning-support-for-avichal-garg-s-proposal-with-amendments/35184
.. _Andrew Miller: https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-directed-dev-fund-was-20-to-any-combination-of-ecc-zfnd-parity-or-burn/33864
.. _Blocktown: https://forum.zcashcommunity.com/t/blocktown-development-fund-proposal-10-to-a-2-of-3-multisig-with-community-involved-third-entity/34782
.. _Chris Burniske: https://twitter.com/cburniske
.. _Eran Tromer: https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fund-to-ecc-zfnd-major-grants/35364/15
.. _Sonya Mann: https://github.com/sonyamann
Outside ongoing discussions in the forum and with other ZIP authors, I've
spoken with a number of prominent community members while developing this
proposal, though none were provided early access to the text of the proposal.
I appreciated the thoughtful discussions with `Josh Cincinnati`_,
`Zooko Wilcox`_, `Josh Swihart`_, `Ian Miers`_, and others.
.. _Josh Cincinnati: https://twitter.com/acityinohio
.. _Zooko Wilcox: https://twitter.com/zooko
.. _Josh Swihart: https://twitter.com/jswihart
.. _Ian Miers: https://twitter.com/secparam

89
zip-1013.html Normal file
View File

@ -0,0 +1,89 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1013: Keep It Simple, Zcashers: 10% to ECC, 10% to ZF</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1013
Title: Keep It Simple, Zcashers: 10% to ECC, 10% to ZF
Owners: Gordon Mohr (@gojomo on relevant forums)
Status: Draft
Category: Consensus / Process
Created: 2019-11-14
License: Public Domain
Discussions-To: &lt;https://forum.zcashcommunity.com/t/zip-keep-it-simple-zcashers-kisz-10-to-ecc-10-to-zfnd/35425&gt;</pre>
<section id="terminology">
<h2>Terminology</h2>
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">1</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>ECC</dt>
<dd>Electric Coin Company, a US-based limited-liability corporation.</dd>
<dt>ZF</dt>
<dd>Zcash Foundation, a US-based non-profit corporation.</dd>
<dt>Halvening</dt>
<dd>a regularly-scheduled discontinuity where the rate of ZEC issuance halves, expected first in roughly October 2020 then next in roughly October 2024.</dd>
</dl>
</section>
<section id="abstract">
<h2>Abstract</h2>
<p>This ZIP proposes:</p>
<p>After the 1st Zcash Halvening, when the "Founders’ Reward" system- bootstrapping protocol-based development funding expires, continue to direct 20% of new ZEC issuance to development-related activities for ongoing research, development, innovation, and maintenance of Zcash.</p>
<p>Assign half of such funds to the ECC, and half to the ZF. Continue this allocation until the 2nd Halvening.</p>
</section>
<section id="motivation">
<h2>Motivation</h2>
<p>There have been many proposals for potential allocations of Zcash block rewards (ZEC inflation) after the 1st Halvening. Many cluster around similar broad parameters:</p>
<ul>
<li>20% of block rewards for continuing development efforts;</li>
<li>provided to some combination of the Electric Coin Company (ECC), Zcash Foundation (ZF), and other named or to-be-determined entities;</li>
<li>conditioned on certain new allocation formulas or management practices, often involving novel entities, personnel, and feedback/deliberation processes.</li>
</ul>
<p>However, no existing ZIPs explicitly propose the most simple variation on this theme - one that maintains maximal continuity with prior practice. This 'Keep It Simple, Zcashers' ZIP aims to fill that gap.</p>
</section>
<section id="requirements">
<h2>Requirements</h2>
<p>This proposal intends to be easy to describe, understand, and implement.</p>
</section>
<section id="non-requirements">
<h2>Non-requirements</h2>
<p>This proposal does not seek to propose any particular course of action past the 2nd Halvening.</p>
</section>
<section id="specification">
<h2>Specification</h2>
<p>To implement this ZIP, the Zcash protocol and compatible software MUST:</p>
<ul>
<li>maintain a 20% allotment of new ZEC issuance to development activities through to the 2nd Halvening event (expected around October 2024);</li>
<li>formalize a 50-50 relative allocation between the ECC and ZF;</li>
<li>deliver these ZEC to addresses provided by the recipients, in a manner analogous to the original "Founders’ Reward" consensus-encoded block rewards, or any other technically- and/or legally- preferred method agreed to by the ECC &amp; ZF.</li>
</ul>
<p>This proposal specifically refrains from adding any new conditions or procedural formalities, technical or legal, on the delivery of development funds.</p>
<p>There is only the expectation that these recipients SHOULD continue the stated missions, practices of transparency, and responsiveness to community input that they have demonstrated thus far.</p>
</section>
<section id="discussion">
<h2>Discussion</h2>
<p>This proposal primarily differs from similar proposals in two ways: (1) it places no new comditions/processes on the disbursement of ZEC development funds; (2) it specifies a fixed, 50-50 division-of-funds between the ECC and ZF.</p>
<p>These differences are motivated by a desire for simplicity and continuity. This allocation can be implemented technically without novel institutions, processes, or legal agreements.</p>
<p>Rather than relying on lists-of-conditions with underspecified enforcement or dispute-resolution mechanisms, the adequate performance of fund recipients is expected due to:</p>
<ul>
<li>aligned incentives, especially the fact that the value of all funds received over 4 years depends completely on the continued health &amp; growth of the Zcash ecosystem;</li>
<li>proven records of dedication to the Zcash project, and effective efforts on related projects, by receipient entities &amp; personnel – even in the absence of formalized funding conditions.</li>
</ul>
<p>From original "Founders’ Reward"-era development-funds, roughly 15% has been directed to the ZF. (Or, about 3 points of the full 20 points of bootstrap- funds.) However, from its later start, the ZF has recently grown its technical, grantmaking, and organizational capabilities, and wide sentiment in the Zcash community, ECC, and ZF desires the ZF grow to a role of equivalent or greater importance as the ECC for long-term Zcash evolution. Thus this proposal specifies a 50:50 split of future development funds, rather than continuing any prior proportions.</p>
</section>
<section id="references">
<h2>References</h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

135
zip-1013.rst Normal file
View File

@ -0,0 +1,135 @@
::
ZIP: 1013
Title: Keep It Simple, Zcashers: 10% to ECC, 10% to ZF
Owners: Gordon Mohr (@gojomo on relevant forums)
Status: Draft
Category: Consensus / Process
Created: 2019-11-14
License: Public Domain
Discussions-To: <https://forum.zcashcommunity.com/t/zip-keep-it-simple-zcashers-kisz-10-to-ecc-10-to-zfnd/35425>
Terminology
===========
The key words "MUST" and "SHOULD" in this document are to be interpreted as
described in RFC 2119. [#RFC2119]_
The terms below are to be interpreted as follows:
ECC
Electric Coin Company, a US-based limited-liability corporation.
ZF
Zcash Foundation, a US-based non-profit corporation.
Halvening
a regularly-scheduled discontinuity where the rate of ZEC issuance halves,
expected first in roughly October 2020 then next in roughly October 2024.
Abstract
========
This ZIP proposes:
After the 1st Zcash Halvening, when the "Founders’ Reward" system-
bootstrapping protocol-based development funding expires, continue to
direct 20% of new ZEC issuance to development-related activities for ongoing
research, development, innovation, and maintenance of Zcash.
Assign half of such funds to the ECC, and half to the ZF. Continue this
allocation until the 2nd Halvening.
Motivation
==========
There have been many proposals for potential allocations of Zcash block
rewards (ZEC inflation) after the 1st Halvening. Many cluster around similar
broad parameters:
* 20% of block rewards for continuing development efforts;
* provided to some combination of the Electric Coin Company (ECC),
Zcash Foundation (ZF), and other named or to-be-determined entities;
* conditioned on certain new allocation formulas or management practices,
often involving novel entities, personnel, and feedback/deliberation
processes.
However, no existing ZIPs explicitly propose the most simple variation
on this theme - one that maintains maximal continuity with prior practice.
This 'Keep It Simple, Zcashers' ZIP aims to fill that gap.
Requirements
============
This proposal intends to be easy to describe, understand, and implement.
Non-requirements
================
This proposal does not seek to propose any particular course of action
past the 2nd Halvening.
Specification
=============
To implement this ZIP, the Zcash protocol and compatible software MUST:
* maintain a 20% allotment of new ZEC issuance to development activities
through to the 2nd Halvening event (expected around October 2024);
* formalize a 50-50 relative allocation between the ECC and ZF;
* deliver these ZEC to addresses provided by the recipients, in a manner
analogous to the original "Founders’ Reward" consensus-encoded block
rewards, or any other technically- and/or legally- preferred method
agreed to by the ECC & ZF.
This proposal specifically refrains from adding any new conditions or
procedural formalities, technical or legal, on the delivery of development
funds.
There is only the expectation that these recipients SHOULD continue the
stated missions, practices of transparency, and responsiveness to community
input that they have demonstrated thus far.
Discussion
==========
This proposal primarily differs from similar proposals in two ways: (1) it
places no new comditions/processes on the disbursement of ZEC development
funds; (2) it specifies a fixed, 50-50 division-of-funds between the ECC and
ZF.
These differences are motivated by a desire for simplicity and continuity.
This allocation can be implemented technically without novel institutions,
processes, or legal agreements.
Rather than relying on lists-of-conditions with underspecified enforcement or
dispute-resolution mechanisms, the adequate performance of fund recipients is
expected due to:
* aligned incentives, especially the fact that the value of all funds received
over 4 years depends completely on the continued health & growth of the Zcash
ecosystem;
* proven records of dedication to the Zcash project, and effective efforts on
related projects, by receipient entities & personnel – even in the absence
of formalized funding conditions.
From original "Founders’ Reward"-era development-funds, roughly 15% has been
directed to the ZF. (Or, about 3 points of the full 20 points of bootstrap-
funds.) However, from its later start, the ZF has recently grown its
technical, grantmaking, and organizational capabilities, and wide sentiment in
the Zcash community, ECC, and ZF desires the ZF grow to a role of equivalent
or greater importance as the ECC for long-term Zcash evolution. Thus this
proposal specifies a 50:50 split of future development funds, rather than
continuing any prior proportions.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_

4
zip-guide.html
View File

@ -97,7 +97,7 @@ sudo pip install rst2html5</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Zcash Protocol Specification, Version {...} or later [Overwinter+Sapling+Blossom]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version {...} or later [Overwinter+Sapling+Blossom]</a></td>
</tr>
</tbody>
</table>
@ -105,7 +105,7 @@ sudo pip install rst2html5</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="https://github.com/zcash/zips/blob/master/zip-xxxx.rst">ZIP xxxx: Title</a></td>
<td><a href="zip-xxxx">ZIP xxxx: Title</a></td>
</tr>
</tbody>
</table>

4
zip-guide.rst
View File

@ -138,5 +138,5 @@ References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#protocol] `Zcash Protocol Specification, Version {...} or later [Overwinter+Sapling+Blossom] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#zip-xxxx] `ZIP xxxx: Title <https://github.com/zcash/zips/blob/master/zip-xxxx.rst>`_
.. [#protocol] `Zcash Protocol Specification, Version {...} or later [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_
.. [#zip-xxxx] `ZIP xxxx: Title <zip-xxxx.rst>`_