mirror of https://github.com/zcash/zips.git
Use "validate" rather than "verify" for signature validation in ZIPs.
"Validate" is also used for blocks and transactions, but not for proofs, commitments, or Merkle paths. The same change will be made to the protocol specification in the next version. Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
092e79e017
commit
cf70811274
|
|
@ -66,7 +66,7 @@ Index of ZIPs
|
|||
<tr> <th>ZIP</th> <th>Title</th> <th>Status</th> </tr>
|
||||
<tr> <td>0</td> <td class="left"><a href="zip-0000.rst">ZIP Process</a></td> <td>Active</td>
|
||||
<tr> <td>32</td> <td class="left"><a href="zip-0032.rst">Shielded Hierarchical Deterministic Wallets</a></td> <td>Final</td>
|
||||
<tr> <td>143</td> <td class="left"><a href="zip-0143.rst">Transaction Signature Verification for Overwinter</a></td> <td>Final</td>
|
||||
<tr> <td>143</td> <td class="left"><a href="zip-0143.rst">Transaction Signature Validation for Overwinter</a></td> <td>Final</td>
|
||||
<tr> <td>173</td> <td class="left"><a href="zip-0173.rst">Bech32 Format</a></td> <td>Final</td>
|
||||
<tr> <td>200</td> <td class="left"><a href="zip-0200.rst">Network Upgrade Mechanism</a></td> <td>Final</td>
|
||||
<tr> <td>201</td> <td class="left"><a href="zip-0201.rst">Network Peer Management for Overwinter</a></td> <td>Final</td>
|
||||
|
|
@ -82,9 +82,9 @@ Index of ZIPs
|
|||
<tr> <td>212</td> <td class="left"><a href="zip-0212.rst">Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td> <td>Proposed</td>
|
||||
<tr> <td>213</td> <td class="left"><a href="zip-0213.rst">Shielded Coinbase</a></td> <td>Implemented (zcashd)</td>
|
||||
<tr> <td>214</td> <td class="left"><a href="zip-0214.rst">Consensus rules for a Zcash Development Fund</a></td> <td>Proposed</td>
|
||||
<tr> <td>215</td> <td class="left"><a href="zip-0215.rst">Explicitly define Ed25519 validation rules</a></td> <td>Proposed</td>
|
||||
<tr> <td>215</td> <td class="left"><a href="zip-0215.rst">Explicitly Defining and Modifying Ed25519 Validation Rules</a></td> <td>Proposed</td>
|
||||
<tr> <td>221</td> <td class="left"><a href="zip-0221.rst">FlyClient - Consensus-Layer Changes</a></td> <td>Implemented (zcashd)</td>
|
||||
<tr> <td>243</td> <td class="left"><a href="zip-0243.rst">Transaction Signature Verification for Sapling</a></td> <td>Final</td>
|
||||
<tr> <td>243</td> <td class="left"><a href="zip-0243.rst">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
|
||||
<tr> <td>250</td> <td class="left"><a href="zip-0250.rst">Deployment of the Heartwood Network Upgrade</a></td> <td>Implemented (zcashd)</td>
|
||||
<tr> <td>251</td> <td class="left"><a href="zip-0251.rst">Deployment of the Canopy Network Upgrade</a></td> <td>Proposed</td>
|
||||
<tr> <td>308</td> <td class="left"><a href="zip-0308.rst">Sprout to Sapling Migration</a></td> <td>Final</td>
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@
|
|||
<tr> <th>ZIP</th> <th>Title</th> <th>Status</th> </tr>
|
||||
<tr> <td>0</td> <td class="left"><a href="zip-0000">ZIP Process</a></td> <td>Active</td>
|
||||
<tr> <td>32</td> <td class="left"><a href="zip-0032">Shielded Hierarchical Deterministic Wallets</a></td> <td>Final</td>
|
||||
<tr> <td>143</td> <td class="left"><a href="zip-0143">Transaction Signature Verification for Overwinter</a></td> <td>Final</td>
|
||||
<tr> <td>143</td> <td class="left"><a href="zip-0143">Transaction Signature Validation for Overwinter</a></td> <td>Final</td>
|
||||
<tr> <td>173</td> <td class="left"><a href="zip-0173">Bech32 Format</a></td> <td>Final</td>
|
||||
<tr> <td>200</td> <td class="left"><a href="zip-0200">Network Upgrade Mechanism</a></td> <td>Final</td>
|
||||
<tr> <td>201</td> <td class="left"><a href="zip-0201">Network Peer Management for Overwinter</a></td> <td>Final</td>
|
||||
|
|
@ -55,9 +55,9 @@
|
|||
<tr> <td>212</td> <td class="left"><a href="zip-0212">Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td> <td>Proposed</td>
|
||||
<tr> <td>213</td> <td class="left"><a href="zip-0213">Shielded Coinbase</a></td> <td>Implemented (zcashd)</td>
|
||||
<tr> <td>214</td> <td class="left"><a href="zip-0214">Consensus rules for a Zcash Development Fund</a></td> <td>Proposed</td>
|
||||
<tr> <td>215</td> <td class="left"><a href="zip-0215">Explicitly define Ed25519 validation rules</a></td> <td>Proposed</td>
|
||||
<tr> <td>215</td> <td class="left"><a href="zip-0215">Explicitly Defining and Modifying Ed25519 Validation Rules</a></td> <td>Proposed</td>
|
||||
<tr> <td>221</td> <td class="left"><a href="zip-0221">FlyClient - Consensus-Layer Changes</a></td> <td>Implemented (zcashd)</td>
|
||||
<tr> <td>243</td> <td class="left"><a href="zip-0243">Transaction Signature Verification for Sapling</a></td> <td>Final</td>
|
||||
<tr> <td>243</td> <td class="left"><a href="zip-0243">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
|
||||
<tr> <td>250</td> <td class="left"><a href="zip-0250">Deployment of the Heartwood Network Upgrade</a></td> <td>Implemented (zcashd)</td>
|
||||
<tr> <td>251</td> <td class="left"><a href="zip-0251">Deployment of the Canopy Network Upgrade</a></td> <td>Proposed</td>
|
||||
<tr> <td>308</td> <td class="left"><a href="zip-0308">Sprout to Sapling Migration</a></td> <td>Final</td>
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 143: Transaction Signature Verification for Overwinter</title>
|
||||
<title>ZIP 143: Transaction Signature Validation for Overwinter</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: 143
|
||||
Title: Transaction Signature Verification for Overwinter
|
||||
Title: Transaction Signature Validation for Overwinter
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Johnson Lau
|
||||
|
|
@ -23,13 +23,13 @@ License: MIT</pre>
|
|||
<p>The term "Overwinter" in this document is to be interpreted as described in ZIP 201. <a id="id3" class="footnote_reference" href="#zip-0201">11</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines a new transaction digest algorithm for signature verification from the Overwinter network upgrade, in order to minimize redundant data hashing in verification, and to cover the input value by the signature.</p>
|
||||
<p>This proposal defines a new transaction digest algorithm for signature validation from the Overwinter network upgrade, in order to minimize redundant data hashing in validation, and to cover the input value by the signature.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>There are 4 ECDSA signature verification codes in the original Zcash script system: <code>CHECKSIG</code>, <code>CHECKSIGVERIFY</code>, <code>CHECKMULTISIG</code>, <code>CHECKMULTISIGVERIFY</code> ("sigops"). According to the sighash type (<code>ALL</code>, <code>NONE</code>, or <code>SINGLE</code>, possibly modified by <code>ANYONECANPAY</code>), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is verified against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. <a id="id4" class="footnote_reference" href="#wiki-checksig">2</a> The transaction digest is additionally used for the JoinSplit signature (solely with sighash type <code>ALL</code>). <a id="id5" class="footnote_reference" href="#zcash-protocol">3</a></p>
|
||||
<p>There are 4 ECDSA signature validation operations in the original Zcash script system: <code>CHECKSIG</code>, <code>CHECKSIGVERIFY</code>, <code>CHECKMULTISIG</code>, <code>CHECKMULTISIGVERIFY</code> ("sigops"). According to the sighash type (<code>ALL</code>, <code>NONE</code>, or <code>SINGLE</code>, possibly modified by <code>ANYONECANPAY</code>), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is validated against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. <a id="id4" class="footnote_reference" href="#wiki-checksig">2</a> The transaction digest is additionally used for the JoinSplit signature (solely with sighash type <code>ALL</code>). <a id="id5" class="footnote_reference" href="#zcash-protocol">3</a></p>
|
||||
<p>Unfortunately, there are at least 2 weaknesses in the original SignatureHash transaction digest algorithm:</p>
|
||||
<ul>
|
||||
<li>For the verification of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n<sup>2</sup>) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to verify with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to verify. This could be fixed by optimizing the digest algorithm by introducing some reusable "midstate", so the time complexity becomes O(n). <a id="id6" class="footnote_reference" href="#quadratic">4</a></li>
|
||||
<li>For the validation of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n<sup>2</sup>) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to validate with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to validate. This could be fixed by optimizing the digest algorithm by introducing some reusable "midstate", so the time complexity becomes O(n). <a id="id6" class="footnote_reference" href="#quadratic">4</a></li>
|
||||
<li>The algorithm does not involve the value being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the lack of knowledge of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of a lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funds would be lost. <a id="id7" class="footnote_reference" href="#offline-wallets">5</a></li>
|
||||
</ul>
|
||||
<p>Deploying the aforementioned fixes in the original script system is not a simple task.</p>
|
||||
|
|
@ -126,7 +126,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="notes"><h3><span class="section-heading">Notes</span><span class="section-anchor"> <a href="#notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The <code>hashPrevouts</code>, <code>hashSequence</code>, <code>hashOutputs</code>, and <code>hashJoinSplits</code> calculated in an earlier verification can be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n<sup>2</sup>) to O(n).</p>
|
||||
<p>The <code>hashPrevouts</code>, <code>hashSequence</code>, <code>hashOutputs</code>, and <code>hashJoinSplits</code> calculated in an earlier validation can be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n<sup>2</sup>) to O(n).</p>
|
||||
<p>Refer to the reference implementation, reproduced below, for the precise algorithm:</p>
|
||||
<pre data-language="cpp"><span class="k">const</span> <span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">ZCASH_PREVOUTS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span> <span class="o">=</span>
|
||||
<span class="p">{</span><span class="sc">'Z'</span><span class="p">,</span><span class="sc">'c'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">,</span><span class="sc">'P'</span><span class="p">,</span><span class="sc">'r'</span><span class="p">,</span><span class="sc">'e'</span><span class="p">,</span><span class="sc">'v'</span><span class="p">,</span><span class="sc">'o'</span><span class="p">,</span><span class="sc">'u'</span><span class="p">,</span><span class="sc">'t'</span><span class="p">,</span><span class="sc">'H'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">};</span>
|
||||
|
|
|
|||
18
zip-0143.rst
18
zip-0143.rst
|
|
@ -1,7 +1,7 @@
|
|||
::
|
||||
|
||||
ZIP: 143
|
||||
Title: Transaction Signature Verification for Overwinter
|
||||
Title: Transaction Signature Validation for Overwinter
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Johnson Lau
|
||||
|
|
@ -27,28 +27,28 @@ The term "Overwinter" in this document is to be interpreted as described in ZIP
|
|||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines a new transaction digest algorithm for signature verification from the Overwinter
|
||||
network upgrade, in order to minimize redundant data hashing in verification, and to cover the input value by
|
||||
This proposal defines a new transaction digest algorithm for signature validation from the Overwinter
|
||||
network upgrade, in order to minimize redundant data hashing in validation, and to cover the input value by
|
||||
the signature.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
There are 4 ECDSA signature verification codes in the original Zcash script system: ``CHECKSIG``,
|
||||
There are 4 ECDSA signature validation operations in the original Zcash script system: ``CHECKSIG``,
|
||||
``CHECKSIGVERIFY``, ``CHECKMULTISIG``, ``CHECKMULTISIGVERIFY`` ("sigops"). According to the sighash type
|
||||
(``ALL``, ``NONE``, or ``SINGLE``, possibly modified by ``ANYONECANPAY``), a transaction digest is generated
|
||||
with a double SHA256 of a serialized subset of the transaction, and the signature is verified against this
|
||||
with a double SHA256 of a serialized subset of the transaction, and the signature is validated against this
|
||||
digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. [#wiki-checksig]_
|
||||
The transaction digest is additionally used for the JoinSplit signature (solely with sighash type ``ALL``).
|
||||
[#zcash-protocol]_
|
||||
|
||||
Unfortunately, there are at least 2 weaknesses in the original SignatureHash transaction digest algorithm:
|
||||
|
||||
* For the verification of each signature, the amount of data hashing is proportional to the size of the
|
||||
* For the validation of each signature, the amount of data hashing is proportional to the size of the
|
||||
transaction. Therefore, data hashing grows in O(n\ :sup:`2`) as the number of sigops in a transaction
|
||||
increases. While a 1 MB block would normally take 2 seconds to verify with an average computer in 2015, a
|
||||
1MB transaction with 5569 sigops may take 25 seconds to verify. This could be fixed by optimizing the digest
|
||||
increases. While a 1 MB block would normally take 2 seconds to validate with an average computer in 2015, a
|
||||
1MB transaction with 5569 sigops may take 25 seconds to validate. This could be fixed by optimizing the digest
|
||||
algorithm by introducing some reusable "midstate", so the time complexity becomes O(n). [#quadratic]_
|
||||
|
||||
* The algorithm does not involve the value being spent by the input. This is usually not a problem for online
|
||||
|
|
@ -197,7 +197,7 @@ Notes
|
|||
-----
|
||||
|
||||
The ``hashPrevouts``, ``hashSequence``, ``hashOutputs``, and ``hashJoinSplits`` calculated in an earlier
|
||||
verification can be reused in other inputs of the same transaction, so that the time complexity of the whole
|
||||
validation can be reused in other inputs of the same transaction, so that the time complexity of the whole
|
||||
hashing process reduces from O(n\ :sup:`2`) to O(n).
|
||||
|
||||
Refer to the reference implementation, reproduced below, for the precise algorithm:
|
||||
|
|
|
|||
|
|
@ -284,7 +284,7 @@ License: MIT</pre>
|
|||
<li>the version group ID is unknown; or</li>
|
||||
<li>the version number is unknown.</li>
|
||||
</ul>
|
||||
<p>Validation of version 3 transactions MUST use the signature verification process detailed in the Transaction Signature Verification for Overwinter ZIP <a id="id10" class="footnote_reference" href="#zip-0143">2</a>.</p>
|
||||
<p>Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id10" class="footnote_reference" href="#zip-0143">2</a>.</p>
|
||||
</section>
|
||||
<section id="implementation"><h2><span class="section-heading">Implementation</span><span class="section-anchor"> <a href="#implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The comments and code samples in this section apply to the reference C++ implementation of Zcash. Other implementations may vary.</p>
|
||||
|
|
@ -317,7 +317,7 @@ License: MIT</pre>
|
|||
}</pre>
|
||||
<p>It is expected that this test involving <code>nVersionGroupId</code> is only required when a transaction is being constructed or deserialized e.g. when an external transaction enters the system.</p>
|
||||
<p>However, it's possible that a clone of Zcash is using the same version group ID and passes the conditional.</p>
|
||||
<p>Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature verification process detailed in the Transaction Signature Verification for Overwinter ZIP <a id="id11" class="footnote_reference" href="#zip-0143">2</a>.</p>
|
||||
<p>Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id11" class="footnote_reference" href="#zip-0143">2</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -343,7 +343,7 @@ License: MIT</pre>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="zip-0143">ZIP 143: Transaction Signature Verification for Overwinter</a></td>
|
||||
<td><a href="zip-0143">ZIP 143: Transaction Signature Validation for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -190,7 +190,7 @@ Overwinter validators MUST reject transactions for violating consensus rules if:
|
|||
- the version group ID is unknown; or
|
||||
- the version number is unknown.
|
||||
|
||||
Validation of version 3 transactions MUST use the signature verification process detailed in the Transaction Signature Verification for Overwinter ZIP [#zip-0143]_.
|
||||
Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP [#zip-0143]_.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
|
@ -246,7 +246,7 @@ It is expected that this test involving ``nVersionGroupId`` is only required whe
|
|||
|
||||
However, it's possible that a clone of Zcash is using the same version group ID and passes the conditional.
|
||||
|
||||
Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature verification process detailed in the Transaction Signature Verification for Overwinter ZIP [#zip-0143]_.
|
||||
Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP [#zip-0143]_.
|
||||
|
||||
Deployment
|
||||
==========
|
||||
|
|
@ -276,7 +276,7 @@ References
|
|||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <zip-0143.rst>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Handshaking for Overwinter <zip-0201.rst>`_
|
||||
.. [#zip-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ License: MIT</pre>
|
|||
<li>Greater throughput of transactions in unit time.</li>
|
||||
</ul>
|
||||
<p>The latter goal could alternatively be achieved by increasing the block size limit, but that would not also achieve the former goal.</p>
|
||||
<p>Note that, for a given security requirement (in terms of the expected cost distribution of a rollback attack), the number of confirmations needed increases more slowly than the decrease in block time, and so, up to a point, decreasing the block target spacing can provide a better trade-off between latency and security. This argument assumes that the verification and propagation time for a block remain small compared to the block target spacing. See <a id="id5" class="footnote_reference" href="#slowfastblocks">8</a> for further analysis in various attack models.</p>
|
||||
<p>Note that, for a given security requirement (in terms of the expected cost distribution of a rollback attack), the number of confirmations needed increases more slowly than the decrease in block time, and so, up to a point, decreasing the block target spacing can provide a better trade-off between latency and security. This argument assumes that the validation and propagation time for a block remain small compared to the block target spacing. See <a id="id5" class="footnote_reference" href="#slowfastblocks">8</a> for further analysis in various attack models.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The changes described in this section are to be made in <a id="id6" class="footnote_reference" href="#latest-protocol">1</a>, relative to the pre-Blossom specification in [#preblossom-protocol].</p>
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ Note that, for a given security requirement (in terms of the expected cost
|
|||
distribution of a rollback attack), the number of confirmations needed
|
||||
increases more slowly than the decrease in block time, and so, up to a point,
|
||||
decreasing the block target spacing can provide a better trade-off between
|
||||
latency and security. This argument assumes that the verification and
|
||||
latency and security. This argument assumes that the validation and
|
||||
propagation time for a block remain small compared to the block target spacing.
|
||||
See [#slowfastblocks]_ for further analysis in various attack models.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 215: Explicitly define Ed25519 validation rules</title>
|
||||
<title>ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules</title>
|
||||
<meta charset="utf-8" />
|
||||
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 215
|
||||
Title: Explicitly define Ed25519 validation rules
|
||||
Title: Explicitly Defining and Modifying Ed25519 Validation Rules
|
||||
Owners: Henry de Valence <hdevalence@zfnd.org>
|
||||
Status: Proposed
|
||||
Category: Consensus
|
||||
|
|
@ -18,11 +18,11 @@ License: BSD-2-Clause</pre>
|
|||
<p>The key words "MUST" and "MUST NOT" in this document is to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash uses Ed25519 signatures as part of Sprout transactions. However, Ed25519 does not clearly define criteria for signature validity, and implementations conformant to RFC 8032 <a id="id2" class="footnote_reference" href="#rfc8032">2</a> need not agree on whether signatures are valid. This is unacceptable for a consensus-critical application like Zcash. Currently, Zcash inherits criteria for signature verification from an obsolete version of <cite>libsodium</cite>. Instead, this ZIP settles the situation by explicitly defining the Ed25519 verification criteria and changing them to be compatible with batch verification.</p>
|
||||
<p>Zcash uses Ed25519 signatures as part of Sprout transactions. However, Ed25519 does not clearly define criteria for signature validity, and implementations conformant to RFC 8032 <a id="id2" class="footnote_reference" href="#rfc8032">2</a> need not agree on whether signatures are valid. This is unacceptable for a consensus-critical application like Zcash. Currently, Zcash inherits criteria for signature validation from an obsolete version of <cite>libsodium</cite>. Instead, this ZIP settles the situation by explicitly defining the Ed25519 validation criteria and changing them to be compatible with batch validation.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The lack of clear verification criteria for Ed25519 signatures poses a maintenance burden. The initial implementation of Zcash consensus in <cite>zcashd</cite> inherited validation criteria from a then-current version of <cite>libsodium</cite> (1.0.15). Due to <a href="https://github.com/zcash/zcash/issues/2872#issuecomment-576911471">a bug in libsodium</a>, this was different from the intended criteria documented in the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol">3</a> (before the specification was changed to match <cite>libsodium</cite> 1.0.15 in specification version 2020.1.2). Also, <cite>libsodium</cite> never guaranteed stable validation criteria, and changed behavior in a later point release. This forced <cite>zcashd</cite> to use an older version of the library before eventually patching a newer version to have consistent validation criteria. To be compatible, Zebra had to implement a special library, <cite>ed25519-zebra</cite> to provide Zcash-flavored Ed25519, attempting to match <cite>libsodium</cite> 1.0.15 exactly. And the initial attempt to implement <cite>ed25519-zebra</cite> was also incompatible, because it precisely matched the wrong compile-time configuration of <cite>libsodium</cite>.</p>
|
||||
<p>In addition, the validation criteria used by Zcash preclude the use of batch verification of Ed25519 signatures. While signature verification is not the primary bottleneck for Zcash, it would be nice to be able to batch-verify signatures, as is the case for RedJubJub.</p>
|
||||
<p>The lack of clear validation criteria for Ed25519 signatures poses a maintenance burden. The initial implementation of Zcash consensus in <cite>zcashd</cite> inherited validation criteria from a then-current version of <cite>libsodium</cite> (1.0.15). Due to <a href="https://github.com/zcash/zcash/issues/2872#issuecomment-576911471">a bug in libsodium</a>, this was different from the intended criteria documented in the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol">3</a> (before the specification was changed to match <cite>libsodium</cite> 1.0.15 in specification version 2020.1.2). Also, <cite>libsodium</cite> never guaranteed stable validation criteria, and changed behavior in a later point release. This forced <cite>zcashd</cite> to use an older version of the library before eventually patching a newer version to have consistent validation criteria. To be compatible, Zebra had to implement a special library, <cite>ed25519-zebra</cite> to provide Zcash-flavored Ed25519, attempting to match <cite>libsodium</cite> 1.0.15 exactly. And the initial attempt to implement <cite>ed25519-zebra</cite> was also incompatible, because it precisely matched the wrong compile-time configuration of <cite>libsodium</cite>.</p>
|
||||
<p>In addition, the validation criteria used by Zcash preclude the use of batch validation of Ed25519 signatures. While signature validation is not the primary bottleneck for Zcash, it would be nice to be able to batch-validate signatures, as is the case for RedJubjub.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>After activation of this ZIP, the
|
||||
|
|
@ -65,13 +65,13 @@ License: BSD-2-Clause</pre>
|
|||
-coordinate of the points may be unreduced modulo
|
||||
<span class="math">\(2^{255}-19\)</span>
|
||||
.</p>
|
||||
<p>Note: the alternate verification equation
|
||||
<p>Note: the alternate validation equation
|
||||
<span class="math">\([S]B = R + [k]A\)</span>
|
||||
, allowed by RFC 8032, MUST NOT be used.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This change simplifies the Ed25519 validation logic and reduces future maintenance burden. Because multiplication by the cofactor admits more solutions to the verification equation, not fewer, it is compatible with all existing Ed25519 signatures on the chain.</p>
|
||||
<p>It also allows the use of batch verification, which requires multiplication by the cofactor in the verification equation.</p>
|
||||
<p>This change simplifies the Ed25519 validation logic and reduces future maintenance burden. Because multiplication by the cofactor admits more solutions to the validation equation, not fewer, it is compatible with all existing Ed25519 signatures on the chain.</p>
|
||||
<p>It also allows the use of batch validation, which requires multiplication by the cofactor in the validation equation.</p>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This change has no effect on honestly-generated signatures. Unlike the current validation rules, it makes it possible for a user to generate weak signing keys or to generate signing keys with nonzero torsion component and submit them to the blockchain. However, doing so provides them with no advantage, only compromise to their own security. Moreover, these cases are not a failure mode of any deployed implementation.</p>
|
||||
|
|
|
|||
24
zip-0215.rst
24
zip-0215.rst
|
|
@ -1,7 +1,7 @@
|
|||
::
|
||||
|
||||
ZIP: 215
|
||||
Title: Explicitly define Ed25519 validation rules
|
||||
Title: Explicitly Defining and Modifying Ed25519 Validation Rules
|
||||
Owners: Henry de Valence <hdevalence@zfnd.org>
|
||||
Status: Proposed
|
||||
Category: Consensus
|
||||
|
|
@ -22,15 +22,15 @@ Zcash uses Ed25519 signatures as part of Sprout transactions. However, Ed25519
|
|||
does not clearly define criteria for signature validity, and implementations conformant
|
||||
to RFC 8032 [#RFC8032]_ need not agree on whether signatures are valid. This is
|
||||
unacceptable for a consensus-critical application like Zcash. Currently, Zcash
|
||||
inherits criteria for signature verification from an obsolete version of
|
||||
inherits criteria for signature validation from an obsolete version of
|
||||
`libsodium`. Instead, this ZIP settles the situation by explicitly defining the
|
||||
Ed25519 verification criteria and changing them to be compatible with batch
|
||||
verification.
|
||||
Ed25519 validation criteria and changing them to be compatible with batch
|
||||
validation.
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
The lack of clear verification criteria for Ed25519 signatures poses a
|
||||
The lack of clear validation criteria for Ed25519 signatures poses a
|
||||
maintenance burden. The initial implementation of Zcash consensus in `zcashd`
|
||||
inherited validation criteria from a then-current version of `libsodium` (1.0.15).
|
||||
Due to `a bug in libsodium <https://github.com/zcash/zcash/issues/2872#issuecomment-576911471>`_,
|
||||
|
|
@ -46,9 +46,9 @@ the initial attempt to implement `ed25519-zebra` was also incompatible, because
|
|||
it precisely matched the wrong compile-time configuration of `libsodium`.
|
||||
|
||||
In addition, the validation criteria used by Zcash preclude the use of batch
|
||||
verification of Ed25519 signatures. While signature verification is not the
|
||||
primary bottleneck for Zcash, it would be nice to be able to batch-verify
|
||||
signatures, as is the case for RedJubJub.
|
||||
validation of Ed25519 signatures. While signature validation is not the
|
||||
primary bottleneck for Zcash, it would be nice to be able to batch-validate
|
||||
signatures, as is the case for RedJubjub.
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
|
@ -70,7 +70,7 @@ It is *not* required that :math:`\underline{A}` and :math:`\underline{R}`
|
|||
are canonical encodings; in other words, the integer encoding the
|
||||
:math:`y`-coordinate of the points may be unreduced modulo :math:`2^{255}-19`.
|
||||
|
||||
Note: the alternate verification equation :math:`[S]B = R + [k]A`, allowed
|
||||
Note: the alternate validation equation :math:`[S]B = R + [k]A`, allowed
|
||||
by RFC 8032, MUST NOT be used.
|
||||
|
||||
Rationale
|
||||
|
|
@ -78,11 +78,11 @@ Rationale
|
|||
|
||||
This change simplifies the Ed25519 validation logic and reduces future
|
||||
maintenance burden. Because multiplication by the cofactor admits more
|
||||
solutions to the verification equation, not fewer, it is compatible with all
|
||||
solutions to the validation equation, not fewer, it is compatible with all
|
||||
existing Ed25519 signatures on the chain.
|
||||
|
||||
It also allows the use of batch verification, which requires multiplication
|
||||
by the cofactor in the verification equation.
|
||||
It also allows the use of batch validation, which requires multiplication
|
||||
by the cofactor in the validation equation.
|
||||
|
||||
Security and Privacy Considerations
|
||||
===================================
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 243: Transaction Signature Verification for Sapling</title>
|
||||
<title>ZIP 243: Transaction Signature Validation for Sapling</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: 243
|
||||
Title: Transaction Signature Verification for Sapling
|
||||
Title: Transaction Signature Validation for Sapling
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Simon Liu
|
||||
|
|
@ -21,7 +21,7 @@ License: MIT</pre>
|
|||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205. <a id="id3" class="footnote_reference" href="#zip-0205">6</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines a new transaction digest algorithm for signature verification from the Sapling network upgrade, to account for the presence of Sapling shielded inputs and outputs in transactions.</p>
|
||||
<p>This proposal defines a new transaction digest algorithm for signature validation from the Sapling network upgrade, to account for the presence of Sapling shielded inputs and outputs in transactions.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Sapling network upgrade introduced new shielded inputs and outputs. We want these to be covered by the transaction digest algorithm used for signatures, in order to ensure they are correctly bound.</p>
|
||||
|
|
@ -95,7 +95,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="notes"><h3><span class="section-heading">Notes</span><span class="section-anchor"> <a href="#notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The <code>hashPrevouts</code>, <code>hashSequence</code>, <code>hashOutputs</code>, <code>hashJoinSplits</code>, <code>hashShieldedSpends</code>, and <code>hashShieldedOutputs</code> calculated in an earlier verification can be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n<sup>2</sup>) to O(n).</p>
|
||||
<p>The <code>hashPrevouts</code>, <code>hashSequence</code>, <code>hashOutputs</code>, <code>hashJoinSplits</code>, <code>hashShieldedSpends</code>, and <code>hashShieldedOutputs</code> calculated in an earlier validation can be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n<sup>2</sup>) to O(n).</p>
|
||||
<p>Refer to the reference implementation, reproduced below, for the precise algorithm:</p>
|
||||
<pre data-language="cpp"><span class="k">const</span> <span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">ZCASH_PREVOUTS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span> <span class="o">=</span>
|
||||
<span class="p">{</span><span class="sc">'Z'</span><span class="p">,</span><span class="sc">'c'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">,</span><span class="sc">'P'</span><span class="p">,</span><span class="sc">'r'</span><span class="p">,</span><span class="sc">'e'</span><span class="p">,</span><span class="sc">'v'</span><span class="p">,</span><span class="sc">'o'</span><span class="p">,</span><span class="sc">'u'</span><span class="p">,</span><span class="sc">'t'</span><span class="p">,</span><span class="sc">'H'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">};</span>
|
||||
|
|
@ -471,7 +471,7 @@ vJoinSplit: 00</pre>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="zip-0143">ZIP 143: Transaction Signature Verification for Overwinter</a></td>
|
||||
<td><a href="zip-0143">ZIP 143: Transaction Signature Validation for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
::
|
||||
|
||||
ZIP: 243
|
||||
Title: Transaction Signature Verification for Sapling
|
||||
Title: Transaction Signature Validation for Sapling
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Simon Liu
|
||||
|
|
@ -25,7 +25,7 @@ The term "Sapling" in this document is to be interpreted as described in ZIP 205
|
|||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines a new transaction digest algorithm for signature verification from the Sapling network
|
||||
This proposal defines a new transaction digest algorithm for signature validation from the Sapling network
|
||||
upgrade, to account for the presence of Sapling shielded inputs and outputs in transactions.
|
||||
|
||||
|
||||
|
|
@ -136,7 +136,7 @@ Notes
|
|||
-----
|
||||
|
||||
The ``hashPrevouts``, ``hashSequence``, ``hashOutputs``, ``hashJoinSplits``, ``hashShieldedSpends``, and
|
||||
``hashShieldedOutputs`` calculated in an earlier verification can be reused in other inputs of the same
|
||||
``hashShieldedOutputs`` calculated in an earlier validation can be reused in other inputs of the same
|
||||
transaction, so that the time complexity of the whole hashing process reduces from O(n\ :sup:`2`) to O(n).
|
||||
|
||||
Refer to the reference implementation, reproduced below, for the precise algorithm:
|
||||
|
|
@ -529,7 +529,7 @@ References
|
|||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol] `Zcash Protocol Specification [Overwinter+Sapling] <protocol/protocol.pdf>`_
|
||||
.. [#BLAKE2-personalization] `"BLAKE2: simpler, smaller, fast as MD5", Section 2.8 <https://blake2.net/blake2.pdf>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <zip-0143.rst>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
|
||||
.. [#test-vectors] `ZIP 243 Test Vectors <https://github.com/zcash-hackworks/zcash-test-vectors/blob/master/zip_0243.py>`_
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ License: MIT</pre>
|
|||
<li>ZIP 211: Disabling Addition of New Value to the Sprout Value Pool <a id="id8" class="footnote_reference" href="#zip-0211">6</a></li>
|
||||
<li>ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <a id="id9" class="footnote_reference" href="#zip-0212">7</a></li>
|
||||
<li>ZIP 214: Consensus rules for a Zcash Development Fund <a id="id10" class="footnote_reference" href="#zip-0214">8</a></li>
|
||||
<li>ZIP 215: Modifying Ed25519 validation rules to allow batch verification <a id="id11" class="footnote_reference" href="#zip-0215">9</a></li>
|
||||
<li>ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules <a id="id11" class="footnote_reference" href="#zip-0215">9</a></li>
|
||||
<li>ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <a id="id12" class="footnote_reference" href="#zip-1014">11</a>.</li>
|
||||
</ul>
|
||||
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id13" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
|
||||
|
|
@ -146,7 +146,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="https://github.com/zcash/zips/pull/355">Draft ZIP 215: Modifying Ed25519 validation rules to allow batch verification</a></td>
|
||||
<td><a href="zip-0215">ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ The primary sources of information about Canopy consensus protocol changes are:
|
|||
- ZIP 211: Disabling Addition of New Value to the Sprout Value Pool [#zip-0211]_
|
||||
- ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext [#zip-0212]_
|
||||
- ZIP 214: Consensus rules for a Zcash Development Fund [#zip-0214]_
|
||||
- ZIP 215: Modifying Ed25519 validation rules to allow batch verification [#zip-0215]_
|
||||
- ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules [#zip-0215]_
|
||||
- ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants [#zip-1014]_.
|
||||
|
||||
The network handshake and peer management mechanisms defined in ZIP 201 [#zip-0201]_
|
||||
|
|
@ -138,6 +138,6 @@ References
|
|||
.. [#zip-0211] `ZIP 211: Disabling Addition of New Value to the Sprout Value Pool <zip-0211.rst>`_
|
||||
.. [#zip-0212] `ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <zip-0212.rst>`_
|
||||
.. [#zip-0214] `ZIP 214: Consensus rules for a Zcash Development Fund <zip-0214.rst>`_
|
||||
.. [#zip-0215] `Draft ZIP 215: Modifying Ed25519 validation rules to allow batch verification <https://github.com/zcash/zips/pull/355>`_
|
||||
.. [#zip-0215] `ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules <zip-0215.rst>`_
|
||||
.. [#zip-0243] `ZIP 243: Transaction Signature Verification for Sapling <zip-0243.rst>`_
|
||||
.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <zip-1014.rst>`_
|
||||
|
|
|
|||
Loading…
Reference in New Issue