[ZIP 1001] Final: ZIP proposal Keep the block distribution as initally defined. 90% to miners

[mistfpga]

Mod edit at @mistfpga’s request: Please read the GitHub version, which is different from the earlier draft below.

02/Aug/19 Hopefully zip ready.

---

01/Aug/19 Total rework of format and ZIP to incorporate feedback.

New feedback required please.
@nathan-at-least - this is my proposal I would like your comments on.

---

ZIP proposal Keep the block distribution as initaly defined. 90% to miners

---

I will make it better in github.

---

1 - Header

ZIP: unassigned.
Title: ZIP proposal Keep the block distribution as initaly defined. 90% to miners
Advocate: mistfpga (zcash forums)
ZIP Status: Draft
PreZIP Status: Proposal @ [ZIP 1001] Final: ZIP proposal Keep the block distribution as initally defined. 90% to miners
Category: Potocol?
Created: 2019-08-01
License: CC BY-SA 4.0 (Creative Commons Attribution-ShareAlike 4.0) [1]

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:

• Mining software in the context of this zip refers to pool software, local mining software, or staking software.
• Mining is defined as the action of processing transactions, so this include proof of stake, if zcash would switch to that.
• Mining coins transferred via fees are considered rewards (infinite), coins generated via block generation are considered distribution (finite).
• Block distribution is defined as the block reward - transaction fees.
• Spirit is defined as what is the intended outcome of the zip.[2]

3 - Out of Scope for this proposal:

• Governance on how decisions are made, this ZIP is not meant to be used as a form of governance.
• Future funding
• It does not cover other donations or revenue streams but it does cover how the current FR funds the ECC should be used at a very top level.

4 - Abstract/Spirit

The main spirit is not to stop potential future funding, it is to ensure that the FR ends.

It is a simplistic short zip to honour the initial promise of 90% of block distribution by giving miners 100% of block distribution goes to miners after the first halving.

Hopefully it will be compatible with a number of other zips and can be worked into them.

Please note, this does cover how funding should be used. is not forcing anyone person to do anything it is binding a company to continue work on the zcash protocol using funds raised for that work, and not to use them for other purposes.

5 - Motivation and Rationale

• To ensure the the distibution is kept as initialy defined. - This term is contested, please see discussion.
• Enforcing some kind of mandatory donation via whatever mechanism would be seen as continuation of the FR.
• The ECC should use the funding as they have stated they would in the initial promise.
• The community has managed to raise development funds via the FR, this should be used for development of the zcash protocol for as long as those funds last.
• The ECC’s sole source of income is the FR[3] This zip does not stop them having alternate streams.

6 - Requirements

• The ECC SHOULD use its portion of the FR for zcash development.
• The ECC SHOULD NOT use it portion of the FR funding for pivoting.
• This zip SHOULD NOT preclude the ECC from sourcing funding elsewhere, or from donations.

7 - Specification

• The existing Founders’ Reward consensus rules [6],[7] MUST be preserved.
• Specifically, FoundersReward(height) MUST equal 0 if Halving(height) >= 1
  (For clarity once the halving happens the FR stops. as per the rules outlined in [6],[7])
• This line of code is only mean to stop the FR not protocol based donations.

Issues & Further Discussion

This section contains a variety of information, questions and concerns. There is no real structure to answering or questioning this section.

Implications to other users.

• Block distribution payouts to FR addresses will need to be removed from the codebase.
• Pools and other software may need to make adjustments for this.

Further discussion needed on:

• If a governance mechanism is decided for and implemented in NU5 the effect for the ECC should be relatively seamless.
• This gives almost 2 years to think about and switch to a new governance system, using already credited funding.
• inital promise implies more than just a social contract. the inital promise does allow for chaninging of the ‘rules’ so I do not see the contention anymore.

Technical implementation.

• help?

Associated zips

References

[1] - Creative Commons — Attribution-ShareAlike 4.0 International — CC BY-SA 4.0 <-I like this one best, dont know which the ECC prefers.
[2] - If there is contradiction between Spirit and any other part of the proposal that needs to be addressed. in the even it is not addressed Spirit is assumed to overrule all.
[3] - Need to find the quote from zooko. // probably not needed
[4] - Need to find the quote from nathan. // probably not needed
[5] - Need to all link to stream timecode. // probably not needed
[6] Section 7.7: Calculation of Block Subsidy and Founders Reward. Zcash Protocol Specification, Version 2019.0.0 [Overwinter+Sapling]
[7] Section 7.8: Payment of Founders’ Reward. Zcash Protocol Specification, Version 2019.0.0 [Overwinter+Sapling]
edit: spelling.

