195 lines
7.8 KiB
ReStructuredText
195 lines
7.8 KiB
ReStructuredText
::
|
||
|
||
ZIP: 1004
|
||
Title: Miner-Directed Dev Fund
|
||
Owner: 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 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] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||
.. [#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
|