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

Community Collaborations protocol
1

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

02/Sept/19 Final

This zip in no way impacts 2-2 or whatever so should not fail under those reasons.

Thanks to @daira and @str4d for their advice. I will GitHub this as soon as I get finished doing final proposals on the forums.

13/Aug/19 Added clarity to terminology. thanks sonya.

28/July/19 Total rework of format and ZIP to incorporate feedback and @Daira design template

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

1 - Header

ZIP: unassigned.
Title: Genuine Protocol opt-in/out donation feature
Adviocte: mistfpga (zcash forums)
ZIP Status: Draft
__Community Status: Final : @ [ZIP 1002] FINAL: ZIP Proposal - Genuine Protocol opt-in/out donation feature updated 02/sept
Category: Process
Created: 2019-07-17
License: CC BY-SA 4.0 (Creative Commons Attribution-ShareAlike 4.0) [3]

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:

  • Signalling is defined as expressing a voice through whatever mechanism is implemented or sought for that decision. In the context of this zip it is primarily referred to in regards signalling what to do with funds. This could be done by miners, straw poll, coinbase, proof of value, some internet poll thing, etc.
  • Mining software in the context of this zip refers to pool software, local mining software, or staking software.
  • Custodial services include any service which a 3rd party controls the private keys of a 3d party, mining pools and online wallets are examples.
  • Mining is defined as the action of processing transactions, so this include proof of stake, if zcash would switch to that.
  • User is defined that anyone that uses ZEC or the zcash technology.
  • Mining coins transferred via fees are considered rewards (infinite), coins generated via block generation are considered distribution (finite).
  • Opt-in v opt-out - Opting out is a purely selfish act in the context of this ZIP. They do not burn the coins therefore giving everyone value. They keep them.
  • Burning coins is purposefully taking them out of circulation forever at the protocol block distribution level, by the protocol.
  • initial promise is defined as complete honour of distributing all rewards to the miner. - This is a non neutral phrase. I accept that.
  • Transaction sender is defined as anyone who sends a transaction across the zcash network, be it t-t, z-z, t-z, z-t.
  • fee is the standard transaction fee that a sender puts on a transaction to get it included into a block and the miner is in control of
  • transaction donation is an optional signalling string that create a transaction to the coins base donations.
  • Block Reward is defined as block distribution + mining 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. it is protocol level opt-in/out for supporting the zcash network development. (like the FR, just with opt-out)

  • Signalling. Whilst a lot of the zip relies on the ability to signal intent in one way or another, it does not put forward such a mechanism and is designed to work with various form of signalling. Or potentially without signalling at all.

4 - Abstract/Spirit

Not to change the current contract where miners get 90% of block distribution. (Note: This means 100% of block distribution goes to miners after the first halving)

To allow continual funding of the ECC, the foundation, or some combination of these should a user choose to do so.

5 - Motivation

To build trust in the ECC that the initial promise cannot be changed.

Technology changes, and it changes fast. What works now, may be easily breakable in 10 years, 20 years and certainly 50 years.

To help ensure ZEC can keep up with these changes, now and in 50 or 500 years time, there needs to be a continual funding for research into new technology and the ability for financial stability so the company can attract new talent.

The only source of indefinite wealth transfer is transaction fees or donations. This zip is specifically about voluntary donations. (including via mining fees)

To ensure the initial promise is honoured.

6 - Requirements

  • An additional opt-in mechanism, baked into the protocol. This is a condition of the foundation too [1]
  • Give an alterative to redistribution of either; the current block distribution structure, or emission curve.
  • The foundation MUST use this funding to fund zec development for the lifetime of their receipt of it.
  • To give a strong indication to the community and users that they have freedom to decide what they do with their coins and donations
  • Baking the addresses into the codebase you do not need the wallet software or pool software to keep track of donation addresses.
  • It prevents users from sending donations to old addresses.
  • It makes it easier for pools to add support and prove that they are actually donating the % they say they are.
  • Current and future usecases MUST NOT be prevented by this zip (see objections/issues)
  • Users MUST NOT be forced to signal.