test edit by Shawn

[nathan-at-least]

Thanks for starting this proposal here!

@mistfpga

I don’t know if I am doing this right, but @paige and others said they would help flesh it out if needs be.

Yeah, the whole community can help flesh it out. The goal, IMO, is to make each proposal as clear and specific as possible so that the community can be clear about which decision they’re making.

@mistfpga

I am not sure how this is an Improvement but - I just want it on record.

This sounds more like a “community resolution” rather than a protocol change. Resolutions are definitely improvements for Zcash even though they aren’t literal changes to the protocol, because they help everyone know what the community intends for the future of Zcash.

I would argue that the ZIP process already has a space for resolutions like this, but if it doesn’t, I advocate extending the ZIP process to include them.

@mistfpga

Thank you. and sorry if I got this wrong and this isn’t what I am supposed to do. Just delete it.

No need to apologize! This is exactly the kind of contribution I was requesting in my Dev fund proposals & sentiments - #16 by nathan-at-least post.

I have some clarifying questions:

• Would this preclude any introduction of proof-of-stake, including hybrid PoW-PoS?

  Those kinds of changes alter block rewards such that some go to stakers instead of miners, and I’ve seen different people interpreting that differently.

• Does this include transaction fees?

  Would this resolution prohibit introducing consensus rules that redirect some or all of transaction fees to anyone other than miners?

  Example rule: half of transaction fees go to the block miner and half go to a development fund.

• What does “explicit user consent” mean?

  Does that mean users can introduce a rule to redistribute mining rewards or fees, as long as they consent? Maybe an example of how “consent” is measured is stake-based voting, where if 60% of all ZEC votes for a change to a mining reward redistribution, then that’s acceptable.

  Or does it mean that rules that let users redirect funds “dynamically” are acceptable? For example: users can vote either for or against allocating issued tokens to a dev organization in each block?

• Does the “current status quo” of block rewards include only the amounts of block rewards, or does it also include transaction details such as the ability to use t-addresses? For example, would the resolution prohibit disabling t-addresses for mining rewards in the future?

[mistfpga]

@nathan-at-least

No need to apologize! This is exactly the kind of contribution I was requesting in my Dev fund proposals & sentiments post.

Cool. Thank you for the speedy response, there is little time. I will try to champion some other zips too. Can I please use RFC language? I think it will be easier most people are familiar with those.

@nathan-at-least

Would this preclude any introduction of proof-of-stake, including hybrid PoW-PoS?

No, mining is the processing of transactions. Stakers are miners too. They should get block distribution if PoS comes in.

@nathan-at-least

Does this include transaction fees?

This I don’t know. I cannot find any stance from the ECC in the early docs that state what happens to the transaction fees, only block rewards. I would really appreciate it if you can point me to any more info on this.

but in principle no, it doesn’t. (until I find information to the contrary)

@nathan-at-least

Would this resolution prohibit introducing consensus rules that redirect some or all of transaction fees to anyone other than miners?

Not in principle. but it is kinda an assumption that they will go there. - but I see this as the potential funding source.

@nathan-at-least

What does “explicit user consent” mean?

This means that like the current FR rewards are baked into the coinbase, so would the addresses for donations for the foundation.
A user would signal by enabling a switch on their mining software or transaction client that would let them give an additional percentage of either the transaction or block distribution e.g.

• I sent you 1 zec.
• I pay 0.001 zec in mining fees that at in this zip go to the miner
• I opt to pay 0.001zec on top as a donation. (by ticking a box in the software)

In this case the sender sends 1.002 zec. 0.001 goes to the foundation.
The miner if the pool or software he is using donates a percentage of his fee’s say 10% the miner donates 10% of the blocks total fees. I am leaving out block distribution because that will run out. I am open to the idea of putting it into the zip though.

@nathan-at-least

where if 60% of all ZEC votes for a change to a mining reward redistribution, then that’s acceptable.

