zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #505 from nuttycom/zip_244_empty_hashes 

The roots of empty transaction hash subtrees are now uniformly committed to with empty hashes.
This commit is contained in:
Kris Nuttycombe 2021-05-18 08:16:46 -06:00 committed by GitHub
parent 8e6b15e9e9 97aa1be78e
commit 2b520f41f9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 341 additions and 362 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

98
zip-0225.html
View File

@ -411,100 +411,6 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
</table>
<p>The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ of the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#protocol-actiondesc">5</a>.</p>
</section>
<section id="modifications-to-zip-244"><h3><span class="section-heading">Modifications to ZIP 244</span><span class="section-anchor"> <a rel="bookmark" href="#modifications-to-zip-244"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="txid-digest"><h4><span class="section-heading">TxId Digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The tree of hashes defined by ZIP 244 <a id="id8" class="footnote_reference" href="#zip-0244">7</a> is re-structured to include a new branch for Orchard hashes. The <code>orchard_digest</code> branch is the only new addition to the tree; <code>header_digest</code>, <code>transparent_digest</code>, and <code>sapling_digest</code> are as in ZIP 244:</p>
<pre>txid_digest
├── header_digest
├── transparent_digest
├── sapling_digest
└── orchard_digest</pre>
<section id="id9"><h5><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id9"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>The top hash of the <code>txid_digest</code> tree is modified from the ZIP 244 structure to be a BLAKE2b-256 hash of the following values</p>
<pre>T.1: header_digest (32-byte hash output)
T.2: transparent_digest (32-byte hash output)
T.3: sapling_digest (32-byte hash output)
T.4: orchard_digest (32-byte hash output)</pre>
<p>The personalization field of this hash is unmodified from ZIP 244.</p>
</section>
<section id="t-4-orchard-digest"><h5><span class="section-heading">T.4: <code>orchard_digest</code></span><span class="section-anchor"> <a rel="bookmark" href="#t-4-orchard-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>T.4a: orchard_actions_compact_digest (32-byte hash output)
T.4b: orchard_actions_memos_digest (32-byte hash output)
T.4c: orchard_actions_noncompact_digest (32-byte hash output)
T.4d: flagsOrchard (1 byte)
T.4e: valueBalanceOrchard (64-bit signed little-endian)
T.4f: anchorOrchard (32 bytes)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdOrchardHash"</pre>
</section>
<section id="t-4a-orchard-actions-compact-digest"><h5><span class="section-heading">T.4a: orchard_actions_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4a-orchard-actions-compact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 <a id="id10" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4a.i : nullifier (field encoding bytes)
T.4a.ii : cmx (field encoding bytes)
T.4a.iii: ephemeralKey (field encoding bytes)
T.4a.iv : encCiphertext[..52] (First 52 bytes of field encoding)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdOrcOutCHash"</pre>
</section>
<section id="t-4b-orchard-actions-memos-digest"><h5><span class="section-heading">T.4b: orchard_actions_memos_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4b-orchard-actions-memos-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the subset of Orchard shielded memo field data for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4b.i: encCiphertext[52..564] (contents of the encrypted memo field)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdOrcOutMHash"</pre>
</section>
<section id="t-4c-orchard-actions-noncompact-digest"><h5><span class="section-heading">T.4c: orchard_actions_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4c-orchard-actions-noncompact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the remaining subset of Orchard Action information <strong>not</strong> intended for inclusion in an updated version of the the ZIP 307 <a id="id11" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4c.i : cv (field encoding bytes)
T.4c.ii : rk (field encoding bytes)
T.4c.iii: encCiphertext[564..] (post-memo suffix of field encoding)
T.4c.iv : outCiphertext (field encoding bytes)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdOrcOutNHash"</pre>
</section>
</section>
<section id="signature-digest"><h4><span class="section-heading">Signature Digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The signature digest creation algorithm defined by ZIP 244 <a id="id12" class="footnote_reference" href="#zip-0244">7</a> is modified to include a new branch for Orchard hashes. The <code>orchard_digest</code> branch is the only new addition to the tree; <code>header_digest</code>, <code>transparent_sig_digest</code>, and <code>sapling_digest</code> are as in ZIP 244:</p>
<pre>signature_digest
├── header_digest
├── transparent_sig_digest
├── sapling_digest
└── orchard_digest</pre>
<section id="id13"><h5><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id13"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>S.1: header_digest (32-byte hash output)
S.2: transparent_sig_digest (32-byte hash output)
S.3: sapling_digest (32-byte hash output)
S.4: orchard_digest (32-byte hash output)</pre>
<p>The personalization field of this hash is unmodified from ZIP 244</p>
</section>
<section id="s-4-orchard-digest"><h5><span class="section-heading">S.4: orchard_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-4-orchard-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>Identical to that specified for the transaction identifier.</p>
</section>
</section>
<section id="authorizing-data-commitment"><h4><span class="section-heading">Authorizing Data Commitment</span><span class="section-anchor"> <a rel="bookmark" href="#authorizing-data-commitment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The tree of hashes defined by ZIP 244 <a id="id14" class="footnote_reference" href="#zip-0244">7</a> for authorizing data commitments is re-structured to include a new branch for Orchard Actions. The <code>orchard_auth_digest</code> branch is the only new addition to the tree; <code>transparent_scripts_digest</code>, and <code>sapling_auth_digest</code> are as in ZIP 244:</p>
<pre>auth_digest
├── transparent_scripts_digest
├── sapling_auth_digest
└── orchard_auth_digest</pre>
<section id="auth-digest"><h5><span class="section-heading">auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#auth-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the following values:</p>
<pre>A.1: transparent_scripts_digest (32-byte hash output)
A.2: sapling_auth_digest (32-byte hash output)
A.3: orchard_auth_digest (32-byte hash output)</pre>
<p>The personalization field of this hash is unmodified from ZIP 244.</p>
</section>
<section id="a-3-orchard-auth-digest"><h5><span class="section-heading">A.3: orchard_auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-3-orchard-auth-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the field encoding of the <code>zkProofsOrchard</code>, <code>spendAuthSigsOrchard</code>, and <code>bindingSigOrchard</code> fields of the transaction:</p>
<pre>A.3a: proofsOrchard (field encoding bytes)
A.3b: vSpendAuthSigsOrchard (field encoding bytes)
A.3c: bindingSigOrchard (field encoding bytes)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxAuthOrchaHash"</pre>
</section>
</section>
</section>
</section>
<section id="alternatives"><h2><span class="section-heading">Alternatives</span><span class="section-anchor"> <a rel="bookmark" href="#alternatives"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The original version of ZIP-225 included Sprout-related fields <code>nJoinSplit</code>, <code>vJoinSplit</code>, <code>joinSplitPubKey</code>, and <code>joinSplitSig</code> in the V5 transaction format. The Electric Coin Company and Zcash Foundation teams have elected to remove these fields from the V5 transaction format as part of the continuing process of deprecation of the Sprout shielded pool. As a consequence of these fields being removed:</p>
@ -514,9 +420,9 @@ A.3c: bindingSigOrchard (field encoding bytes)</pre>
<p>Removing these fields reduces the complexity of the NU5 upgrade in the following ways:</p>
<ul>
<li>V5 parsing and serialization code does not need to take these fields into account.</li>
<li>ZIP 244 <a id="id15" class="footnote_reference" href="#zip-0244">7</a> transaction identifier, signature hash, and authorizing data commitment computations are simplified by excluding consideration of these fields.</li>
<li>ZIP 244 <a id="id8" class="footnote_reference" href="#zip-0244">7</a> transaction identifier, signature hash, and authorizing data commitment computations are simplified by excluding consideration of these fields.</li>
</ul>
<p>Removal of these fields means that that in the future, removing the support for the V4 transaction format will also effectively end support for Sprout transactions on the Zcash network, though it might be possible to restore limited support for migration via a future ZIP 222 <a id="id16" class="footnote_reference" href="#zip-0222">6</a> extension or by other means not yet determined.</p>
<p>Removal of these fields means that that in the future, removing the support for the V4 transaction format will also effectively end support for Sprout transactions on the Zcash network, though it might be possible to restore limited support for migration via a future ZIP 222 <a id="id9" class="footnote_reference" href="#zip-0222">6</a> extension or by other means not yet determined.</p>
<p>The original definitions for the transaction fields that have been removed are:</p>
<table>
<tbody>

