mirror of https://github.com/zcash/zips.git
Specify that shielded outputs of coinbase transactions MUST use v2 note plaintexts after Canopy activation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
9b55332fc2
commit
5689d59d32
|
|
@ -8950,6 +8950,9 @@ $\versionField \geq 4$ and $\nShieldedSpend + \nShieldedOutput > 0$.
|
|||
\heartwoodonwarditem{All \Sapling outputs in \coinbaseTransactions{} \MUST decrypt to a \notePlaintext,
|
||||
i.e. the procedure in \crossref{saplingdecryptovk} does not return $\bot$, using a sequence of
|
||||
$32$ zero bytes as the \outgoingViewingKey.}
|
||||
\canopyonwarditem{Any \Sapling output of a \coinbaseTransaction decrypted to a \notePlaintext according
|
||||
to the preceding rule \MUST have \notePlaintextLeadByte equal to $\hexint{02}$. (This applies even
|
||||
during the ``grace period'' specified in \cite{ZIP-212}.)}
|
||||
\item \todo{Other rules inherited from \Bitcoin.}
|
||||
\end{consensusrules}
|
||||
|
||||
|
|
@ -8998,6 +9001,11 @@ each \spendDescription (\crossref{spendencoding}), and each \outputDescription (
|
|||
to spend coinbase outputs only in \transactions with no \transparent outputs, applied to
|
||||
\emph{all} coinbase outputs.
|
||||
}
|
||||
\canopy{
|
||||
\item The rule that \Sapling outputs in \coinbaseTransactions \MUST decrypt to a \notePlaintext
|
||||
with lead byte $\hexint{02}$, also applies to \fundingStream outputs that specify \Sapling
|
||||
\paymentAddresses, if there are any.
|
||||
}
|
||||
\end{pnotes}
|
||||
|
||||
\introlist
|
||||
|
|
@ -10510,6 +10518,10 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
|
|||
\item Repair the argument for $\GroupJHash{\URS}$ being usable as a random oracle, which
|
||||
previously depended on $\abstJ$ being injective.
|
||||
}
|
||||
\canopy{
|
||||
\item Specify that \shieldedOutputs of \coinbaseTransactions \MUST use v2 \notePlaintexts after
|
||||
\Canopy activation.
|
||||
}
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -31,14 +31,14 @@ License: MIT</pre>
|
|||
</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal specifies a mechanism to support funding streams, distributed from a portion of the block subsidy for a specified range of block heights.</p>
|
||||
<p>This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 <a id="id7" class="footnote_reference" href="#zip-0214">11</a>. It should be read in conjunction with ZIP 1014 <a id="id8" class="footnote_reference" href="#zip-1014">13</a>, which describes the high-level requirements for that fund.</p>
|
||||
<p>This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 <a id="id7" class="footnote_reference" href="#zip-0214">12</a>. It should be read in conjunction with ZIP 1014 <a id="id8" class="footnote_reference" href="#zip-1014">14</a>, which describes the high-level requirements for that fund.</p>
|
||||
</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Motivation for the Zcash Development Fund is considered in ZIP 1014 <a id="id9" class="footnote_reference" href="#zip-1014">13</a>.</p>
|
||||
<p>Motivation for the Zcash Development Fund is considered in ZIP 1014 <a id="id9" class="footnote_reference" href="#zip-1014">14</a>.</p>
|
||||
<p>This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP is being reintroduced for that purpose in order to reuse specification, analysis, and implementation effort.</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 <a id="id10" class="footnote_reference" href="#zip-0214">11</a> to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 <a id="id11" class="footnote_reference" href="#zip-1014">13</a>, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.</p>
|
||||
<p>The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 <a id="id10" class="footnote_reference" href="#zip-0214">12</a> to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 <a id="id11" class="footnote_reference" href="#zip-1014">14</a>, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.</p>
|
||||
<p>As for the original Founders' Reward, addresses for a given funding stream are changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.</p>
|
||||
</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -202,9 +202,11 @@ License: MIT</pre>
|
|||
<li>The existing consensus rule for payment of the Founders' Reward <a id="id17" class="footnote_reference" href="#protocol-foundersreward">6</a> is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)</li>
|
||||
<li>The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.</li>
|
||||
<li>The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form <code>OP_HASH160 RedeemScriptHash(height) OP_EQUAL</code> as the <code>scriptPubKey</code>.</li>
|
||||
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="id18" class="footnote_reference" href="#zip-0213">10</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key.</li>
|
||||
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="id18" class="footnote_reference" href="#zip-0213">11</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be
|
||||
<span class="math">\(\mathbf{0x02}\)</span>
|
||||
, as specified in <a id="id19" class="footnote_reference" href="#zip-0212">10</a>.</li>
|
||||
</ul>
|
||||
<p>For the funding stream definitions to be activated at Canopy, see ZIP 214. <a id="id19" class="footnote_reference" href="#zip-0214">11</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id20" class="footnote_reference" href="#zip-0000">7</a></p>
|
||||
<p>For the funding stream definitions to be activated at Canopy, see ZIP 214. <a id="id20" class="footnote_reference" href="#zip-0214">12</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id21" class="footnote_reference" href="#zip-0000">7</a></p>
|
||||
</section>
|
||||
<section id="example-implementation"><h3><span class="section-heading">Example implementation</span><span class="section-anchor"> <a rel="bookmark" href="#example-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<pre data-language="cpp"><span class="k">struct</span> <span class="n">FundingPeriod</span> <span class="p">{</span>
|
||||
|
|
@ -369,7 +371,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal is intended to be deployed with Canopy. <a id="id21" class="footnote_reference" href="#zip-0251">12</a></p>
|
||||
<p>This proposal is intended to be deployed with Canopy. <a id="id22" class="footnote_reference" href="#zip-0251">13</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
|
||||
|
|
@ -450,10 +452,18 @@ License: MIT</pre>
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0213" class="footnote">
|
||||
<table id="zip-0212" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<td><a href="zip-0212">ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0213" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<td><a href="zip-0213">ZIP 213: Shielded Coinbase</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -461,7 +471,7 @@ License: MIT</pre>
|
|||
<table id="zip-0214" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<th>12</th>
|
||||
<td><a href="zip-0214">ZIP 214: Consensus rules for a Zcash Development Fund</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -469,7 +479,7 @@ License: MIT</pre>
|
|||
<table id="zip-0251" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<th>13</th>
|
||||
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -477,7 +487,7 @@ License: MIT</pre>
|
|||
<table id="zip-1014" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>13</th>
|
||||
<th>14</th>
|
||||
<td><a href="zip-1014">ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
|
|||
|
|
@ -198,6 +198,8 @@ Once the Canopy network upgrade activates:
|
|||
That is, all Sapling outputs in coinbase transactions (including, but not
|
||||
limited to, outputs for funding streams) MUST have valid note commitments
|
||||
when recovered using a 32-byte array of zeroes as the outgoing viewing key.
|
||||
In this case the note plaintext lead byte MUST be :math:`\mathbf{0x02}`, as
|
||||
specified in [#zip-0212]_.
|
||||
|
||||
For the funding stream definitions to be activated at Canopy, see ZIP 214. [#zip-0214]_
|
||||
Funding stream definitions can be added, changed, or deleted in ZIPs associated
|
||||
|
|
@ -404,6 +406,7 @@ References
|
|||
.. [#zip-0000] `ZIP 0: ZIP Process <zip-0000.rst>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
|
||||
.. [#zip-0212] `ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <zip-0212.rst>`_
|
||||
.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_
|
||||
.. [#zip-0214] `ZIP 214: Consensus rules for a Zcash Development Fund <zip-0214.rst>`_
|
||||
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_
|
||||
|
|
|
|||
|
|
@ -161,6 +161,11 @@ License: MIT</pre>
|
|||
and check that
|
||||
<span class="math">\(\mathsf{epk} = [\mathsf{esk}] \mathsf{g_d}\)</span>
|
||||
and fail decryption if this check is not satisfied.</p>
|
||||
<p>TODO: grace period.</p>
|
||||
</section>
|
||||
<section id="consensus-rule-change-for-coinbase-transactions"><h3><span class="section-heading">Consensus rule change for coinbase transactions</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-rule-change-for-coinbase-transactions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>After the activation of this ZIP, any Sapling output of a coinbase transaction that is decrypted to a note plaintext as specified in <a id="id11" class="footnote_reference" href="#zip-0213">10</a>, MUST have note plaintext lead byte equal to 0x02.</p>
|
||||
<p>This applies even during the “grace period”, and also applies to funding stream outputs <a id="id12" class="footnote_reference" href="#zip-0207">9</a> sent to shielded payment addresses, if there are any.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -177,6 +182,7 @@ License: MIT</pre>
|
|||
itself, but this appears to be an unnecessary complication and is likely slower than just supplying
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
.</p>
|
||||
<p>TODO: rationale for grace period.</p>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The changes made in this proposal prevent an interactive attack that could link together diversified addresses by only breaking the knowledge soundness assumption of the zk-SNARK. It is already assumed that the adversary cannot defeat the EC-DDH assumption of the Jubjub elliptic curve, for it could perform a linkability attack trivially in that case.</p>
|
||||
|
|
@ -257,6 +263,22 @@ License: MIT</pre>
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0207" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="zip-0207">ZIP 207: Split Founders' Reward</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0213" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<td><a href="zip-0213">ZIP 213: Shielded Coinbase</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
|
|
|
|||
18
zip-0212.rst
18
zip-0212.rst
|
|
@ -151,6 +151,19 @@ Further, the recipient MUST compute :math:`\mathsf{esk}` as
|
|||
that :math:`\mathsf{epk} = [\mathsf{esk}] \mathsf{g_d}` and fail decryption
|
||||
if this check is not satisfied.
|
||||
|
||||
TODO: grace period.
|
||||
|
||||
Consensus rule change for coinbase transactions
|
||||
-----------------------------------------------
|
||||
|
||||
After the activation of this ZIP, any Sapling output of a coinbase transaction
|
||||
that is decrypted to a note plaintext as specified in [#zip-0213]_, MUST have
|
||||
note plaintext lead byte equal to 0x02.
|
||||
|
||||
This applies even during the “grace period”, and also applies to funding stream
|
||||
outputs [#zip-0207]_ sent to shielded payment addresses, if there are any.
|
||||
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
|
|
@ -175,6 +188,9 @@ It is possible to transmit a signature of knowledge of a correct
|
|||
to be an unnecessary complication and is likely slower than just supplying
|
||||
:math:`\mathsf{esk}`.
|
||||
|
||||
TODO: rationale for grace period.
|
||||
|
||||
|
||||
Security and Privacy Considerations
|
||||
===================================
|
||||
|
||||
|
|
@ -214,3 +230,5 @@ References
|
|||
.. [#saplingdecryptivk] `Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#saplingdecryptivk>`_
|
||||
.. [#saplingdecryptovk] `Section 4.17.3: Decryption using a Full Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#saplingdecryptovk>`_
|
||||
.. [#saplingsend] `Section 4.6.2: Sending Notes (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#saplingsend>`_
|
||||
.. [#zip-0207] `ZIP 207: Split Founders' Reward <zip-0207.rst>`_
|
||||
.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_
|
||||
|
|
|
|||
Loading…
Reference in New Issue