Advocate: @mistfpga zcash forums
I am in the process of updating this zip to be in a better format. and to incorporate the comments below. and from other forum members that I solicited via PM. thankyou for your input.
I intend to have this ready asap.
different rules for likes in this section - click to expand.
In my humble opinion liking this post, or any proposal post, is no indication of your support for or against this proposal. It is to encourage the poster to keep working on it, and to show that you have read it and are engaged in that topic at least on a thought level.
This is how I will be using and interpreting likes on a post. (this is not begging for likes, im just saying likes have a different meaning than the standard “I agree”)
@nathan-at-least @Shawn @str4d @acityinohio @sonya @paige @amiller - sorry for @ so many of you, I would like a much feedback on this as possible. You have all been involved in this particular discussion, do you feel this zip meets the standards of a zip (if not what do I need to do to improve) and does it accurately convey the thoughts and objections raised by yourselves.
Thank you for your help and feedback so far.
I hope this is better. Please see this posts edit history for previous versions.
I have tried to address the points raised without quoting the questions, this is for brevity. This zip is a collaborative effort and not just the work of myself. Thank you for all that have helped so far.
If this template is any good please feel free to use it yourself. If the people who will be judging this zip like this format I will be happy to write up example questions that you can ask yourself, so you can fill out the template.
I have probably missed some things, so I will reread over the posts and keep making updates. Please keep adding comments, criticisms and ideas to this thread. All is welcome. All is very appreciated.
If some stuff is out of scope and it should be in scope, ask the question and I will add the answer the OP.
ZIP NaN - A genuine opt-in protocol level development donation option.
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.
The only source of indefinite wealth transfer is transaction fees or donations. This zip is specifically about voluntary donations.
The baked opt-in idea is because it incentivises people to donate, because if they stop so will development.
Clarification of 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).
- Opt-in v opt-out - Opting out is a purely selfish act in the context of this ZIP (there is nothing wrong with being selfish, even though the word has negative connotations). They do not burn the coins therefore giving everyone value. They keep them.
Rational behind proposal:
- To help continual funding of the Foundation, via an additional opt-in mechanism, baked into the protocol.
- To give an alterative to redistribution of either, the current, block distribution structure or transaction fee structure.
- The foundation will use this funding to fund zec development for the lifetime of the ZEC Coin.
- To give a strong indication to the community and users that they have freedom to decide what they do with their coins and donations.
Rational for baking addresses into the coinbase:
- Baking the addresses into the codebase you do not need the wallet software or pool software to keep track of donation addresses.
- It prevents wallets sending to old addresses.
- Should the addresses change, their is no need for wallet maintainer to reissue their software build.
- It makes it easier for pools to add support and prove that they are actually donating the % they say they are.
Motivation for proposal:
- To ensure that there is continual and indefinite funding of the Foundation.
- To give users an opt-in choice via software or service provider.
- To bake the reward structure into the protocol
- Longevity of zcash infrastructure and protocol
Out of Scope:
- Block distribution is not directly covered by this zip. This is because there will be a time when all blocks are distributed, but technology will still advance.
- 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.
- Use ability is not impacted
- security is not lessened
- this must not contradict the main use cases for zcash.
- this feature must be opt-in via a user set flag
Further discussion is needed on:
- Block sizes, this may impact the motivation to increase block sizes should that need arise.
- Details of technical adjustment.
- Cost to implement
- Manhours needed to implement and test
- Is this a trivial adjustment or not
- 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
- What if the mining software signals donation/no donation but the pool software is set to the opposite?
- This adds complexity to the protocol
- This does not add anything that cannot already be done under the current protocol.
- Other coins have added a similar mechanism and some mining pools do support this feature. (GRIN?)
- Wallet creators already have a feature similar to this in their software, but at the software level.