This is unacceptable in this zip under any circumstance except emergency security issues. The block distribution is not up for change from the miners(transaction processors) in this zip. The intent of this zip is to honour the 90% block distribution as set out when we all opted in to zec. No voting. This zip is to stop that exact above scenario.

You could add these opt-in’s to the block distribution but that stops one day. Fees are forever, I am trying to think 60 years time when most of us will be long gone. There will be massive advances in tech over that time which this will have to keep up with.

• The spirit of the zip is also longevity.

@nathan-at-least

Does the “current status quo” of block rewards include only the amounts of block rewards, or does it also include transaction details such as the ability to use t-addresses? For example, would the resolution prohibit disabling t-addresses for mining rewards in the future?

• Not at all the intent of the zip is to preserve the 90% block distribution. to the miners (transaction processors) not to disrupt the usecases for zcash, especially its most important ones.

This zip kinda needs z only mining addressing to work properly, there might be too many correlation attacks from fees otherwise.

Now on to your next post.

[daira]

@nathan-at-least

This sounds more like a “community resolution” rather than a protocol change. Resolutions are definitely improvements for Zcash even though they aren’t literal changes to the protocol, because they help everyone know what the community intends for the future of Zcash.

I would argue that the ZIP process already has a space for resolutions like this, but if it doesn’t, I advocate extending the ZIP process to include them.

Speaking as a ZIP Editor, @mistfpga’s proposal is entirely in scope for a potential ZIP, under the current process. ZIPs do not have to describe protocol changes (especially in a case like this where they are acting as an alternative to one or more other proposed ZIPs).

Such a ZIP would of course have a very simple Specification section; the meat would be in the Rationale.

[mistfpga]

@daira

(especially in a case like this where they are acting as an alternative to one or more other proposed ZIPs).

Such a ZIP would of course have a very simple Specification section; the meat would be in the Rationale.

Thank you so much for this, it has really helped how I think about this and how I will write it up.

Glad to see you back on the forums.

[nathan-at-least]

Hi, thanks for making the effort to follow my requests in Proposal authors, please read: Help making ZIPs . I’ll check back to you in the next week or so to help you with any formatting or editorial needs.

[mistfpga]

Bump because this is a total rework

• Simplified to make intent more obvious
• Removed a lot of stuff in the hope of making it more compatible with other zips.
• Would really like feedback from the community on this.

@daira do you feel I have met the Rationale requirements, or maybe more correctly are they useful? I have tried to use concise statements to make machine translation easier, and also hopefully easier for non native English speakers to read.

@sonya can you please note in the high signal/low noise thread that my proposals are ready in their draft format for the community to reassess. especially this one. I have tried to make it as compatible with other zips/czips as possible.

This current one - [ZIP 1001] Final: ZIP proposal Keep the block distribution as initally defined. 90% to miners

And this one. - [ZIP 1002] FINAL: ZIP Proposal - Genuine Protocol opt-in/out donation feature updated 02/sept

[Anton1]

Together with this proposal, we can consider an additional progressive scale of allocations for the unit.
1 month -1%
2 month -2%
…
6 month -20%
That is, half the year will have to spend reserves of the past period.

[str4d]

@mistfpga

The mining community has already raised enough funds for the ECC to work until NU5, they should be spent on zcash.

@mistfpga

• The ECC has enough funding until NU5[4]

Nathan and Zooko said at Zcon1 that ECC had roughly 24 months of runway, and that if it went below 12 months, ECC would have to reconsider its All-In-On-ZEC strategy. Therefore, ECC has enough funding to continue its Zcash operations as-usual until mid-way between NU3 and NU4, as (barring any large price movements) that would be roughly where the 12-month remaining total runway is reached.

@mistfpga

7 - Specification

• The FR MUST end at NU4 activation.

This specification as-written modifies the existing FR, which contradicts the proposal’s title and rationale. I think the point of confusion is that NU4 activation is not the same thing as the first block halving. They may end up being at different heights (i.e. NU4 might activate before or after the halving; we won’t know when until mid-next year).

I suggest something along these lines:

The existing Founders’ Reward consensus rules [1, 2] MUST be preserved. Specifically, FoundersReward(height) MUST equal 0 if Halving(height) >= 1.

[1] Section 7.7: Calculation of Block Subsidy and Founders’ Reward. Zcash Protocol Specification, Version 2019.0.0 [Overwinter+Sapling]
[2] Section 7.8: Payment of Founders’ Reward. Zcash Protocol Specification, Version 2019.0.0 [Overwinter+Sapling]