7 - Specification

  • This zip MUST enforce the initial promise as defined by default.
  • the official client MUST default to be counted as initial promise
  • No signal MUST be counted as whatever the pool is signalling or initial promise SHOULD offer the private key holder have the option to signal.
  • Security MUST NOT be lessened
  • This zip MAY be set to opt-in via a user set flag
  • This zip MUST contain donation addresses in the coinbase, in a similar fashion to the current FR.
  • When sending transactions the sender MAY signal their donation.
  • A signal from a transaction sender MUST NOT override the default transaction processor signal for that transaction.
  • A transaction sender MAY elect to include separate donation fees which MUST NOT be overridden by the transaction processor if this use or not.

Issues & Further Discussion

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

Raised objections and issues so far:

  • This adds complexity to the protocol, which is technically not needed and generally a bad idea.
  • This does not add anything that cannot already be done under the current protocol by users manually, although not to the same extent.
  • Block sizes, this may impact the motivation to increase block sizes should that need arise.
  • Signalling from shielded addresses to donations at taddresses?
  • Once zcash goes full z address, how will transparency of donations be proven?
  • ZEC is designed to not have high transaction fees or a secondary transaction fee market. Is this a core principle?
  • A similar goal can be achieved without initial promise and just burn - mistfpga: I dislike taking coins out of circulation intentionally - it is an attempt to avoid that.

Implications to other users.

  • Wallet development will need to be considered. Hopefully the requirements will lessen this impact after the first initial change.

  • What happens if the Foundation closes down, will the donations:

    • go to into the mining fee
    • get burnt
    • get sent as change to the original sender
    • distributed via some other mechanism

  • What if the mining software signals donation/no donation but the pool software is set to the opposite?

Further discussion needed on:

  • HOW TO SIGNAL - this zip should be compatible with as many other signalling zips as possible.
  • I am unsure how much ability there is for an asic owner to signal using their mining hardware

Technical implementation.

Stuff that is already implemented in some form or another:

  • Optional fees are already implemented in some wallet software.
  • Optional Fees already cannot be overridden by miners.
  • Hardcoded donation addresses are already baked into the protocol so it should be minor work to adjust them to the signalling addresses.
  • Hardcoded donation address already cannot be changed by pools or software.
  • Signalling could be handled at the pool level
  • Pools already add their own addresses to the coinbase, including donations.

Associated zips

zips that interact with this zip should be listed here if possible

References

[1] [quote=“acityinohio, post:193, topic:32372”]
The Foundation would only support proposals that:

a) don’t rely on the Foundation being a single gatekeeper of funds
b) don’t change the upper bound of ZEC supply
and c) have some kind of opt in mechanism for choosing to disburse funds (from miners and/or users)
[/quote]

[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] - Creative Commons — Attribution-ShareAlike 4.0 International — CC BY-SA 4.0 <-I like this one best, dont know which the ECC prefers.

3 Likes
2

Hi, I don’t understand how this is different than voluntary donations as part of existing transactions.

The Foundation could publish a donation address, and then when users create transactions, they can spend some of their funds for their main destination, some for the transaction fee, and some as a donation to the Foundation. This is completely opt-in and works with the existing protocol.

So how is this proposal different?

It makes more sense if the mechanism affects block rewards (i.e. newly issued ZEC coins) rather than only transaction fees. Is that the intent of this proposal?

Here’s a more specific proposal with concrete numbers and details just for clarification (I am not literally proposing this). Let me know if this fits your intent or not with this proposal:

  • Starting with NU4 activation at the first halving [corrected by @daira] (the block immediately after the Founders’ Reward ends):
  • Each block rewards 5 ZEC to miners and between 0 - 1.25 ZEC to a Dev Fund.
  • At each halving interval thereafter, both the miner reward and the max Dev Fund reward are reduced by half, indefinitely.
  • Users have some way to vote with their ZEC how much to fund the Dev Fund on some periodic basis. Let’s say these votes happen monthly. Some examples:
    • If all ZEC votes to support the Dev Fund, the full 1.25 ZEC per block is issued to the Dev Fund for the following month.
    • If only 40% of existing ZEC supports the Dev Fund, then only 0.5 ZEC per block are issued to the Dev Fund for the following month.
    • If 0 ZEC supports the Dev Fund, 0 ZEC per block are issued to the Dev Fund for the following month.

