mirror of https://github.com/zcash/zips.git
434 lines
32 KiB
ReStructuredText
434 lines
32 KiB
ReStructuredText
::
|
||
|
||
ZIP: 225
|
||
Title: Version 5 Transaction Format
|
||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||
Jack Grigg <jack@electriccoin.co>
|
||
Sean Bowe <sean@electriccoin.co>
|
||
Kris Nuttycombe <kris@electriccoin.co>
|
||
Ying Tong Lai <yingtong@electriccoin.co>
|
||
Status: Draft
|
||
Category: Consensus
|
||
Discussions-To: <https://github.com/zcash/zips/issues/440>
|
||
|
||
Terminology
|
||
===========
|
||
|
||
The key words "MUST" and "MAY" in this document are to be interpreted as described in
|
||
RFC 2119. [#RFC2119]_
|
||
|
||
The term "network upgrade" in this document is to be interpreted as described in ZIP 200
|
||
[#zip-0200]_.
|
||
|
||
Abstract
|
||
========
|
||
|
||
This proposal defines an update to the Zcash peer-to-peer transaction format to include
|
||
support for data elements required to support the Orchard protocol [#protocol_nu5]_. The
|
||
new transaction format defines well-bounded regions of the serialized form for to serve
|
||
each of the existing pools of funds, and adds and describes a new region containing
|
||
Orchard-specific elements.
|
||
|
||
This ZIP also depends upon and defines modifications to the computation of the values
|
||
**TxId Digest**, **Signature Digest**, and **Authorizing Data Commitment** defined by ZIP
|
||
244 [#zip-0244]_.
|
||
|
||
Motivation
|
||
==========
|
||
|
||
The new Orchard shielded pool requires a serialized data elements that are distinct from
|
||
any previous Zcash transaction. In addition, with the activation of ZIP 244, the
|
||
serialized transaction format will no longer be consensus-critical. It makes sense at this
|
||
point to define a format that can readily accommodate future extension in a systematic
|
||
fashion, where elements required for support for a given pool are kept separate.
|
||
|
||
Requirements
|
||
============
|
||
|
||
The new format must fully support the Orchard protocol.
|
||
|
||
The new format should lend itself to future extension or pruning to add or remove
|
||
value pools.
|
||
|
||
The computation of the non-malleable transaction identifier hash must include all
|
||
newly incorporated elements except those that attest to transaction validity.
|
||
|
||
The computation of the commitment to authorizing data for a transaction must include
|
||
all newly incorporated elements that attest to transaction validity.
|
||
|
||
Non-requirements
|
||
================
|
||
|
||
More general forms of extensibility, such as definining a key/value format that
|
||
allows for parsers that are unaware of some components, are not required.
|
||
|
||
Specification
|
||
=============
|
||
|
||
The Zcash transaction format for transaction version 5 is as follows:
|
||
|
||
Transaction Format
|
||
------------------
|
||
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
| Bytes | Name | Data Type | Description |
|
||
+=============================+==========================+======================================+============================================================+
|
||
| **Common Transaction Fields** |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``4`` |``header`` |``uint32`` |Contains: |
|
||
| | | | * fOverwintered flag (bit 31, always set) |
|
||
| | | | * version (bits 30 .. 0) – transaction version. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``4`` |``nVersionGroupId`` |``uint32`` |Version group ID (nonzero). |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``4`` |``lock_time`` |``uint32`` |Unix-epoch UTC time or block height, encoded as in Bitcoin. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``4`` |``nExpiryHeight`` |``uint32`` |A block height in the range {1 .. 499999999} after which |
|
||
| | | |the transaction will expire, or 0 to disable expiry. |
|
||
| | | |[ZIP-203] |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
| **Transparent Transaction Fields** |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``varies`` |``tx_in_count`` |``compactSize`` |Number of transparent inputs in tx_in |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``varies`` |``tx_in`` |``tx_in`` |Transparent inputs, encoded as in Bitcoin |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``varies`` |``tx_out_count`` |``compactSize`` |Number of transparent outputs in tx_out |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``varies`` |``tx_out`` |``tx_out`` |Transparent outputs, encoded as in Bitcoin |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
| **Sprout Transaction Fields** |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``varies`` |``nJoinSplits`` |``compactSize`` |The number of JoinSplit descriptions in vJoinSplits |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``1698 * nJoinSplits`` |``vJoinSplits`` |``JSDescriptionGroth16[nJoinSplits]`` |A sequence of JoinSplit descrptions using Groth16 proofs, |
|
||
| | | |encoded per § 7.2 ‘JoinSplit Description Encoding |
|
||
| | | |and Consensus’ |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``32`` |``joinSplitPubKey`` |``byte[32]`` |An encoding of a JoinSplitSig public validating key |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``64`` |``joinSplitSig`` |``byte[64]`` |A signature on a prefix of the transaction encoding, |
|
||
| | | |to be verfied using joinSplitPubKeyas specied in § 4.11 |
|
||
| | | |‘Non-malleability (Sprout)’ |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
| **Sapling Transaction Fields** |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``varies`` |``nSaplingSpends`` |``compactSize`` |Number of Sapling Spend Descriptions in vSaplingSpends |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``128 * nSaplingSpends`` |``vSaplingSpends`` |``SaplingSpendNU5[nSaplingSpends]`` |A sequence of Sapling Spend Descriptions, encoded per |
|
||
| | | |protocol §7.3 "Spend Description Encoding and Consensus" |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``varies`` |``nSaplingOutputs`` |``compactSize`` |Number of Sapling Output Decriptions in vSaplingOutputs |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``756 * nSaplingOutputs`` |``vSaplingOutputs`` |``SaplingOutputNU5[nSaplingOutputs]`` |A sequence of Sapling Output Descriptions, encoded per |
|
||
| | | |protocol §7.4 "Output Description Encoding and Consensus" |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``8`` |``valueBalanceSapling`` |``int64`` |The net value of Sapling spends minus outputs |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``32`` |``anchorSapling`` |``byte[32]`` |A root of the Sapling note commitment tree |
|
||
| | | |at some block height in the past |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``192 * nSaplingSpends`` |``zkproofsSaplingSpend`` |``byte[192 * nSaplingSpends]`` |Encodings of the zk-SNARK proofs for each SaplingSpend |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``64 * nSaplingSpends`` |``spendAuthSigsSapling`` |``byte[64 * nSaplingSpends]`` |Authorizing signatures for each SaplingSpend |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``192 * nSaplingOutputs`` |``zkproofsSaplingOutput`` |``byte[192 * nSaplingOutputs]`` |Encodings of the zk-SNARK proofs for each SaplingOutput |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``64`` |``bindingSigSapling`` |``byte[64]`` |A Sapling binding signature on the SIGHASH transaction hash |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
| **Orchard Transaction Fields** |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``varies`` |``nOrchardActions`` |``compactSize`` |The number of Orchard Action Descriptions in |
|
||
| | | |vOrchardActions |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``884 * nOrchardActions`` |``vOrchardActions`` |``OrchardAction[nOrchardActions]`` |A sequence of Orchard Action descriptions, encoded per |
|
||
| | | |§ 7.5 ‘Action Description Encoding and Consensus’ |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``8`` |``valueBalanceOrchard`` |``int64`` |The net value of Orchard spends minus outputs |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``32`` |``anchorOrchard`` |``byte[32]`` |A root of the Orchard note commitment tree at some block |
|
||
| | | |height in the past |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``2208 * nOrchardActions`` |``zkproofsOrchard`` |``byte[2208 * nOrchardActions]`` |Encodings of the zk-SNARK proofs for each OrchardAction |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``64 * nOrchardActions`` |``spendAuthSigsOrchard`` |``byte[64 * nOrchardActions]`` |Authorizing signatures for each OrchardAction |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``64`` |``bindingSigOrchard`` |``byte[64]`` |An Orchard binding signature on the SIGHASH transaction hash|
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|
||
* The valueBalanceSapling , anchorSapling , and bindingSigSapling fields are present if
|
||
and only if nSaplingSpends + nSaplingOutputs > 0. If valueBalanceSapling is not present,
|
||
then valueBalanceSapling is defined to be 0.
|
||
|
||
* The valueBalanceOrchard , anchorOrchard , and bindingSigOrchard fields are present if
|
||
and only if nOrchardActions > 0. If valueBalanceOrchard is not present, then valueBalanceOrchard is
|
||
defined to be 0.
|
||
|
||
* The joinSplitPubKey and joinSplitSig fields are present if and only if nJoinSplit > 0.
|
||
|
||
* The elements of ``zkproofsSaplingSpend`` and ``spendAuthSigsSapling`` have a 1:1
|
||
correspondence to the elements of ``vSaplingSpends`` and must be ordered such that
|
||
the proof or signature at a given index corresponds to the ``SaplingSpendNU5`` at
|
||
the same index.
|
||
|
||
* The elements of ``zkproofsSaplingOutput`` have a 1:1 correspondence to the elements of
|
||
``vSaplingOutputs`` and must be ordered such that the proof at a given index corresponds
|
||
to the ``SaplingOutputNU5`` at the same index.
|
||
|
||
* The elements of ``zkProofsOrchard`` and ``spendAuthSigsOrchard`` have a 1:1
|
||
correspondence to the elements of ``vOrchardActions`` and must be ordered such that
|
||
the proof or signature at a given index corresponds to the ``OrchardAction`` at
|
||
the same index.
|
||
|
||
The encodings of ``tx_in``, ``tx_out``, and ``JSDescriptionGroth16``, are as in NU4
|
||
[#protocol_nu4]_. The encodings of ``SaplingSpendNU5``, ``SaplingOutputNU5`` and
|
||
``OrchardAction`` are described below. The encoding of Sapling spends and outputs has
|
||
changed relative to prior versions in order to better separate data that describe
|
||
the effects of the transaction from the proofs of and commitments to those effects,
|
||
and for symmetry with this separation the Orchard-related section of the transaction
|
||
format.
|
||
|
||
Sapling Spend Description
|
||
--------------------------
|
||
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
| Bytes | Name | Data Type | Description |
|
||
+=============================+==========================+======================================+============================================================+
|
||
|``32`` |``cv`` |``byte[32]`` |A value commitment to the net value of the input note. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``32`` |``nullifier`` |``byte[32]`` |The nullifier of the input note. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``32`` |``rk`` |``byte[32]`` |The randomized validating key for the element of |
|
||
| | | |spendAuthSigsSapling corresponding to this spend. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|
||
The encodings of each of these elements are defined in § 7.3 ‘Spend Description Encoding
|
||
and Consensus’ of version 2021.1.16 of the Zcash Protocol Specification [#protocol_nu5]_.
|
||
|
||
Sapling Output Description
|
||
--------------------------
|
||
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
| Bytes | Name | Data Type | Description |
|
||
+=============================+==========================+======================================+============================================================+
|
||
|``32`` |``cv`` |``byte[32]`` |A value commitment to the net value of the output note. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``32`` |``cmu`` |``byte[32]`` |The u-coordinate of the note commitment for the output note |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``32`` |``ephemeralKey`` |``byte[32]`` |An encoding of an ephemeral Jubjub public key |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``580`` |``encCiphertext`` |``byte[580]`` |The encrypted contents of the note plaintext. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``80`` |``outCiphertext`` |``byte[580]`` |The encrypted contents of the byte string created by |
|
||
| | | |concatenation of the transmission key with the ephemeral |
|
||
| | | |secret key. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|
||
The encodings of each of these elements are defined in § 7.4 ‘Output Description Encoding
|
||
and Consensus’ of version 2021.1.16 of the Zcash Protocol Specification [#protocol_nu5]_.
|
||
|
||
Orchard Action Description
|
||
--------------------------
|
||
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
| Bytes | Name | Data Type | Description |
|
||
+=============================+==========================+======================================+============================================================+
|
||
|``32`` |``cv`` |``byte[32]`` |A value commitment to the net value of the input note minus |
|
||
| | | |the output note. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``32`` |``nullifier`` |``byte[32]`` |The nullifier of the input note. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``32`` |``rk`` |``byte[32]`` |The randomized validating key for the element of |
|
||
| | | |spendAuthSigsOrchard corresponding to this action. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``32`` |``cmx`` |``byte[32]`` |The x-coordinate of the note commitment for the output note |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``32`` |``ephemeralKey`` |``byte[32]`` |An encoding of an ephemeral Pallas public key |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``580`` |``encCiphertext`` |``byte[580]`` |The encrypted contents of the note plaintext. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|``80`` |``outCiphertext`` |``byte[580]`` |The encrypted contents of the byte string created by |
|
||
| | | |concatenation of the transmission key with the ephemeral |
|
||
| | | |secret key. |
|
||
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|
||
|
||
The encodings of each of these elements are defined in § 7.5 ‘Action Description Encoding
|
||
and Consensus’ of version 2021.1.16 of the Zcash Protocol Specification [#protocol_nu5]_.
|
||
|
||
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``, ``sprout_digest``, and ``sapling_digest``
|
||
are as in ZIP 244::
|
||
|
||
txid_digest
|
||
├── header_digest
|
||
├── transparent_digest
|
||
├── sprout_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: sprout_digest (32-byte hash output)
|
||
T.4: sapling_digest (32-byte hash output)
|
||
T.5: orchard_digest (32-byte hash output)
|
||
|
||
The personalization field of this hash is unmodified from ZIP 244.
|
||
|
||
2: ``orchard_digest``
|
||
'''''''''''''''''''''
|
||
A BLAKE2b-256 hash of the following values ::
|
||
|
||
T.5c: anchorOrchard (32 bytes)
|
||
T.5b: orchard_actions_compact_digest (32-byte hash output)
|
||
T.5c: orchard_actions_memos_digest (32-byte hash output)
|
||
T.5d: orchard_actions_noncompact_digest (32-byte hash output)
|
||
T.5e: valueBalanceOrchard (64-bit signed little-endian)
|
||
|
||
The personalization field of this hash is set to::
|
||
|
||
"ZTxIdOrchardHash"
|
||
|
||
T.5b: 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.5b.i : nullifier (field encoding bytes)
|
||
T.5b.ii : cmx (field encoding bytes)
|
||
T.5b.iii: ephemeralKey (field encoding bytes)
|
||
T.5b.iv : encCiphertext[..52] (First 52 bytes of field encoding)
|
||
|
||
The personalization field of this hash is set to::
|
||
|
||
"ZTxIdOrcOutCHash"
|
||
|
||
T.5c: 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.5c.i: encCiphertext[52..564] (contents of the encrypted memo field)
|
||
|
||
The personalization field of this hash is set to::
|
||
|
||
"ZTxIdOrcOutMHash"
|
||
|
||
T.5d: 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.5d.i : cv (field encoding bytes)
|
||
T.5d.ii : rk (field encoding bytes)
|
||
T.5d.iii: encCiphertext[564..] (post-memo suffix of field encoding)
|
||
T.5d.iv : outCiphertext (field encoding bytes)
|
||
|
||
The personalization field of this hash is set to::
|
||
|
||
"ZTxIdOrcOutNHash" (2 underscore characters)
|
||
|
||
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_digest``, ``sprout_digest``, and
|
||
``sapling_digest`` are as in ZIP 244::
|
||
|
||
signature_digest
|
||
├── header_digest
|
||
├── transparent_digest
|
||
├── sprout_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_digest (32-byte hash output)
|
||
S.3: sprout_digest (32-byte hash output)
|
||
S.4: sapling_digest (32-byte hash output)
|
||
S.5: orchard_digest (32-byte hash output)
|
||
|
||
The personalization field of this hash is unmodified from ZIP 244
|
||
|
||
S.5: 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_digest`` branch
|
||
is the only new addition to the tree; ``transparent_digest``, and ``sprout_digest``
|
||
``sapling_digest`` are as in ZIP 244::
|
||
|
||
auth_digest
|
||
├── transparent_scripts_digest
|
||
├── sprout_auth_digest
|
||
├── sapling_auth_digest
|
||
└── orchard_auth_digest
|
||
|
||
auth_digest
|
||
```````````
|
||
The tree of hashes defined by ZIP 244 [#zip-0244]_ for authorizing data commitments is
|
||
re-structured to include a new branch for Orchard authorizing data. The
|
||
``orchard_auth_digest`` branch is the only new addition to the tree;
|
||
``transparent_auth_digest``, ``sprout_auth_digest``, and ``sapling_auth_digest`` are as in
|
||
ZIP 244::
|
||
|
||
A.1: transparent_scripts_digest (32-byte hash output)
|
||
A.2: sprout_auth_digest (32-byte hash output)
|
||
A.3: sapling_auth_digest (32-byte hash output)
|
||
A.4: orchard_auth_digest (32-byte hash output)
|
||
|
||
The personalization field of this hash is unmodified from ZIP 244.
|
||
|
||
A.4: orchard_auth_digest
|
||
````````````````````````
|
||
A BLAKE2b-256 hash of the field encoding of the ``zkProofsOrchard``,
|
||
``spendAuthSigsOrchard``, and ``bindingSigOrchard`` fields of the transaction::
|
||
|
||
A.4a: zkproofsOrchard (field encoding bytes)
|
||
A.4b: spendAuthSigsOrchard (field encoding bytes)
|
||
A.4c: bindingSigOrchard (field encoding bytes)
|
||
|
||
The personalization field of this hash is set to::
|
||
|
||
"ZTxAuthOrchaHash"
|
||
|
||
Reference implementation
|
||
========================
|
||
|
||
TBD
|
||
|
||
References
|
||
==========
|
||
|
||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||
.. [#protocol_nu4] `Zcash Protocol Specification, Version 2020.1.15 <protocol/protocol.pdf>`_
|
||
.. [#protocol_nu5] `Zcash Protocol Specification, Version 2021.1.16 or later <protocol/orchard.pdf>`_
|
||
.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability<zip-0244.rst>`_
|
||
.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection <zip-0307.rst>`_
|