From d0c02c94a5ffea052fa8745b0333a5210f7cab89 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sun, 29 Jun 2025 15:42:07 +0530 Subject: [PATCH 1/4] making the renaming changes in ZIP 227 and ZIP 230 --- zips/zip-0227.rst | 32 +++++++++++++++++--------------- zips/zip-0230.rst | 6 +++--- 2 files changed, 20 insertions(+), 18 deletions(-) diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst index cfb251599..3b67dfaa0 100644 --- a/zips/zip-0227.rst +++ b/zips/zip-0227.rst @@ -85,7 +85,9 @@ The OrchardZSA Protocol adds the following keys to the key components [#protocol 1. The issuance authorizing key, denoted as $\mathsf{isk}$, is the key used to authorize the issuance of Asset Identifiers by a given issuer, and is only used by that issuer. -2. The issuance validating key, denoted as $\mathsf{ik}$, is the key that is used to validate issuance transactions. This key is used to validate the issuance of Asset Identifiers by a given issuer, and is used by all blockchain users (specifically the owners of notes for that Asset, and consensus validators) to associate the Asset in question with the issuer. +2. The issuance validating key, is the key that is used to validate issuance transactions and also as an identifier of a particular Issuer. + It is denoted as $\mathsf{issuer}$. + This key is used to validate the issuance of Asset Identifiers by a given issuer, and is used by all blockchain users (specifically the owners of notes for that Asset, and consensus validators) to associate the Asset in question with the issuer. The relations between these keys are shown in the following diagram: @@ -157,11 +159,11 @@ Derivation of issuance validating key Define $\mathsf{IssueAuthSig.DerivePublic} \;{\small ⦂}\; (\mathsf{isk} \;{\small ⦂}\; \mathsf{IssueAuthSig.Private}) \to \mathsf{IssueAuthSig.Public}$ as: -* $\mathsf{ik} := \mathtt{0x00} || \textit{PubKey}(\mathsf{isk})$ -* Return $\bot$ if the $\textit{PubKey}$ algorithm invocation fails, otherwise return $\mathsf{ik}$. +* $\mathsf{issuer} := \mathtt{0x00} || \textit{PubKey}(\mathsf{isk})$ +* Return $\bot$ if the $\textit{PubKey}$ algorithm invocation fails, otherwise return $\mathsf{issuer}$. 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 byte indicating the signature scheme, which MUST be $\mathtt{0x00}$ indicating BIP 340. +The encoding of $\mathsf{issuer}$ 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. @@ -183,10 +185,10 @@ Note that $\mathsf{IssueAuthSig.Sign}$ could return $\bot$ with very low probabi 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. -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: +Define $\mathsf{IssueAuthSig.Validate} \;{\small ⦂}\; (\mathsf{issuer} \;{\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$. -* Parse $\text{σ}$ as $\mathtt{0x00} || \mathsf{sig}$ and parse $\mathsf{ik}$ as $\mathtt{0x00} || \mathsf{key}$. Return $0$ if the parsing fails. +* Parse $\text{σ}$ as $\mathtt{0x00} || \mathsf{sig}$ and parse $\mathsf{issuer}$ 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]_. @@ -218,7 +220,7 @@ OrchardZSA protocol and potentially future Zcash shielded protocols. ZIP 227 Asset Identifiers ````````````````````````` -Assets issued using the protocol specified in this ZIP are scoped to the $\mathsf{ik}$ +Assets issued using the protocol specified in this ZIP are scoped to the $\mathsf{issuer}$ that issued them. Within that scope, Asset Identifier uniqueness is obtained by way of an asset description, $\mathsf{asset\_desc}$, which includes any information pertaining to the issuance. $\mathsf{asset\_desc}$ is a non-empty byte sequence which SHOULD be a @@ -230,11 +232,11 @@ Define We define Asset Identifiers for Assets issued under this ZIP as -.. math:: \mathsf{AssetId} := (\mathsf{ik}, \mathsf{assetDescHash}) +.. math:: \mathsf{AssetId} := (\mathsf{issuer}, \mathsf{assetDescHash}) and define their canonical encoding as -.. math:: \mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}((\mathsf{ik}, \mathsf{assetDescHash})) := \mathtt{0x00} || \mathsf{ik} || \mathsf{assetDescHash} +.. math:: \mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}((\mathsf{issuer}, \mathsf{assetDescHash})) := \mathtt{0x00} || \mathsf{issuer} || \mathsf{assetDescHash} Note that the initial $\mathtt{0x00}$ byte is a version byte, enabling future ZIPs to specify alternative issuance protocols and Asset Identifiers. @@ -299,7 +301,7 @@ An Issue Note is a tuple $(\mathsf{d}, \mathsf{pk_d}, \mathsf{v}, \mathsf{AssetB - $\mathsf{rseed}: \mathbb{B}^{[\mathbb{Y}^{32}]}$ MUST be sampled uniformly at random by the issuer. ZIP 230 [#zip-0230-issue-note]_ defines, in ``IssueNote``, field encodings which together with -$\mathsf{ik}$ from the parent `Issuance Bundle`_ and $\mathsf{AssetDescHash}$ from the parent +$\mathsf{issuer}$ from the parent `Issuance Bundle`_ and $\mathsf{AssetDescHash}$ from the parent `Issuance Action`_, specify an Issue Note. Let $\mathsf{Note^{Issue}}$ be the type of an Issue Note, i.e. @@ -333,7 +335,7 @@ An issuance bundle is the aggregate of all the issuance-related information. Specifically, contains all the issuance actions and the issuer signature on the transaction SIGHASH that validates the issuance itself. It contains the following fields: -- $\mathsf{ik}$: the issuance validating key, that allows the validators to verify that the $\mathsf{AssetId}$ is properly associated with the issuer. +- $\mathsf{issuer}$: the issuance validating key, that allows the validators to verify that the $\mathsf{AssetId}$ is properly associated with the issuer. - ``vIssueActions``: an array of issuance actions, of type ``IssueAction``. - $\mathsf{issueAuthSig}$: the signature of the transaction SIGHASH, signed by the issuance authorizing key, $\mathsf{isk}$, that validates the issuance. @@ -366,7 +368,7 @@ For all actions ``IssueAction``: - encode $\mathsf{asset\_desc}$ as a UTF-8 byte string. - compute $\mathsf{assetDescHash}$ -- compute $\mathsf{AssetDigest}$ from the issuance validating key $\mathsf{ik}$ and $\mathsf{assetDescHash}$ as decribed in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section. +- compute $\mathsf{AssetDigest}$ from the issuance validating key $\mathsf{issuer}$ and $\mathsf{assetDescHash}$ as decribed in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section. - compute $\mathsf{AssetBase}$ from $\mathsf{AssetDigest}$ as decribed in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section. - set the $\mathsf{finalize}$ boolean as desired (if more issuance actions are to be created for this $\mathsf{AssetBase}$, set $\mathsf{finalize} = 0$, otherwise set $\mathsf{finalize} = 1$). - for each recipient $i$: @@ -379,7 +381,7 @@ For all actions ``IssueAction``: For the ``IssueBundle``: - encode the ``vIssueActions`` vector. -- encode the $\mathsf{ik}$ as 32 byte-string. +- encode the $\mathsf{issuer}$ as 32 byte-string. - sign the SIGHASH transaction hash with the issuance authorizing key, $\mathsf{isk}$, using the $\mathsf{IssueAuthSig}$ signature scheme. The signature is then added to the issuance bundle. @@ -447,7 +449,7 @@ For every transaction: - It MUST be the case that for all $(\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}$, $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{balance} \geq \mathsf{v}$. The node then MUST update $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase})$ prior to processing the issuance bundle in the following manner. For every $(\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{AssetBurn}$, $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{balance} = \mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{balance} - \mathsf{v}$. - Let $\mathsf{SigHash}$ be the SIGHASH transaction hash of this transaction, as defined in §4.10 of the protocol specification [#protocol-sighash]_ with the modifications described in ZIP 226 [#zip-0226-txiddigest]_, using $\mathsf{SIGHASH\_ALL}$. - If the transaction contains an Issuance Bundle, it MUST also contain at least one OrchardZSA Action Group. -- The issuance authorization signature, $\mathsf{issueAuthSig}$, MUST be a valid $\mathsf{IssueAuthSig}$ signature over $\mathsf{SigHash}$, i.e. $\mathsf{IssueAuthSig}.\!\mathsf{Validate}(\mathsf{ik}, \mathsf{SigHash}, \mathsf{issueAuthSig}) = 1$. +- The issuance authorization signature, $\mathsf{issueAuthSig}$, MUST be a valid $\mathsf{IssueAuthSig}$ signature over $\mathsf{SigHash}$, i.e. $\mathsf{IssueAuthSig}.\!\mathsf{Validate}(\mathsf{issuer}, \mathsf{SigHash}, \mathsf{issueAuthSig}) = 1$. - For every issuance action description ($\mathsf{IssueAction}_\mathsf{i},\ 1 \leq i \leq \mathtt{nIssueActions}$) in the issuance bundle: - Every Issue Note in ``IssueAction`` MUST be a valid encoding of the $\mathsf{Note^{Issue}}$ type, and MUST encode the same $\mathsf{AssetBase}$. @@ -507,7 +509,7 @@ asset description, for the following reasons: rules had required it to be a Unicode string instead of only recommending it). - The lack of key rotation in this issuance protocol means that it is not sufficient to - mark an $\mathsf{ik}$ as trusted and then accept whatever asset descriptions are issued + mark an $\mathsf{issuer}$ as trusted and then accept whatever asset descriptions are issued by it. Each Asset Identifier needs to be independently verified, which requires some out-of-band protocol that can also convey the corresponding asset description. diff --git a/zips/zip-0230.rst b/zips/zip-0230.rst index a0917276c..d39085e90 100644 --- a/zips/zip-0230.rst +++ b/zips/zip-0230.rst @@ -158,9 +158,9 @@ Transaction Format +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ | varies |``vIssueActions`` |``IssueAction[nIssueActions]`` |A sequence of issuance action descriptions. | +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ -| varies |``ikLength`` |``compactSize`` |The length of the issuance validating key of the issuer. | +| varies |``issuerLength`` |``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 | +| varies |``issuer`` |``byte[issuerLength]`` |The issuance validating key of the issuer, used to validate the | | | | |signature. | +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ | varies |``issueAuthSigLength`` |``compactSize`` |The length of the issuance authorization signature. | @@ -203,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 ``ikLength``, ``ik``, ``issueAuthSigLength``, and ``issueAuthSig`` are present if and only if $\mathtt{nIssueActions} > 0$. +* The fields ``issuerLength``, ``issuer``, ``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$. From c23cbf79aca72e3a2071b06566df48a282671735 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sun, 29 Jun 2025 15:42:27 +0530 Subject: [PATCH 2/4] updating the images --- ...-asset-identifier-relation-orchard-zsa.svg | 14 ++++++------- zips/zip-0227-key-components-zsa.svg | 20 +++++++++---------- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/zips/zip-0227-asset-identifier-relation-orchard-zsa.svg b/zips/zip-0227-asset-identifier-relation-orchard-zsa.svg index 4f6b07b8e..897586a4d 100644 --- a/zips/zip-0227-asset-identifier-relation-orchard-zsa.svg +++ b/zips/zip-0227-asset-identifier-relation-orchard-zsa.svg @@ -25,11 +25,11 @@ borderopacity="1.0" inkscape:pageopacity="0.0" inkscape:pageshadow="2" - inkscape:zoom="0.5" - inkscape:cx="631" - inkscape:cy="218" + inkscape:zoom="0.60419345" + inkscape:cx="734.86398" + inkscape:cy="79.444754" inkscape:document-units="px" - inkscape:current-layer="layer1" + inkscape:current-layer="g481-4" showgrid="false" inkscape:window-width="1068" inkscape:window-height="916" @@ -360,14 +360,14 @@ style="fill:#ffeeaa;fill-opacity:1;stroke:#000000;stroke-width:1.1017;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />ikissueriskikissuer Date: Sun, 29 Jun 2025 15:56:50 +0530 Subject: [PATCH 3/4] renaming issuance validating key to issuer identifier --- zips/zip-0227.rst | 25 ++++++++++++------------- zips/zip-0230.rst | 4 ++-- 2 files changed, 14 insertions(+), 15 deletions(-) diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst index 3b67dfaa0..b7dc6d5c0 100644 --- a/zips/zip-0227.rst +++ b/zips/zip-0227.rst @@ -85,9 +85,8 @@ The OrchardZSA Protocol adds the following keys to the key components [#protocol 1. The issuance authorizing key, denoted as $\mathsf{isk}$, is the key used to authorize the issuance of Asset Identifiers by a given issuer, and is only used by that issuer. -2. The issuance validating key, is the key that is used to validate issuance transactions and also as an identifier of a particular Issuer. - It is denoted as $\mathsf{issuer}$. - This key is used to validate the issuance of Asset Identifiers by a given issuer, and is used by all blockchain users (specifically the owners of notes for that Asset, and consensus validators) to associate the Asset in question with the issuer. +2. The issuer identifier, denoted by $\mathsf{issuer}$ is the identifier of a particular Issuer. + This identifier is used to validate the issuance of Asset Identifiers by a given issuer, and is used by all blockchain users (specifically the owners of notes for that Asset, and consensus validators) to associate the Asset in question with the issuer. The relations between these keys are shown in the following diagram: @@ -123,7 +122,7 @@ The associated types of the $\mathsf{IssueAuthSig}$ signature scheme are as foll 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]_. -The issuance authorizing key generation algorithm and the issuance validating key derivation algorithm are defined in the `Issuance Key Derivation`_ section, while the corresponding signing and validation algorithms are defined in the `Issuance Authorization Signing and Validation`_ section. +The issuance authorizing key generation algorithm and the issuer identifier derivation algorithm are defined in the `Issuance Key Derivation`_ section, while the corresponding signing and validation algorithms are defined in the `Issuance Authorization Signing and Validation`_ section. Issuance Key Derivation ----------------------- @@ -154,8 +153,8 @@ We use the notation of ZIP 32 [#zip-0032-orchard-key-path]_ for shielded HD path From the generated $(\mathsf{sk}, \mathsf{c})$, we set the issuance authorizing key to be $\mathsf{isk} := \mathsf{sk}$. -Derivation of issuance validating key -````````````````````````````````````` +Derivation of issuer identifier +``````````````````````````````` Define $\mathsf{IssueAuthSig.DerivePublic} \;{\small ⦂}\; (\mathsf{isk} \;{\small ⦂}\; \mathsf{IssueAuthSig.Private}) \to \mathsf{IssueAuthSig.Public}$ as: @@ -280,7 +279,7 @@ where $\mathsf{GroupHash}^\mathbb{P}$ is defined as in [#protocol-concretegrouph :align: center :figclass: align-center - Diagram relating the Issuance validating key, asset description, asset description hash, Asset Identifier, Asset Digest, and Asset Base for the OrchardZSA Protocol. + Diagram relating the Issuer identifier, asset description, asset description hash, Asset Identifier, Asset Digest, and Asset Base for the OrchardZSA Protocol. Specification: Issue Note, Issuance Action, Issuance Bundle and Issuance Protocol @@ -335,7 +334,7 @@ An issuance bundle is the aggregate of all the issuance-related information. Specifically, contains all the issuance actions and the issuer signature on the transaction SIGHASH that validates the issuance itself. It contains the following fields: -- $\mathsf{issuer}$: the issuance validating key, that allows the validators to verify that the $\mathsf{AssetId}$ is properly associated with the issuer. +- $\mathsf{issuer}$: the issuer identifier, that allows the validators to verify that the $\mathsf{AssetId}$ is properly associated with the issuer. - ``vIssueActions``: an array of issuance actions, of type ``IssueAction``. - $\mathsf{issueAuthSig}$: the signature of the transaction SIGHASH, signed by the issuance authorizing key, $\mathsf{isk}$, that validates the issuance. @@ -368,7 +367,7 @@ For all actions ``IssueAction``: - encode $\mathsf{asset\_desc}$ as a UTF-8 byte string. - compute $\mathsf{assetDescHash}$ -- compute $\mathsf{AssetDigest}$ from the issuance validating key $\mathsf{issuer}$ and $\mathsf{assetDescHash}$ as decribed in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section. +- compute $\mathsf{AssetDigest}$ from the issuer identifier $\mathsf{issuer}$ and $\mathsf{assetDescHash}$ as decribed in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section. - compute $\mathsf{AssetBase}$ from $\mathsf{AssetDigest}$ as decribed in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section. - set the $\mathsf{finalize}$ boolean as desired (if more issuance actions are to be created for this $\mathsf{AssetBase}$, set $\mathsf{finalize} = 0$, otherwise set $\mathsf{finalize} = 1$). - for each recipient $i$: @@ -453,7 +452,7 @@ For every transaction: - For every issuance action description ($\mathsf{IssueAction}_\mathsf{i},\ 1 \leq i \leq \mathtt{nIssueActions}$) in the issuance bundle: - Every Issue Note in ``IssueAction`` MUST be a valid encoding of the $\mathsf{Note^{Issue}}$ type, and MUST encode the same $\mathsf{AssetBase}$. - - This $\mathsf{AssetBase}$ MUST satisfy the derivation from the issuance validating key and asset description described in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section. + - This $\mathsf{AssetBase}$ MUST satisfy the derivation from the issuer identifier and asset description described in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section. - It MUST be the case that $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{final} \neq 1$. - If $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{note_{ref}} = \bot$, then let $\mathsf{note}_1$ be the first Issue Note in the Issuance Action. @@ -487,7 +486,7 @@ Rationale The following is a list of rationale for different decisions made in the proposal: - The issuance key structure is independent of the original key tree, but derived in an analogous manner (via ZIP 32). This keeps the issuance details and the Asset Identifiers consistent across multiple shielded pools. It also separates the issuance authority from the spend authority, allowing for the potential transfer of issuance authority without compromising the spend authority. -- The Custom Asset is described via a combination of the issuance validating key and an asset description string, to preclude the possibility of two different issuers creating colliding Custom Assets. +- The Custom Asset is described via a combination of the issuer identifier and an asset description string, to preclude the possibility of two different issuers creating colliding Custom Assets. - The requirement of at least one OrchardZSA Action Group in the presence of an issue bundle is both to allow for the computation of the $\text{ρ}$ field of the issue notes, as well as to prevent replay attacks. If a transaction includes only an issue bundle, the SIGHASH transaction hash would be computed solely based on the issue bundle. A duplicate bundle would have the same SIGHASH transaction hash, potentially allowing for a replay attack. Hash of the asset description @@ -605,9 +604,9 @@ Wallets need to communicate the names of the Assets in a non-confusing way to us Issuance Key Compromise ----------------------- -The design of this protocol does not currently allow for rotation of the issuance validating key that would allow for replacing the key of a specific Asset. In case of compromise, the following actions are recommended: +The design of this protocol does not currently allow for rotation of the issuer identifier that would allow for replacing the key of a specific Asset. In case of compromise, the following actions are recommended: -- If an issuance validating key is compromised, the $\mathsf{finalize}$ boolean for all the Assets issued with that key should be set to $1$ and the issuer should change to a new issuance authorizing key, and issue new Assets, each with a new $\mathsf{AssetId}$. +- If an issuer identifier is compromised, the $\mathsf{finalize}$ boolean for all the Assets issued with that key should be set to $1$ and the issuer should change to a new issuance authorizing key, and issue new Assets, each with a new $\mathsf{AssetId}$. Bridging Assets --------------- diff --git a/zips/zip-0230.rst b/zips/zip-0230.rst index d39085e90..59851f190 100644 --- a/zips/zip-0230.rst +++ b/zips/zip-0230.rst @@ -158,9 +158,9 @@ Transaction Format +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ | varies |``vIssueActions`` |``IssueAction[nIssueActions]`` |A sequence of issuance action descriptions. | +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ -| varies |``issuerLength`` |``compactSize`` |The length of the issuance validating key of the issuer. | +| varies |``issuerLength`` |``compactSize`` |The length of the issuer identifier of the issuer. | +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ -| varies |``issuer`` |``byte[issuerLength]`` |The issuance validating key of the issuer, used to validate the | +| varies |``issuer`` |``byte[issuerLength]`` |The issuer identifier of the issuer, used to validate the | | | | |signature. | +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ | varies |``issueAuthSigLength`` |``compactSize`` |The length of the issuance authorization signature. | From 1a7d1505dac97f116a3213dc5e02443cc8c7c71a Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 30 Jun 2025 13:52:45 +0530 Subject: [PATCH 4/4] minor corrections --- zips/zip-0227-key-components-zsa.svg | 4 ++-- zips/zip-0227.rst | 3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/zips/zip-0227-key-components-zsa.svg b/zips/zip-0227-key-components-zsa.svg index 4b36d3684..7ad43c80e 100644 --- a/zips/zip-0227-key-components-zsa.svg +++ b/zips/zip-0227-key-components-zsa.svg @@ -26,7 +26,7 @@ inkscape:pageopacity="0.0" inkscape:pageshadow="2" inkscape:zoom="0.80392436" - inkscape:cx="183.47497" + inkscape:cx="1.8658472" inkscape:cy="176.63353" inkscape:document-units="px" inkscape:current-layer="layer1" @@ -183,7 +183,7 @@ y="909.8241" x="184.16003" id="tspan3852" - sodipodi:role="line">Issuance validating keyIssuer identifier