Some implications of this design:

  • The total issuance matches the current Zcash issuance schedule, so same number of ZEC are produced over time tapering off at 21M ZEC.
  • If the Dev Fund issued in any month is less than the maximum, then fewer total ZEC are issued. This means there would be a smaller supply of ZEC so all ZEC holders would benefit in proportion to the ZEC they hold.

Some open questions:

  • How would the voting be implemented technically and securely?
  • Would the voting be private so that no one can tell how anyone else voted? (Seems ideal, but potentially difficult.)
  • What about people who don’t vote?
    • This is actually more specific about ZEC which doesn’t vote. This is probably an extremely important decision, because much ZEC will be in cold storage, on exchanges, etc… From what I’ve noticed of “on-chain governance” examples, like Aragon, Tezos, Cosmos, etc… I think typical turn out for votes is often in the 2-5% range, or maybe 10% in extreme cases. So the main question would be if non-votes support or reject the Dev Funding.
  • What about custodial systems? If a user owns ZEC in a deposit on an exchange, what if the exchange (who controls the private key) votes with those funds? What if the exchange doesn’t vote, but the user wants to vote? What about cold storage? etc…

Let me know if this example proposal matches the intent of the original proposal, or if not, how not.

Edit: Added examples about non-votes being very important. Added open question about custodial services and voting.

4 Likes
3

The crux, is this zip is going for longevity.

  • Mining fees are what will keep the system running.

  • By baking the addresses into the codebase you do not need the wallet software or pool software to show an address. This limits 3rd party developers redirecting these funds for themselves - in the same way as the FR

  • The addresses might need updating from time to time. This prevents wallets sending to old addresses and meant wallet maintainer do not need to keep remaking their software.

  • It makes it easier for pools to add support and prove that they are actually donating the % they say they are. So by mining software I am including pool software.

It already exists. No one seems to use it.

The opt-in I agree with, however for longevity it would be advisable to bake it into the protocol. That way when I get my usb drive out in 20 years it will automatically donate (if set) to the foundation.

I would like to put in a quote from a different thread about this exact issue from @acityinohio

That is the last post in a very small bit of the 2020 thread. please read this from @str4d and the following two posts. That quote is from the third.

It is a much easier sell to a pool and wallet developer to include it, than it is for someone to actively think, I need to donate, how do I do that, etc.

Not really no. I will put forward some proposals I don’t agree with because we are running out of time and no one else seems to be doing it. - but not today.

Block distribution has to remain the same. The spirit of this zip is to eliminate the need for voting, whilst enabling features in the previous zip.

The problem with voting is getting a quorum, for the very reasons you outlined. It is a store of value (like bitcoin) not an asset of transference of value (like monero) - But this is only because of where we are at in the development cycle. Until zec can be a monero replacement, which it will be, these will be tough times. I posted to you in another thread regarding this, and if this is done by the end of the FR then it has been a success.

  • non votes are always for not changing. its unfortunate but I don’t think voting and crypto go together.
  • What if people vote to depreciate z transactions?
  • If amount of coins increases your voting power then whales and mining pools will always vote that the users pay.

This is exactly the issue. We are making decisions with other peoples money that they have in a safety deposit box and probably don’t follow the forums, or crypto in general. This is why it is so important that the initial rules are stuck to, and backward compatibility is maintained.

This is why we cannot have voting.

Am I still doing this right? Thanks again for the quick response.

2 Likes
4

It should be noted that that was a donation page I set up before I started working for the Zcash Foundation. It was not for Zcash protocol Development, but to help pay for monthly server costs since I used to run the chat and main website out of my own pocket, but now I work as a contractor with the Foundation and have taken links to that page down from the main site. I will also take down that page too.

Edit, it’s removed.

3 Likes
5

My apologies for the mistake.

You kinda undermined my argument a bit here tho, lol. That is some nice donation money for keeping things up and running. Im sure it didn’t cover everything but you did really well.

Thank you for doing what you did. I never really realised how much you had given to the community before.

3 Likes
6

BTC price wasn’t as high back then, so it wasn’t enough to cover everything but it was enough to keep my wife from yelling at me when I paid the bill for it each month :joy:

But to your point, as I and Radix42 can attest to, just having a donation page up is almost never enough to support full time work on a project unless the developer is willing to donate thier time for free and have donations cover the hard costs.

