Switching the issuance authorization scheme to using Bitcoin Schnorr over secp256k1, as in BIP 340.
#40
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: daniben31 <danielbenarroch92@gmail.com> Co-authored-by: Deirdre Connolly <durumcrustulum@gmail.com> Co-authored-by: Daira Hopwood <daira@jacaranda.org> Co-authored-by: Jonathan S. Rouach <jon@rouach.net> Co-authored-by: str4d <thestr4d@gmail.com> Co-authored-by: Paul <lauxpaul@protonmail.com>
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
Includes improvements to mathematical notation, and typographical edits. Co-authored-by: Daira Hopwood <daira@jacaranda.org> Co-authored-by: Deirdre Connolly <durumcrustulum@gmail.com>
This covers the changes made to derive the issuance key independently of the Orchard key structure, using the techniques from [ZIP 32](https://zips.z.cash/zip-0032).
…ations (#13) Minor changes to the Security and Privacy Considerations to make it more in line with the format specified in ZIP 0.
This rearranges and rewrites various sections of the ZIP to make it more in line with the suggestions in ZIP 0. It also updates the Split Notes, Circuit Statement and Burn Mechanism sections with more information.
This adds in the reference links to the test vectors and reference implementations corresponding to the ZSA Protocol. Some corrections to the notation for better consistency and some updates to the formulae for syncing with the implementation are also included here.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
Link to the nested README in `protocol/README` to install all the dependencies needed to build ZIPs and the specs.
This details the changes to the transaction digest algorithm for the ZSA protocol. - A new branch is added for hashing the information in a transaction related to issuance. - Some branches are added and modified in the orchard_digest subtree to account for the additional Asset Base value that needs to be hashed.
Improved style and content of ZIP 227. --------- Co-authored-by: Vivek Arte <vivek@qed-it.com>
This adds details of the changes to the Orchard Action encodings and the changes to the transaction format that occur due to the ZSA Protocol. It also improves the formatting of existing tables for Asset Burn.
A few of the issue bundle hash personalizations were 15 characters long instead of the required 16. This is being fixed here.
As per the title, this is a tiny fix to adjust the boundary of the math environment which wasn't properly closed and thus rendered poorly on the html.
This makes the naming conventions for variables more consistent, largely with a view to using double backticks for terms that appear in the transaction format and datatype description tables. These tables have also been reformatted to be consistent with other ZIPs in their rst form. The `previously_finalized` set is renamed to `finalized_assets`, and this set now stores `AssetDigest` values rather than `AssetId` values for more compactness in the global state.
Removed redundant terminology in ZIP226, building on ZIP227, fixed abstract and used consistent terminology to stick to issuance instead of creation of assets. --------- Co-authored-by: Vivek Arte <46618816+vivek-arte@users.noreply.github.com>
…mentation (#29) This makes the changes in ZIP 227 based on [this comment](QED-it/orchard#66 (comment)).
This PR adds missing indices over sums. It also fixes and makes improvements to the burn mechanism description. --------- Co-authored-by: Vivek Arte <46618816+vivek-arte@users.noreply.github.com>
…on (#30) This PR improves the naming of variables to make them consistent with the broader ZIPs conventions. It also makes changes to the issuance key derivation and the terms used for the various keys.
- Add the new nullifier equation for split notes - Add a link to Orchard circuit document - Add is_native_asset auxiliary witness - Remove constraint (split_flag=1) => (v_old != 0) - Add constraint (split_flag=1) => (is_native_asset=0)
These are the changes to the rst files based on ZIP editors typographical changes. Co-authored-by: Deirdre Connolly <durumcrustulum@gmail.com>
This adds to the specification to provide wallets instructions on displaying Asset information to users in an unambiguous way. This addresses [this comment](zcash#680 (comment)).
#33) This addresses [this comment](zcash#680 (comment)).
This rearranges the positioning of the burn mechanism in order to remove duplication of material between the burn mechanism section and the value balance verification section. There is also some simplification of the naming convention for the Asset Base variable.
This PR adds enable_zsa flag into ZIP 226.
✅ Deploy Preview for zcash-zips-qedit ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
vivek-arte
force-pushed
the
issue_auth_sig_schnorr_secp256k1
branch
from
70eb8d7
to
aa9c3cf
Compare
PaulLaux
reviewed
Oct 5, 2023
zip-0227.rst
Outdated
|
|
||
| The signing algorithm :math:`\mathsf{IssueAuthSig.Sign}` is defined as the :math:`\mathsf{Sign}` algorithm from BIP 340 [#bip-0340]_ with the auxiliary data (denoted by :math:`a`) fixed to the 32-byte string of zeros: | ||
|
|
||
| * :math:`\mathsf{IssueAuthSig.Sign}(\mathsf{sk}, M) := \mathsf{Sign}(sk,M)` with :math:`a = \mathtt{[0x00]}^{32}`. |
There was a problem hiding this comment.
define sk, M in the context of this zip. Should be structured as
Input:
the IssuanceMasterKey imk : a 32 byte array / B^Y^32
...
Same as bip340
Same for verification
There was a problem hiding this comment.
Did this, but slightly differently, in paragraph form. Does that seem alright too?
There was a problem hiding this comment.
Updated this part based on discussion.
zip-0227.rst
Outdated
Comment on lines
104
to
126
|
|
||
| The associated types of the :math:`\mathsf{IssueAuthSig}` signature scheme are as follows: | ||
|
|
||
| * :math:`\mathsf{IssueAuthSig.Message} = \mathbb{B}^{\mathbb{Y}^{[\mathbb{N}]}}` | ||
| * :math:`\mathsf{IssueAuthSig.Signature} = \mathbb{B}^{\mathbb{Y}^{[64]}}` | ||
| * :math:`\mathsf{IssueAuthSig.Public} = \mathbb{B}^{\mathbb{Y}^{[32]}}` | ||
| * :math:`\mathsf{IssueAuthSig.Private} = \mathbb{B}^{\mathbb{Y}^{[32]}}` | ||
|
|
||
| where :math:`\mathbb{B}^{\mathbb{Y}^{[k]}}` denotes the set of sequences of :math:`k` bytes, and :math:`\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 signing key generation algorithm and the validating key derivation algorithm are defined in the `Issuance Key Derivation`_ section below. | ||
|
|
||
| We use :math:`\mathsf{hash}_{\mathsf{name}} : \mathbb{B}^{\mathbb{Y}^{[\mathbb{N}]}} \to \mathbb{B}^{\mathbb{Y}^{[32]}}` in the same manner as defined in BIP 340 [#bip-0340]_, that is, | ||
| :math:`\mathsf{hash}_{\mathsf{name}}(\mathsf{x}) := \mathsf{SHA256}(\mathsf{SHA256}(\mathsf{tag}) \| \mathsf{SHA256}(\mathsf{tag}) \| \mathsf{x})` | ||
| where :math:`\mathsf{tag}` is the UTF-8 encoding of :math:`\mathsf{name}`. | ||
|
|
||
| The signing algorithm :math:`\mathsf{IssueAuthSig.Sign}` is defined as the :math:`\mathsf{Sign}` algorithm from BIP 340 [#bip-0340]_ with the auxiliary data (denoted by :math:`a`) fixed to the 32-byte string of zeros: | ||
|
|
||
| * :math:`\mathsf{IssueAuthSig.Sign}(\mathsf{sk}, M) := \mathsf{Sign}(sk,M)` with :math:`a = \mathtt{[0x00]}^{32}`. | ||
|
|
||
| The validating algorithm :math:`\mathsf{IssueAuthSig.Validate}(\mathsf{vk}, M, \sigma)` is defined using the :math:`\mathsf{Verify}` algorithm from BIP 340 [#bip-0340]_ as: | ||
|
|
||
| * Return :math:`1` if :math:`\mathsf{Verify}(vk, M, \sigma)` succeeds, otherwise :math:`0`. |
There was a problem hiding this comment.
This entire section should come after Issuance Key Derivation and use notations from the derivation part as inputs.
specifically after Derivation of issuance validating key under the title Issuance signature and verification or similar.
There was a problem hiding this comment.
Rearranged. One question is whether the levels of the headings should be different (aka lower levels for the "issuance key derivation" and "issuance authorization signing and validation" sections).
PaulLaux
approved these changes
Oct 15, 2023
vivek-arte
added a commit
that referenced
this pull request
Feb 12, 2024
…over `secp256k1`, as in BIP 340. (#40) We switch the `issueAuthSig` scheme from RedPallas without key re-randomization to the Bitcoin Schnorr signature (as described in bip340). We also perform notation changes of `idk` to `imk`, and adjust the derivation of the issuance keys to fit with the updated Issuance Authorization Signature scheme.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR, we switch the
issueAuthSigscheme from RedPallas without key re-randomization to the Bitcoin Schnorr signature (as described in bip340).We also perform notation changes of
idktoimk, and adjust the derivation of the issuance keys to fit with the updated Issuance Authorization Signature scheme.