Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 20 additions & 9 deletions zips/zip-0227.rst
Original file line number Diff line number Diff line change
Expand Up @@ -100,17 +100,23 @@ The relations between these keys are shown in the following diagram:
Issuance Authorization Signature Scheme
---------------------------------------

We instantiate the issuance authorization signature scheme $\mathsf{IssueAuthSig}$ as a BIP-340 Schnorr signature over the secp256k1 curve. The signing and validation algorithms, signature encoding, and public key encoding MUST follow BIP 340 [#bip-0340]_.
The issuance authorization signature $\mathsf{issueAuthSig}$ is used to authorize the issuance of Custom Assets by the issuer.
The issuance authorization signature scheme, $\mathsf{IssueAuthSig}$, comprises of all the associated types and algorithms defined in the protocol specification [#protocol-abstractsig]_.

Batch verification MAY be used. Precomputation MAY be used if and only if it produces equivalent results; for example, for a given verification key $pk$ and $\mathit{lift\_x}(\mathit{int}(pk))$ MAY be precomputed.
Batch verification MAY be used. Precomputation MAY be used if and only if it produces equivalent results.

Orchard ZSA Issuance Authorization Signature Scheme
```````````````````````````````````````````````````

In the OrchardZSA protocol, we instantiate the issuance authorization signature scheme $\mathsf{IssueAuthSig}$ as a BIP-340 Schnorr signature over the secp256k1 curve.
We define the constants as per the secp256k1 standard parameters, as described in BIP 340.
The encodings of the signature and the public key differ slightly from that of BIP 340, and we specify the changes in what follows.

The associated types of the $\mathsf{IssueAuthSig}$ signature scheme are as follows:

* $\mathsf{IssueAuthSig.Message} = \mathbb{B}^{\mathbb{Y}^{[\mathbb{N}]}}$
* $\mathsf{IssueAuthSig.Signature} = \mathbb{B}^{\mathbb{Y}^{[64]}} \cup \{\bot\}$
* $\mathsf{IssueAuthSig.Public} = \mathbb{B}^{\mathbb{Y}^{[32]}} \cup \{\bot\}$
* $\mathsf{IssueAuthSig.Signature} = \mathbb{B}^{\mathbb{Y}^{[65]}} \cup \{\bot\}$
* $\mathsf{IssueAuthSig.Public} = \mathbb{B}^{\mathbb{Y}^{[33]}} \cup \{\bot\}$
* $\mathsf{IssueAuthSig.Private} = \mathbb{B}^{\mathbb{Y}^{[32]}}$

where $\mathbb{B}^{\mathbb{Y}^{[k]}}$ denotes the set of sequences of $k$ bytes, and $\mathbb{B}^{\mathbb{Y}^{[\mathbb{N}]}}$ denotes the type of byte sequences of arbitrary length, as defined in the Zcash protocol specification [#protocol-notation]_.
Expand Down Expand Up @@ -151,11 +157,11 @@ Derivation of issuance validating key

Define $\mathsf{IssueAuthSig.DerivePublic} \;{\small ⦂}\; (\mathsf{isk} \;{\small ⦂}\; \mathsf{IssueAuthSig.Private}) \to \mathsf{IssueAuthSig.Public}$ as:

* $\mathsf{ik} := \textit{PubKey}(\mathsf{isk})$
* $\mathsf{ik} := \mathtt{0x00} || \textit{PubKey}(\mathsf{isk})$
* Return $\bot$ if the $\textit{PubKey}$ algorithm invocation fails, otherwise return $\mathsf{ik}$.

where the $\textit{PubKey}$ algorithm is defined in BIP 340 [#bip-0340]_.
Note that the byte representation of $\mathsf{ik}$ is in big-endian order as defined in BIP 340.
where the $\textit{PubKey}$ algorithm is defined in BIP 340 [#bip-0340]_, and the output of the algorithm is in big-endian order as defined in BIP 340.
The encoding of $\mathsf{ik}$ begins with a version byte that is $\mathtt{0x00}$. This enables future ZIPs to specify alternative signature schemes.
Copy link
Collaborator

@daira daira Jun 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"The encoding of $\mathsf{ik}$ begins with a byte indicating the signature scheme, which MUST be $\mathtt{0x00}$ indicating BIP 340. This enables future ZIPs to specify alternative signature schemes."


It is possible for the $\textit{PubKey}$ algorithm to fail with very low probability, which means that $\mathsf{IssueAuthSig.DerivePublic}$ could return $\bot$ with very low probability.
If this happens, discard the keys and repeat with a different $\mathsf{isk}$.
Expand All @@ -168,17 +174,20 @@ Issuance Authorization Signing and Validation
Define $\mathsf{IssueAuthSig.Sign} \;{\small ⦂}\; (\mathsf{isk} \;{\small ⦂}\; \mathsf{IssueAuthSig.Private}) \times (M \;{\small ⦂}\; \mathsf{IssueAuthSig.Message}) \to \mathsf{IssueAuthSig.Signature}$ as:

* Let the auxiliary data $a = [\mathtt{0x00}]^{32}$.
* Let $\text{σ} = \mathsf{Sign}(\mathsf{isk}, M)$.
* Let $\text{σ} = \mathtt{0x00} || \mathsf{Sign}(\mathsf{isk}, M)$.
* Return $\bot$ if the $\mathsf{Sign}$ algorithm fails in the previous step, otherwise return $\text{σ}$.

where the $\mathsf{Sign}$ algorithm is defined in BIP 340 and $a$ denotes the auxiliary data used in BIP 340 [#bip-0340]_.
Note that $\mathsf{IssueAuthSig.Sign}$ could return $\bot$ with very low probability.
Note that the initial $\mathtt{0x00}$ byte in the signature is a version byte, enabling future ZIPs to
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"The encoding of the signature begins with a byte indicating the signature scheme, which MUST be $\mathtt{0x00}$ indicating BIP 340. This enables future ZIPs to specify alternative signature schemes."

specify alternative issuance authorization signature schemes.


Define $\mathsf{IssueAuthSig.Validate} \;{\small ⦂}\; (\mathsf{ik} \;{\small ⦂}\; \mathsf{IssueAuthSig.Public}) \times (M \;{\small ⦂}\; \mathsf{IssueAuthSig.Message}) \times (\text{σ} \;{\small ⦂}\; \mathsf{IssueAuthSig.Signature}) \to \mathbb{B}$ as:

* Return $0$ if $\text{σ} = \bot$.
* Return $1$ if $\mathsf{Verify}(\mathsf{ik}, M, \text{σ})$ succeeds, otherwise $0$.
* Parse $\text{σ}$ as $\mathtt{0x00} || \mathsf{sig}$ and parse $\mathsf{ik}$ as $\mathtt{0x00} || \mathsf{key}$. Return $0$ if the parsing fails.
* Return $1$ if $\mathsf{Verify}(\mathsf{key}, M, \mathsf{sig})$ succeeds, otherwise $0$.

where the $\mathsf{Verify}$ algorithm is defined in BIP 340 [#bip-0340]_.

Expand All @@ -198,6 +207,7 @@ For context, the relations between the Asset Identifier, Asset Digest, and Asset

**Note:** To keep notations light and concise, we may omit $\mathsf{AssetId}$ in the subscript when the Asset Identifier is clear from the context.


Asset Identifiers
-----------------

Expand Down Expand Up @@ -657,6 +667,7 @@ References
.. [#protocol-notation] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 2: Notation <protocol/protocol.pdf#notation>`_
.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.1: Payment Addresses and Keys <protocol/protocol.pdf#addressesandkeys>`_
.. [#protocol-notes] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.2: Notes <protocol/protocol.pdf#notes>`_
.. [#protocol-abstractsig] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.1.7: Signature <protocol/protocol.pdf#abstractsig>`_
.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.2.3: Orchard Key Components <protocol/protocol.pdf#orchardkeycomponents>`_
.. [#protocol-sighash] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.10: SIGHASH Transaction Hashing <protocol/protocol.pdf#sighash>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
Expand Down
10 changes: 7 additions & 3 deletions zips/zip-0230.rst
Original file line number Diff line number Diff line change
Expand Up @@ -158,10 +158,14 @@ Transaction Format
+-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
| varies |``vIssueActions`` |``IssueAction[nIssueActions]`` |A sequence of issuance action descriptions. |
+-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
| 32 |``ik`` |``byte[32]`` |The issuance validating key of the issuer, used to validate the |
| varies |``ikLength`` |``compactSize`` |The length of the issuance validating key of the issuer. |
+-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
| varies |``ik`` |``byte[ikLength]`` |The issuance validating key of the issuer, used to validate the |
| | | |signature. |
+-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
| 64 |``issueAuthSig`` |``byte[64]`` |The signature of the transaction SIGHASH, signed by the issuer, |
| varies |``issueAuthSigLength`` |``compactSize`` |The length of the issuance authorization signature. |
+-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
| varies |``issueAuthSig`` |``byte[issueAuthSigLength]`` |The signature of the transaction SIGHASH, signed by the issuer, |
| | | |validated as in Issuance Authorization Signature Scheme [#zip-0227]_.|
+-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
| **Memo Bundle Fields** |
Expand Down Expand Up @@ -199,7 +203,7 @@ Transaction Format
only if $\mathtt{nActionGroupsOrchard} > 0$. If ``valueBalanceOrchard`` is not present,
then $\mathsf{v^{balanceOrchard}}$ is defined to be $0$.

* The fields ``ik`` and ``issueAuthSig`` are present if and only if $\mathtt{nIssueActions} > 0$.
* The fields ``ikLength``, ``ik``, ``issueAuthSigLength``, and ``issueAuthSig`` are present if and only if $\mathtt{nIssueActions} > 0$.

* For coinbase transactions, the ``enableSpendsOrchard`` and ``enableZSAs`` bits MUST be set to $0$.

Expand Down