[ZIP 1004] Dev fund proposal: Miner Directed Dev Fund (was: 20% to any combination of ECC, Zfnd, Parity, or "burn")

Community Collaborations protocol
1

1 - Header

ZIP: unassigned.
Title: Miner Directed Dev Fund
Advocate: Andrew Miller (amiller on zcash forums)
ZIP Status: Draft
Community Status: Request for comments : @ Dev fund proposal: Miner Directed Dev Fund (was: 20% to any combination of ECC, Zfnd, Parity, or “burn”)
Category: Process
Created: 2019-06-19
License: public domain

2 - Terminology

To understand this ZIP it is critical that people understand the right terminology so their requirements can be quickly checked.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”

Have special meaning and people should familiarise themselves with it. - RFC 2119: Key words for use in RFCs to Indicate Requirement Levels

For clarity in this zip I define 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%).

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

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

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

6 - 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

7 - 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 - #267 by acityinohio 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
10 Likes
2

I like this proposal a lot. However, when miners start burning the rewards instead of providing it to dev fund, it means zcash has conquered the blockchain space and has achieved full decentralization (various independent devs voluntarily improving and contributing to protocol).

We should definitely consider the idea of burning in combination with dev fund. It works really well in both bull and bear markets.

1 Like
3

Idea is good but not fair:
ECC and Foundation haven’t recieved full 10% during first 4 years why give even greater funds for a more than certain unexpected performance?
First 2 years have been productive and many improvements have been made, but next NUs are not as juicy as the past 2… if ECC and Foundation can make promisses (staking, scalability and smart contracts) then the discussion is valid, if no garantess are put on the table I don’t see any real interest in a continous funding.

I would be happy to fund 5% from mining reward for a garantee on smart contracts or full coda protocol implementation…

NU4 might turn out incredibly refreshing and the blockhchain might be at a mature state, too bad we can’t decide with smaller time frames, august zip deadlines for 2020 upgrade kinda sucks… it is what it is…

6 Likes
4

I totally agree with this argumentation and this makes absolute sense, hence why i was asking in some previous post more or less the sames including: What are the goals (road map), when they are planned for (time line) and how much is the estiminated cost for these (budget plan) …

4 Likes
5

Good point. For dev fund to get allocated, community needs at a minimum of roadmap and big features that can be launched on Zcash (ex: fully shielded, scalable blockchain etc.,).

3 Likes
6

I really like this idea. This way, the dev fee available to the ECC/Foundation can be dynamically adjusted, depending on future ZEC price, the community’s happiness with the ECC and/or Foundation roadmap.

I specifically like that the miners can chose the allocation between ECC, Foundation and Burn, allowing the mining community some control over how to spend funds (or return them back to the community via burning)

It also allows miners to opt-in, rewarding or penalizing depending on how they think the roadmap/development is going.

8 Likes
7

I would rather have a mandatory minimum lower percentage. Otherwise some miners won’t give funds and it could cause problems with a few carrying the load of others. 10% for everyone would raise the same or more money. If only part of the community of miners donates their percentage will ECC or the foundation be forced to plead with the mining community to donate? 10% is not too much to ask for continued development as there is plenty more work to be done.

If more than enough money is raised than is needed then the community could vote on how to allocate the funds.

8

I like the idea (more than my own proposal)

There are some big pools out there who would have an equally big influence, would that be a problem ?

https://explorer.zcha.in/statistics/miners

9

Interesting thought, but than again, with most proposals so far the miners allready carry the whole load.
While your argumention for sure has a valid and good point someone could see this even as a stimulating design.
Means the more appealing, necessary, logic, innovative the development is (or the NUs) the more the miners should be interested to donate from the mining rewards.

This could be combined to make it fairer and not only on the miners responsibility but as well for example some “dev reward donation transaction fees” and/or dev reward wallet fee, just as ideas out of air…

The dev reward donation transaction fee for example could be mean “sending”, 10x faster if possible or whatever.

Damn, there are sooo many options that this discussion should have needed to begin months ago. Makes me think about what are the chances to delay the process (NU) to get the best ideas together?

10

This discussion did begin months ago, it’s just people get sidetracked I guess and start thinking about other things, chances of delay aren’t good

I like this proposal and I would also propose 20% of all of the development fee mining goes to the foundation regardless of the split
80 % miners/ 20% dev fee
Of all dev fee
20% ZFND mandatory/ 80% miners choices
So basically 1 in 5 dev fee sessions is mandatory ZFND
If we’re serious about keeping the ECC around and properly funded they should be appropriated a mandatory portion as well and not leave it wholly to chance

New proposal split
20%ZFND /20%ECC /60%Miners choice

I’ll start my own thread for this proposal unless others think this would be a more appropriate modification to this one

2 Likes
11

