151 lines
14 KiB
HTML
151 lines
14 KiB
HTML
<!DOCTYPE html>
|
||
<html>
|
||
<head>
|
||
<title>ZIP 1002: Opt-in Donation Feature</title>
|
||
<meta charset="utf-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||
<body>
|
||
<section>
|
||
<pre>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 <<a href="https://creativecommons.org/licenses/by-sa/4.0/">https://creativecommons.org/licenses/by-sa/4.0/</a>>
|
||
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-opt-in-protocol-level-development-donation-option/33846">https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-opt-in-protocol-level-development-donation-option/33846</a>></pre>
|
||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">3</a></p>
|
||
<p>This ZIP defines these terms:</p>
|
||
<ul>
|
||
<li>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.</li>
|
||
<li>Mining software in the context of this ZIP refers to pool software, local mining software, or staking software.</li>
|
||
<li>Custodial services include any service in which a party controls the private keys of another party; mining pools and online wallets are examples.</li>
|
||
<li>Mining is defined as the action of processing transactions, so this would include proof of stake, if Zcash would switch to that.</li>
|
||
<li>User is defined as anyone that uses ZEC or another coin that adopts this ZIP.</li>
|
||
<li>Mining coins transferred via fees are considered rewards (infinite), coins generated via block generation are considered distribution (finite).</li>
|
||
<li>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.</li>
|
||
<li>Burning coins is purposefully taking them out of circulation forever at the protocol block distribution level.</li>
|
||
<li>Initial promise is defined as complete honour of distributing all rewards to the miner. - This is a non neutral phrase. I accept that.</li>
|
||
<li>Transaction sender is defined as anyone who sends a transaction across the Zcash network, be it t-t, z-z, t-z, z-t.</li>
|
||
<li>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.</li>
|
||
<li>Transaction donation is an optional signalling string that creates a payment to the coins base donations.</li>
|
||
<li>Block Reward is defined as block distribution plus mining fees.</li>
|
||
<li>Spirit is defined as what is the intended outcome of the ZIP. <a id="id2" class="footnote_reference" href="#spirit">1</a></li>
|
||
</ul>
|
||
<table id="spirit" class="footnote">
|
||
<tbody>
|
||
<tr>
|
||
<th>1</th>
|
||
<td>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.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</section>
|
||
<section id="out-of-scope-for-this-proposal"><h2><span class="section-heading">Out of Scope for this Proposal</span><span class="section-anchor"> <a rel="bookmark" href="#out-of-scope-for-this-proposal"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
<p>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).</p>
|
||
<p>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.</p>
|
||
</section>
|
||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
<p>The spirit of this ZIP is:</p>
|
||
<ul>
|
||
<li>To allow continual funding of the Electric Coin Company, the Zcash Foundation, or some combination of these should a user choose to do so.</li>
|
||
<li>To add a genuine opt-in feature, which is done at the user's choice.</li>
|
||
</ul>
|
||
</section>
|
||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
<p>Technology changes, and it changes fast. What works now, may be easily breakable in 10 years, 20 years and certainly 50 years.</p>
|
||
<p>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.</p>
|
||
<p>The only source of indefinite wealth transfer is transaction fees or donations. This ZIP is specifically about voluntary donations (including via mining fees).</p>
|
||
</section>
|
||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
<ul>
|
||
<li>An additional opt-in mechanism, baked into the protocol. This is a condition of the Zcash Foundation too. <a id="id3" class="footnote_reference" href="#foundation">2</a></li>
|
||
<li>Give an alterative to redistribution of either the current block distribution structure or the emission curve.</li>
|
||
<li>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.</li>
|
||
<li>To give a strong indication to the community and users that they have freedom to decide what they do with their coins and donations.</li>
|
||
<li>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.</li>
|
||
<li>Prevent users from sending donations to old addresses.</li>
|
||
<li>Make it easier for pools to add support and prove that they are actually donating the percentage they say they are.</li>
|
||
<li>Users MUST NOT be forced to signal.</li>
|
||
</ul>
|
||
<table id="foundation" class="footnote">
|
||
<tbody>
|
||
<tr>
|
||
<th>2</th>
|
||
<td>The Zcash Foundation has stated (later clarified in <a id="id4" class="footnote_reference" href="#zfnd-guidance">4</a>) 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).</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</section>
|
||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
<ul>
|
||
<li>This ZIP MUST enforce the initial promise as defined by default.</li>
|
||
<li>The official client MUST default to be counted as initial promise.</li>
|
||
<li>No signal MUST be counted as whatever the pool is signalling for, when using a pool.</li>
|
||
<li>Security MUST NOT be lessened.</li>
|
||
<li>This ZIP MAY be set to opt-in via a user set flag.</li>
|
||
<li>This ZIP MUST contain donation addresses in the coinbase, in a similar fashion to the current FR.</li>
|
||
<li>When sending transactions the sender MAY signal their donation.</li>
|
||
<li>A signal from a transaction sender MUST NOT override the default transaction processor signal for that transaction.</li>
|
||
<li>A transaction sender MAY elect to include separate donation fees which MUST NOT be overridden by the transaction processor if this used or not.</li>
|
||
</ul>
|
||
<p><span class="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.</span></p>
|
||
</section>
|
||
<section id="raised-objections-and-issues-so-far"><h2><span class="section-heading">Raised objections and issues so far</span><span class="section-anchor"> <a rel="bookmark" href="#raised-objections-and-issues-so-far"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
<ul>
|
||
<li>This adds complexity to the protocol, which is technically not needed and generally a bad idea.</li>
|
||
<li>This does not add anything that cannot already be done under the current protocol by users manually, although not to the same extent.</li>
|
||
<li>Block sizes, this may impact the motivation to increase block sizes should that need arise.</li>
|
||
<li>Signalling from shielded addresses to donations at taddresses?</li>
|
||
<li>Once zcash goes full z address, how will transparency of donations be proven?</li>
|
||
<li>ZEC is designed to not have high transaction fees or a secondary transaction fee market. <em>Is this a core principle?</em></li>
|
||
<li>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.</li>
|
||
<li>Further note: If burn must be an option I would like to use something like the "rolling burn" option. <span class="editor-note">this is not defined; it was intended that another ZIP be written to define it, but that has not been done.</span></li>
|
||
</ul>
|
||
</section>
|
||
<section id="implications-to-other-users"><h2><span class="section-heading">Implications to other users</span><span class="section-anchor"> <a rel="bookmark" href="#implications-to-other-users"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
<ul>
|
||
<li>Wallet development will need to be considered. Hopefully the requirements will lessen this impact after the first initial change.</li>
|
||
<li>What happens if the Electric Coin Company and/or the Zcash Foundation close down, will the donations:
|
||
<ul>
|
||
<li>go to into the mining fee</li>
|
||
<li>get burnt</li>
|
||
<li>get sent as change to the original sender</li>
|
||
<li>be distributed via some other mechanism?</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
<section id="technical-implementation"><h2><span class="section-heading">Technical implementation</span><span class="section-anchor"> <a rel="bookmark" href="#technical-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
<p>Stuff that is already implemented in some form or another:</p>
|
||
<ul>
|
||
<li>Optional fees are already implemented in some wallet software.</li>
|
||
<li>Optional fees already cannot be overridden by miners.</li>
|
||
<li>Hardcoded donation addresses are already baked into the protocol so it should be minor work to adjust them to the signalling addresses.</li>
|
||
<li>Hardcoded donation address already cannot be changed by pools or software.</li>
|
||
<li>Signalling could be handled at the pool level</li>
|
||
<li>Pools already add their own addresses to the coinbase, including donations.</li>
|
||
</ul>
|
||
</section>
|
||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
<table id="rfc2119" class="footnote">
|
||
<tbody>
|
||
<tr>
|
||
<th>3</th>
|
||
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<table id="zfnd-guidance" class="footnote">
|
||
<tbody>
|
||
<tr>
|
||
<th>4</th>
|
||
<td><a href="https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/">Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019.</a></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</section>
|
||
</section>
|
||
</body>
|
||
</html> |