Merge pull request #1275 from daira/zip-2005-drop-leadByte-from-hrcm

ZIP 2005: Improve security argument; drop leadByte and AssetBase from H^{rcm,Orchard}; commit to deployment option 1

Author: daira

README.rst

@@ -176,7 +176,6 @@ written.
     <tr> <td>226</td> <td class="left"><a href="zips/zip-0226.rst">Transfer and Burn of Zcash Shielded Assets</a></td> <td>Draft</td> <td class="left"><a href="https://github.com/zcash/zips/issues/618">zips#618</a></td>
     <tr> <td>227</td> <td class="left"><a href="zips/zip-0227.rst">Issuance of Zcash Shielded Assets</a></td> <td>Draft</td> <td class="left"><a href="https://github.com/zcash/zips/issues/618">zips#618</a></td>
     <tr> <td><span class="reserved">228</span></td> <td class="left"><a class="reserved" href="zips/zip-0228.rst">Asset Swaps for Zcash Shielded Assets</a></td> <td>Reserved</td> <td class="left"><a href="https://github.com/zcash/zips/issues/776">zips#776</a></td>
-    <tr> <td>230</td> <td class="left"><a href="zips/zip-0230.rst">Version 6 Transaction Format</a></td> <td>Draft</td> <td class="left"><a href="https://github.com/zcash/zips/issues/686">zips#686</a></td>
     <tr> <td>231</td> <td class="left"><a href="zips/zip-0231.md">Memo Bundles</a></td> <td>Draft</td> <td class="left"><a href="https://github.com/zcash/zips/issues/627">zips#627</a></td>
     <tr> <td>233</td> <td class="left"><a href="zips/zip-0233.md">Network Sustainability Mechanism: Removing Funds From Circulation</a></td> <td>Draft</td> <td class="left"><a href="https://github.com/zcash/zips/issues/922">zips#922</a></td>
     <tr> <td>234</td> <td class="left"><a href="zips/zip-0234.md">Network Sustainability Mechanism: Issuance Smoothing</a></td> <td>Draft</td> <td class="left"><a href="https://github.com/zcash/zips/issues/923">zips#923</a></td>
@@ -250,6 +249,7 @@ Withdrawn, Rejected, or Obsolete ZIPs
     <tr> <th>ZIP</th> <th>Title</th> <th>Status</th> </tr>
     <tr> <td><strike>210</strike></td> <td class="left"><strike><a href="zips/zip-0210.rst">Sapling Anchor Deduplication within Transactions</a></strike></td> <td>Withdrawn</td>
     <tr> <td><strike>220</strike></td> <td class="left"><strike><a href="zips/zip-0220.rst">Zcash Shielded Assets</a></strike></td> <td>Withdrawn</td>
+    <tr> <td><strike>230</strike></td> <td class="left"><strike><a href="zips/zip-0230.rst">Withdrawn Version 6 Transaction Format</a></strike></td> <td>Withdrawn</td>
     <tr> <td><strike>254</strike></td> <td class="left"><strike><a href="zips/zip-0254.md">Deployment of the NU7 Network Upgrade (Withdrawn)</a></strike></td> <td>Withdrawn</td>
     <tr> <td><strike>313</strike></td> <td class="left"><strike><a href="zips/zip-0313.rst">Reduce Conventional Transaction Fee to 1000 zatoshis</a></strike></td> <td>Obsolete</td>
     <tr> <td><strike>1001</strike></td> <td class="left"><strike><a href="zips/zip-1001.rst">Keep the Block Distribution as Initially Defined — 90% to Miners</a></strike></td> <td>Obsolete</td>
@@ -316,7 +316,7 @@ Index of ZIPs
     <tr> <td>226</td> <td class="left"><a href="zips/zip-0226.rst">Transfer and Burn of Zcash Shielded Assets</a></td> <td>Draft</td>
     <tr> <td>227</td> <td class="left"><a href="zips/zip-0227.rst">Issuance of Zcash Shielded Assets</a></td> <td>Draft</td>
     <tr> <td><span class="reserved">228</span></td> <td class="left"><a class="reserved" href="zips/zip-0228.rst">Asset Swaps for Zcash Shielded Assets</a></td> <td>Reserved</td>
