From 331098ae10e472e063792da0351e23e4ddce80a7 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 22 Nov 2019 15:25:57 +0000 Subject: [PATCH] ZIP 1004: Editing to regularize all the dev fund ZIPs. Signed-off-by: Daira Hopwood --- README.rst | 1 + drafts/miner-directed-devfund.rst | 106 ---------------- index.html | 1 + zip-1004.html | 158 ++++++++++++++++++++++++ zip-1004.rst | 194 ++++++++++++++++++++++++++++++ 5 files changed, 354 insertions(+), 106 deletions(-) delete mode 100644 drafts/miner-directed-devfund.rst create mode 100644 zip-1004.html create mode 100644 zip-1004.rst diff --git a/README.rst b/README.rst index 9b82adc3..061c0ec2 100644 --- a/README.rst +++ b/README.rst @@ -85,6 +85,7 @@ Index of ZIPs 1001 Keep the Block Distribution as Initially Defined — 90% to Miners Draft 1002 Opt-in Donation Feature Draft 1003 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate Draft + 1004 Miner-Directed Dev Fund Draft 1006 Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity Draft 1007 Enforce Development Fund Commitments with a Legal Charter Draft 1008 Fund ECC for Two More Years Draft diff --git a/drafts/miner-directed-devfund.rst b/drafts/miner-directed-devfund.rst deleted file mode 100644 index bf467962..00000000 --- a/drafts/miner-directed-devfund.rst +++ /dev/null @@ -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 `__. - - -Terminology -=========== - -`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 diff --git a/index.html b/index.html index 6064bbbe..ac62cf84 100644 --- a/index.html +++ b/index.html @@ -85,6 +85,7 @@ 1001 Keep the Block Distribution as Initially Defined — 90% to Miners Draft 1002 Opt-in Donation Feature Draft 1003 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate Draft + 1004 Miner-Directed Dev Fund Draft 1006 Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity Draft 1007 Enforce Development Fund Commitments with a Legal Charter Draft 1008 Fund ECC for Two More Years Draft diff --git a/zip-1004.html b/zip-1004.html new file mode 100644 index 00000000..dad2e93a --- /dev/null +++ b/zip-1004.html @@ -0,0 +1,158 @@ + + + + ZIP 1004: Miner-Directed Dev Fund + + + +
+ 
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. 1

+

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. 2

+

Unlike most other development fund proposals, this proposal is distinct in providing a fine-grained “opt-in” 3 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 5), 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 4, 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

+ + + + + + + +
1Key words for use in RFCs to Indicate Requirement Levels
+ + + + + + + +
2Notes on reaching agreement about a potential Zcash development fund. Andrew Miller, June 3, 2019.
+ + + + + + + +
3Comment on a post “The future of Zcash in the year 2020” in the Zcash Community Forum. Josh Cincinnati, June 3, 2019.
+ + + + + + + +
4Executive Summary: Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 15, 2019.
+ + + + + + + +
5ZIP 208: Shorter Block Target Spacing
+
+
+

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
    • +
+
+
+ + \ No newline at end of file diff --git a/zip-1004.rst b/zip-1004.rst new file mode 100644 index 00000000..849da472 --- /dev/null +++ b/zip-1004.rst @@ -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: + + +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 `_ +.. [#amiller-notes] `Notes on reaching agreement about a potential Zcash development fund. Andrew Miller, June 3, 2019. `_ +.. [#acityinohio-comment] `Comment on a post “The future of Zcash in the year 2020” in the Zcash Community Forum. Josh Cincinnati, June 3, 2019. `_ +.. [#blocktown-summary] `Executive Summary: Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 15, 2019. `_ +.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing `_ + +.. raw:: html + +
+ +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