5 Likes
7

Just a quick question.

I was going to @ a few ppl but I thought Id ask you quickly first:

Do you think it would help to consolidate the OP with my responses to Nathan and possible objections/issues and stuff that is not covered by it?

8

Entirely up to you, think if you were visiting this thread for the first time, what information would be best to present in the first post to help you convey your idea?

1 Like
9

I think for threads like this where a proposal idea is being crystallized into a ZIP draft, it makes sense to use the OP for tracking this progress. That could include continually-updated “Motivation” and “Rationale” sections (that would become part of the ZIP), which would probably be the most useful sections for a newcomer to read in order to catch up with the current state. Maybe also include the full proto-draft itself depending on its length (or a link to wherever the thread participants are drafting the text).

2 Likes
10

That’s mostly very true.
However, it could be at least be part of several independet funding sources which together could add up in covering developement or given tasks that must/should be funded.

1 Like
11

Thank you. Could you point me towards a couple of well written zips so I know what sort of format to copy, and what sort of wording to use.

I complete agree with the sentiment that hopefully the OP can just be cut n pasted into a zip.

cheers.

1 Like
12

ZIP 210 is probably the simplest ZIP that was written after ZIP 0 was finished. It has all the sections that you’ll see defined in the ZIP Format and Structure section of ZIP 0, for what is conceptually a simple proposal.

Other ZIPs that affect coinbase, and may be useful for you to examine:

You can ignore reference implementations etc. for now.

Having seen your current OP summary, I’m now also thinking that it may be useful to have “Drawbacks” and “Alternatives” sections in some ZIPs to complement the “Rationale” section, similar to in Rust RFCs (here’s a short example). It may be useful as a summary of the community discussions that led to the ZIP. We can figure that out as we go.

2 Likes
13

Thank you for hand holding me thorough this - I saw the templates but didn’t really get it until the examples you gave. Personally I like bullet points, but I will do both and see which works better.

I think have everything I need now. I will have problems with the specification part. I will fill in what I can.

I agree on the Rust style, that is what I am a lot more familiar with.

And for reference implementation, I probably will not be able to provide that.

Thanks again.

3 Likes
14

My main concern with this proposal and any other fully opt-in funding mechanism at this stage of development is that it creates a lot of uncertainty and potentially instability. With proper governance and accountability, I think a lot more can be achieved through a guaranteed funding pool. I admit that this comes with its own set of problems and challenges, so it all boils down to strategic trade-offs and timing. I’m not against opt-in, I’m just worried whether it will create more problems than it solves given where Zcash is and what needs to happen for it to be successful.

4 Likes
15

Thank you - I appreciate you taking the time to give me feedback

For me that is really valuable and useful feedback. I will try to incorporate it in. It does also help my greed v burn suggestion. the greed option was my compromise I was going to put in to make my proposal more inline with anthers (I think amiller’s, not 100% sure - the idea seemed to get a lot of community support, wanted a greed option added.)

I will think about this and the best way to address it in this zip, once I have done that I will post some updates to the OP and maybe a few more questions in this thread.

It is a concern that does need to be highlighted in the proposal somewhere, if I find a mechanism or idea to solve it - it will probably be needed to be solved or at least properly against other zips (I can do that)

3 Likes
16

Hi (again). 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.

(Sorry for reposting boilerplate, but I thought it would help someone who sees only one of your proposals to have the same information.)

1 Like
17

Complete rewrite of OP.

Please use this one to comment on. bumping thread in hopes of exposure without having to @ half the forum.

2 Likes
18

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.

Had to add a few extra words so I can post it.

19

Why did you conclude that it’s not going anywhere?

1 Like
20

Because it realistically cannot fund the ECC. I think even you flat out said “dentations don’t work” This zip is very similar to amillers, except it has greed.

I am starting to get a little concerned we are wandering into some areas of game theory that no one wins. idk. I have sent you a PM I will be unable to answer stuff for a week or so. I will mull it over, whilst away.

I haven’t official withdrawn anything, but the objections section just got huge. It will take me some time to address the live stream comments and work them into the zip.

I understand I am representing not just my voice with this zip so I will continue to champion it. So even if I am wasting my time I am still doing the right thing by other people. (strange how moments of clarity come whilst typing thing up)

1 Like