-    <tr> <td>230</td> <td class="left"><a href="zips/zip-0230.rst">Version 6 Transaction Format</a></td> <td>Draft</td>
+    <tr> <td><strike>230</strike></td> <td class="left"><strike><a href="zips/zip-0230.rst">Withdrawn Version 6 Transaction Format</a></strike></td> <td>Withdrawn</td>
     <tr> <td>231</td> <td class="left"><a href="zips/zip-0231.md">Memo Bundles</a></td> <td>Draft</td>
     <tr> <td>233</td> <td class="left"><a href="zips/zip-0233.md">Network Sustainability Mechanism: Removing Funds From Circulation</a></td> <td>Draft</td>
     <tr> <td>234</td> <td class="left"><a href="zips/zip-0234.md">Network Sustainability Mechanism: Issuance Smoothing</a></td> <td>Draft</td>

zips/zip-0226.rst

@@ -42,7 +42,7 @@ Abstract
 This ZIP (ZIP 226) proposes the Orchard Zcash Shielded Assets (OrchardZSA) protocol, in conjunction with ZIP 227 [#zip-0227]_. The OrchardZSA protocol is an extension of the Orchard protocol that enables the issuance, transfer and burn of custom Assets on the Zcash chain. The issuance of such Assets is defined in ZIP 227 [#zip-0227]_, while the transfer and burn of such Assets is defined in this ZIP (ZIP 226).
 While the proposed OrchardZSA protocol is a modification to the Orchard protocol, it has been designed with adaptation to possible future shielded protocols in mind.
 
-This ZIP is defined relative to the Zcash protocol with the changes specified in ZIP 2005 [#zip-2005]_ applied. ZIP 2005 (Orchard Quantum Recoverability) is expected to deploy before any ZSA activation; the references in this document to $\mathsf{H^{rcm,Orchard}}$, $\mathsf{H^{\text{ψ},Orchard}}$, recoverable note plaintexts (lead byte $\mathtt{0x03}$), and related constructs are to be interpreted as defined by ZIP 2005's modifications to the protocol specification.
+This ZIP is defined relative to the Zcash protocol with the changes specified in ZIP 2005 [#zip-2005]_ applied. ZIP 2005 (Orchard Quantum Recoverability) is expected to deploy before any ZSA activation; the references in this document to $\mathsf{H^{rcm,Orchard}}$, $\mathsf{H^{\text{ψ},Orchard}}$, recoverable note plaintexts, and related constructs are to be interpreted as defined by ZIP 2005's modifications to the protocol specification.
 
 Motivation
 ==========
@@ -159,7 +159,7 @@ The nullifier is generated in the same manner as in the Orchard protocol §4.16
 The OrchardZSA note plaintext also includes the Asset Base $\mathsf{asset\_base} : \mathbb{B}^{[\ell_{\mathbb{P}}]}$ in addition to the components in the Orchard note plaintext [#protocol-notept]_.
 The explicit encoding of the note plaintext is provided in ZIP 230 [#zip-0230-orchard-note-plaintext]_.
 
-When § 4.7.3 'Sending Notes (Orchard)' [#protocol-orchardsend]_ or § 4.8.3 'Dummy Notes (Orchard)' [#protocol-orcharddummynotes]_ are invoked directly or indirectly in the computation of $\text{ρ}$ and $\text{ψ}$ for an OrchardZSA note, $\mathsf{leadByte}$ MUST be set to $\mathtt{0x03}$.
+When § 4.7.3 'Sending Notes (Orchard)' [#protocol-orchardsend]_ or § 4.8.3 'Dummy Notes (Orchard)' [#protocol-orcharddummynotes]_ are invoked directly or indirectly in the computation of $\text{ρ}$ and $\text{ψ}$ for an OrchardZSA note, $\mathsf{leadByte}$ MUST be set to {{ZSALEADBYTE}}.
 
 The explicit order of addition of the note commitments to the note commitment tree is specified in ZIP 227 [#zip-0227-note-commitment-order]_.
 
@@ -392,11 +392,9 @@ The following requirements on wallets are specified and motivated in ZIP 230
   ZEC asset. For other consequences see ZIP 230.
 
 * *All* wallets should be ready to receive funds in outputs of v6 transactions as soon
-  as ZSAs activate — in particular to support decrypting recoverable note plaintexts
-  (lead byte $\mathtt{0x03}$) [#zip-0230-note-plaintexts]_. The consequence of not doing so would
-  be that funds sent to Orchard addresses of a wallet without this support could be
-  temporarily inaccessible, until the wallet is upgraded to fully support v6 and to
-  rescan outputs since v6 activation.
+  as ZSAs activate. The consequence of not doing so would be that funds sent to Orchard
+  addresses of a wallet without this support could be temporarily inaccessible, until
+  the wallet is upgraded to fully support v6 and to rescan outputs since v6 activation.
 
 Sighash modifications relative to ZIP 244 [#zip-0244]_
 ------------------------------------------------------

zips/zip-0230.rst

@@ -1,7 +1,7 @@
 ::
 
   ZIP: 230
-  Title: Version 6 Transaction Format
+  Title: Withdrawn Version 6 Transaction Format
   Owners: Daira-Emma Hopwood <daira@jacaranda.org>
           Jack Grigg <thestr4d@gmail.com>
           Sean Bowe <ewillbefull@gmail.com>
@@ -11,7 +11,7 @@
   Original-Authors: Greg Pfeil
                     Deirdre Connolly
   Credits: Ying Tong Lai
-  Status: Draft
+  Status: Withdrawn
   Category: Consensus
   Created: 2023-04-18
   License: MIT
@@ -35,6 +35,15 @@ The character § is used when referring to sections of the Zcash Protocol Specif
 Abstract
 ========
 
+.. warning::
+    This ZIP has been obsoleted by ZIP 248 [#zip-0248]_, and will not be deployed. Transaction
+    version number 6 is now defined by ZIP 248.
+
+    Occurrences of the note plaintext lead byte constant it introduced (originally $\mathtt{0x03}$)
+    have been changed to "{{LEADBYTE}}", to clarify that this ZIP does not reserve that lead byte
+    value, and to avoid confusion with the different specification of lead byte $\mathtt{0x03}$ in
+    ZIP 2005 [#zip-2005]_.
+
 This proposal defines a new Zcash peer-to-peer transaction format, which supports the
 changes being deployed in Network Upgrade 7 [#draft-arya-deploy-nu7]_. It follows the same design
 pattern as the v5 transaction format [#zip-0225]_.
@@ -46,7 +55,7 @@ Motivation
 The OrchardZSA protocol requires serialized data elements that are distinct from
 any previous Zcash transaction. Since ZIP 244 was activated in NU5, the
 v5 and later serialized transaction formats are not consensus-critical.
-Thus, this ZIP defines format that can easily accommodate future extensions,
+Thus, this ZIP defines a format that can easily accommodate future extensions,
 where elements or a given pool are kept separate.
 
 
@@ -487,11 +496,11 @@ An issuance note description, ``IssueNoteDescription`` contains the following fi
 Note Plaintexts
 ---------------
 
-New note plaintext formats using lead byte $\mathtt{0x03}$ are introduced for
+New note plaintext formats using lead byte {{LEADBYTE}} are introduced for
 Sapling and Orchard, in order to support memo bundles and (for Orchard) ZSAs and
 quantum recoverability.
 
-The $\mathsf{leadByte}$ MUST be $\mathtt{0x03}$ for all note plaintexts in v6
+The $\mathsf{leadByte}$ MUST be {{LEADBYTE}} for all note plaintexts in v6
 transactions.
 
 Sapling Note Plaintext
@@ -546,8 +555,8 @@ The encodings of $\mathsf{d}$, $\mathsf{v}$, and $\mathsf{rseed}$ remain unchang
 Non-normative note: The *use* of the $\mathsf{rseed}$ in Orchard note decryption
 changes, but its type and encoding do not.
 
-Rationale for requiring the lead byte to be 0x03 in v6
-``````````````````````````````````````````````````````
+Rationale for requiring the lead byte to be {{LEADBYTE}} in v6
+``````````````````````````````````````````````````````````````
 
 It was decided to synchronize the changes to note encryption required for
 quantum recoverability, ZSA support, and memo bundles with a change to the
@@ -632,7 +641,7 @@ Support for receiving funds in v6 transactions
 
 Zcash wallets MUST support parsing and processing v6 transactions by the time
 they are allowed on the network (scheduled for NU7 activation). This includes
-detecting and decrypting lead-byte $\mathtt{0x03}$ note plaintexts and memo
+detecting and decrypting lead-byte {{LEADBYTE}} note plaintexts and memo
 bundles.
 
 The necessary changes to note decryption are specified in ZIP 231 [#zip-0231]_,
@@ -648,7 +657,7 @@ once that support is added.
 Rationale for being ready to receive v6 transactions at their activation
 ````````````````````````````````````````````````````````````````````````
 
-Note plaintexts with lead byte $\mathtt{0x03}$, which are required for Orchard
+Note plaintexts with lead byte {{LEADBYTE}}, which are required for Orchard
 notes in v6 transactions, can be sent to any Orchard address.
 
 These notes use a different computation of $\mathsf{rcm}$ and $\text{ψ}$ from
@@ -660,7 +669,7 @@ attempting to non-conformantly use the note decryption algorithm for lead byte
 $\mathtt{0x02}$ would compute a different note commitment $\mathsf{cm}_x$ and
 would reject the note.
 
-If wallets do not support v6 transactions and lead-byte $\mathtt{0x03}$ note
+If wallets do not support v6 transactions and lead-byte {{LEADBYTE}} note
 decryption immediately, then funds may be sent to them that they cannot receive.
 This affects both the existing Orchard functionality, and receiving non-native
 ZSA assets.
@@ -720,5 +729,5 @@ References
 .. [#zip-0301] `ZIP 301: Zcash Stratum Protocol <zip-0301.rst>`_
 .. [#zip-2002-motivation] `ZIP 231: Explicit Fees — Motivation <zip-2002.rst#motivation>`_
 .. [#zip-2005] `ZIP 2005: Quantum Recoverability <zip-2005.md>`_
-.. [#zip-2005-security-analysis] `ZIP 2005: Quantum Recoverability — Security Analysis <zip-2005.md#security-analysis>`_
+.. [#zip-2005-security-analysis] `ZIP 2005: Quantum Recoverability — Security Analysis <zip-2005.md#securityanalysis>`_
 .. [#draft-arya-deploy-nu7] `draft-arya-deploy-nu7: Deployment of the NU7 Network Upgrade <draft-arya-deploy-nu7.md>`_

zips/zip-0231.md

@@ -487,7 +487,7 @@ In § 5.5 ‘Encodings of Note Plaintexts and Memo Fields’ [^protocol-notepten
     >
     > $\begin{array}{|c|c|c|c|c|} \hline \raisebox{0.6ex}{\mathstrut} \text{8-bit } \mathsf{leadByte} & \text{88-bit } \mathsf{d} & \text{64-bit } \mathsf{v} & \text{256-bit } \mathsf{rseed} & \text{32-byte } \mathsf{K^{memo}} \\\hline \end{array}$
     >
-    > * A byte 0x03, indicating this version of the encoding of a v6-onward
+    > * A byte {{MBLEADBYTE}}, indicating this version of the encoding of a v6-onward
     >   Sapling or Orchard note plaintext.
     > * 11 bytes specifying $\mathsf{d}$.
     > * 8 bytes specifying $\mathsf{v}$.
@@ -583,6 +583,11 @@ synchronization.
 
 TBD
 
+## Note plaintext lead byte assignment
+
+The lead byte to be used for this proposal, denoted as {{MBLEADBYTE}} above, has
+not yet been assigned.
+
 
 # Rationale