162
zip-0225.rst
View File

@ -259,168 +259,6 @@ Orchard Action Description (``OrchardAction``)
The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding
and Consensus’ of the Zcash Protocol Specification [#protocol-actiondesc]_.
Modifications to ZIP 244
------------------------
TxId Digest
~~~~~~~~~~~
The tree of hashes defined by ZIP 244 [#zip-0244]_ is re-structured to include a new
branch for Orchard hashes. The ``orchard_digest`` branch is the only new addition to the
tree; ``header_digest``, ``transparent_digest``, and ``sapling_digest`` are as in ZIP
244::
txid_digest
├── header_digest
├── transparent_digest
├── sapling_digest
└── orchard_digest
txid_digest
"""""""""""
The top hash of the ``txid_digest`` tree is modified from the ZIP 244 structure
to be a BLAKE2b-256 hash of the following values ::
T.1: header_digest (32-byte hash output)
T.2: transparent_digest (32-byte hash output)
T.3: sapling_digest (32-byte hash output)
T.4: orchard_digest (32-byte hash output)
The personalization field of this hash is unmodified from ZIP 244.
T.4: ``orchard_digest``
"""""""""""""""""""""""
A BLAKE2b-256 hash of the following values ::
T.4a: orchard_actions_compact_digest (32-byte hash output)
T.4b: orchard_actions_memos_digest (32-byte hash output)
T.4c: orchard_actions_noncompact_digest (32-byte hash output)
T.4d: flagsOrchard (1 byte)
T.4e: valueBalanceOrchard (64-bit signed little-endian)
T.4f: anchorOrchard (32 bytes)
The personalization field of this hash is set to::
"ZTxIdOrchardHash"
T.4a: orchard_actions_compact_digest
""""""""""""""""""""""""""""""""""""
A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in
an updated version of the ZIP-307 [#zip-0307]_ ``CompactBlock`` format for all Orchard
Actions belonging to the transaction. For each Action, the following elements are included
in the hash::
T.4a.i : nullifier (field encoding bytes)
T.4a.ii : cmx (field encoding bytes)
T.4a.iii: ephemeralKey (field encoding bytes)
T.4a.iv : encCiphertext[..52] (First 52 bytes of field encoding)
The personalization field of this hash is set to::
"ZTxIdOrcOutCHash"
T.4b: orchard_actions_memos_digest
""""""""""""""""""""""""""""""""""
A BLAKE2b-256 hash of the subset of Orchard shielded memo field data for all Orchard
Actions belonging to the transaction. For each Action, the following elements are included
in the hash::
T.4b.i: encCiphertext[52..564] (contents of the encrypted memo field)
The personalization field of this hash is set to::
"ZTxIdOrcOutMHash"
T.4c: orchard_actions_noncompact_digest
"""""""""""""""""""""""""""""""""""""""
A BLAKE2b-256 hash of the remaining subset of Orchard Action information **not** intended
for inclusion in an updated version of the the ZIP 307 [#zip-0307]_ ``CompactBlock``
format, for all Orchard Actions belonging to the transaction. For each Action,
the following elements are included in the hash::
T.4c.i : cv (field encoding bytes)
T.4c.ii : rk (field encoding bytes)
T.4c.iii: encCiphertext[564..] (post-memo suffix of field encoding)
T.4c.iv : outCiphertext (field encoding bytes)
The personalization field of this hash is set to::
"ZTxIdOrcOutNHash"
Signature Digest
~~~~~~~~~~~~~~~~
The signature digest creation algorithm defined by ZIP 244 [#zip-0244]_ is modified to
include a new branch for Orchard hashes. The ``orchard_digest`` branch is the only new
addition to the tree; ``header_digest``, ``transparent_sig_digest``, and ``sapling_digest``
are as in ZIP 244::
signature_digest
├── header_digest
├── transparent_sig_digest
├── sapling_digest
└── orchard_digest
signature_digest
""""""""""""""""
A BLAKE2b-256 hash of the following values ::
S.1: header_digest (32-byte hash output)
S.2: transparent_sig_digest (32-byte hash output)
S.3: sapling_digest (32-byte hash output)
S.4: orchard_digest (32-byte hash output)
The personalization field of this hash is unmodified from ZIP 244
S.4: orchard_digest
"""""""""""""""""""
Identical to that specified for the transaction identifier.
Authorizing Data Commitment
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The tree of hashes defined by ZIP 244 [#zip-0244]_ for authorizing data commitments is
re-structured to include a new branch for Orchard Actions. The ``orchard_auth_digest``
branch is the only new addition to the tree; ``transparent_scripts_digest``, and
``sapling_auth_digest`` are as in ZIP 244::
auth_digest
├── transparent_scripts_digest
├── sapling_auth_digest
└── orchard_auth_digest
auth_digest
"""""""""""
A BLAKE2b-256 hash of the following values::
A.1: transparent_scripts_digest (32-byte hash output)
A.2: sapling_auth_digest (32-byte hash output)
A.3: orchard_auth_digest (32-byte hash output)
The personalization field of this hash is unmodified from ZIP 244.
A.3: orchard_auth_digest
""""""""""""""""""""""""
A BLAKE2b-256 hash of the field encoding of the ``zkProofsOrchard``,
``spendAuthSigsOrchard``, and ``bindingSigOrchard`` fields of the transaction::
A.3a: proofsOrchard (field encoding bytes)
A.3b: vSpendAuthSigsOrchard (field encoding bytes)
A.3c: bindingSigOrchard (field encoding bytes)
The personalization field of this hash is set to::
"ZTxAuthOrchaHash"
Alternatives
============

176
zip-0244.html
View File

@ -18,7 +18,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/411">https://g
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">2</a></p>
<p>The term "field encoding" refers to the binary serialized form of a Zcash transaction field, as specified in section 7.1 of the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol-txnencodingandconsensus">7</a>.</p>
<p>The term "field encoding" refers to the binary serialized form of a Zcash transaction field, as specified in section 7.1 of the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol-txnencodingandconsensus">8</a>.</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a new transaction digest algorithm for the NU5 network upgrade onward, in order to introduce non-malleable transaction identifiers that commit to all transaction data except for attestations to transaction validity.</p>
@ -46,7 +46,8 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/411">https://g
</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>
<section id="digests"><h3><span class="section-heading">Digests</span><span class="section-anchor"> <a rel="bookmark" href="#digests"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>All digests are personalized BLAKE2b-256 hashes. In cases where no elements are available for hashing (for example, if there are no transparent inputs) the resulting hash will be over just the personalization string, providing domain separation even for empty data fields.</p>
<p>All digests are personalized BLAKE2b-256 hashes. In cases where no elements are available for hashing (for example, if there are no transparent transaction inputs or no Orchard actions), a personalized hash of the empty byte array will be used. The personalization string therefore provides domain separation for the hashes of even empty data fields.</p>
<p>The notation <code>BLAKE2b-256(personalization_string, [])</code> is used to refer to hashes constructed in this manner.</p>
<section id="txid-digest"><h4><span class="section-heading">TxId Digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A new transaction digest algorithm is defined that constructs the identifier for a transaction from a tree of hashes. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:</p>
<pre>txid_digest
@ -55,21 +56,29 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/411">https://g
│   ├── prevouts_digest
│   ├── sequence_digest
│   └── outputs_digest
└── sapling_digest
   ├── sapling_spends_digest
│   ├── sapling_spends_compact_digest
│   └── sapling_spends_noncompact_digest
├── sapling_outputs_digest
│   ├── sapling_outputs_compact_digest
│   ├── sapling_outputs_memos_digest
│   └── sapling_outputs_noncompact_digest
  └── valueBalance</pre>
├── sapling_digest
│   ├── sapling_spends_digest
│   │   ├── sapling_spends_compact_digest
│   │   └── sapling_spends_noncompact_digest
│   ├── sapling_outputs_digest
│   │   ├── sapling_outputs_compact_digest
│   │   ├── sapling_outputs_memos_digest
│   │   └── sapling_outputs_noncompact_digest
│   └── valueBalance
└── orchard_digest
   ├── orchard_actions_compact_digest
   ├── orchard_actions_memos_digest
   ├── orchard_actions_noncompact_digest
   ├── flagsOrchard
   ├── valueBalanceOrchard
   └── anchorOrchard</pre>
<p>Each node written as <code>snake_case</code> in this tree is a BLAKE2b-256 hash of its children, initialized with a personalization string specific to that branch of the tree. Nodes that are not themselves digests are written in <code>camelCase</code>. In the specification below, nodes of the tree are presented in depth-first order.</p>
<section id="id4"><h5><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id4"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>T.1: header_digest (32-byte hash output)
T.2: transparent_digest (32-byte hash output)
T.3: sapling_digest (32-byte hash output)</pre>
T.3: sapling_digest (32-byte hash output)
T.4: orchard_digest (32-byte hash output)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZcashTxHash_" || CONSENSUS_BRANCH_ID</pre>
<p><code>ZcashTxHash_</code> has 1 underscore character.</p>
@ -86,42 +95,54 @@ T.1e: expiry_height (4-byte little-endian block height)</pre>
<pre>"ZTxIdHeadersHash"</pre>
</section>
<section id="t-2-transparent-digest"><h6><span class="section-heading">T.2: transparent_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-2-transparent-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>A BLAKE2b-256 hash of the following values</p>
<p>In the case that transparent inputs or outputs are present, the transparent digest consists of a BLAKE2b-256 hash of the following values</p>
<pre>T.2a: prevouts_digest (32-byte hash)
T.2b: sequence_digest (32-byte hash)
T.2c: outputs_digest (32-byte hash)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdTranspaHash"</pre>
<p>In the case that the transaction has no transparent components, <code>transparent_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdTranspaHash", [])</pre>
<section id="t-2a-prevouts-digest"><h7><span class="section-heading">T.2a: prevouts_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-2a-prevouts-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>A BLAKE2b-256 hash of the field encoding of all <code>outpoint</code> field values of transparent inputs to the transaction.</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdPrevoutHash"</pre>
<p>In the case that the transaction has transparent outputs but no transparent inputs, <code>prevouts_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdPrevoutHash", [])</pre>
</section>
<section id="t-2b-sequence-digest"><h7><span class="section-heading">T.2b: sequence_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-2b-sequence-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>A BLAKE2b-256 hash of the 32-bit little-endian representation of all <code>nSequence</code> field values of transparent inputs to the transaction.</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdSequencHash"</pre>
<p>In the case that the transaction has transparent outputs but no transparent inputs, <code>sequence_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdSequencHash", [])</pre>
</section>
<section id="t-2c-outputs-digest"><h7><span class="section-heading">T.2c: outputs_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-2c-outputs-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>A BLAKE2b-256 hash of the concatenated field encodings of all transparent output values of the transaction. The field encoding of such an output consists of the encoded output <code>amount</code> (8-byte little endian) followed by the <code>scriptPubKey</code> byte array (serialized as Bitcoin script).</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdOutputsHash"</pre>
<p>In the case that the transaction has transparent inputs but no transparent outputs, <code>outputs_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdOutputsHash", [])</pre>
</section>
</section>
<section id="t-3-sapling-digest"><h6><span class="section-heading">T.3: sapling_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3-sapling-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>The digest of Sapling components is composed of two subtrees which are organized to permit easy interoperability with the <code>CompactBlock</code> representation of Sapling data specified by the ZIP 307 Light Client Protocol <a id="id6" class="footnote_reference" href="#zip-0307">6</a>.</p>
<p>In the case that Sapling spends or outputs are present, the digest of Sapling components is composed of two subtrees which are organized to permit easy interoperability with the <code>CompactBlock</code> representation of Sapling data specified by the ZIP 307 Light Client Protocol <a id="id6" class="footnote_reference" href="#zip-0307">7</a>.</p>
<p>This digest is a BLAKE2b-256 hash of the following values</p>
<pre>T.3a: sapling_spends_digest (32-byte hash)
T.3b: sapling_outputs_digest (32-byte hash)
T.3c: valueBalance (64-bit signed little-endian)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdSaplingHash"</pre>
<p>In the case that the transaction has no Sapling spends or outputs, <code>sapling_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdSaplingHash", [])</pre>
<section id="t-3a-sapling-spends-digest"><h7><span class="section-heading">T.3a: sapling_spends_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3a-sapling-spends-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>This digest is a BLAKE2b-256 hash of the following values</p>
<p>In the case that Sapling spends are present, this digest is a BLAKE2b-256 hash of the following values</p>
<pre>T.3a.i: sapling_spends_compact_digest (32-byte hash)
T.3a.ii: sapling_spends_noncompact_digest (32-byte hash)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdSSpendsHash"</pre>
<p>In the case that the transaction has Sapling outputs but no Sapling spends, <code>sapling_spends_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdSSpendsHash", [])</pre>
<section id="t-3a-i-sapling-spends-compact-digest"><h8><span class="section-heading">T.3a.i: sapling_spends_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3a-i-sapling-spends-compact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<p>A BLAKE2b-256 hash of the field encoding of all <code>nullifier</code> field values of Sapling shielded spends belonging to the transaction.</p>
<p>The personalization field of this hash is set to:</p>
@ -138,14 +159,16 @@ T.3a.ii.3: rk (field encoding bytes)</pre>
</section>
</section>
<section id="t-3b-sapling-outputs-digest"><h7><span class="section-heading">T.3b: sapling_outputs_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-sapling-outputs-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>This digest is a BLAKE2b-256 hash of the following values</p>
<p>In the case that Sapling outputs are present, this digest is a BLAKE2b-256 hash of the following values</p>
<pre>T.3b.i: sapling_outputs_compact_digest (32-byte hash)
T.3b.ii: sapling_outputs_memos_digest (32-byte hash)
T.3b.iii: sapling_outputs_noncompact_digest (32-byte hash)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdSOutputHash"</pre>
<p>In the case that the transaction has Sapling spends but no Sapling outputs, <code>sapling_outputs_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdSOutputHash", [])</pre>
<section id="t-3b-i-sapling-outputs-compact-digest"><h8><span class="section-heading">T.3b.i: sapling_outputs_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-i-sapling-outputs-compact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<p>A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP-307 <a id="id7" class="footnote_reference" href="#zip-0307">6</a> <code>CompactBlock</code> format for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
<p>A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP-307 <a id="id7" class="footnote_reference" href="#zip-0307">7</a> <code>CompactBlock</code> format for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
<pre>T.3b.i.1: cmu (field encoding bytes)
T.3b.i.2: ephemeral_key (field encoding bytes)
T.3b.i.3: enc_ciphertext[..52] (First 52 bytes of field encoding)</pre>
@ -159,29 +182,68 @@ T.3b.i.3: enc_ciphertext[..52] (First 52 bytes of field encoding)</pre>
<pre>"ZTxIdSOutM__Hash" (2 underscore characters)</pre>
</section>
<section id="t-3b-iii-sapling-outputs-noncompact-digest"><h8><span class="section-heading">T.3b.iii: sapling_outputs_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-iii-sapling-outputs-noncompact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<p>A BLAKE2b-256 hash of the remaining subset of Sapling output information <strong>not</strong> included in the ZIP 307 <a id="id8" class="footnote_reference" href="#zip-0307">6</a> <code>CompactBlock</code> format, excluding zkproof data, for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
<p>A BLAKE2b-256 hash of the remaining subset of Sapling output information <strong>not</strong> included in the ZIP 307 <a id="id8" class="footnote_reference" href="#zip-0307">7</a> <code>CompactBlock</code> format, excluding zkproof data, for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
<pre>T.3b.iii.1: cv (field encoding bytes)
T.3b.iii.2: enc_ciphertext[564..] (post-memo Poly1305 AEAD tag of field encoding)
T.3b.iii.3: out_ciphertext (field encoding bytes)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdSOutN__Hash" (2 underscore characters)</pre>
<section id="t-4-orchard-digest"><h9><span class="section-heading">T.4: <code>orchard_digest</code></span><span class="section-anchor"> <a rel="bookmark" href="#t-4-orchard-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h9>
<p>In the case that Orchard actions are present in the transaction, this digest is a BLAKE2b-256 hash of the following values</p>
<pre>T.4a: orchard_actions_compact_digest (32-byte hash output)
T.4b: orchard_actions_memos_digest (32-byte hash output)
T.4c: orchard_actions_noncompact_digest (32-byte hash output)
T.4d: flagsOrchard (1 byte)
T.4e: valueBalanceOrchard (64-bit signed little-endian)
T.4f: anchorOrchard (32 bytes)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdOrchardHash"</pre>
<p>In the case that the transaction has no Orchard actions, <code>orchard_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdOrchardHash", [])</pre>
</section>
<section id="t-4a-orchard-actions-compact-digest"><h9><span class="section-heading">T.4a: orchard_actions_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4a-orchard-actions-compact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h9>
<p>A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 <a id="id9" class="footnote_reference" href="#zip-0307">7</a> <code>CompactBlock</code> format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4a.i : nullifier (field encoding bytes)
T.4a.ii : cmx (field encoding bytes)
T.4a.iii: ephemeralKey (field encoding bytes)
T.4a.iv : encCiphertext[..52] (First 52 bytes of field encoding)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdOrcActCHash"</pre>
</section>
<section id="t-4b-orchard-actions-memos-digest"><h9><span class="section-heading">T.4b: orchard_actions_memos_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4b-orchard-actions-memos-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h9>
<p>A BLAKE2b-256 hash of the subset of Orchard shielded memo field data for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4b.i: encCiphertext[52..564] (contents of the encrypted memo field)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdOrcActMHash"</pre>
</section>
<section id="t-4c-orchard-actions-noncompact-digest"><h9><span class="section-heading">T.4c: orchard_actions_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4c-orchard-actions-noncompact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h9>
<p>A BLAKE2b-256 hash of the remaining subset of Orchard Action information <strong>not</strong> intended for inclusion in an updated version of the the ZIP 307 <a id="id10" class="footnote_reference" href="#zip-0307">7</a> <code>CompactBlock</code> format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4c.i : cv (field encoding bytes)
T.4c.ii : rk (field encoding bytes)
T.4c.iii: encCiphertext[564..] (post-memo suffix of field encoding)
T.4c.iv : outCiphertext (field encoding bytes)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdOrcActNHash"</pre>
</section>
</section>
</section>
</section>
</section>
</section>
<section id="signature-digest"><h4><span class="section-heading">Signature Digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A new per-input transaction digest algorithm is defined that constructs a hash that may be signed by a transaction creator to commit to the effects of the transaction. In the case that the transaction consumes no transparent inputs, it should be possible to just sign the transaction identifier produced by the <code>TxId Digest</code> algorithm. In the case that transparent inputs are present, this algorithm follows closely the ZIP 143 <a id="id9" class="footnote_reference" href="#zip-0143">5</a> algorithm.</p>
<p>A new per-input transaction digest algorithm is defined that constructs a hash that may be signed by a transaction creator to commit to the effects of the transaction. A signature digest is produced for each transparent input, each Sapling input, and each Orchard action. For transparent inputs, this follows closely the algorithms from ZIP 143 <a id="id11" class="footnote_reference" href="#zip-0143">5</a> and ZIP 243 <a id="id12" class="footnote_reference" href="#zip-0243">6</a>. For shielded inputs, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.</p>
<p>The overall structure of the hash is as follows; each name referenced here will be described in detail below:</p>
<pre>signature_digest
├── header_digest
├── transparent_sig_digest
└── sapling_digest</pre>
<section id="id10"><h5><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id10"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
├── sapling_digest
└── orchard_digest</pre>
<section id="id13"><h5><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id13"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>S.1: header_digest (32-byte hash output)
S.2: transparent_sig_digest (32-byte hash output)
S.3: sapling_digest (32-byte hash output)</pre>
S.3: sapling_digest (32-byte hash output)
S.4: orchard_digest (32-byte hash output)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZcashTxHash_" || CONSENSUS_BRANCH_ID</pre>
<p><code>ZcashTxHash_</code> has 1 underscore character.</p>
@ -190,13 +252,14 @@ S.3: sapling_digest (32-byte hash output)</pre>
<p>Identical to that specified for the transaction identifier.</p>
</section>
<section id="s-2-transparent-sig-digest"><h6><span class="section-heading">S.2: transparent_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2-transparent-sig-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>If we are producing a hash for the signature over a transparent input, the value of the digest produced here depends upon the value of a <code>hash_type</code> flag as in ZIP 143 <a id="id11" class="footnote_reference" href="#zip-0143">5</a>.</p>
<p>If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, the value of <code>transparent_sig_digest</code> is identical to the value specified in section <a href="#t-2-transparent-digest">T.2</a>.</p>
<p>If we are producing a hash for signature over a transparent input, the value of <code>transparent_sig_digest</code> depends upon the value of a <code>hash_type</code> flag as in ZIP 143 <a id="id14" class="footnote_reference" href="#zip-0143">5</a>.</p>
<p>The construction of each component below depends upon the values of the <code>hash_type</code> flag bits. Each component will be described separately</p>
<p>This digest is a BLAKE2b-256 hash of the following values</p>
<pre>S.2a: prevouts_sig_digest (32-byte hash)
S.2b: sequence_sig_digest (32-byte hash)
S.2c: outputs_sig_digest (32-byte hash)
S.2d: txin_sig_digest (32-byte hash)</pre>
S.2d: txin_sig_digest (32-byte hash)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdTranspaHash"</pre>
<section id="s-2a-prevouts-sig-digest"><h7><span class="section-heading">S.2a: prevouts_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2a-prevouts-sig-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
@ -205,8 +268,7 @@ S.2d: txin_sig_digest (32-byte hash)</pre>
<pre>identical to the value of ``prevouts_digest`` as specified for the
transaction identifier in section T.2a.</pre>
<p>otherwise:</p>
<pre>the hash is immediately finalized, without being updated with any
additional data</pre>
<pre>BLAKE2b-256(``ZTxIdPrevoutHash``, [])</pre>
</section>
<section id="s-2b-sequence-sig-digest"><h7><span class="section-heading">S.2b: sequence_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2b-sequence-sig-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>This is a BLAKE2b-256 hash initialized with the personalization field value <code>ZTxIdSequencHash</code>.</p>
@ -214,8 +276,7 @@ additional data</pre>
<pre>identical to the value of ``sequence_digest`` as specified for the
transaction identifier in section T.2b.</pre>
<p>otherwise:</p>
<pre>the hash is immediately finalized, without being updated with any
additional data</pre>
<pre>BLAKE2b-256(``ZTxIdSequencHash``, [])</pre>
</section>
<section id="s-2c-outputs-sig-digest"><h7><span class="section-heading">S.2c: outputs_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2c-outputs-sig-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>This is a BLAKE2b-256 hash initialized with the personalization field value <code>ZTxIdOutputsHash</code>.</p>
@ -223,56 +284,71 @@ additional data</pre>
<pre>identical to the value of ``outputs_digest`` as specified for the
transaction identifier in section T.2c.</pre>
<p>If the sighash type is <code>SIGHASH_SINGLE</code> and the signature hash is being computed for the transparent input at a particular index, and a transparent output appears in the transaction at that index:</p>
<pre>the hash is updated with the transaction serialized form of the
transparent output at that index, and finalized.</pre>
<p>If the sighash type is <code>SIGHASH_SINGLE</code> and the signature is being computed for a shielded input, or if the sighash type is <code>SIGHASH_NONE</code>:</p>
<pre>the hash is immediately finalized, without being updated with any
additional data</pre>
<pre>the hash is over the transaction serialized form of the transparent output at that
index</pre>
<p>otherwise:</p>
<pre>BLAKE2b-256(``ZTxIdOutputsHash``, [])</pre>
</section>
<section id="s-2d-txin-sig-digest"><h7><span class="section-heading">S.2d: txin_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2d-txin-sig-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h7>
<p>This is a BLAKE2b-256 hash initialized with the personalization field value <code>Zcash___TxInHash</code> (3 underscores).</p>
<p>If the signature hash is being computed for a transparent input, the hash is updated with the following properties of that input:</p>
<p>This is a BLAKE2b-256 hash of the following properties of the transparent input being signed, initialized with the personalization field value <code>Zcash___TxInHash</code> (3 underscores):</p>
<pre>S.2d.i: prevout (field encoding)
S.2d.ii: script_code (field encoding)
S.2d.iii: value (8-byte signed little-endian)
S.2d.iv: nSequence (4-byte unsigned little-endian)</pre>
<p>otherwise:</p>
<pre>the hash is immediately finalized, without being updated with any
additional data</pre>
<p>Note: <code>value</code> is defined in the consensus rules to be a nonnegative value &lt;= <code>MAX_MONEY</code>, but all existing implementations parse this value as signed and enforce the nonnegative constraint as a consensus check. It is defined as signed here for consistency with those existing implementations.</p>
</section>
</section>
<section id="s-3-sapling-digest"><h6><span class="section-heading">S.3: sapling_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-3-sapling-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>Identical to that specified for the transaction identifier.</p>
</section>
<section id="s-4-orchard-digest"><h6><span class="section-heading">S.4: orchard_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-4-orchard-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>Identical to that specified for the transaction identifier.</p>
</section>
</section>
</section>
<section id="authorizing-data-commitment"><h4><span class="section-heading">Authorizing Data Commitment</span><span class="section-anchor"> <a rel="bookmark" href="#authorizing-data-commitment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A new transaction digest algorithm is defined that constructs a digest which commits to the authorizing data of a transaction from a tree of BLAKE2b-256 hashes. The overall structure of the hash is as follows:</p>
<pre>auth_digest
├── transparent_scripts_digest
└── sapling_auth_digest</pre>
├── sapling_auth_digest
└── orchard_auth_digest</pre>
<p>Each node written as <code>snake_case</code> in this tree is a BLAKE2b-256 hash of authorizing data of the transaction.</p>
<p>The pair (Transaction Identifier, Auth Commitment) constitutes a commitment to all the data of a serialized transaction that may be included in a block.</p>
<section id="auth-digest"><h5><span class="section-heading">auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#auth-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>A1: transparent_scripts_digest (32-byte hash output)
A2: sapling_auth_digest (32-byte hash output)</pre>
<pre>A.1: transparent_scripts_digest (32-byte hash output)
A.2: sapling_auth_digest (32-byte hash output)
A.3: orchard_auth_digest (32-byte hash output)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxAuthHash_" || CONSENSUS_BRANCH_ID</pre>
<p><code>ZTxAuthHash_</code> has 1 underscore character.</p>
<section id="a-1-transparent-scripts-digest"><h6><span class="section-heading">A.1: transparent_scripts_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-1-transparent-scripts-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>A BLAKE2b-256 hash of the field encoding of the Bitcoin script associated with each transparent input belonging to the transaction.</p>
<p>In the case that the transaction contains transparent inputs, this is a BLAKE2b-256 hash of the field encoding of the concatenated values of the Bitcoin script values associated with each transparent input belonging to the transaction.</p>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxAuthTransHash"</pre>
<p>In the case that the transaction has no transparent inputs, <code>transparent_scripts_digest</code> is</p>
<pre>BLAKE2b-256("ZTxAuthTransHash", [])</pre>
</section>
<section id="a-2-sapling-auth-digest"><h6><span class="section-heading">A.2: sapling_auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-2-sapling-auth-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>A BLAKE2b-256 hash of the field encoding of the Sapling <code>zkproof</code> value of each Sapling Spend Description, followed by the field encoding of the <code>spend_auth_sig</code> value of each Sapling Spend Description belonging to the transaction, followed by the field encoding of the <code>zkproof</code> field of each Sapling Output Description belonging to the transaction, followed by the field encoding of the binding signature:</p>
<p>In the case that Sapling Spends or Sapling Outputs are present, this is a BLAKE2b-256 hash of the field encoding of the Sapling <code>zkproof</code> value of each Sapling Spend Description, followed by the field encoding of the <code>spend_auth_sig</code> value of each Sapling Spend Description belonging to the transaction, followed by the field encoding of the <code>zkproof</code> field of each Sapling Output Description belonging to the transaction, followed by the field encoding of the binding signature:</p>
<pre>A.2a: spend_zkproofs (field encoding bytes)
A.2b: spend_auth_sigs (field encoding bytes)
A.2c: output_zkproofs (field encoding bytes)
A.2d: binding_sig (field encoding bytes)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxAuthSapliHash"</pre>
<p>In the case that the transaction has no Sapling Spends or Sapling Outputs, <code>sapling_auth_digest</code> is</p>
<pre>BLAKE2b-256("ZTxAuthSapliHash", [])</pre>
</section>
<section id="a-3-orchard-auth-digest"><h6><span class="section-heading">A.3: orchard_auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-3-orchard-auth-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>In the case that Orchard Actions are present, this is a BLAKE2b-256 hash of the field encoding of the <code>zkProofsOrchard</code>, <code>spendAuthSigsOrchard</code>, and <code>bindingSigOrchard</code> fields of the transaction:</p>
<pre>A.3a: proofsOrchard (field encoding bytes)
A.3b: vSpendAuthSigsOrchard (field encoding bytes)
A.3c: bindingSigOrchard (field encoding bytes)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxAuthOrchaHash"</pre>
<p>In the case that the transaction has no Orchard Actions, <code>orchard_auth_digest</code> is</p>
<pre>BLAKE2b-256("ZTxAuthOrchaHash", [])</pre>
</section>
</section>
</section>
@ -281,7 +357,7 @@ A.2d: binding_sig (field encoding bytes)</pre>
<p>The nonmalleable transaction identifier specified by this ZIP will be used in the place of the current malleable transaction identifier within the Merkle tree committed to by the <code>hashMerkleRoot</code> value. However, this change now means that <code>hashMerkleRoot</code> is not sufficient to fully commit to the transaction data, including witnesses, that appear within the block.</p>
<p>As a consequence, we now need to add a new commitment to the block header. This commitment will be the root of a Merkle tree that has parallel structure to the tree committed to by <code>hashMerkleRoot</code> (a path through this Merkle tree to a transaction identifies the same transaction as that path reaches in the tree rooted at <code>hashMerkleRoot</code>), but where the leaves are hashes produced according to the <cite>Authorizing Data Commitment</cite> part of this specification.</p>
<p>This new commitment is named <code>hashAuthDataRoot</code> and is the root of a left-dense binary Merkle tree of transaction authorizing data commitments. Empty internal nodes and leaves in the Merkle tree (nodes without children) have the "null" hash value <code>[0u8; 32]</code>. Hashes in this tree are BLAKE2b-256 hashes personalized by the string <code>"ZcashAuthDatHash"</code>.</p>
<p>Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the <code>hashLightClientRoot</code> field, described in ZIP 221 <a id="id12" class="footnote_reference" href="#zip-0221">3</a>, is changed.</p>
<p>Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the <code>hashLightClientRoot</code> field, described in ZIP 221 <a id="id15" class="footnote_reference" href="#zip-0221">3</a>, is changed.</p>
<p><code>hashLightClientRoot</code> is renamed to <code>hashBlockCommitments</code>. The value of this hash is the BLAKE2b-256 hash personalized by the string <code>"ZcashBlockCommit"</code> of the following elements:</p>
<pre>hashLightClientRoot (as described in ZIP 221)
hashAuthDataRoot (as described below)
@ -338,10 +414,18 @@ terminator [0u8;32]</pre>
</tr>
</tbody>
</table>
<table id="zip-0307" class="footnote">
<table id="zip-0243" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="zip-0243">ZIP 243: Transaction Signature Validation for Sapling</a></td>
</tr>
</tbody>
</table>
<table id="zip-0307" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="zip-0307">ZIP 307: Light Client Protocol for Payment Detection</a></td>
</tr>
</tbody>
@ -349,7 +433,7 @@ terminator [0u8;32]</pre>
<table id="protocol-txnencodingandconsensus" class="footnote">
<tbody>
<tr>
<th>7</th>
<th>8</th>
<td><a href="protocol/nu5.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>

267
zip-0244.rst
View File

@ -107,10 +107,13 @@ Specification
Digests
-------
All digests are personalized BLAKE2b-256 hashes. In cases where no elements are
available for hashing (for example, if there are no transparent inputs) the resulting hash
will be over just the personalization string, providing domain separation even for
empty data fields.
All digests are personalized BLAKE2b-256 hashes. In cases where no elements are available
for hashing (for example, if there are no transparent transaction inputs or no Orchard
actions), a personalized hash of the empty byte array will be used. The personalization
string therefore provides domain separation for the hashes of even empty data fields.
The notation ``BLAKE2b-256(personalization_string, [])`` is used to refer to hashes
constructed in this manner.
TxId Digest
===========
@ -127,15 +130,22 @@ below::
│   ├── prevouts_digest
│   ├── sequence_digest
│   └── outputs_digest
└── sapling_digest
   ├── sapling_spends_digest
│   ├── sapling_spends_compact_digest
│   └── sapling_spends_noncompact_digest
   ├── sapling_outputs_digest
│   ├── sapling_outputs_compact_digest
│   ├── sapling_outputs_memos_digest
│   └── sapling_outputs_noncompact_digest
    └── valueBalance
├── sapling_digest
│   ├── sapling_spends_digest
│   │   ├── sapling_spends_compact_digest
│   │   └── sapling_spends_noncompact_digest
│   ├── sapling_outputs_digest
│   │   ├── sapling_outputs_compact_digest
│   │   ├── sapling_outputs_memos_digest
│   │   └── sapling_outputs_noncompact_digest
│   └── valueBalance
└── orchard_digest
   ├── orchard_actions_compact_digest
   ├── orchard_actions_memos_digest
   ├── orchard_actions_noncompact_digest
   ├── flagsOrchard
   ├── valueBalanceOrchard
   └── anchorOrchard
Each node written as ``snake_case`` in this tree is a BLAKE2b-256 hash of its
children, initialized with a personalization string specific to that branch
@ -149,6 +159,7 @@ A BLAKE2b-256 hash of the following values ::
T.1: header_digest (32-byte hash output)
T.2: transparent_digest (32-byte hash output)
T.3: sapling_digest (32-byte hash output)
T.4: orchard_digest (32-byte hash output)
The personalization field of this hash is set to::
@ -184,7 +195,8 @@ The personalization field of this hash is set to::
T.2: transparent_digest
```````````````````````
A BLAKE2b-256 hash of the following values ::
In the case that transparent inputs or outputs are present, the transparent digest
consists of a BLAKE2b-256 hash of the following values ::
T.2a: prevouts_digest (32-byte hash)
T.2b: sequence_digest (32-byte hash)
@ -194,6 +206,10 @@ The personalization field of this hash is set to::
"ZTxIdTranspaHash"
In the case that the transaction has no transparent components, ``transparent_digest`` is ::
BLAKE2b-256("ZTxIdTranspaHash", [])
T.2a: prevouts_digest
'''''''''''''''''''''
A BLAKE2b-256 hash of the field encoding of all ``outpoint``
@ -203,6 +219,11 @@ The personalization field of this hash is set to::
"ZTxIdPrevoutHash"
In the case that the transaction has transparent outputs but no transparent inputs,
``prevouts_digest`` is ::
BLAKE2b-256("ZTxIdPrevoutHash", [])
T.2b: sequence_digest
'''''''''''''''''''''
A BLAKE2b-256 hash of the 32-bit little-endian representation of all ``nSequence``
@ -212,22 +233,33 @@ The personalization field of this hash is set to::
"ZTxIdSequencHash"
In the case that the transaction has transparent outputs but no transparent inputs,
``sequence_digest`` is ::
BLAKE2b-256("ZTxIdSequencHash", [])
T.2c: outputs_digest
''''''''''''''''''''
A BLAKE2b-256 hash of the concatenated field encodings of all transparent
A BLAKE2b-256 hash of the concatenated field encodings of all transparent
output values of the transaction. The field encoding of such an output consists
of the encoded output ``amount`` (8-byte little endian) followed by
of the encoded output ``amount`` (8-byte little endian) followed by
the ``scriptPubKey`` byte array (serialized as Bitcoin script).
The personalization field of this hash is set to::
"ZTxIdOutputsHash"
In the case that the transaction has transparent inputs but no transparent outputs,
``outputs_digest`` is ::
BLAKE2b-256("ZTxIdOutputsHash", [])
T.3: sapling_digest
```````````````````
The digest of Sapling components is composed of two subtrees which are organized to
permit easy interoperability with the ``CompactBlock`` representation of Sapling data
specified by the ZIP 307 Light Client Protocol [#zip-0307]_.
In the case that Sapling spends or outputs are present, the digest of Sapling components
is composed of two subtrees which are organized to permit easy interoperability with the
``CompactBlock`` representation of Sapling data specified by the ZIP 307 Light Client
Protocol [#zip-0307]_.
This digest is a BLAKE2b-256 hash of the following values ::
@ -239,9 +271,14 @@ The personalization field of this hash is set to::
"ZTxIdSaplingHash"
In the case that the transaction has no Sapling spends or outputs, ``sapling_digest`` is ::
BLAKE2b-256("ZTxIdSaplingHash", [])
T.3a: sapling_spends_digest
'''''''''''''''''''''''''''
This digest is a BLAKE2b-256 hash of the following values ::
In the case that Sapling spends are present, this digest is a BLAKE2b-256 hash of the
following values ::
T.3a.i: sapling_spends_compact_digest (32-byte hash)
T.3a.ii: sapling_spends_noncompact_digest (32-byte hash)
@ -250,6 +287,11 @@ The personalization field of this hash is set to::
"ZTxIdSSpendsHash"
In the case that the transaction has Sapling outputs but no Sapling spends,
``sapling_spends_digest`` is ::
BLAKE2b-256("ZTxIdSSpendsHash", [])
T.3a.i: sapling_spends_compact_digest
.....................................
A BLAKE2b-256 hash of the field encoding of all ``nullifier`` field
@ -278,7 +320,8 @@ The personalization field of this hash is set to::
T.3b: sapling_outputs_digest
''''''''''''''''''''''''''''
This digest is a BLAKE2b-256 hash of the following values ::
In the case that Sapling outputs are present, this digest is a BLAKE2b-256 hash of the
following values ::
T.3b.i: sapling_outputs_compact_digest (32-byte hash)
T.3b.ii: sapling_outputs_memos_digest (32-byte hash)
@ -288,6 +331,11 @@ The personalization field of this hash is set to::
"ZTxIdSOutputHash"
In the case that the transaction has Sapling spends but no Sapling outputs,
``sapling_outputs_digest`` is ::
BLAKE2b-256("ZTxIdSOutputHash", [])
T.3b.i: sapling_outputs_compact_digest
......................................
A BLAKE2b-256 hash of the subset of Sapling output information included in the
@ -330,15 +378,82 @@ The personalization field of this hash is set to::
"ZTxIdSOutN__Hash" (2 underscore characters)
T.4: ``orchard_digest``
"""""""""""""""""""""""
In the case that Orchard actions are present in the transaction, this digest is
a BLAKE2b-256 hash of the following values ::
T.4a: orchard_actions_compact_digest (32-byte hash output)
T.4b: orchard_actions_memos_digest (32-byte hash output)
T.4c: orchard_actions_noncompact_digest (32-byte hash output)
T.4d: flagsOrchard (1 byte)
T.4e: valueBalanceOrchard (64-bit signed little-endian)
T.4f: anchorOrchard (32 bytes)
The personalization field of this hash is set to::
"ZTxIdOrchardHash"
In the case that the transaction has no Orchard actions, ``orchard_digest`` is ::
BLAKE2b-256("ZTxIdOrchardHash", [])
T.4a: orchard_actions_compact_digest
""""""""""""""""""""""""""""""""""""
A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in
an updated version of the ZIP-307 [#zip-0307]_ ``CompactBlock`` format for all Orchard
Actions belonging to the transaction. For each Action, the following elements are included
in the hash::
T.4a.i : nullifier (field encoding bytes)
T.4a.ii : cmx (field encoding bytes)
T.4a.iii: ephemeralKey (field encoding bytes)
T.4a.iv : encCiphertext[..52] (First 52 bytes of field encoding)
The personalization field of this hash is set to::
"ZTxIdOrcActCHash"
T.4b: orchard_actions_memos_digest
""""""""""""""""""""""""""""""""""
A BLAKE2b-256 hash of the subset of Orchard shielded memo field data for all Orchard
Actions belonging to the transaction. For each Action, the following elements are included
in the hash::
T.4b.i: encCiphertext[52..564] (contents of the encrypted memo field)
The personalization field of this hash is set to::
"ZTxIdOrcActMHash"
T.4c: orchard_actions_noncompact_digest
"""""""""""""""""""""""""""""""""""""""
A BLAKE2b-256 hash of the remaining subset of Orchard Action information **not** intended
for inclusion in an updated version of the the ZIP 307 [#zip-0307]_ ``CompactBlock``
format, for all Orchard Actions belonging to the transaction. For each Action,
the following elements are included in the hash::
T.4c.i : cv (field encoding bytes)
T.4c.ii : rk (field encoding bytes)
T.4c.iii: encCiphertext[564..] (post-memo suffix of field encoding)
T.4c.iv : outCiphertext (field encoding bytes)
The personalization field of this hash is set to::
"ZTxIdOrcActNHash"
Signature Digest
================
A new per-input transaction digest algorithm is defined that constructs a hash that may be
signed by a transaction creator to commit to the effects of the transaction. In the case
that the transaction consumes no transparent inputs, it should be possible to just sign
the transaction identifier produced by the ``TxId Digest`` algorithm. In the case that
transparent inputs are present, this algorithm follows closely the ZIP 143 [#zip-0143]_
algorithm.
signed by a transaction creator to commit to the effects of the transaction. A signature
digest is produced for each transparent input, each Sapling input, and each Orchard
action. For transparent inputs, this follows closely the algorithms from ZIP 143 [#zip-0143]_
and ZIP 243 [#zip-0243]_. For shielded inputs, this algorithm has the exact same output
as the transaction digest algorithm, thus the txid may be signed directly.
The overall structure of the hash is as follows; each name referenced here will be
described in detail below::
@ -346,7 +461,8 @@ described in detail below::
signature_digest
├── header_digest
├── transparent_sig_digest
└── sapling_digest
├── sapling_digest
└── orchard_digest
signature_digest
----------------
@ -355,6 +471,7 @@ A BLAKE2b-256 hash of the following values ::
S.1: header_digest (32-byte hash output)
S.2: transparent_sig_digest (32-byte hash output)
S.3: sapling_digest (32-byte hash output)
S.4: orchard_digest (32-byte hash output)
The personalization field of this hash is set to::
@ -372,9 +489,13 @@ Identical to that specified for the transaction identifier.
S.2: transparent_sig_digest
```````````````````````````
If we are producing a hash for the signature over a transparent input,
the value of the digest produced here depends upon the value of a ``hash_type``
flag as in ZIP 143 [#zip-0143]_.
If we are producing a hash for the signature over a Sapling Spend or an Orchard Action,
the value of ``transparent_sig_digest`` is identical to the value specified in section
`T.2 <#t-2-transparent-digest>`_.
If we are producing a hash for signature over a transparent input, the value of
``transparent_sig_digest`` depends upon the value of a ``hash_type`` flag as in ZIP 143
[#zip-0143]_.
The construction of each component below depends upon the values of the
``hash_type`` flag bits. Each component will be described separately
@ -384,7 +505,7 @@ This digest is a BLAKE2b-256 hash of the following values ::
S.2a: prevouts_sig_digest (32-byte hash)
S.2b: sequence_sig_digest (32-byte hash)
S.2c: outputs_sig_digest (32-byte hash)
S.2d: txin_sig_digest (32-byte hash)
S.2d: txin_sig_digest (32-byte hash)
The personalization field of this hash is set to::
@ -402,8 +523,7 @@ If the ``SIGHASH_ANYONECANPAY`` flag is not set::
otherwise::
the hash is immediately finalized, without being updated with any
additional data
BLAKE2b-256(``ZTxIdPrevoutHash``, [])
S.2b: sequence_sig_digest
'''''''''''''''''''''''''
@ -418,8 +538,7 @@ If the ``SIGHASH_ANYONECANPAY`` flag is not set, and the sighash type is neither
otherwise::
the hash is immediately finalized, without being updated with any
additional data
BLAKE2b-256(``ZTxIdSequencHash``, [])
S.2c: outputs_sig_digest
''''''''''''''''''''''''
@ -435,37 +554,37 @@ If the sighash type is ``SIGHASH_SINGLE`` and the signature hash is being comput
the transparent input at a particular index, and a transparent output appears in
the transaction at that index::
the hash is updated with the transaction serialized form of the
transparent output at that index, and finalized.
the hash is over the transaction serialized form of the transparent output at that
index
If the sighash type is ``SIGHASH_SINGLE`` and the signature is being computed for
a shielded input, or if the sighash type is ``SIGHASH_NONE``::
otherwise::
the hash is immediately finalized, without being updated with any
additional data
BLAKE2b-256(``ZTxIdOutputsHash``, [])
S.2d: txin_sig_digest
'''''''''''''''''''''
This is a BLAKE2b-256 hash initialized with the personalization field value
``Zcash___TxInHash`` (3 underscores).
If the signature hash is being computed for a transparent input, the hash
is updated with the following properties of that input::
This is a BLAKE2b-256 hash of the following properties of the transparent input being
signed, initialized with the personalization field value ``Zcash___TxInHash`` (3
underscores)::
S.2d.i: prevout (field encoding)
S.2d.ii: script_code (field encoding)
S.2d.iii: value (8-byte signed little-endian)
S.2d.iv: nSequence (4-byte unsigned little-endian)
otherwise::
the hash is immediately finalized, without being updated with any
additional data
Note: ``value`` is defined in the consensus rules to be a nonnegative value <=
``MAX_MONEY``, but all existing implementations parse this value as signed and
enforce the nonnegative constraint as a consensus check. It is defined as signed
here for consistency with those existing implementations.
S.3: sapling_digest
```````````````````
Identical to that specified for the transaction identifier.
S.4: orchard_digest
```````````````````
Identical to that specified for the transaction identifier.
Authorizing Data Commitment
===========================
@ -475,7 +594,8 @@ The overall structure of the hash is as follows::
auth_digest
├── transparent_scripts_digest
└── sapling_auth_digest
├── sapling_auth_digest
└── orchard_auth_digest
Each node written as ``snake_case`` in this tree is a BLAKE2b-256 hash of authorizing
data of the transaction.
@ -487,8 +607,9 @@ auth_digest
-----------
A BLAKE2b-256 hash of the following values ::
A1: transparent_scripts_digest (32-byte hash output)
A2: sapling_auth_digest (32-byte hash output)
A.1: transparent_scripts_digest (32-byte hash output)
A.2: sapling_auth_digest (32-byte hash output)
A.3: orchard_auth_digest (32-byte hash output)
The personalization field of this hash is set to::
@ -498,19 +619,25 @@ The personalization field of this hash is set to::
A.1: transparent_scripts_digest
```````````````````````````````
A BLAKE2b-256 hash of the field encoding of the Bitcoin script associated
In the case that the transaction contains transparent inputs, this is a BLAKE2b-256 hash
of the field encoding of the concatenated values of the Bitcoin script values associated
with each transparent input belonging to the transaction.
The personalization field of this hash is set to::
"ZTxAuthTransHash"
In the case that the transaction has no transparent inputs, ``transparent_scripts_digest`` is ::
BLAKE2b-256("ZTxAuthTransHash", [])
A.2: sapling_auth_digest
````````````````````````
A BLAKE2b-256 hash of the field encoding of the Sapling ``zkproof`` value of each Sapling
Spend Description, followed by the field encoding of the ``spend_auth_sig`` value of each
Sapling Spend Description belonging to the transaction, followed by the field encoding of
the ``zkproof`` field of each Sapling Output Description belonging to the transaction,
In the case that Sapling Spends or Sapling Outputs are present, this is a BLAKE2b-256 hash
of the field encoding of the Sapling ``zkproof`` value of each Sapling Spend Description,
followed by the field encoding of the ``spend_auth_sig`` value of each Sapling Spend
Description belonging to the transaction, followed by the field encoding of the
``zkproof`` field of each Sapling Output Description belonging to the transaction,
followed by the field encoding of the binding signature::
A.2a: spend_zkproofs (field encoding bytes)
@ -522,6 +649,29 @@ The personalization field of this hash is set to::
"ZTxAuthSapliHash"
In the case that the transaction has no Sapling Spends or Sapling Outputs,
``sapling_auth_digest`` is ::
BLAKE2b-256("ZTxAuthSapliHash", [])
A.3: orchard_auth_digest
````````````````````````
In the case that Orchard Actions are present, this is a BLAKE2b-256 hash of the field
encoding of the ``zkProofsOrchard``, ``spendAuthSigsOrchard``, and ``bindingSigOrchard``
fields of the transaction::
A.3a: proofsOrchard (field encoding bytes)
A.3b: vSpendAuthSigsOrchard (field encoding bytes)
A.3c: bindingSigOrchard (field encoding bytes)
The personalization field of this hash is set to::
"ZTxAuthOrchaHash"
In the case that the transaction has no Orchard Actions, ``orchard_auth_digest`` is ::
BLAKE2b-256("ZTxAuthOrchaHash", [])
--------------------
Block Header Changes
--------------------
@ -592,5 +742,6 @@ References
.. [#zip-0221] `ZIP 221: FlyClient - Consensus Layer Changes <zip-0221.rst>`_
.. [#zip-0076] `ZIP 76: Transaction Signature Validation before Overwinter <zip-0076.rst>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling <zip-0243.rst>`_
.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection <zip-0307.rst>`_
.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus <protocol/nu5.pdf#txnencodingandconsensus>`_