diff --git a/zip-0244.html b/zip-0244.html index 7db6fb17..faa60ce4 100644 --- a/zip-0244.html +++ b/zip-0244.html @@ -3,6 +3,7 @@ ZIP 244: Transaction Identifier Non-Malleability +
@@ -307,12 +308,13 @@ S.2d.iv: nSequence (4-byte unsigned little-endian)

Authorizing Data Commitment

-

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:

+

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. For v5 transactions, the overall structure of the hash is as follows:

auth_digest
 ├── transparent_scripts_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.

+

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.

The pair (Transaction Identifier, Auth Commitment) constitutes a commitment to all the data of a serialized transaction that may be included in a block.

auth_digest

A BLAKE2b-256 hash of the following values

@@ -355,8 +357,14 @@ A.3c: bindingSigOrchard (field encoding bytes)

Block Header Changes

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 hashMerkleRoot value. However, this 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. This commitment will be the root of a Merkle tree that has parallel structure to the tree committed to by hashMerkleRoot (a path through this Merkle tree to a transaction identifies the same transaction as that path reaches in the tree rooted at hashMerkleRoot), but where the leaves are hashes produced according to the Authorizing Data Commitment part of this specification.

-

This new commitment is named hashAuthDataRoot 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 [0u8; 32]. Hashes in this tree are BLAKE2b-256 hashes personalized by the string "ZcashAuthDatHash".

+

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 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 + \(\mathsf{ceil(log_2(tx\_count))}\) + , padded with leaves having the "null" hash value [0u8; 32]. Note that + \(\mathsf{log_2(tx\_count)}\) + is well-defined because + \(\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".

Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the hashLightClientRoot field, described in ZIP 221 3, is changed.

hashLightClientRoot is renamed to hashBlockCommitments. The value of this hash is the BLAKE2b-256 hash personalized by the string "ZcashBlockCommit" of the following elements:

hashLightClientRoot (as described in ZIP 221)
diff --git a/zip-0244.rst b/zip-0244.rst
index 8b2ee8a9..29feae16 100644
--- a/zip-0244.rst
+++ b/zip-0244.rst
@@ -590,7 +590,7 @@ Authorizing Data Commitment
 
 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::
+For v5 transactions, the overall structure of the hash is as follows::
 
     auth_digest
     ├── transparent_scripts_digest
@@ -600,6 +600,10 @@ The overall structure of the hash is as follows::
 Each node written as ``snake_case`` in this tree is a BLAKE2b-256 hash of authorizing
 data of the transaction.
 
+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`_.
+
 The pair (Transaction Identifier, Auth Commitment) constitutes a commitment to all the
 data of a serialized transaction that may be included in a block.
 
@@ -683,18 +687,22 @@ 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.
-This commitment will be the root of a Merkle tree that has parallel structure
-to the tree committed to by ``hashMerkleRoot`` (a path through this Merkle
-tree to a transaction identifies the same transaction as that path reaches
-in the tree rooted at ``hashMerkleRoot``), but where the leaves are hashes
-produced according to the `Authorizing Data Commitment` part of this
-specification.
+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 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
-``[0u8; 32]``. Hashes in this tree are BLAKE2b-256 hashes personalized by the string
-``"ZcashAuthDatHash"``.
+This new commitment is named ``hashAuthDataRoot`` and is the root of a
+binary Merkle tree of transaction authorizing data commitments having height
+: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"``.
 
 Changing the block header format to allow space for an additional
 commitment is somewhat invasive. Instead, the name and meaning of the