I think the Foundation might not support this, as (IIRC) @acityinohio has stated that the Foundation’s position is that the new fee needs to be opt-in

2 Likes
12

That makes sense, I actually touched on the conflict of interest a few days ago and apparently had slipped my mind

New proposal
40% ECC of which half is pledged to the ZFND / 60% Miners choice

This doesn’t seem too unlike how it is now with the founders pledging
Again I will move this if that would be more appropriate (actually Shawns the wizard, he’ll probably do it : )

Caveat, I would probably support the full option ability if we had a more inclusive mining system which was another thing we were talking about that just kind of stopped
That’s why I don’t think it should be left to chance because it will fall primarily in the hands of large mining Farms
I also don’t think it’s fair at all to string the ECC along with the hopes of maybe being able to pay their employees, at that point I think it’s more fair to cut them loose so they can focus on their future prospects
In or out, no halfwaysies

1 Like
13

In my personal opinion, this is the best proposal so far. Including a burn mechanism is clever and keeps the system consensual, which is important (as you noted).

2 Likes
14

We all still want more inclusive, more decentralized mining dynamics! But it’s really hard to achieve that goal without compromising other important aspects of Zcash. @daira has analyzed this extensively with respect to the security implications of Harmony Mining (for example in this GitHub thread).

There’s no free lunch, unfortunately. We have to bite the bullet on a tradeoff, and the tradeoff that Zcash has chosen, at least for now, is the relative centralization of huge ASIC farms, versus being more vulnerable to 51% attacks. Personally, I think that’s the right choice.

(Caveat: I’m not an expert on this. Epistemic status: Strong opinions weakly held; AKA I’m open to being convinced otherwise.)

3 Likes
15

Hi,

Can you clarify what you mean by miner. - transaction processors (be that PoW/PoS/Hybrid)?

Is there room in the proposal for a ‘keep’ where the coins are not burnt but get distributed to the miner?

It is a selfish act, but that does not make it inherently bad. This addition I feel would give a true opt-out, and could also fix the issue of the 90% rule at the same time, without creating potential forks and community split.

Is there scope in this proposal to have a time weight from moving the funding from block distribution to being from fees (distribution will run out, fees will not). so start at the 20% or whatever or block distribution and slowly move over to fees when the distribution is running out.

I feel this will also stop the need to have this conversation again in 2 halvings time.

And would signal that usability grown is the top priority after getting the tech (and politics, etc) fully locked down.

If this is out of scope, please let me know. Your suggestion seems to have quite high community support here so far and I wouldn’t mind copying the zip and putting those items I outlined earlier in myself. (is that an allowed thing to do?)

Thanks,

2 Likes
16

Go for it - feel free to remix this idea how you like :slight_smile: I’m stoked to see several positive reactions to this right away though I’m wary of interpreting forum replies as broad support yet. I will probably leave this post the way it is though except for clarifications… for now I like the simplicity of it compared to adding in a fixed minimum donation etc., though I see the potential appeal.

Here are two immediate drawbacks to this approach I’ve thought of:

  1. A plausible ultimatum by miners could be to veto the use of dev fund for any research into GPU-based or proof-of-stake based alternatives

  2. Another plausible ultimatum would be, for example, “we’ll direct 20% dev fund to ECC, but only if they promise to keep just 5% and refund 15% back to the miners via the coinbase address in the previous block”.

So this mechanism is clearly imperfect, but perhaps still good enough?

3 Likes
17

This suits me very well. Love the idea and feels perfectly fitting.

3 Likes
18

Two really good, insightful points. I would never have thought of that, so my well intentioned idea may have very bad unintended consequences in 5 years.

I certainly have a lot more to think about.

I am finding it difficult to absorb so much information and implication even though I though I knew exactly what was right. as always the devil is in the detail.

And with so much at stake is “perhaps good enough” good enough? aaaarrrg my head hurts :slight_smile:

EDIT:
@amiller - One issue I see with your proposal is that all of the mechanisms, even the burn option will enrich the ECC - This is only a contention because the ECC is for profit. It is a negligible concernn though but it does somewhat remove the ‘free will’ aspect of not wating to enrich a for profit.

Just highlighting it incase you had not thought about it.

1 Like
19

Yes of course, I followed the zip process closely
I was referring more to on this forum, there are a number of threads where we were discussing such things and although the selection was not decided upon for NU3 I was hoping people would still continue to consider the future possibilities

1 Like
20

This is a really interesting idea. I would imagine it would bring in a whole heap of uncertainty to the Foundation, ECC et al. when the funding could be cut to zero at any point. Maybe that is not a bad thing but seems hard to budget for and could have the unintended consequence of forcing any organisation to be overly conservative.

Leaving it up to miners to decide any development funding has obvious conflicts of interests such as funding work of proof of stake or alternative non-POW consensus mechanisms.

6 Likes