Skip to content

Latest commit

 

History

History
195 lines (143 loc) · 7.93 KB

zip-1004.rst

File metadata and controls

195 lines (143 loc) · 7.93 KB
Raw
ZIP: 1004
Title: Miner-Directed Dev Fund
Owners: Andrew Miller (@amiller on zcash forums)
Status: Obsolete
Category: Consensus Process
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 BCP 141 when, and only when, they appear in all capitals.

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 Upgrade4), 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 proposal5, 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


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

  1. Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"↩

  2. Notes on reaching agreement about a potential Zcash development fund. Andrew Miller, June 3, 2019.↩

  3. Comment on a post “The future of Zcash in the year 2020” in the Zcash Community Forum. Josh Cincinnati, June 3, 2019.↩

  4. ZIP 208: Shorter Block Target Spacing↩

  5. Executive Summary: Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 15, 2019.↩