mirror of https://github.com/zcash/zips.git
201 lines
8.5 KiB
ReStructuredText
201 lines
8.5 KiB
ReStructuredText
::
|
||
|
||
ZIP: 1002
|
||
Title: Opt-in Donation Feature
|
||
Owner: mistfpga (zcash forums) <steve@mistfpga.net>
|
||
Status: Draft
|
||
Category: Standards Track
|
||
Created: 2019-07-17
|
||
License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/>
|
||
Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-opt-in-protocol-level-development-donation-option/33846>
|
||
|
||
|
||
Terminology
|
||
===========
|
||
|
||
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this
|
||
document are to be interpreted as described in RFC 2119. [#RFC2119]_
|
||
|
||
This ZIP defines 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
|
||
primarily refers to 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 in which a party controls the
|
||
private keys of another party; mining pools and online wallets are examples.
|
||
* Mining is defined as the action of processing transactions, so this would
|
||
include proof of stake, if Zcash would switch to that.
|
||
* User is defined as anyone that uses ZEC or another coin that adopts this
|
||
ZIP.
|
||
* Mining coins transferred via fees are considered rewards (infinite), coins
|
||
generated via block generation are considered distribution (finite).
|
||
* Opt-in vs 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.
|
||
* 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 that is collected by the miner of that
|
||
block.
|
||
* Transaction donation is an optional signalling string that creates a payment
|
||
to the coins base donations.
|
||
* Block Reward is defined as block distribution plus mining fees.
|
||
* Spirit is defined as what is the intended outcome of the ZIP. [#spirit]_
|
||
|
||
.. [#spirit] If there is contradiction between Spirit and any other part of
|
||
the proposal that needs to be addressed, in the event it is not addressed
|
||
Spirit is assumed to overrule all.
|
||
|
||
|
||
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 a protocol-level opt-in for supporting the Zcash
|
||
network development (like the Founders’ Reward, 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.
|
||
|
||
|
||
Abstract
|
||
========
|
||
|
||
The spirit of this ZIP is:
|
||
|
||
* To allow continual funding of the Electric Coin Company, the Zcash Foundation,
|
||
or some combination of these should a user choose to do so.
|
||
* To add a genuine opt-in feature, which is done at the user's choice.
|
||
|
||
|
||
Motivation
|
||
==========
|
||
|
||
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
|
||
financial stability in order to 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).
|
||
|
||
|
||
Requirements
|
||
============
|
||
|
||
.. role:: editor-note
|
||
|
||
* An additional opt-in mechanism, baked into the protocol. This is a condition
|
||
of the Zcash Foundation too. [#foundation]_
|
||
* Give an alterative to redistribution of either the current block distribution
|
||
structure or the emission curve.
|
||
* The funding received by the Electric Coin Company and/or Zcash Foundation under
|
||
this proposal MUST only be used 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.
|
||
* Bake the addresses into the node codebase, in order that the wallet software
|
||
or pool software does not need to keep track of donation addresses.
|
||
* Prevent users from sending donations to old addresses.
|
||
* Make it easier for pools to add support and prove that they are actually
|
||
donating the percentage they say they are.
|
||
* Users MUST NOT be forced to signal.
|
||
|
||
.. [#foundation] The Zcash Foundation has stated (later clarified in
|
||
[#zfnd-guidance]_) that 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).
|
||
|
||
|
||
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 for, when using
|
||
a pool.
|
||
* 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 used or not.
|
||
|
||
:editor-note:`this proposal is being published as a ZIP for the purpose of
|
||
discussion and for the Zcash Foundation's sentiment collection process,
|
||
despite significant issues with lack of clarity in the above specification.`
|
||
|
||
|
||
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.
|
||
* Further note: If burn must be an option I would like to use something like the
|
||
"rolling burn" option. :editor-note:`this is not defined; it was intended that
|
||
another ZIP be written to define it, but that has not been done.`
|
||
|
||
|
||
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 Electric Coin Company and/or the Zcash Foundation close down,
|
||
will the donations:
|
||
|
||
- go to into the mining fee
|
||
- get burnt
|
||
- get sent as change to the original sender
|
||
- be distributed via some other mechanism?
|
||
|
||
|
||
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.
|
||
|
||
|
||
References
|
||
==========
|
||
|
||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||
.. [#zfnd-guidance] `Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. <https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/>`_
|