@mistfpga

• All hardcoded FR donation addresses MUST be removed from the protocol at NU4 activation.

This part of the specification is unclear, and possibly redundant:

• The existing hard-coded FR addresses cannot be removed from the protocol as a whole, because they are part of the historic chain.
• If you mean “not be part of the consensus rules from NU4 activation”, then this is covered entirely by the first part of the specification.
• The addresses can eventually be removed from implementations (once there is sufficient distance from the NU that rollbacks can be discounted / prevented with checkpoints, and earlier blocks can be assumed valid), but that is an implementation-specific issue, and not relevant to consensus.

[mistfpga]

Thank you for your feedback, I have directly incorporated it. It makes more sense the way you wrote it.

This point though is one of contention so I raised it as an objection.

@str4d

Nathan and Zooko said at Zcon1 that ECC had roughly 24 months of runway, and that if it went below 12 months, ECC would have to reconsider its All-In-On-ZEC strategy. Therefore, ECC has enough funding to continue its Zcash operations as-usual until mid-way between NU3 and NU4, as (barring any large price movements) that would be roughly where the 12-month remaining total runway is reached.

There was no mention of a 12 month runway in the initial contract. So does the ECC have the power to change that at will? We certainly don’t have a mechanism for the community to decide, well not by the 31st anyway.

I understand that people need to live, be secure, know they have job safety, etc. However they also need to honour their promises. Had their been mention of this 12 month runway 3 years ago, there probably wouldn’t been a need for this zip.

It is a contentious point and one I am trying to talk about from a non emotional point of view. I understand if this black/white rule idea is offensive to some. There was no room for negotiation when some people decided that taking away the FR was a good idea (last year sometime) I strongly disagreed with that, because it was not upholding the contract. I am coming at this from the same position with this zip.

I really value your input. Thank you.

It feels strange and a bit creepy to me to be talking about what should happen with other peoples money. I don’t really like having these conversations and am continually learning from them. It is not my intent to upset anyone.

[mistfpga]

That is a really interesting idea. I will think about it and the implications. thanks!

[sonya]

I think updating in this thread is fine since that bumps and people can click through. I’ll add GitHub links when pull requests are opened in ZIP repo.

[mistfpga]

Watched the live stream.

This is not going to go anywhere. Should I retract it? I don’t want to have to waste my time championing something that is not relevant.

[mistfpga]

Thank you for you comment,

You made me realise something important.

I am representing not just my voice with this zip, but others too.

I will continue to champion it. So even if I am wasting my time I am still doing the right thing for other people.

Thank you again.

[ChileBob]

I wouldn’t abandon the default setting.

Its what will happen if things remain as they are, that makes it an important baseline which should be explored and considered.

[yzec]

Keep the block distribution as inital defined, that is 90% to minner is not bad. I maybe vote for it.

[str4d]

@daira and I made an initial review pass over this PreZIP. This is not a formal part of the proposal process (in particular, @daira is not acting in hir role as ZIP editor); this is just a joint comment between @daira and myself on the current state of the PreZIP.

---

@mistfpga

• To ensure the initial contract is honoured.

@mistfpga

• The ECC should use the funding as they have stated they would in the initial contract.

There is no contract. It would be reasonable to say “implied social contract”, as this is then a matter of opinion.

@mistfpga

To build trust within the long term holders and non active participants that the rules that they initially agreed to will be honoured.

It’s not a neutral point of view to imply that the rules in place at launch were immutable. From this blog post before Zcash launched:

Upgrade Strategy

[…]

At some point, a proposed upgrade may not be so clearly desired by all participants. Even in this scenario, a proposed upgrade may still provide benefits that outweight the drawbacks (e.g. confusion caused by diverging blockchains). If that’s the case, we may still advocate for the upgrade and release software for it. Or, we may decide the risk of a blockchain divergence outweighs the benefit.

[…]

Potentially Surprising Upgrades

[…] The following examples are not comprehensive, nor are they the coolest or most exciting upgrades on our radar. Rather they are a selection of upgrades we expect will surprise some fraction of potential users, and are thus the most important to communicate before Zcash launches.

[…]

…and More

