mirror of https://github.com/zcash/zips.git
383 lines
25 KiB
HTML
383 lines
25 KiB
HTML
<!DOCTYPE html>
|
||
<html>
|
||
<head>
|
||
<title>Draft ecc-lockbox-disbursement: Deferred Dev Fund Lockbox Disbursement</title>
|
||
<meta charset="utf-8" />
|
||
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.16.11/dist/katex.min.css" integrity="sha384-nB0miv6/jRmo5UMMR1wu3Gz6NLsoTkbqJghGIsx//Rlm+ZU03BU6SQNC66uf4l5+" crossorigin="anonymous">
|
||
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.16.11/dist/katex.min.js" integrity="sha384-7zkQWkzuo3B5mTepMUcHkMB5jZaolc2xDwL6VFqjFALcbeS9Ggm/Yr2r3Dy4lfFg" crossorigin="anonymous"></script>
|
||
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.16.11/dist/contrib/auto-render.min.js" integrity="sha384-43gviWU0YVjaDtb/GhzOouOXtZMP/7XUzwPTstBeZFe/+rCMvRwr4yROQP43s0Xk" crossorigin="anonymous" onload="renderMathInElement(document.body);"></script>
|
||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css">
|
||
</head>
|
||
<body>
|
||
<pre><code>ZIP: XXX
|
||
Title: Deferred Dev Fund Lockbox Disbursement
|
||
Owners: Daira-Emma Hopwood <daira@jacaranda.org>
|
||
Kris Nuttycombe <kris@nutty.land>
|
||
Jack Grigg <jack@electriccoin.co>
|
||
Status: Draft
|
||
Category: Consensus / Process
|
||
Created: 2025-02-19
|
||
License: MIT
|
||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/989">https://github.com/zcash/zips/pull/989</a>>
|
||
<<a href="https://github.com/zcash/zips/pull/1014">https://github.com/zcash/zips/pull/1014</a>>
|
||
<<a href="https://github.com/zcash/zips/pull/1015">https://github.com/zcash/zips/pull/1015</a>>
|
||
</code></pre>
|
||
|
||
<h1 id="terminology"><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></h1>
|
||
|
||
<p>The key words “MUST”, “MUST NOT”, and “RECOMMENDED” in this document are
|
||
to be interpreted as described in BCP 14 <a href="#fn:1" id="fnref:1" title="see footnote" class="footnote"><sup>1</sup></a> when, and only when, they
|
||
appear in all capitals.</p>
|
||
|
||
<h1 id="abstract"><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></h1>
|
||
|
||
<p>This ZIP proposes an extension of protocol-based development funding, in the
|
||
context of multiple alternatives for distributing funds that have accrued to
|
||
the Deferred Dev Fund Lockbox. This proposal is intended to be evaluated in the
|
||
context of the Community And Coinholder Funding Model
|
||
<a href="#fn:2" id="fnref:2" title="see footnote" class="footnote"><sup>2</sup></a> and Zcash Governance Bloc
|
||
<a href="#fn:3" id="fnref:3" title="see footnote" class="footnote"><sup>3</sup></a> proposals; the mechanisms it describes are applicable to
|
||
both of these and may be applicable to other similar proposals as well.</p>
|
||
|
||
<p>At a high level, this ZIP proposes:</p>
|
||
|
||
<ul>
|
||
<li>A one-time disbursement of the full contents of the lockbox to a transparent
|
||
P2SH multisig address, at the time of the activation of this ZIP. The
|
||
key-holders for that address are then responsible for distributing the
|
||
resulting funds in the form of development grants, according to the rules set
|
||
by either <a href="#fn:2" title="see footnote" class="footnote"><sup>2</sup></a> or <a href="#fn:3" title="see footnote" class="footnote"><sup>3</sup></a>, or
|
||
another similar proposal.</li>
|
||
<li>Extension of protocol-based development funding blocks starting from the
|
||
scheduled end height of the current <code>FS_DEFERRED</code> and <code>FS_FPF_ZCG</code>
|
||
funding streams defined in ZIP 1015 <a href="#fn:4" id="fnref:4" title="see footnote" class="footnote"><sup>4</sup></a>.</li>
|
||
<li>A variety of different mechanisms that may be used for distributing funds
|
||
that accrue during the period of the extension, which may vary depending upon
|
||
the proposal that uses this mechanism.</li>
|
||
</ul>
|
||
|
||
<h1 id="requirements"><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></h1>
|
||
|
||
<ul>
|
||
<li>Funds are held in a multisig resistant to compromise of some of the parties'
|
||
keys, up to a given threshold.</li>
|
||
<li>No single party’s non-cooperation or loss of keys is able to cause any
|
||
Protocol-defined Ecosystem Funding to be locked up unrecoverably.</li>
|
||
<li>The funds previously accrued to the Deferred Dev Fund Lockbox as the activation
|
||
height of this ZIP will be usable immediately on activation.</li>
|
||
</ul>
|
||
|
||
<h1 id="specification"><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></h1>
|
||
|
||
<p>This ZIP proposes the creation of a new Zcash Development Fund. The balance of
|
||
this Fund consists of the contents of the ZIP 1015 Deferred Development Fund
|
||
Lockbox as of the activation height of this ZIP, plus any funds that later
|
||
accrue to either the lockbox or to one or more transparent multisig addresses
|
||
as specified by this ZIP.</p>
|
||
|
||
<h2 id="one-timelockboxdisbursement"><span class="section-heading">One-time lockbox disbursement</span><span class="section-anchor"> <a rel="bookmark" href="#one-timelockboxdisbursement"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
|
||
<p>The coinbase transaction of the activation block of this ZIP MUST include a
|
||
lockbox disbursement output to a 2-of-3 P2SH multisig with keys held by the
|
||
following “Key-Holder Organizations”: Zcash Foundation, the Electric Coin Company,
|
||
and Shielded Labs.</p>
|
||
|
||
<p>Let <span class="math">\(v\)</span> be the zatoshi amount in the Deferred Dev Fund Lockbox as of the end
|
||
of the block preceding the activation height. (<span class="math">\(v\)</span> can be predicted in advance
|
||
given that height.)</p>
|
||
|
||
<p>The additional coinbase output MUST contain at least one output that pays
|
||
<span class="math">\(v\)</span> zatoshi to the above P2SH multisig address, using a standard P2SH script
|
||
as specified in <a href="#fn:5" id="fnref:5" title="see footnote" class="footnote"><sup>5</sup></a>. <span class="math">\(v\)</span> zatoshi are added to the transparent
|
||
transaction value pool of the coinbase transaction to fund this output, and
|
||
deducted from the balance of the Deferred Dev Fund Lockbox.
|
||
The latter deduction occurs before any other change to the Deferred Dev Fund
|
||
Lockbox balance in the transaction, and MUST NOT cause the Deferred Dev Fund
|
||
Lockbox balance to become negative at that point.</p>
|
||
|
||
<p>Exactly one of the following options will also be taken. The proposal that
|
||
activates this ZIP must define values for the following two parameters:</p>
|
||
|
||
<ul>
|
||
<li><span class="math">\(\mathsf{stream\_value}\)</span>: the percentage of the block subsidy to send to
|
||
a new funding stream, as described in the options below.</li>
|
||
<li><span class="math">\(\mathsf{stream\_end\_height}\)</span>: The ending block height of that stream.</li>
|
||
</ul>
|
||
|
||
<p>Note: The value <span class="math">\(v\)</span> might need to be precalculated so that it is known at
|
||
the point when the relevant consensus check is done in node implementations.
|
||
If so, the specification should be written in terms of the precalculated
|
||
value.</p>
|
||
|
||
<h3 id="rationaleforusingap2shoutput"><span class="section-heading">Rationale for using a P2SH output</span><span class="section-anchor"> <a rel="bookmark" href="#rationaleforusingap2shoutput"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||
|
||
<details>
|
||
<summary>
|
||
Rationale
|
||
</summary>
|
||
|
||
<p>The keyholders may desire the grant-filling transactions use transparent inputs or
|
||
shielded inputs. Regardless of their desire, the one-time disbursement must at some
|
||
point go through a shielded pool, because this ZIP does not propose altering the
|
||
consensus rules for spendability of transparent coinbase outputs. That would be far
|
||
too complex a change for the intended scope.</p>
|
||
|
||
<p>This means that by using a P2SH output in consensus, the Key-Holder Organizations
|
||
will need to spend the one-time disbursement completely into a shielded output.
|
||
This spend would presumably be to a FROST address in order to maintain consistent
|
||
security position over the lockbox funds; perhaps publishing the viewing key to
|
||
maintain visibility.</p>
|
||
|
||
<p>An alternative proposal could require the one-time disbursement to directly create
|
||
a shielded output to the FROST address. This would mean that the Key-Holder
|
||
Organizations could immediately start disbursing grants (although the 100-block
|
||
coinbase maturity is not particularly onerous).</p>
|
||
|
||
<p>This ZIP instead uses a P2SH output for two reasons:</p>
|
||
|
||
<ul>
|
||
<li>Using a shielded output would place a requirement on the miner (or mining pool)
|
||
to be able to create shielded coinbase outputs. Technically that requirement
|
||
is already in the consensus rules, but it has never before been exercised,
|
||
since no Funding Stream has been defined with a shielded address.</li>
|
||
<li>Using a shielded output in the context of this ZIP would mean that the FROST
|
||
address needs to be derived well in advance of NU activation. At the time of
|
||
writing (May 2025), ZIP 312 does not specify key generation, and it would be
|
||
undesirable to couple the specification process for that to this ZIP. P2SH
|
||
multisig addresses by comparison have a stable and well understood format and
|
||
generation process.
|
||
</details></li>
|
||
</ul>
|
||
|
||
<h3 id="changetothezcashprotocolspecification"><span class="section-heading">Change to the Zcash Protocol Specification</span><span class="section-anchor"> <a rel="bookmark" href="#changetothezcashprotocolspecification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||
|
||
<p>In section <strong>7.1.2 Transaction Consensus Rules</strong> <a href="#fn:6" id="fnref:6" title="see footnote" class="footnote"><sup>6</sup></a>, change:</p>
|
||
|
||
<blockquote>
|
||
<ul>
|
||
<li>A transaction MUST NOT spend a transparent output of a coinbase transaction
|
||
from a block less than 100 blocks prior to the spend. Note that transparent
|
||
outputs of coinbase transactions include Founders’ Reward outputs and
|
||
transparent funding stream outputs.</li>
|
||
</ul>
|
||
</blockquote>
|
||
|
||
<p>to</p>
|
||
|
||
<blockquote>
|
||
<ul>
|
||
<li>A transaction MUST NOT spend a transparent output of a coinbase transaction
|
||
from a block less than 100 blocks prior to the spend. Note that transparent
|
||
outputs of coinbase transactions include Founders’ Reward outputs,
|
||
transparent funding stream outputs <a href="zip-0207">[ZIP-207]</a>, and lockbox
|
||
disbursement outputs {{ reference to this ZIP section }}.</li>
|
||
</ul>
|
||
</blockquote>
|
||
|
||
<h2 id="option1:extendthelockboxfundingstream"><span class="section-heading">Option 1: Extend the lockbox funding stream</span><span class="section-anchor"> <a rel="bookmark" href="#option1:extendthelockboxfundingstream"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
|
||
<p>The <code>FS_DEFERRED</code> lockbox funding stream is set to receive
|
||
<span class="math">\(\mathsf{stream\_value}\%\)</span> of the block subsidy and is extended until block
|
||
height <span class="math">\(\mathsf{stream\_end\_height}\)</span>. Both of these parameters must be
|
||
specified by the proposal under which this ZIP is activated.</p>
|
||
|
||
<h3 id="rationaleforoption1"><span class="section-heading">Rationale for Option 1</span><span class="section-anchor"> <a rel="bookmark" href="#rationaleforoption1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||
|
||
<details>
|
||
<summary>
|
||
Rationale
|
||
</summary>
|
||
|
||
<p>Performing a one-time disbursement to a P2SH multisig address will provide a
|
||
source of grant funding for a limited period, allowing time for a lockbox
|
||
disbursement mechanism to be specified and deployed, as originally intended by
|
||
ZIP 1015 <a href="#fn:7" id="fnref:7" title="see footnote" class="footnote"><sup>7</sup></a>.</p>
|
||
|
||
<p>In particular, this provides an opportunity for transaction format changes that
|
||
may be required for such a mechanism to be included in the v6 transaction
|
||
format <a href="#fn:8" id="fnref:8" title="see footnote" class="footnote"><sup>8</sup></a>. It is desirable to limit the frequency of transaction
|
||
format changes because such changes are disruptive to the ecosystem. It is not
|
||
necessary that protocol rules for disbursement actually be implemented until
|
||
after the transaction format changes are live on the network. It is RECOMMENDED
|
||
that any such transaction format changes be included in the upcoming v6
|
||
transaction format in order to avoid such disruption.</p>
|
||
|
||
<p>By implementing a one-time disbursement along with a continuation of the
|
||
<code>FS_DEFERRED</code> stream, we prioritize both the availability of grant funding
|
||
and the implementation of a more flexible and secure mechanism for disbursement
|
||
from the lockbox — making it possible to address the need to rotate keys and/or
|
||
alter the set of key holders in a way that reverting to hard-coded output
|
||
addresses for repeated disbursements would not.
|
||
</details></p>
|
||
|
||
<h2 id="option2:reverttohard-codedoutputaddress"><span class="section-heading">Option 2: Revert to hard-coded output address</span><span class="section-anchor"> <a rel="bookmark" href="#option2:reverttohard-codedoutputaddress"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
|
||
<p>A new funding stream consisting of <span class="math">\(\mathsf{stream\_value}\%\)</span> of the block
|
||
subsidy is defined to begin when the existing ZIP 1015 funding streams
|
||
<a href="#fn:4" title="see footnote" class="footnote"><sup>4</sup></a> end. The new streams will distribute funds to a
|
||
3-of-5 P2SH multisig with keys held by the same Key-Holder Organizations as
|
||
above. The resulting Fund is considered to include both this stream of funds,
|
||
and funds from the one-time lockbox disbursement described above.</p>
|
||
|
||
<p>Option 2 can be realized by either of the following mechanisms:</p>
|
||
|
||
<h3 id="mechanism2a:classicfundingstream"><span class="section-heading">Mechanism 2a: Classic funding stream</span><span class="section-anchor"> <a rel="bookmark" href="#mechanism2a:classicfundingstream"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||
|
||
<p>A new funding stream is defined that pays directly to the above-mentioned 3-of-5
|
||
multisig address on a block-by-block basis. It is defined to start at the end
|
||
height of the existing <code>FS_DEFERRED</code> funding stream and end at
|
||
<span class="math">\(\mathsf{stream\_end\_height}\)</span> and consists of <span class="math">\(\mathsf{stream\_value}\%\)</span> of the
|
||
block subsidy.</p>
|
||
|
||
<h3 id="mechanism2b:periodiclockboxdisbursement"><span class="section-heading">Mechanism 2b: Periodic lockbox disbursement</span><span class="section-anchor"> <a rel="bookmark" href="#mechanism2b:periodiclockboxdisbursement"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||
|
||
<p>Constant parameter <span class="math">\(N = 35000\)</span> blocks <span class="math">\(=
|
||
\mathsf{PostBlossomHalvingInterval}/48\)</span> (i.e. approximately one month of
|
||
blocks).</p>
|
||
|
||
<p>The <code>FS_DEFERRED</code> lockbox funding stream is extended to end at height
|
||
<span class="math">\(\mathsf{stream\_end\_height}\)</span> and has its per-block output value set to
|
||
<span class="math">\(\mathsf{stream\_value}\%\)</span>. A consensus rule is added to disburse from the
|
||
Deferred Dev Fund Lockbox to a 2-of-3 P2SH multisig with keys held by the same
|
||
Key-Holder Organizations as above, starting at block height
|
||
<span class="math">\(\mathsf{activation\_height} + N\)</span> and continuing at periodic intervals of <span class="math">\(N\)</span>
|
||
blocks until <span class="math">\(\mathsf{stream\_end\_height}\)</span>. Each disbursement empties the
|
||
lockbox.</p>
|
||
|
||
<p>This is equivalent to specifying
|
||
<span class="math">\(\frac{\mathstrut\mathsf{stream\_end\_height} \,-\, \mathsf{activation\_height}}{N}\)</span> <a href="#one-timelockboxdisbursement">One-time lockbox disbursement</a>s,
|
||
that all output to the same address.</p>
|
||
|
||
<h4 id="rationaleforperiodicdisbursement"><span class="section-heading">Rationale for periodic disbursement</span><span class="section-anchor"> <a rel="bookmark" href="#rationaleforperiodicdisbursement"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||
|
||
<details>
|
||
<summary>
|
||
Rationale
|
||
</summary>
|
||
|
||
<p>Classic funding streams <a href="#fn:9" id="fnref:9" title="see footnote" class="footnote"><sup>9</sup></a> produce many small output values, due to
|
||
only being able to direct funds from a single block’s subsidy at a time. This
|
||
creates operational burdens to utilizing the funds — in particular due to block
|
||
and transaction sizes limiting how many outputs can be combined at once, which
|
||
increases the number of required transactions and correspondingly the overall
|
||
fee.</p>
|
||
|
||
<p>The periodic lockbox disbursement mechanism can produce the same effective
|
||
funding stream, but with aggregation performed for free: the output to the
|
||
funding stream recipient is aggregated into larger outputs every <span class="math">\(N\)</span> blocks. In
|
||
the specific case of Mechanism 2b, the recipient multisig address would receive
|
||
around 40 outputs, instead of around 1,300,000.
|
||
</details></p>
|
||
|
||
<h1 id="privacyandsecurityimplications"><span class="section-heading">Privacy and Security Implications</span><span class="section-anchor"> <a rel="bookmark" href="#privacyandsecurityimplications"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h1>
|
||
|
||
<p>As development funding is a public good on the Zcash network, there are not
|
||
relevant privacy concerns related to this proposal; all disbursement of
|
||
(but not necessarily subsequent distribution) of development funds is
|
||
transparent and auditable by any participant in the network.</p>
|
||
|
||
<h2 id="securityimplicationsoftheone-timelockboxdisbursement"><span class="section-heading">Security implications of the One-Time Lockbox Disbursement</span><span class="section-anchor"> <a rel="bookmark" href="#securityimplicationsoftheone-timelockboxdisbursement"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
|
||
<p>After the activation block of this ZIP has been mined, all development funds
|
||
previously accrued to the in-protocol lockbox will be held instead by a 2-of-3
|
||
multisig address. The key-holders for this address will have the capability to
|
||
spend these funds. Compromise or loss of 2 of these 3 keys would result in
|
||
total loss of funds; as such, in the event of the compromise or loss of a
|
||
single key, the Key-Holders MUST establish a new multisig key set and address,
|
||
and transfer remaining unspent funds held by the original address before
|
||
additional loss or compromise occurs.</p>
|
||
|
||
<p>Because this is a one-time disbursement, additional key rotation infrastructure
|
||
is not required.</p>
|
||
|
||
<h2 id="securityimplicationsforoption1"><span class="section-heading">Security implications for Option 1</span><span class="section-anchor"> <a rel="bookmark" href="#securityimplicationsforoption1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
|
||
<p>Funds will continue to securely accrue to the Deferred Development Lockbox
|
||
until a disbursement mechanism for the lockbox is implemented in a future
|
||
network upgrade. Such a disbursement mechanism should be designed to include an
|
||
in-protocol option for key rotation, such that it is not necessary to perform a
|
||
network upgrade to recover from key loss or compromise, or to change the size
|
||
of the signing set or the number of signatures required to reach threshold.</p>
|
||
|
||
<h2 id="securityimplicationsformechanism2a"><span class="section-heading">Security implications for Mechanism 2a</span><span class="section-anchor"> <a rel="bookmark" href="#securityimplicationsformechanism2a"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
|
||
<p>As of the activation height of this ZIP, development funds will begin accruing
|
||
as additional outputs spendable by a 2-of-3 multisig address on a
|
||
block-by-block basis. Key-Holders will need to perform regular multiparty
|
||
signing ceremonies in order to shield the resulting coinbase outputs. Each such
|
||
signing ceremony involves shared spending authority being used to sign
|
||
thousands of inputs to large shielding transactions; for practical reasons,
|
||
this is often handled using a scripted process that has spending authority over
|
||
these funds. This process is an attractive target for compromise; for this
|
||
reason it is RECOMMENDED that address rotation (in this case, by means of
|
||
hard-coding a sequence of addresses, each of which receives a time-bounded
|
||
subset of the block reward fractional outputs) be implemented, as was done
|
||
for the ECC funding stream described in ZIP 1014 <a href="#fn:10" id="fnref:10" title="see footnote" class="footnote"><sup>10</sup></a>.</p>
|
||
|
||
<p>In the case of key compromise or loss, it may be necessary to perform an
|
||
emergency Network Upgrade to perform a manual key rotation to ensure that
|
||
future development funds are not lost.</p>
|
||
|
||
<h2 id="securityimplicationsformechanism2b"><span class="section-heading">Security implications for Mechanism 2b</span><span class="section-anchor"> <a rel="bookmark" href="#securityimplicationsformechanism2b"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
|
||
<p>Due to the aggregation of funds recommended by Option 2b, it is no longer
|
||
necessary to use scripts with spending privileges to perform shielding and/or
|
||
distribution operations; instead, these operations can be performed by human
|
||
operators using an interactive protocol that does not require sharing spending
|
||
key material.</p>
|
||
|
||
<p>As with Option 2a, key compromise or loss would require an emergency Network
|
||
Upgrade to perform manual key rotation to mitigate the potential for loss of
|
||
funds.</p>
|
||
|
||
<h1 id="references"><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></h1>
|
||
|
||
<div class="footnotes">
|
||
<hr />
|
||
<ol>
|
||
|
||
<li id="fn:1">
|
||
<p><a href="https://www.rfc-editor.org/info/bcp14">Information on BCP 14 — “RFC 2119: Key words for use in RFCs to Indicate Requirement Levels” and “RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”</a> <a href="#fnref:1" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
||
</li>
|
||
|
||
<li id="fn:2">
|
||
<p><a href="draft-ecc-community-and-coinholder">draft-ecc-community-and-coinholder: Community and Coinholder Funding Model</a> <a href="#fnref:2" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
||
</li>
|
||
|
||
<li id="fn:3">
|
||
<p><a href="draft-ecc-zbloc">draft-ecc-zbloc: Zcash Governance Bloc</a> <a href="#fnref:3" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
||
</li>
|
||
|
||
<li id="fn:4">
|
||
<p><a href="zip-1015#funding-streams">ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Funding Streams</a> <a href="#fnref:4" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
||
</li>
|
||
|
||
<li id="fn:5">
|
||
<p><a href="https://developer.bitcoin.org/devguide/transactions.html#multisig">Bitcoin Developer Documentation — Pay To Script Hash (P2SH) — Multisig</a> <a href="#fnref:5" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
||
</li>
|
||
|
||
<li id="fn:6">
|
||
<p><a href="protocol/protocol.pdf#txnconsensus">Zcash Protocol Specification, Version 2024.5.1. Section 7.1.2: Transaction Consensus Rules</a> <a href="#fnref:6" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
||
</li>
|
||
|
||
<li id="fn:7">
|
||
<p><a href="zip-1015">ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding</a> <a href="#fnref:7" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
||
</li>
|
||
|
||
<li id="fn:8">
|
||
<p><a href="zip-0230">ZIP 230: Version 6 Transaction Format</a> <a href="#fnref:8" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
||
</li>
|
||
|
||
<li id="fn:9">
|
||
<p><a href="zip-0207">ZIP 207: Funding Streams</a> <a href="#fnref:9" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
||
</li>
|
||
|
||
<li id="fn:10">
|
||
<p>zip-1014 <a href="#fnref:10" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
||
</li>
|
||
|
||
</ol>
|
||
</div>
|
||
</body>
|
||
</html>
|