mirror of https://github.com/zcash/zips.git
198 lines
8.5 KiB
ReStructuredText
198 lines
8.5 KiB
ReStructuredText
|
::
|
|||
|
|
|||
|
ZIP: 1002
|
|||
|
Title: Opt-in Donation Feature
|
|||
|
Owner: mistfpga (zcash forums) <steve@mistfpga.net>
|
|||
|
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
|
|||
|
============
|
|||
|
|
|||
|
* 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 [Editor's note: this was 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's 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's 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/>`_
|