2020-09-14 07:22:13 -07:00
|
|
|
|
::
|
|
|
|
|
|
|
|
|
|
ZIP: 244
|
2021-01-26 14:06:30 -08:00
|
|
|
|
Title: Transaction Identifier Non-Malleability
|
2020-09-14 07:22:13 -07:00
|
|
|
|
Owners: Kris Nuttycombe <kris@electriccoin.co>
|
2021-01-13 15:27:19 -08:00
|
|
|
|
Daira Hopwood <daira@electriccoin.co>
|
2021-02-15 12:51:36 -08:00
|
|
|
|
Status: Proposed
|
2020-09-14 07:22:13 -07:00
|
|
|
|
Category: Consensus
|
2021-01-13 15:27:19 -08:00
|
|
|
|
Created: 2021-01-06
|
|
|
|
|
License: MIT
|
|
|
|
|
Discussions-To: <https://github.com/zcash/zips/issues/411>
|
|
|
|
|
|
|
|
|
|
===========
|
|
|
|
|
Terminology
|
|
|
|
|
===========
|
|
|
|
|
|
|
|
|
|
The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. [#RFC2119]_
|
|
|
|
|
|
|
|
|
|
The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as
|
|
|
|
|
described in ZIP 200. [#zip-0200]_
|
|
|
|
|
|
2021-02-02 12:06:43 -08:00
|
|
|
|
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
|
2021-03-30 12:19:33 -07:00
|
|
|
|
[#protocol-txnencodingandconsensus]_.
|
2021-02-02 12:06:43 -08:00
|
|
|
|
|
2021-01-13 15:27:19 -08:00
|
|
|
|
========
|
|
|
|
|
Abstract
|
|
|
|
|
========
|
|
|
|
|
|
2021-03-26 14:21:11 -07:00
|
|
|
|
This proposal defines a new transaction digest algorithm for the NU5 network upgrade
|
2021-01-13 15:27:19 -08:00
|
|
|
|
onward, in order to introduce non-malleable transaction identifiers that commit to
|
|
|
|
|
all transaction data except for attestations to transaction validity.
|
|
|
|
|
|
|
|
|
|
This proposal also defines a new transaction digest algorithm for signature validation,
|
2021-02-02 12:06:43 -08:00
|
|
|
|
which shares all available structure produced during the construction of transaction
|
2021-01-13 15:27:19 -08:00
|
|
|
|
identifiers, in order to minimize redundant data hashing in validation.
|
|
|
|
|
|
2021-01-21 16:23:09 -08:00
|
|
|
|
This proposal also defines a new name and semantics for the ``hashLightClientRoot`` field of the
|
2021-01-13 15:27:19 -08:00
|
|
|
|
block header, to enable additional commitments to be represented in this hash and to
|
|
|
|
|
provide a mechanism for future extensibility of the set of commitments represented.
|
|
|
|
|
|
|
|
|
|
==========
|
|
|
|
|
Motivation
|
|
|
|
|
==========
|
|
|
|
|
|
|
|
|
|
In all cases, but particularly in order to support the use of transactions in
|
|
|
|
|
higher-level protocols, any modification of the transaction that has not been
|
|
|
|
|
explicitly permitted (such as via anyone-can-spend inputs) should invalidate
|
|
|
|
|
attestations to spend authority or to the included outputs. Following the activation
|
2021-02-02 12:06:43 -08:00
|
|
|
|
of this proposed change, transaction identifiers will be stable irrespective of
|
2021-01-13 15:54:37 -08:00
|
|
|
|
any possible malleation of "witness data" such as proofs and transaction
|
|
|
|
|
signatures.
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-02-08 10:19:14 -08:00
|
|
|
|
In addition, by specifying a transaction identifier and signature algorithm
|
|
|
|
|
that is decoupled from the serialized format of the transaction as a whole,
|
2021-03-26 14:21:11 -07:00
|
|
|
|
this change makes it so that the wire format of transactions is no longer
|
2021-02-08 10:19:14 -08:00
|
|
|
|
consensus-critical.
|
|
|
|
|
|
2021-01-13 15:27:19 -08:00
|
|
|
|
============
|
|
|
|
|
Requirements
|
|
|
|
|
============
|
|
|
|
|
|
2021-02-02 12:06:43 -08:00
|
|
|
|
- Continue to support existing functionality of the protocol (multisig,
|
2021-01-13 15:27:19 -08:00
|
|
|
|
signing modes for transparent inputs).
|
|
|
|
|
|
|
|
|
|
- Allow the use of transaction ids, and pairs of the form (transaction id,
|
2021-02-02 12:06:43 -08:00
|
|
|
|
output index) as stable identifiers.
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
- A sender must be able to recognize their own transaction, even given allowed
|
2021-01-13 15:54:37 -08:00
|
|
|
|
forms of malleability such as recomputation of transaction signatures.
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
- In the case of transparent inputs, it should be possible to create a
|
|
|
|
|
transaction (B) that spends the outputs from a previous transaction (A) even
|
|
|
|
|
before (A) has been mined. This should also be possible in the case that the
|
2021-01-13 15:57:38 -08:00
|
|
|
|
creator of (B) does not wait for confirmations of (A). That is, (B) should remain
|
2021-01-13 15:27:19 -08:00
|
|
|
|
valid so long as any variant of (A) is eventually mined.
|
|
|
|
|
|
|
|
|
|
- It should not be possible for an attacker to malleate a transaction in a
|
|
|
|
|
fashion that would result in the transaction being interpreted as a
|
|
|
|
|
double-spend.
|
|
|
|
|
|
|
|
|
|
- It should be possible in the future to upgrade the protocol in such a fashion
|
|
|
|
|
that only non-malleable transactions are accepted.
|
|
|
|
|
|
|
|
|
|
- It should be possible to use the transaction id unmodified as the value that
|
|
|
|
|
is used to produce a signature hash in the case that the transaction contains
|
2021-03-26 14:14:59 -07:00
|
|
|
|
no transparent inputs.
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
================
|
|
|
|
|
Non-requirements
|
|
|
|
|
================
|
|
|
|
|
|
|
|
|
|
In order to support backwards-compatibility with parts of the ecosystem that
|
|
|
|
|
have not yet upgraded to the non-malleable transaction format, it is not an
|
|
|
|
|
initial requirement that all transactions be non-malleable.
|
|
|
|
|
|
2021-03-26 14:21:11 -07:00
|
|
|
|
It is not required that legacy (Sapling V4 and earlier) transaction formats
|
|
|
|
|
support construction of non-malleable transaction identifiers, even though
|
|
|
|
|
they may continue to be accepted by the network after the NU5 upgrade.
|
|
|
|
|
|
2021-01-13 15:27:19 -08:00
|
|
|
|
=============
|
|
|
|
|
Specification
|
|
|
|
|
=============
|
|
|
|
|
|
|
|
|
|
-------
|
|
|
|
|
Digests
|
|
|
|
|
-------
|
|
|
|
|
|
2021-05-06 14:49:50 -07:00
|
|
|
|
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.
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
TxId Digest
|
|
|
|
|
===========
|
|
|
|
|
|
|
|
|
|
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
|
2021-02-02 12:06:43 -08:00
|
|
|
|
correspond to a specific subset of transaction data. The overall structure of
|
2021-01-13 15:27:19 -08:00
|
|
|
|
the hash is as follows; each name referenced here will be described in detail
|
2021-01-26 14:06:30 -08:00
|
|
|
|
below::
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-01-13 15:57:38 -08:00
|
|
|
|
txid_digest
|
|
|
|
|
├── header_digest
|
|
|
|
|
├── transparent_digest
|
|
|
|
|
│ ├── prevouts_digest
|
|
|
|
|
│ ├── sequence_digest
|
|
|
|
|
│ └── outputs_digest
|
2021-05-06 14:49:50 -07:00
|
|
|
|
├── 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
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-02-02 12:06:43 -08:00
|
|
|
|
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
|
|
|
|
|
of the tree. Nodes that are not themselves digests are written in ``camelCase``.
|
2021-01-13 15:27:19 -08:00
|
|
|
|
In the specification below, nodes of the tree are presented in depth-first order.
|
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
txid_digest
|
|
|
|
|
-----------
|
2021-01-13 15:27:19 -08:00
|
|
|
|
A BLAKE2b-256 hash of the following values ::
|
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
T.1: header_digest (32-byte hash output)
|
|
|
|
|
T.2: transparent_digest (32-byte hash output)
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3: sapling_digest (32-byte hash output)
|
2021-05-06 14:49:50 -07:00
|
|
|
|
T.4: orchard_digest (32-byte hash output)
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZcashTxHash_" || CONSENSUS_BRANCH_ID
|
|
|
|
|
|
2021-02-04 09:57:28 -08:00
|
|
|
|
``ZcashTxHash_`` has 1 underscore character.
|
2021-02-02 12:22:02 -08:00
|
|
|
|
|
2021-01-20 16:28:39 -08:00
|
|
|
|
As in ZIP 143 [#zip-0143]_, CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of
|
|
|
|
|
the consensus branch ID for the epoch of the block containing the transaction. Domain
|
|
|
|
|
separation of the transaction id hash across parallel consensus branches provides replay
|
|
|
|
|
protection: transactions targeted for one consensus branch will not have the same
|
|
|
|
|
transaction identifier on other consensus branches.
|
|
|
|
|
|
2021-02-04 09:57:28 -08:00
|
|
|
|
This signature hash personalization prefix has been changed to reflect the new role of
|
|
|
|
|
this hash (relative to ``ZcashSigHash`` as specified in ZIP 143) as a transaction
|
|
|
|
|
identifier rather than a commitment that is exclusively used for signature purposes.
|
|
|
|
|
The previous computation of the transaction identifier was a SHA256d hash of the
|
|
|
|
|
serialized transaction contents, and was not personalized.
|
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
T.1: header_digest
|
|
|
|
|
``````````````````
|
2021-01-20 16:28:39 -08:00
|
|
|
|
A BLAKE2b-256 hash of the following values ::
|
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
T.1a: version (4-byte little-endian version identifier including overwinter flag)
|
|
|
|
|
T.1b: version_group_id (4-byte little-endian version group identifier)
|
|
|
|
|
T.1c: consensus_branch_id (4-byte little-endian consensus branch id)
|
|
|
|
|
T.1d: lock_time (4-byte little-endian nLockTime value)
|
|
|
|
|
T.1e: expiry_height (4-byte little-endian block height)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxIdHeadersHash"
|
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
T.2: transparent_digest
|
|
|
|
|
```````````````````````
|
2021-05-10 13:14:39 -07:00
|
|
|
|
In the case that transparent inputs or outputs are present, the transparent digest
|
2021-05-06 14:49:50 -07:00
|
|
|
|
consists of a BLAKE2b-256 hash of the following values ::
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
T.2a: prevouts_digest (32-byte hash)
|
|
|
|
|
T.2b: sequence_digest (32-byte hash)
|
|
|
|
|
T.2c: outputs_digest (32-byte hash)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxIdTranspaHash"
|
|
|
|
|
|
2021-05-06 14:49:50 -07:00
|
|
|
|
In the case that the transaction has no transparent components, ``transparent_digest`` is ::
|
|
|
|
|
|
|
|
|
|
BLAKE2b-256("ZTxIdTranspaHash", [])
|
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
T.2a: prevouts_digest
|
|
|
|
|
'''''''''''''''''''''
|
2021-01-13 15:27:19 -08:00
|
|
|
|
A BLAKE2b-256 hash of the field encoding of all ``outpoint``
|
|
|
|
|
field values of transparent inputs to the transaction.
|
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxIdPrevoutHash"
|
|
|
|
|
|
2021-05-18 07:16:00 -07:00
|
|
|
|
In the case that the transaction has transparent outputs but no transparent inputs,
|
|
|
|
|
``prevouts_digest`` is ::
|
2021-05-06 14:49:50 -07:00
|
|
|
|
|
|
|
|
|
BLAKE2b-256("ZTxIdPrevoutHash", [])
|
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
T.2b: sequence_digest
|
|
|
|
|
'''''''''''''''''''''
|
2021-01-13 15:27:19 -08:00
|
|
|
|
A BLAKE2b-256 hash of the 32-bit little-endian representation of all ``nSequence``
|
|
|
|
|
field values of transparent inputs to the transaction.
|
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxIdSequencHash"
|
|
|
|
|
|
2021-05-18 07:16:00 -07:00
|
|
|
|
In the case that the transaction has transparent outputs but no transparent inputs,
|
|
|
|
|
``sequence_digest`` is ::
|
2021-05-06 14:49:50 -07:00
|
|
|
|
|
|
|
|
|
BLAKE2b-256("ZTxIdSequencHash", [])
|
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
T.2c: outputs_digest
|
|
|
|
|
''''''''''''''''''''
|
2021-05-06 14:49:50 -07:00
|
|
|
|
A BLAKE2b-256 hash of the concatenated field encodings of all transparent
|
2021-04-23 07:20:20 -07:00
|
|
|
|
output values of the transaction. The field encoding of such an output consists
|
2021-05-06 14:49:50 -07:00
|
|
|
|
of the encoded output ``amount`` (8-byte little endian) followed by
|
2021-04-23 07:20:20 -07:00
|
|
|
|
the ``scriptPubKey`` byte array (serialized as Bitcoin script).
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxIdOutputsHash"
|
|
|
|
|
|
2021-05-18 07:16:00 -07:00
|
|
|
|
In the case that the transaction has transparent inputs but no transparent outputs,
|
|
|
|
|
``outputs_digest`` is ::
|
2021-05-06 14:49:50 -07:00
|
|
|
|
|
|
|
|
|
BLAKE2b-256("ZTxIdOutputsHash", [])
|
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3: sapling_digest
|
2021-01-26 14:29:24 -08:00
|
|
|
|
```````````````````
|
2021-05-06 14:49:50 -07:00
|
|
|
|
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]_.
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
This digest is a BLAKE2b-256 hash of the following values ::
|
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3a: sapling_spends_digest (32-byte hash)
|
|
|
|
|
T.3b: sapling_outputs_digest (32-byte hash)
|
|
|
|
|
T.3c: valueBalance (64-bit signed little-endian)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxIdSaplingHash"
|
|
|
|
|
|
2021-05-06 14:49:50 -07:00
|
|
|
|
In the case that the transaction has no Sapling spends or outputs, ``sapling_digest`` is ::
|
|
|
|
|
|
|
|
|
|
BLAKE2b-256("ZTxIdSaplingHash", [])
|
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3a: sapling_spends_digest
|
2021-01-26 14:29:24 -08:00
|
|
|
|
'''''''''''''''''''''''''''
|
2021-05-06 14:49:50 -07:00
|
|
|
|
In the case that Sapling spends are present, this digest is a BLAKE2b-256 hash of the
|
|
|
|
|
following values ::
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3a.i: sapling_spends_compact_digest (32-byte hash)
|
|
|
|
|
T.3a.ii: sapling_spends_noncompact_digest (32-byte hash)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxIdSSpendsHash"
|
|
|
|
|
|
2021-05-18 07:16:00 -07:00
|
|
|
|
In the case that the transaction has Sapling outputs but no Sapling spends,
|
|
|
|
|
``sapling_spends_digest`` is ::
|
2021-05-06 14:49:50 -07:00
|
|
|
|
|
|
|
|
|
BLAKE2b-256("ZTxIdSSpendsHash", [])
|
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3a.i: sapling_spends_compact_digest
|
2021-01-26 14:29:24 -08:00
|
|
|
|
.....................................
|
2021-01-26 13:31:47 -08:00
|
|
|
|
A BLAKE2b-256 hash of the field encoding of all ``nullifier`` field
|
2021-01-13 15:27:19 -08:00
|
|
|
|
values of Sapling shielded spends belonging to the transaction.
|
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxIdSSpendCHash"
|
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3a.ii: sapling_spends_noncompact_digest
|
2021-01-26 14:29:24 -08:00
|
|
|
|
.........................................
|
2021-01-13 15:27:19 -08:00
|
|
|
|
A BLAKE2b-256 hash of the non-nullifier information for all Sapling shielded spends
|
2021-02-09 07:06:00 -08:00
|
|
|
|
belonging to the transaction, excluding both zkproof data and spend authorization
|
|
|
|
|
signature(s). For each spend, the following elements are included in the hash::
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3a.ii.1: cv (field encoding bytes)
|
|
|
|
|
T.3a.ii.2: anchor (field encoding bytes)
|
|
|
|
|
T.3a.ii.3: rk (field encoding bytes)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-04-20 15:08:12 -07:00
|
|
|
|
In Transaction version 5, Sapling Spends have a shared anchor, which is hashed
|
|
|
|
|
into the sapling_spends_noncompact_digest for *each* Spend.
|
|
|
|
|
|
2021-01-13 15:27:19 -08:00
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxIdSSpendNHash"
|
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3b: sapling_outputs_digest
|
2021-01-26 14:29:24 -08:00
|
|
|
|
''''''''''''''''''''''''''''
|
2021-05-06 14:49:50 -07:00
|
|
|
|
In the case that Sapling outputs are present, this digest is a BLAKE2b-256 hash of the
|
|
|
|
|
following values ::
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-03-30 09:45:49 -07:00
|
|
|
|
T.3b.i: sapling_outputs_compact_digest (32-byte hash)
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3b.ii: sapling_outputs_memos_digest (32-byte hash)
|
|
|
|
|
T.3b.iii: sapling_outputs_noncompact_digest (32-byte hash)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxIdSOutputHash"
|
|
|
|
|
|
2021-05-18 07:16:00 -07:00
|
|
|
|
In the case that the transaction has Sapling spends but no Sapling outputs,
|
|
|
|
|
``sapling_outputs_digest`` is ::
|
2021-05-06 14:49:50 -07:00
|
|
|
|
|
|
|
|
|
BLAKE2b-256("ZTxIdSOutputHash", [])
|
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3b.i: sapling_outputs_compact_digest
|
2021-01-26 14:29:24 -08:00
|
|
|
|
......................................
|
2021-02-02 12:06:43 -08:00
|
|
|
|
A BLAKE2b-256 hash of the subset of Sapling output information included in the
|
2021-01-13 15:54:37 -08:00
|
|
|
|
ZIP-307 [#zip-0307]_ ``CompactBlock`` format for all Sapling shielded outputs
|
2021-01-13 15:27:19 -08:00
|
|
|
|
belonging to the transaction. For each output, the following elements are included
|
2021-02-02 12:06:43 -08:00
|
|
|
|
in the hash::
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
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)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
2021-02-02 12:22:02 -08:00
|
|
|
|
"ZTxIdSOutC__Hash" (2 underscore characters)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-03-30 09:45:49 -07:00
|
|
|
|
T.3b.ii: sapling_outputs_memos_digest
|
2021-01-26 14:29:24 -08:00
|
|
|
|
.....................................
|
2021-02-02 12:06:43 -08:00
|
|
|
|
A BLAKE2b-256 hash of the subset of Sapling shielded memo field data for all Sapling
|
|
|
|
|
shielded outputs belonging to the transaction. For each output, the following elements
|
|
|
|
|
are included in the hash::
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3b.ii.1: enc_ciphertext[52..564] (contents of the encrypted memo field)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
2021-02-02 12:22:02 -08:00
|
|
|
|
"ZTxIdSOutM__Hash" (2 underscore characters)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-03-30 09:45:49 -07:00
|
|
|
|
T.3b.iii: sapling_outputs_noncompact_digest
|
2021-01-26 14:29:24 -08:00
|
|
|
|
...........................................
|
2021-01-13 15:27:19 -08:00
|
|
|
|
A BLAKE2b-256 hash of the remaining subset of Sapling output information **not** included
|
2021-01-20 16:28:39 -08:00
|
|
|
|
in the ZIP 307 [#zip-0307]_ ``CompactBlock`` format, excluding zkproof data, for all
|
|
|
|
|
Sapling shielded outputs belonging to the transaction. For each output, the following
|
2021-02-02 12:06:43 -08:00
|
|
|
|
elements are included in the hash::
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3b.iii.1: cv (field encoding bytes)
|
2021-04-20 13:52:46 -07:00
|
|
|
|
T.3b.iii.2: enc_ciphertext[564..] (post-memo Poly1305 AEAD tag of field encoding)
|
2021-03-26 14:14:59 -07:00
|
|
|
|
T.3b.iii.3: out_ciphertext (field encoding bytes)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
2021-01-13 15:57:38 -08:00
|
|
|
|
"ZTxIdSOutN__Hash" (2 underscore characters)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-05-06 14:49:50 -07:00
|
|
|
|
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"
|
|
|
|
|
|
2021-01-20 16:28:39 -08:00
|
|
|
|
Signature Digest
|
|
|
|
|
================
|
|
|
|
|
|
2021-01-26 13:31:47 -08:00
|
|
|
|
A new per-input transaction digest algorithm is defined that constructs a hash that may be
|
2021-05-06 14:49:50 -07:00
|
|
|
|
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]_
|
2021-05-18 07:16:00 -07:00
|
|
|
|
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.
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
|
|
|
|
The overall structure of the hash is as follows; each name referenced here will be
|
2021-01-26 14:06:30 -08:00
|
|
|
|
described in detail below::
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
|
|
|
|
signature_digest
|
|
|
|
|
├── header_digest
|
2021-02-15 08:59:01 -08:00
|
|
|
|
├── transparent_sig_digest
|
2021-05-06 14:49:50 -07:00
|
|
|
|
├── sapling_digest
|
|
|
|
|
└── orchard_digest
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
signature_digest
|
|
|
|
|
----------------
|
2021-01-20 16:28:39 -08:00
|
|
|
|
A BLAKE2b-256 hash of the following values ::
|
|
|
|
|
|
2021-02-15 08:59:01 -08:00
|
|
|
|
S.1: header_digest (32-byte hash output)
|
|
|
|
|
S.2: transparent_sig_digest (32-byte hash output)
|
2021-03-26 14:14:59 -07:00
|
|
|
|
S.3: sapling_digest (32-byte hash output)
|
2021-05-06 14:49:50 -07:00
|
|
|
|
S.4: orchard_digest (32-byte hash output)
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZcashTxHash_" || CONSENSUS_BRANCH_ID
|
|
|
|
|
|
2021-02-04 09:57:28 -08:00
|
|
|
|
``ZcashTxHash_`` has 1 underscore character.
|
2021-02-02 12:22:02 -08:00
|
|
|
|
|
|
|
|
|
This value has the same personalization as the top hash of the transaction
|
|
|
|
|
identifier digest tree, so that what is being signed in the case that there are
|
|
|
|
|
no transparent inputs is just the transaction id.
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
S.1: header_digest
|
|
|
|
|
``````````````````
|
2021-01-20 16:28:39 -08:00
|
|
|
|
Identical to that specified for the transaction identifier.
|
|
|
|
|
|
2021-02-15 08:59:01 -08:00
|
|
|
|
S.2: transparent_sig_digest
|
|
|
|
|
```````````````````````````
|
2021-05-06 14:49:50 -07:00
|
|
|
|
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]_.
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-02-02 12:06:43 -08:00
|
|
|
|
The construction of each component below depends upon the values of the
|
2021-01-21 16:23:09 -08:00
|
|
|
|
``hash_type`` flag bits. Each component will be described separately
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
|
|
|
|
This digest is a BLAKE2b-256 hash of the following values ::
|
|
|
|
|
|
2021-02-15 08:59:01 -08:00
|
|
|
|
S.2a: prevouts_sig_digest (32-byte hash)
|
|
|
|
|
S.2b: sequence_sig_digest (32-byte hash)
|
|
|
|
|
S.2c: outputs_sig_digest (32-byte hash)
|
2021-05-06 14:49:50 -07:00
|
|
|
|
S.2d: txin_sig_digest (32-byte hash)
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxIdTranspaHash"
|
|
|
|
|
|
2021-02-15 08:59:01 -08:00
|
|
|
|
S.2a: prevouts_sig_digest
|
|
|
|
|
'''''''''''''''''''''''''
|
2021-02-02 12:06:43 -08:00
|
|
|
|
This is a BLAKE2b-256 hash initialized with the personalization field value
|
2021-02-04 09:57:28 -08:00
|
|
|
|
``ZTxIdPrevoutHash``.
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-01-21 16:23:09 -08:00
|
|
|
|
If the ``SIGHASH_ANYONECANPAY`` flag is not set::
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
identical to the value of ``prevouts_digest`` as specified for the
|
|
|
|
|
transaction identifier in section T.2a.
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
|
|
|
|
otherwise::
|
|
|
|
|
|
2021-05-06 14:49:50 -07:00
|
|
|
|
BLAKE2b-256(``ZTxIdPrevoutHash``, [])
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-02-15 08:59:01 -08:00
|
|
|
|
S.2b: sequence_sig_digest
|
|
|
|
|
'''''''''''''''''''''''''
|
2021-02-02 12:06:43 -08:00
|
|
|
|
This is a BLAKE2b-256 hash initialized with the personalization field value
|
2021-02-04 09:57:28 -08:00
|
|
|
|
``ZTxIdSequencHash``.
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-02-04 09:57:28 -08:00
|
|
|
|
If the ``SIGHASH_ANYONECANPAY`` flag is not set, and the sighash type is neither
|
|
|
|
|
``SIGHASH_SINGLE`` nor ``SIGHASH_NONE``::
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
identical to the value of ``sequence_digest`` as specified for the
|
|
|
|
|
transaction identifier in section T.2b.
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
|
|
|
|
otherwise::
|
|
|
|
|
|
2021-05-06 14:49:50 -07:00
|
|
|
|
BLAKE2b-256(``ZTxIdSequencHash``, [])
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-02-15 08:59:01 -08:00
|
|
|
|
S.2c: outputs_sig_digest
|
|
|
|
|
''''''''''''''''''''''''
|
2021-02-02 12:06:43 -08:00
|
|
|
|
This is a BLAKE2b-256 hash initialized with the personalization field value
|
2021-05-18 07:05:07 -07:00
|
|
|
|
``ZTxIdOutputsHash``.
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-02-04 09:57:28 -08:00
|
|
|
|
If the sighash type is neither ``SIGHASH_SINGLE`` nor ``SIGHASH_NONE``::
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
identical to the value of ``outputs_digest`` as specified for the
|
|
|
|
|
transaction identifier in section T.2c.
|
2021-01-21 16:23:09 -08:00
|
|
|
|
|
2021-02-04 09:57:28 -08:00
|
|
|
|
If the sighash type is ``SIGHASH_SINGLE`` and the signature hash is being computed for
|
2021-01-21 16:23:09 -08:00
|
|
|
|
the transparent input at a particular index, and a transparent output appears in
|
|
|
|
|
the transaction at that index::
|
|
|
|
|
|
2021-05-06 14:49:50 -07:00
|
|
|
|
the hash is over the transaction serialized form of the transparent output at that
|
|
|
|
|
index
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-05-06 14:49:50 -07:00
|
|
|
|
otherwise::
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-05-06 14:49:50 -07:00
|
|
|
|
BLAKE2b-256(``ZTxIdOutputsHash``, [])
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
S.2d: txin_sig_digest
|
|
|
|
|
'''''''''''''''''''''
|
2021-05-06 14:49:50 -07:00
|
|
|
|
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
|
2021-05-11 07:16:33 -07:00
|
|
|
|
underscores)::
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
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)
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-05-18 06:53:40 -07:00
|
|
|
|
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.
|
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
S.3: sapling_digest
|
2021-01-26 14:29:24 -08:00
|
|
|
|
```````````````````
|
2021-01-20 16:28:39 -08:00
|
|
|
|
Identical to that specified for the transaction identifier.
|
|
|
|
|
|
2021-05-06 14:49:50 -07:00
|
|
|
|
S.4: orchard_digest
|
|
|
|
|
```````````````````
|
|
|
|
|
Identical to that specified for the transaction identifier.
|
|
|
|
|
|
2021-01-21 11:52:53 -08:00
|
|
|
|
Authorizing Data Commitment
|
|
|
|
|
===========================
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
A new transaction digest algorithm is defined that constructs a digest which commits
|
2021-02-02 12:06:43 -08:00
|
|
|
|
to the authorizing data of a transaction from a tree of BLAKE2b-256 hashes.
|
2021-06-14 07:58:17 -07:00
|
|
|
|
For v5 transactions, the overall structure of the hash is as follows::
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-01-13 15:57:38 -08:00
|
|
|
|
auth_digest
|
|
|
|
|
├── transparent_scripts_digest
|
2021-05-06 14:49:50 -07:00
|
|
|
|
├── sapling_auth_digest
|
|
|
|
|
└── orchard_auth_digest
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
Each node written as ``snake_case`` in this tree is a BLAKE2b-256 hash of authorizing
|
|
|
|
|
data of the transaction.
|
|
|
|
|
|
2021-06-14 07:58:17 -07:00
|
|
|
|
For transaction versions before v5, a placeholder value consisting of 32 bytes of
|
|
|
|
|
``0xFF`` is used in place of the authorizing data commitment. This is only used in
|
|
|
|
|
the tree committed to by ``hashAuthDataRoot``, as defined in `Block Header Changes`_.
|
|
|
|
|
|
2021-01-20 16:28:39 -08:00
|
|
|
|
The pair (Transaction Identifier, Auth Commitment) constitutes a commitment to all the
|
2021-02-02 12:06:43 -08:00
|
|
|
|
data of a serialized transaction that may be included in a block.
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
auth_digest
|
|
|
|
|
-----------
|
2021-01-13 15:27:19 -08:00
|
|
|
|
A BLAKE2b-256 hash of the following values ::
|
|
|
|
|
|
2021-05-06 15:06:03 -07:00
|
|
|
|
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)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
2021-01-26 13:31:47 -08:00
|
|
|
|
"ZTxAuthHash_" || CONSENSUS_BRANCH_ID
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
2021-02-04 09:57:28 -08:00
|
|
|
|
``ZTxAuthHash_`` has 1 underscore character.
|
2021-02-02 12:22:02 -08:00
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
A.1: transparent_scripts_digest
|
|
|
|
|
```````````````````````````````
|
2021-05-06 15:06:03 -07:00
|
|
|
|
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
|
2021-01-13 15:27:19 -08:00
|
|
|
|
with each transparent input belonging to the transaction.
|
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxAuthTransHash"
|
|
|
|
|
|
2021-05-06 15:06:03 -07:00
|
|
|
|
In the case that the transaction has no transparent inputs, ``transparent_scripts_digest`` is ::
|
|
|
|
|
|
|
|
|
|
BLAKE2b-256("ZTxAuthTransHash", [])
|
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
A.2: sapling_auth_digest
|
2021-01-26 14:29:24 -08:00
|
|
|
|
````````````````````````
|
2021-05-06 15:06:03 -07:00
|
|
|
|
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,
|
2021-02-09 07:06:00 -08:00
|
|
|
|
followed by the field encoding of the binding signature::
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-03-26 14:14:59 -07:00
|
|
|
|
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)
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
The personalization field of this hash is set to::
|
|
|
|
|
|
|
|
|
|
"ZTxAuthSapliHash"
|
|
|
|
|
|
2021-05-06 15:06:03 -07:00
|
|
|
|
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", [])
|
|
|
|
|
|
2021-01-13 15:27:19 -08:00
|
|
|
|
--------------------
|
|
|
|
|
Block Header Changes
|
|
|
|
|
--------------------
|
|
|
|
|
|
2021-01-21 11:52:53 -08:00
|
|
|
|
The nonmalleable transaction identifier specified by this ZIP will be used
|
|
|
|
|
in the place of the current malleable transaction identifier within the
|
2021-02-15 08:52:53 -08:00
|
|
|
|
Merkle tree committed to by the ``hashMerkleRoot`` value. However, this
|
2021-01-21 11:52:53 -08:00
|
|
|
|
change now means that ``hashMerkleRoot`` is not sufficient to fully commit
|
|
|
|
|
to the transaction data, including witnesses, that appear within the block.
|
|
|
|
|
|
|
|
|
|
As a consequence, we now need to add a new commitment to the block header.
|
2021-06-14 07:58:17 -07:00
|
|
|
|
This commitment will be the root of a Merkle tree having leaves that are
|
|
|
|
|
transaction authorizing data commitments, produced according to the
|
|
|
|
|
`Authorizing Data Commitment`_ part of this specification. The insertion
|
|
|
|
|
order for this Merkle tree MUST be identical to the insertion order of
|
|
|
|
|
transaction identifiers into the Merkle tree that is used to construct
|
|
|
|
|
``hashMerkleRoot``, such that a path through this Merkle tree to a
|
|
|
|
|
transaction identifies the same transaction as that path reaches in the tree
|
|
|
|
|
rooted at ``hashMerkleRoot``.
|
|
|
|
|
|
|
|
|
|
This new commitment is named ``hashAuthDataRoot`` and is the root of a
|
|
|
|
|
binary Merkle tree of transaction authorizing data commitments having height
|
2021-06-15 07:21:45 -07:00
|
|
|
|
:math:`\mathsf{ceil(log_2(tx\_count))}`, padded with leaves having the "null"
|
|
|
|
|
hash value ``[0u8; 32]``. Note that :math:`\mathsf{log_2(tx\_count)}` is
|
|
|
|
|
well-defined because :math:`\mathsf{tx\_count} > 0`, due to the coinbase
|
|
|
|
|
transaction in each block. Non-leaf hashes in this tree are BLAKE2b-256
|
|
|
|
|
hashes personalized by the string ``"ZcashAuthDatHash"``.
|
2021-01-21 11:52:53 -08:00
|
|
|
|
|
2021-02-02 12:06:43 -08:00
|
|
|
|
Changing the block header format to allow space for an additional
|
|
|
|
|
commitment is somewhat invasive. Instead, the name and meaning of the
|
2021-01-26 14:29:24 -08:00
|
|
|
|
``hashLightClientRoot`` field, described in ZIP 221 [#zip-0221]_, is changed.
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-01-21 11:52:53 -08:00
|
|
|
|
``hashLightClientRoot`` is renamed to ``hashBlockCommitments``. The value
|
|
|
|
|
of this hash is the BLAKE2b-256 hash personalized by the string ``"ZcashBlockCommit"``
|
2021-01-26 14:06:30 -08:00
|
|
|
|
of the following elements::
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-01-26 14:29:24 -08:00
|
|
|
|
hashLightClientRoot (as described in ZIP 221)
|
|
|
|
|
hashAuthDataRoot (as described below)
|
|
|
|
|
terminator [0u8;32]
|
2021-01-21 16:23:09 -08:00
|
|
|
|
|
|
|
|
|
This representation treats the ``hashBlockCommitments`` value as a linked
|
|
|
|
|
list of hashes terminated by arbitrary data. In the case of protocol upgrades
|
|
|
|
|
where additional commitments need to be included in the block header, it is
|
|
|
|
|
possible to replace this terminator with the hash of a newly defined structure
|
|
|
|
|
which ends in a similar terminator. Fully validating nodes MUST always use the
|
2021-02-02 12:06:43 -08:00
|
|
|
|
entire structure defined by the latest activated protocol version that they
|
|
|
|
|
support.
|
2021-01-21 16:23:09 -08:00
|
|
|
|
|
2021-02-02 12:06:43 -08:00
|
|
|
|
The linked structure of this hash is intended to provide extensibility for
|
2021-01-21 16:23:09 -08:00
|
|
|
|
use by light clients which may be connected to a third-party server that supports
|
|
|
|
|
a later protocol version. Such a third party SHOULD provide a value that can
|
2021-02-02 12:06:43 -08:00
|
|
|
|
be used instead of the all-zeros terminator to permit the light client to
|
|
|
|
|
perform validation of the parts of the structure it needs.
|
2021-01-20 16:28:39 -08:00
|
|
|
|
|
2021-03-28 21:14:12 -07:00
|
|
|
|
Unlike the ``hashLightClientRoot`` change, the change to ``hashBlockCommitments``
|
|
|
|
|
happens in the block that activates this ZIP.
|
|
|
|
|
|
|
|
|
|
The block header byte format and version are not altered by this ZIP.
|
2021-01-13 15:27:19 -08:00
|
|
|
|
|
|
|
|
|
========================
|
|
|
|
|
Reference implementation
|
|
|
|
|
========================
|
|
|
|
|
|
|
|
|
|
- https://github.com/zcash/librustzcash/pull/319/files
|
|
|
|
|
|
|
|
|
|
==========
|
|
|
|
|
References
|
|
|
|
|
==========
|
2021-01-13 15:54:37 -08:00
|
|
|
|
|
|
|
|
|
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
2021-08-15 15:47:48 -07:00
|
|
|
|
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
2021-01-21 16:23:09 -08:00
|
|
|
|
.. [#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>`_
|
2021-05-06 14:49:50 -07:00
|
|
|
|
.. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling <zip-0243.rst>`_
|
2021-01-21 16:23:09 -08:00
|
|
|
|
.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection <zip-0307.rst>`_
|
2021-04-23 13:57:22 -07:00
|
|
|
|
.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus <protocol/nu5.pdf#txnencodingandconsensus>`_
|