13/Aug/19 Added clarity to terminology. thanks sonya.
28/July/19 Total rework of format and ZIP to encoperate feedback and @Daira design template
New feedback required please. @nathan-at-least - this is my proposal I would like your comments on.
Do I now @ a load of people? or bump the thread and hope?
Genuine Protocol opt-in/out donation feature
This is a community ZIP (CZIP) and not a ZIP ZIP. hopefully I can make this into a ZIP from feedback. Please reread this proposal and make any suggestions below. I am open to changing quite a lot of it and welcome discussion on any part or aspect of it.
I may have made mistakes in typing this up, so all comments are welcome.
If this proves useful I will publish my guide on how to write and fill out these sections. Also I can do a lot of the heavy lifting in terms of formatting, etc. I do need some basic information from you though.
If this current proposal is okay and signed off by the foundation/ecc as a decent example. I will pass my guidelines for how to fill all this stuff out (80% of it can be done by someone else, you just need to engage in questions) I dont want to publish guidelines for them to be wrong and people to have to redo work.
I have created a pull request for the foundation to include the guidelines (as requested by @sonya). the request can be found here
The formal ZIP process parts are taken from this guide by the ECC
1 - Header
Title: Genuine Protocol opt-in/out donation feature
Adviocte: mistfpga (zcash forums)
ZIP Status: Draft
Community Status: Request for comments : @ ZIP Proposal - Genuine Protocol opt-in/out donation feature updated 28/July
License: CC BY-SA 4.0 (Creative Commons Attribution-ShareAlike 4.0) 
Additional Community Status header information - click to expand
Community Status, what part of the process is this zip at.
- Request for comments (from anyone)
- Request for proposal (formal request to help make into a proposal)
- Request for technical review (requesting technical feedback from the ECC)
- Final (this zip is finished and ready for submission)
It should contain the URL of where the discussion is taking place. forum/github
Note: at any point in this process, even if it is labelled final people can still comment. If the status is Request for comments, the ECC can still give technical feedback.
Should these additions get accepted I will add a guide on how to use them.
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. - https://tools.ietf.org/html/rfc2119
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 provided by the ECC
- 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 sending them to an address that has no private key, therefore taking them out of circulation forever.
- Greed is defined as complete honour of the initial contract by distributing all rewards to the miner.
- Transaction sender is defined as anyone who sends a transaction across the zcash network, be it t-t, z-z, t-z, z-t.
- T1 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
- T2 fee is an optional signalling string that create a transaction to the coins base donations.
- Block Reward is defined as block distribution + mining fees [T1 fees only].
- Spirit is defined as what is the intended outcome of the zip.
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 contract 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 contract is honoured.
6 - Requirements
- An additional opt-in mechanism, baked into the protocol. This is a condition of the foundation too 
- 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.
7 - Specification
- This feature MUST enforce the initial contract as defined by default.
- Users MUST NOT be forced to signal.
- No signal SHOULD be counted as greed when solo mining. (the official client MUST default to be counted as greed)
- No signal MUST be counted as whatever the pool is signalling or greed SHOULD offer the private key holder the option to signal.
- Custodial services cannot override the signal of the private key holder
- Current and future usecases MUST NOT be prevented by this czip (see objections/issues)
- Security MUST NOT be lessened
- this feature MAY be set to opt-in via a user set flag
- This feature MUST default to opt-out.
- This feature MUST contain donation addresses in the coinbase.
- 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. [T1 fees only]
- A transaction sender MAY elect to include T2 fees which MUST NOT be overridden by the transaction processor.
- T2 fee state MUST NOT be able to be overridden if it is set or not by the transaction processors
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 achived without greed and just burn
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 what to do in the usecase that the miner signals greed, but the pool signals donate.
- I am unsure how much ability there is for an asic owner to signal using their mining software.
- Technical adjustments needed to make this happen. I cannot assess this.
- What the Foundation does with this money.
- Voting or what political conditions need to be satisfied to implement this zip.
- The default being greed. This will be a contentious point. I would like to hear feedback. Burn could also be an alternative default, for example.
Stuff that is already implemented in some form or another:
- T2 Fees are already implemented in some wallet software.
- T2 Fees already cannot be overridden by miners.
- Hardcoded donation addresses are already baked into the protocol.
- 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.
zips that interact with this zip should be listed here if possible
 [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)
 - 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.
 - https://creativecommons.org/licenses/by-sa/4.0/ <-I like this one best, dont know which the ECC prefers.
Thats it. It will still need updating but hopefully this helps.
Sorry, I cannot help more. Is there enough information for the ECC to work out the implications from the requirements section?
Is there enough information for wallet developers to make objections, ask for clarification from the requirements section?
Is there enough information for governance people to work this into how their models work?
Should I now @ a bunch of people asking for their specific input on particular parts?