initial ZIP drafts for ZSA transfer and issuance

[daniben31]

We propose drafts of the following ZIPs

• ZIP 226: Transfer and Burn of Zcash Shielded Assets
• ZIP 227: Issuance of Zcash Shielded Assets

These two ZIPs are to be reviewed and implemented in conjunction for the proper functioning of the ZSA protocol.
For discussion on these ZIPs, please see #618

[dconnolly]

Suggested change

	This, however, brings some issues when it comes to adding multiple asset types, as the output note of the split Actions *cannot* be of *any* asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.
	This, however, brings some issues when it comes to adding multiple Asset types, as the output note of the split Actions *cannot* be of *any* Asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

[vivek-arte]

Suggestion incorporated in PR#649.

[str4d]

I reviewed the ZIP 227 draft in ZIP Sync today along with @dconnolly, @daira, @teor2345, @nuttycom, and @sellout. Our collective comments are above.

Additionally, the ZIP 227 draft currently feels somewhat inverted to me (for example, the Rationale is first, before any of the specification being rationalized). I would like to see the ZIP draft refactored to have the following structure:

• Motivation
• Use cases
• Requirements
• Specification
  • Asset ID
    • Define "issuer ID", "asset desc".
    • Specify asset_id.
  • Issuer key derivation and management
    • This section will have references to ZIP 32 and ZIP 316 in terms of fitting isk into a wallet's overall key tree.
    • If key rotation were specified, it would go in a subsection here.
  • Global issuance state
    • Describe / specify issuanceSupplyInfoMap here.
    • If key rotation were specified earlier, it would also come up here wrt state storage.
  • Orchard issuance bundles
    • Describe / specify issuance bundles here. At this layer they are Orchard-specific as we are producing Orchard notes, and I think it's fine for now to not make this part generic over future possible shielded protocols (though the ZIP needs to be cognizant of this possible eventuality).
    • Give sufficient detail here of how the issuance bundles will be included in the eventual v6 transaction format. The v6 format itself should be specified in a separate ZIP (as it may include changes beyond ZSA issuance).
  • Orchard issuance protocol
    • This section should describe how to produce a valid issuance bundle.
  • Consensus rule changes
• Rationale
  • For a ZIP of this size, I think a single "Rationale" section is fine, but could also interleave "Rationale for X" sub-sections throughout as some other large ZIPs have done.
• Security and privacy considerations
  • In particular, discussion about key compromise (which is mentioned in several places).

The "Fee Structures" changes should instead be made as changes to ZIP 317 in this PR, now that it exists and (per the most recent ZIP editors meeting) will be a "living ZIP with a shelf life".

[daniben31]

Hi all, thank you for the thorough review and constructive comments. We have takent the time to not only adapt all the comments, but also to rewrite several components (specially of the Issuance ZIP 227) in order to be in agreement with the code and the review that was submitted there as well.

As such, we want to close this PR and have created a second one instead - see here: #649

On this PR we have the following comments:

1. Regarding the issuance ZIP (and specifically @str4d comment above initial ZIP drafts for ZSA transfer and issuance #628 (review)

   • We are not adding a specification for rotating the issuer key, as we did not include a design that would allow for replacing the key of a specific asset. In case of compromise, the following actions are recommended:
     • If an asset ID is compromised, the finalization boolean should be put to 0 and a new asset ID generated.
     • If an issuer verification key is compromised, the finalization boolean should be put to 0 and the issuer should change to a new spending key altogether (for the purpose of issuance).
     • Added this to the security and privacy considerations section too and a future work section explaining.
   • I am not sure how the issuer keys actually relate to ZIP 316 of unified addresses. I mentioned it is in accordance with the zip, but please let me know if I am missing something.
   • Indeed, the v6 transaction format ZIP is going to be left to the joint work to be done in defining the next network upgrade, for now we included a specific component of the issuance bundle to be included in that ZIP.
   • Another comment not resolved is the "AssetIdHasher" by Deirdre -

2. Regarding the Transfer ZIP, all the comments have been addressed and the new notation AssetId has been incorporated too.

@PaulLaux see above comment