zips/zip-1002.rst

::

  ZIP: 1002
  Title: Opt-in Donation Feature
  Owner: mistfpga (zcash forums) <steve@mistfpga.net>
  Status: Obsolete
  Category: Consensus Process
  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] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#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/>`_