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

Thanks for starting this proposal here!

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.

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.

No need to apologize! This is exactly the kind of contribution I was requesting in my Dev fund proposals & sentiments 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?

2 Likes

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.

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

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)

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

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.

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

2 Likes

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.

5 Likes

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.

4 Likes

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.

2 Likes

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 proposal Keep the block distribution as initaly defined. 90% to miners

And this one. - ZIP Proposal - Genuine Protocol opt-in/out donation feature updated 28/July

1 Like

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.

1 Like

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.

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]

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.
1 Like

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.

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.

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

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.

1 Like

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.

1 Like

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.

2 Likes

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.

3 Likes

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

1 Like

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


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

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.

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.

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

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

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

2 Likes

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!

2 Likes

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

@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! :wink:

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.

2 Likes

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.

1 Like

@sonya

Seeing as you are about at the mo, can you please give the new proposal a sanity check to make sure I have got things in the right places (i.e. requirements and spec, etc) I would really appreciate it.

Thought I would ask on the simplest one before I post others. please and thank you

If you are about for a bit, I am about to post a whole lot more of them. :smiley:

1 Like