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

ZIP 1004: Editing to regularize all the dev fund ZIPs. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2019-11-22 15:25:57 +00:00
parent 0651307139
commit 331098ae10
5 changed files with 354 additions and 106 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
README.rst
View File

@ -85,6 +85,7 @@ Index of ZIPs
<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>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>

106
drafts/miner-directed-devfund.rst
View File

@ -1,106 +0,0 @@
::
ZIP: unassigned.
Title: Miner Directed Dev Fund
Owner: unassigned
Author: Andrew Miller (@amiller on zcash forums)
Advocates: Andrew Miller
Category: Protocol
Created: 2019-06-19
ZIP Status: Draft
License: public domain
Originally posted and discussed `on the Zcash Community Forum <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
===========
`RFC2119 <https://tools.ietf.org/html/rfc2119>`__ refrences will be in CAPS.
**The key words include "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"**
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 dev fund
- MR% - Miner Reward Percentage, the portion of newly minted ZEC in each block given to miners (so that DF% + MR% = 100%).
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 dev fund, or how developers should appeal to miners to do so.
Other dev 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.
Abstract
========
This proposal reserves a portion (20%) of the newly minted coins in each block for the dev 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.
Motivation
==========
Like most dev 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.[2]
Unlike most other dev fund proposals, this proposal is distinct in providing a fine-grained “opt-in” [1] feature, since miners have the choice to provide a small amount of dev 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 dev 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 dev 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., ECC, Zfnd, Parity, or others), represented in the code 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 2nd halvening, 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 ECC and DF%/2 to Zfnd)
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 t-addresses of eligible developers, and $Miner is the address of the mining pool mining this block. Assume the total newly minted coins are 6.25 ZEC per block during the 2nd halvening period, and that DF%=20%, MR%=80%.
**Example 1: Split equally between two developers**
The transaction outputs of the coinbase transaction are as follows:
- 5.0 ZEC to $Miner
- 0.625 ZEC to $Dev1
- 0.625 ZEC to $Dev2
**Example 2: Opt-out of the dev fund**
The transaction outputs of the coinbase transaction are as follows:
- 5.0 ZEC to $Miner
Issues & 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 dev fund to DeveloperX, but only if they promise to keep just 5% and pass 15% back to the mining pool.”
- Blocking the dev fund out of greed.
This proposal modifies the terms of what some may consider a social contract: Given the original code in Zcash implementations prior to NU5, by the end of the issuance schedule when all 21M 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 according to the original minting schedule as implemented in Zcashd prior to NU5.
- Several others, notably the Blocktown Capital proposal, have suggested that a 20% dev fund would set a precedent for a perpetual 20% dev fund [3]. 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 dev fund ending in 2024.
References
==========
- [1] The future of Zcash in the year 2020 2 acityinohio
- [2] Notes on reaching agreement about a potential Zcash dev fund - amiller
- [3] Executive Summary: Blocktown Proposal for Zcash 2020 Network Upgrade
**Changelog:**
- 2019-06-19 initial post
- 2019-08-28 update to be more like a zip draft
renamed to Miner Directed Dev Fund (MDDF)
removed references to “Burn”, instead opt-out is in terms of coins never being minted in the first place
- 2019-08-29 address informal preZIP feedback
add example, requirements, fix incomplete sentence about default allocations
- 2019-09-15 move to github

1
index.html
View File

@ -85,6 +85,7 @@
<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>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>

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