forked from ZcashFoundation/zips
-
Notifications
You must be signed in to change notification settings - Fork 1
/
zip-1004.html
148 lines (148 loc) · 13.1 KB
/
zip-1004.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1004: Miner-Directed Dev Fund</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 1004
Title: Miner-Directed Dev Fund
Owner: Andrew Miller (@amiller on zcash forums)
Status: Obsolete
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></pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>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><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></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><span class="section-heading">Out of Scope for this proposal</span><span class="section-anchor"> <a href="#out-of-scope-for-this-proposal"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></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><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></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 id="id2" class="footnote_reference" href="#amiller-notes">2</a></p>
<p>Unlike most other development fund proposals, this proposal is distinct in providing a fine-grained “opt-in” <a id="id3" class="footnote_reference" href="#acityinohio-comment">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><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></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><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></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><span class="section-heading">Examples</span><span class="section-anchor"> <a href="#examples"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></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 id="id4" class="footnote_reference" href="#zip-0208">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><span class="section-heading">Issues and Further Discussion</span><span class="section-anchor"> <a href="#issues-and-further-discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></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 id="id5" class="footnote_reference" href="#blocktown-summary">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><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</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><span class="section-heading">Change Log</span><span class="section-anchor"> <a href="#change-log"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></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>