As mentioned earlier, this list is not comprehensive. We may advocate for other upgrades which may surprise some users, which aren’t listed here.

ZIPs aren’t required to maintain a neutral point of view. However, they should indicate which things are not neutral facts.

@mistfpga

The mining community has already raised enough funds for the ECC to work until NU5, they should be spent on zcash.

@mistfpga

• The ECC has enough funding until NU5[4]

This is misleading, per the first bullet under “Raised objections” and the discussion down-thread. It would need to be expanded, given an appropriate caveat, or removed.

@mistfpga

6 - Requirements

• The ECC MUST use the FR funding to fund zcash development and adoption until it runs out.

This is unenforceable, and also inaccurate (ECC does not have access to the full FR, only to the portion that the FR recipients allocate to it). Suggested alteration:

The ECC SHOULD use its portion of the FR funding […]

Additional comment from @daira: “It is philosophically objectionable to try to enforce that anyone MUST continue a specific job.”

@mistfpga

7 - Specification

• The existing Founders’ Reward consensus rules [6],[7] MUST be preserved.
  Specifically, FoundersReward(height) MUST equal 0 if Halving(height) >= 1
  (For clarity once the halving happens the FR stops. as per the rules outlined in [6],[7])

In order to reflect the intent of the proposal (which appears to be that there should be no issuance-based funding beyond the first halving), the specification should additionally place restrictions on any issuance-based funding for Halving(height) >= 1, possibly only for some limited period. (It’s debatable whether a ZIP should tie the hands of anyone involved in the decisions about protocol design for all time.)

@mistfpga

Implications to other users.

• Will FR addresses will need to be removed from the codebase.

No, because they were part of the consensus rules up to the first halving, and thus need to be present in order to validate previous blocks (until such time as the entire history of the chain up to the first halving can be assumed immutable).

[mistfpga]

Amazing.

Thank you so much. @str4d and @daira.

I will adjust this. I agree on quite a few of the points. I probably remove the NU5 funding rather than heavily caveat it.

I can see where my wording is causing problems now, and whilst I don’t expect much movement on this zip I will bring it inline with the current suggestions.

For clarification I was not trying to force people to do things, I was trying to force a company to make a commitment to spending already raised funds, on what I considered to be a contract - so in a contractually obliged way. If this aspect isn’t actually a contract then yes, this needs a lot of rewording.

Thanks again!

[mistfpga]

Just re going through this, and I was wondering about this

Additional comment from @daira: “It is philosophically objectionable to try to enforce that anyone MUST continue a specific job.”

@daira

tl:dr - I will adjust it to be a no work no money rather than we have paid you must work.

it was just the philosophical aspect I was interested in. I know you are busy so as and when you get time, if you get time.

That was not the intent. the intent is that if I pay someone to build me a house, they build me a house, get someone else to build me a house or give me my money back. - or was I never promised a house, I was promised I would pay to for someone to build me a house, they may or may not do that. after all, its opt-in, eh!

This is what the FR was for. (amongst other things) and has already been paid. That line is to stop the ECC pivoting/winding down before NU4/NU5. So they cannot still receive a portion of the FR and not work on zcash tech.

[mistfpga]

@str4d

In order to reflect the intent of the proposal (which appears to be that there should be no issuance-based funding beyond the first halving), the specification should additionally place restrictions on any issuance-based funding for Halving(height) >= 1 , possibly only for some limited period. (It’s debatable whether a ZIP should tie the hands of anyone involved in the decisions about protocol design for all time.)

I know it reads like that, but I really is not the intent, hence the spirit section (which isn’t really part of a zip I know, but it helps me) This zip may seem a bit superfluous but for the very reasons you mention it should not prevent funding. if people really think block distribution is the way forward. this zip should not stop them. Like you say, it is not productive to tie peoples hands.

It is literally, stop the FR. and use funds raised for the FR for zcash technology/adoption/etc - don’t use them to piviot. use them to slow down, sure. that can be seen to be continued development or at least enabling continued development. - this zip for example wouldn’t stop the ECC from dropping half the staff working on zcash technology and using them to pivot, as long as the funds for the pivoting do not come from their share for the FR that should be used to extend the slowdown period.

I am actually trying to simplify a lot of my proposals so they can be tacked on or adapted to other proposals and at the same time not stopped by something not too relevant to the proposal. yeah, I know this is a bit late in the day.