From a9fc3aed12780edec4505d49777645226988eae1 Mon Sep 17 00:00:00 2001 From: Daira-Emma Hopwood Date: Sat, 9 Nov 2024 20:54:58 +0000 Subject: [PATCH] Re-render. Signed-off-by: Daira-Emma Hopwood --- rendered/zip-0032.html | 294 ++++++++++++++++--------------- rendered/zip-0203.html | 4 +- rendered/zip-0207.html | 4 +- rendered/zip-0212.html | 4 +- rendered/zip-0215.html | 4 +- rendered/zip-0216.html | 4 +- rendered/zip-0221.html | 4 +- rendered/zip-0224.html | 4 +- rendered/zip-0225.html | 14 +- rendered/zip-0226.html | 4 +- rendered/zip-0227.html | 6 +- rendered/zip-0230.html | 4 +- rendered/zip-0231.html | 287 +++++++++++++++--------------- rendered/zip-0233.html | 65 ++++--- rendered/zip-0234.html | 90 ++++++---- rendered/zip-0235.html | 116 ++++++------ rendered/zip-0244.html | 4 +- rendered/zip-0253.html | 1 - rendered/zip-0254.html | 1 - rendered/zip-0304.html | 4 +- rendered/zip-0307.html | 4 +- rendered/zip-0311.html | 4 +- rendered/zip-0312.html | 4 +- rendered/zip-0316.html | 8 +- rendered/zip-0317.html | 4 +- rendered/zip-0320.html | 4 +- rendered/zip-0324.html | 4 +- rendered/zip-0401.html | 4 +- rendered/zip-1011.html | 4 +- rendered/zip-2001.html | 4 +- rendered/zip-2002.html | 4 +- rendered/zip-2004.html | 4 +- rendered/zip-guide-markdown.html | 24 +-- rendered/zip-guide.html | 9 +- 34 files changed, 541 insertions(+), 462 deletions(-) diff --git a/rendered/zip-0032.html b/rendered/zip-0032.html index 432702ad2..5d213a801 100644 --- a/rendered/zip-0032.html +++ b/rendered/zip-0032.html @@ -3,7 +3,9 @@ ZIP 32: Shielded Hierarchical Deterministic Wallets - + + +
@@ -59,30 +61,30 @@ means the sequence formed from the first \(k\) elements of - \(S\) + \(S\!\) .
  • \(a\,||\,b\) means the concatenation of sequences \(a\) then - \(b\) + \(b\!\) .
  • \([k] P\) means scalar multiplication of the elliptic curve point \(P\) by the scalar - \(k\) + \(k\!\) .
  • \(\mathsf{LEOS2IP}_\ell(S)\) is the integer in range - \(\{ 0\,.\!. 2^\ell - 1 \}\) + \(\{ 0\,..\, 2^\ell - 1 \}\) represented in little-endian order by the byte sequence \(S\) of length - \(\ell/8\) + \(\ell/8\!\) .
  • \(\mathsf{I2LEBSP}_\ell(k)\) @@ -96,7 +98,7 @@ is defined as follows when \(\ell\) is a multiple of - \(8\) + \(8\!\) : convert each group of 8 bits in \(B\) to a byte value with the least significant bit first, and concatenate the resulting bytes in the same order as the groups.
    • @@ -108,22 +110,22 @@
  • \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\) refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string - \(p\) + \(p\!\) , and input - \(x\) + \(x\!\) .
  • \(\mathsf{BLAKE2b}\text{-}\mathsf{512}(p, x)\) refers to unkeyed BLAKE2b-512 in sequential mode, with an output digest length of 64 bytes, 16-byte personalization string - \(p\) + \(p\!\) , and input - \(x\) + \(x\!\) .
  • \(\mathsf{PRF^{expand}}(\mathsf{sk}, t) :=\) - \(\mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“Zcash_ExpandSeed”},\) - \(\mathsf{sk}\,||\,t)\) -
    • + \(\mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“Zcash\_ExpandSeed”},\) + \(\mathsf{sk}\,||\,t)\!\) + .
  • \(r_\mathbb{J}\) is the order of the Jubjub large prime subgroup.
    • @@ -132,11 +134,11 @@ is the order of the Pallas curve.
  • \(\mathsf{ToScalar^{Sapling}}(x) :=\) - \(\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{J}}\) + \(\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{J}}\!\) .
  • \(\mathsf{ToScalar^{Orchard}}(x) :=\) - \(\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{P}}\) + \(\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{P}}\!\) .
  • \(\mathsf{DiversifyHash^{Sapling}}(d)\) @@ -151,15 +153,15 @@
  • \(\mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(key, tweak, x)\) refers to the FF1 encryption algorithm using AES with a 256-bit - \(key\) + \(key\!\) , and parameters \(radix = 2,\) \(minlen = 88,\) - \(maxlen = 88\) + \(maxlen = 88\!\) . It will be used only with the empty string \(\texttt{“”}\) as the - \(tweak\) + \(tweak\!\) . \(x\) is a sequence of 88 bits, as is the output.
    • @@ -175,9 +177,9 @@ representing in little-endian order the integer \(k\) in range - \(\{ 0\,.\!. 2^\ell - 1 \}\) + \(\{ 0\,..\, 2^\ell - 1 \}\!\) . It is the reverse operation of - \(\mathsf{LEOS2IP}_\ell(S)\) + \(\mathsf{LEOS2IP}_\ell(S)\!\) .

    Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling and Orchard specifications), which is the opposite of BIP 32.

    @@ -190,7 +192,7 @@
  • \(\mathsf{CKDfvk}(\mathsf{CKDfvk}(\mathsf{CKDfvk}(m_\mathsf{Sapling}, a), b), c)\) is written as - \(m_\mathsf{Sapling} / a / b / c\) + \(m_\mathsf{Sapling} / a / b / c\!\) .
    • @@ -202,7 +204,7 @@
  • We do not derive Sapling public keys directly, as this would prevent the use of diversified addresses. Instead, we derive Sapling full viewing keys, from which payment addresses can be generated. This maintains the trust semantics of BIP 32: someone with access to a BIP 32 extended public key is able to view all transactions involving that address, which a Sapling full viewing key also enables.

    • We represent a Sapling extended spending key as - \((\mathsf{ask, nsk, ovk, dk, c})\) + \((\mathsf{ask, nsk, ovk, dk, c})\!\) , where \((\mathsf{ask, nsk, ovk})\) is the normal Sapling expanded spending key, @@ -211,7 +213,7 @@ \(\mathsf{c}\) is the chain code.

    We represent a Sapling extended full viewing key as - \((\mathsf{ak, nk, ovk, dk, c})\) + \((\mathsf{ak, nk, ovk, dk, c})\!\) , where \((\mathsf{ak, nk, ovk})\) is the normal Sapling full viewing key, @@ -245,40 +247,40 @@ be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.

    Note that the master extended key is invalid if \(\mathsf{ask}_m\) is - \(0\) + \(0\!\) , or if the corresponding \(\mathsf{ivk}\) derived as specified in 11 is - \(0\) + \(0\!\) .

    Sapling child key derivation

    As in BIP 32, the method for deriving a child extended key, given a parent extended key and an index - \(i\) + \(i\!\) , depends on the type of key being derived, and whether this is a hardened or non-hardened derivation.

    Deriving a child extended spending key

    \(\mathsf{CKDsk}((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)\) \(\rightarrow (\mathsf{ask}_i, \mathsf{nsk}_i, \mathsf{ovk}_i, \mathsf{dk}_i, \mathsf{c}_i)\) -

    + :

    • Check whether \(i \geq 2^{31}\) (whether the child is a hardened key).
      • If so (hardened child): let - \(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x11}]\) + \(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\mathtt{0x11}]\) \(||\,\mathsf{EncodeExtSKParts}(\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})\) - \(||\,\mathsf{I2LEOSP}_{32}(i))\) + \(||\,\mathsf{I2LEOSP}_{32}(i))\!\) .
      • If not (normal child): let - \(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x12}]\) + \(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\mathtt{0x12}]\) \(||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})\) \(||\,\mathsf{I2LEOSP}_{32}(i))\) where @@ -342,13 +344,13 @@ into two 32-byte sequences, \(I_L\) and - \(I_R\) + \(I_R\!\) .
      • Let - \(I_\mathsf{ask} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))\) + \(I_\mathsf{ask} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\mathtt{0x13}]))\!\) .
      • Let - \(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))\) + \(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\mathtt{0x14}]))\!\) .
      • Return:
          @@ -359,15 +361,15 @@ \(\mathsf{nsk}_i = (I_\mathsf{nsk} + \mathsf{nsk}_{par}) \pmod{r_\mathbb{J}}\)
        • - \(\mathsf{ovk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x15}]\) + \(\mathsf{ovk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\mathtt{0x15}]\) \(||\,\mathsf{ovk}_{par}))\)
        • - \(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]\) + \(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\mathtt{0x16}]\) \(||\,\mathsf{dk}_{par}))\)
        • - \(\mathsf{c}_i = I_R\) + \(\mathsf{c}_i = I_R\!\) .
        • @@ -375,11 +377,11 @@

        Note that the child extended key is invalid if \(\mathsf{ask}_i\) is - \(0\) + \(0\!\) , or if the corresponding \(\mathsf{ivk}\) derived as specified in 11 is - \(0\) + \(0\!\) .

    Deriving a child extended full viewing key

    @@ -391,7 +393,7 @@

    \(\mathsf{CKDfvk}((\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)\) \(\rightarrow (\mathsf{ak}_{i}, \mathsf{nk}_{i}, \mathsf{ovk}_{i}, \mathsf{dk}_{i}, \mathsf{c}_{i})\) -

    + :

    • Check whether \(i \geq 2^{31}\) @@ -399,9 +401,9 @@
      • If so (hardened child): return failure.
      • If not (normal child): let - \(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x12}]\) + \(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\mathtt{0x12}]\) \(||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})\) - \(||\,\mathsf{I2LEOSP}_{32}(i))\) + \(||\,\mathsf{I2LEOSP}_{32}(i))\!\) .
      • @@ -410,13 +412,13 @@ into two 32-byte sequences, \(I_L\) and - \(I_R\) + \(I_R\!\) .
    • Let - \(I_\mathsf{ask} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))\) + \(I_\mathsf{ask} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\mathtt{0x13}]))\!\) .
    • Let - \(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))\) + \(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\mathtt{0x14}]))\!\) .
    • Return:
        @@ -427,15 +429,15 @@ \(\mathsf{nk}_i = [I_\mathsf{nsk}]\,\mathcal{H}^\mathsf{Sapling} + \mathsf{nk}_{par}\)
      • - \(\mathsf{ovk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x15}]\) + \(\mathsf{ovk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\mathtt{0x15}]\) \(||\,\mathsf{ovk}_{par}))\)
      • - \(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]\) + \(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\mathtt{0x16}]\) \(||\,\mathsf{dk}_{par}))\)
      • - \(\mathsf{c}_i = I_R\) + \(\mathsf{c}_i = I_R\!\) .
      • @@ -445,7 +447,7 @@ is the zero point of Jubjub, or if the corresponding \(\mathsf{ivk}\) derived as specified in 11 is - \(0\) + \(0\!\) .

    @@ -462,26 +464,26 @@ \(\mathsf{nk}\) as specified in 11.
  • Let - \(I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))\) + \(I = \textsf{BLAKE2b-256}(\texttt{"Zcash\_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))\!\) .
  • Let - \(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))\) + \(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))\!\) .
  • Let - \(R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])\) + \(R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])\!\) .
  • Let - \(\mathsf{nsk_{internal}} = (I_\mathsf{nsk} + \mathsf{nsk}) \pmod{r_\mathbb{J}}\) + \(\mathsf{nsk_{internal}} = (I_\mathsf{nsk} + \mathsf{nsk}) \pmod{r_\mathbb{J}}\!\) .
  • Split \(R\) into two 32-byte sequences, \(\mathsf{dk_{internal}}\) and - \(\mathsf{ovk_{internal}}\) + \(\mathsf{ovk_{internal}}\!\) .
  • Return the internal spending key as - \((\mathsf{ask}, \mathsf{nsk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})\) + \((\mathsf{ask}, \mathsf{nsk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})\!\) .

    • Note that the child extended key is invalid if @@ -489,7 +491,7 @@ is the zero point of Jubjub, or if the corresponding \(\mathsf{ivk}\) derived as specified in 11 is - \(0\) + \(0\!\) .

    Deriving a Sapling internal full viewing key

    @@ -501,35 +503,35 @@ be the external full viewing key.

    • Let - \(I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))\) + \(I = \textsf{BLAKE2b-256}(\texttt{"Zcash\_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))\!\) .
    • Let - \(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))\) + \(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))\!\) .
    • Let - \(R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])\) + \(R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])\!\) .
    • Let - \(\mathsf{nk_{internal}} = [I_\mathsf{nsk}] \mathcal{H}^\mathsf{Sapling} + \mathsf{nk}\) + \(\mathsf{nk_{internal}} = [I_\mathsf{nsk}] \mathcal{H}^\mathsf{Sapling} + \mathsf{nk}\!\) .
    • Split \(R\) into two 32-byte sequences, \(\mathsf{dk_{internal}}\) and - \(\mathsf{ovk_{internal}}\) + \(\mathsf{ovk_{internal}}\!\) .
    • Return the internal full viewing key as - \((\mathsf{ak}, \mathsf{nk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})\) + \((\mathsf{ak}, \mathsf{nk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})\!\) .

    This design uses the same technique as non-hardened derivation to obtain a full viewing key with the same spend authority (the private key corresponding to \(\mathsf{ak}\) ) as the original, but viewing authority only for internal transfers.

    The values of - \(I\) + \(I\!\) , - \(I_\mathsf{nsk}\) + \(I_\mathsf{nsk}\!\) , and \(R\) are the same between deriving a full viewing key, and deriving the corresponding spending key. Both of these derivations are shown in the following diagram:

    @@ -544,35 +546,35 @@ is the zero point of Jubjub, or if the corresponding \(\mathsf{ivk_{internal}}\) derived from the internal full viewing key as specified in 11 is - \(0\) + \(0\!\) .

    Sapling diversifier derivation

    The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key - \(\mathsf{dk}\) + \(\mathsf{dk}\!\) . To prevent the diversifier leaking how many diversified addresses have already been generated for an account, we make the sequence of diversifiers pseudorandom and uncorrelated to that of any other account. In order to reach the maximum possible diversifier range without running into repetitions due to the birthday bound, we use FF1-AES256 as a Pseudo-Random Permutation as follows:

    • Let \(j\) be the index of the desired diversifier, in the range - \(0\,.\!. 2^{88} - 1\) + \(0\,..\, 2^{88} - 1\!\) .
    • - \(d_j = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))\) + \(d_j = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))\!\) .

    A valid diversifier \(d_j\) is one for which - \(\mathsf{DiversifyHash^{Sapling}}(d_j) \neq \bot\) + \(\mathsf{DiversifyHash^{Sapling}}(d_j) \neq \bot\!\) . For a given - \(\mathsf{dk}\) + \(\mathsf{dk}\!\) , approximately half of the possible values of \(j\) yield valid diversifiers.

    The default diversifier for a Sapling extended key is defined to be - \(d_j\) + \(d_j\!\) , where \(j\) is the least nonnegative integer yielding a valid diversifier.

    @@ -591,7 +593,7 @@
  • \(\mathsf{Context.CKDDomain}\) is a byte value, used as a domain separator during child key derivation. This should be tracked as part of the global set of domains defined for - \(\mathsf{PRF^{expand}}\) + \(\mathsf{PRF^{expand}}\!\) .
    • @@ -601,30 +603,30 @@ be an input key material byte sequence, which MUST use an unambiguous encoding within the given context, and SHOULD contain at least 256 bits of entropy. It is RECOMMENDED to use a prefix-free encoding, which may require the use of length fields if multiple fields need to be encoded.

    \(\mathsf{MKGh}^\mathsf{Context}(\mathsf{IKM}) \rightarrow (\mathsf{sk}_m, \mathsf{c}_m)\) -

    + :

    @@ -632,14 +634,14 @@

    \(\mathsf{CKDh}^\mathsf{Context}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\) \(\rightarrow (\mathsf{sk}_i, \mathsf{c}_i)\) -

    + :

    @@ -674,7 +676,7 @@ \(\mathsf{Orchard.MKGDomain} = \texttt{“ZcashIP32Orchard”}\)
  • - \(\mathsf{Orchard.CKDDomain} = \texttt{0x81}\) + \(\mathsf{Orchard.CKDDomain} = \mathtt{0x81}\)

    • Orchard extended keys

    @@ -694,7 +696,7 @@
  • Return \(\mathsf{MKGh}^\mathsf{Orchard}(S)\) as the master extended spending key - \(m_\mathsf{Orchard}\) + \(m_\mathsf{Orchard}\!\) .
    • @@ -702,7 +704,7 @@

    \(\mathsf{CKDsk}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\) \(\rightarrow (\mathsf{sk}_{i}, \mathsf{c}_i)\) -

    + :

    Arbitrary master key generation

    @@ -815,7 +817,7 @@

    \(\mathsf{CKDarb}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\) \(\rightarrow (\mathsf{sk}_i, \mathsf{c}_i)\) -

    + :

    • Return \(\mathsf{CKDh}^\mathsf{Arbitrary}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\!\) @@ -844,14 +846,14 @@ : a constant set to \(32'\) (or - \(\texttt{0x80000020}\) + \(\mathtt{0x80000020}\) ) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification.
    • \(coin\_type\) : a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 6. Note that in keeping with that document, all cryptocurrency testnets share \(coin\_type\) index - \(1\) + \(1\!\) .
    • \(account\) @@ -866,11 +868,11 @@

      Sapling key path

      Sapling provides a mechanism to allow the efficient creation of diversified payment addresses with the same spending authority. A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.

      The above key path levels include an account identifier, which in all user interfaces is represented as a "bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Sapling ZIP 32 derivation MUST support the following path for any account in range - \(\{ 0\,.\!. 2^{31} - 1 \}\) + \(\{ 0\,..\, 2^{31} - 1 \}\!\) :

      • - \(m_\mathsf{Sapling} / purpose' / coin\_type' / account'\) + \(m_\mathsf{Sapling} / purpose' / coin\_type' / account'\!\) .

      Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier as defined above) for any account they support. They MAY also support generating a stream of payment addresses for a given account, if they wish to maintain the user experience of giving a unique address to each recipient.

      @@ -882,23 +884,23 @@ path level as in 5:

      • - \(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\) + \(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\!\) .

      zcashd version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase under account - \(\mathtt{0x7FFFFFFF}\) + \(\mathtt{0x7FFFFFFF}\!\) , using hardened derivation for - \(address\_index\) + \(address\_index\!\) .

      Orchard key path

      Orchard supports diversified addresses with the same spending authority (like Sapling). A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.

      The above key path levels include an account identifier, which in all user interfaces is represented as a "bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Orchard ZIP 32 derivation MUST support the following path for any account in range - \(\{ 0\,.\!. 2^{31} - 1 \}\) + \(\{ 0\,..\, 2^{31} - 1 \}\!\) :

      • - \(m_\mathsf{Orchard} / purpose' / coin\_type' / account'\) + \(m_\mathsf{Orchard} / purpose' / coin\_type' / account'\!\) .

      Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier for Orchard) for any account they support. They MAY also support generating a stream of diversified payment addresses for a given account, if they wish to enable users to give a unique address to each recipient.

      @@ -914,7 +916,7 @@ (as specified in 18) is given by:

      • - \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\) + \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\!\) .

      It MAY be used to uniquely identify a particular Sapling full viewing key.

      @@ -926,7 +928,7 @@ (as specified in 20) is given by:

      • - \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})\) + \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})\!\) .

      It MAY be used to uniquely identify a particular Orchard full viewing key.

      @@ -938,8 +940,8 @@ of a hierarchical deterministic wallet is given by:

      • - \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_HD_Seed_FP”},\) - \([\mathsf{length}(S)]\,||\,S)\) + \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash\_HD\_Seed\_FP”},\) + \([\mathsf{length}(S)]\,||\,S)\!\) .

      It MAY be used to uniquely identify a particular hierarchical deterministic wallet.

      @@ -951,13 +953,13 @@

      The following encodings are analogous to the xprv and xpub encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 7 encoding.

      Sapling extended spending keys

      A Sapling extended spending key - \((\mathsf{ask, nsk, ovk, dk, c})\) + \((\mathsf{ask, nsk, ovk, dk, c})\!\) , at depth - \(depth\) + \(depth\!\) , with parent full viewing key tag \(parent\_fvk\_tag\) and child number - \(i\) + \(i\!\) , is represented as a byte sequence:

      • @@ -965,31 +967,31 @@ \(||\,parent\_fvk\_tag\) \(||\,\mathsf{I2LEOSP}_{32}(i)\) \(||\,\mathsf{c}\) - \(||\,\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk})\) + \(||\,\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk})\!\) .

      For the master extended spending key, \(depth\) is - \(0\) + \(0\!\) , \(parent\_fvk\_tag\) is 4 zero bytes, and \(i\) is - \(0\) + \(0\!\) .

      When encoded as Bech32, the Human-Readable Part is secret-extended-key-main for the production network, or secret-extended-key-test for the test network.

      Sapling extended full viewing keys

      A Sapling extended full viewing key - \((\mathsf{ak, nk, ovk, dk, c})\) + \((\mathsf{ak, nk, ovk, dk, c})\!\) , at depth - \(depth\) + \(depth\!\) , with parent full viewing key tag \(parent\_fvk\_tag\) and child number - \(i\) + \(i\!\) , is represented as a byte sequence:

      • @@ -997,47 +999,47 @@ \(||\,parent\_fvk\_tag\) \(||\,\mathsf{I2LEOSP}_{32}(i)\) \(||\,\mathsf{c}\) - \(||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk})\) + \(||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk})\!\) .

      For the master extended full viewing key, \(depth\) is - \(0\) + \(0\!\) , \(parent\_fvk\_tag\) is 4 zero bytes, and \(i\) is - \(0\) + \(0\!\) .

      When encoded as Bech32, the Human-Readable Part is zxviews for the production network, or zxviewtestsapling for the test network.

      Orchard extended spending keys

      An Orchard extended spending key - \((\mathsf{sk, c})\) + \((\mathsf{sk, c})\!\) , at depth - \(depth\) + \(depth\!\) , with parent full viewing key tag \(parent\_fvk\_tag\) and child number - \(i\) + \(i\!\) , is represented as a byte sequence:

      • - \(\mathsf{I2LEOSP}_{8}(depth)\,||\,parent\_fvk\_tag\,||\,\mathsf{I2LEOSP}_{32}(i)\,||\,\mathsf{c}\,||\,\mathsf{sk}\) + \(\mathsf{I2LEOSP}_{8}(depth)\,||\,parent\_fvk\_tag\,||\,\mathsf{I2LEOSP}_{32}(i)\,||\,\mathsf{c}\,||\,\mathsf{sk}\!\) .

      For the master extended spending key, \(depth\) is - \(0\) + \(0\!\) , \(parent\_fvk\_tag\) is 4 zero bytes, and \(i\) is - \(0\) + \(0\!\) .

      When encoded as Bech32, the Human-Readable Part is secret-orchard-extsk-main for Mainnet, or secret-orchard-extsk-test for Testnet.

      We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users 21.

      @@ -1049,17 +1051,17 @@
    • the \(\mathsf{BLAKE2b}\text{-}\mathsf{512}\) personalization - \(\texttt{“ZcashIP32_Sprout”}\) + \(\texttt{“ZcashIP32\_Sprout”}\!\) , formerly specified for derivation of the master key of the Sprout tree;
    • the \(\mathsf{BLAKE2b}\text{-}\mathsf{256}\) personalization - \(\texttt{“Zcash_Sprout_AFP”}\) + \(\texttt{“Zcash\_Sprout\_AFP”}\!\) , formerly specified for generation of Sprout address fingerprints;
    • the \(\mathsf{PRF^{expand}}\) prefix - \(\texttt{0x80}\) + \(\mathtt{0x80}\!\) , formerly specified for Sprout child key derivation;
    • the Bech32 Human-Readable Parts zxsprout and zxtestsprout, formerly specified for Sprout extended spending keys on Mainnet and Testnet respectively.
    diff --git a/rendered/zip-0203.html b/rendered/zip-0203.html index 074d62c7d..00725073f 100644 --- a/rendered/zip-0203.html +++ b/rendered/zip-0203.html @@ -3,7 +3,9 @@ ZIP 203: Transaction Expiry - + + +
    diff --git a/rendered/zip-0207.html b/rendered/zip-0207.html index 6be0e0d5d..1bdcb8c90 100644 --- a/rendered/zip-0207.html +++ b/rendered/zip-0207.html @@ -3,7 +3,9 @@ ZIP 207: Funding Streams - + + +
    diff --git a/rendered/zip-0212.html b/rendered/zip-0212.html index 2c755bc84..846588b62 100644 --- a/rendered/zip-0212.html +++ b/rendered/zip-0212.html @@ -3,7 +3,9 @@ ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext - + + +
    diff --git a/rendered/zip-0215.html b/rendered/zip-0215.html index 4fe952bc9..89e0fe865 100644 --- a/rendered/zip-0215.html +++ b/rendered/zip-0215.html @@ -3,7 +3,9 @@ ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules - + + +
    diff --git a/rendered/zip-0216.html b/rendered/zip-0216.html index 52bc7adab..18831100d 100644 --- a/rendered/zip-0216.html +++ b/rendered/zip-0216.html @@ -3,7 +3,9 @@ ZIP 216: Require Canonical Jubjub Point Encodings - + + +
    diff --git a/rendered/zip-0221.html b/rendered/zip-0221.html index a4e119e7b..57bd407e3 100644 --- a/rendered/zip-0221.html +++ b/rendered/zip-0221.html @@ -3,7 +3,9 @@ ZIP 221: FlyClient - Consensus-Layer Changes - + + +
    diff --git a/rendered/zip-0224.html b/rendered/zip-0224.html index 211d87e21..48d123a0c 100644 --- a/rendered/zip-0224.html +++ b/rendered/zip-0224.html @@ -3,7 +3,9 @@ ZIP 224: Orchard Shielded Protocol - + + +
    diff --git a/rendered/zip-0225.html b/rendered/zip-0225.html index 1ab6b9415..91ac9fc3a 100644 --- a/rendered/zip-0225.html +++ b/rendered/zip-0225.html @@ -3,7 +3,9 @@ ZIP 225: Version 5 Transaction Format - + + +
    @@ -333,7 +335,9 @@ 32 cmu byte[32] - The u-coordinate of the note commitment for the output note. + The + \(u\!\) + -coordinate of the note commitment for the output note. 32 @@ -390,13 +394,15 @@ 32 cmx byte[32] - The x-coordinate of the note commitment for the output note. + The + \(x\!\) + -coordinate of the note commitment for the output note. 32 ephemeralKey byte[32] - An encoding of an ephemeral Pallas public key + An encoding of an ephemeral Pallas public key. 580 diff --git a/rendered/zip-0226.html b/rendered/zip-0226.html index 7482eed04..5a33d14e5 100644 --- a/rendered/zip-0226.html +++ b/rendered/zip-0226.html @@ -3,7 +3,9 @@ ZIP 226: Transfer and Burn of Zcash Shielded Assets - + + +
    diff --git a/rendered/zip-0227.html b/rendered/zip-0227.html index 1231e710a..9a3a9de67 100644 --- a/rendered/zip-0227.html +++ b/rendered/zip-0227.html @@ -3,7 +3,9 @@ ZIP 227: Issuance of Zcash Shielded Assets - + + +
    @@ -144,7 +146,7 @@

    We use hardened-only child key derivation as defined in ZIP 32 4 for the issuance authorizing key.

    \(\mathsf{CKDsk}((\mathsf{sk}_{par},\mathsf{c}_{par}), i) \rightarrow (\mathsf{sk}_{i}, \mathsf{c}_{i})\) -

    + :

    • Return \(\mathsf{CKDh}^{\mathsf{Issuance}}((\mathsf{sk}_{par},\mathsf{c}_{par}), i)\!\) diff --git a/rendered/zip-0230.html b/rendered/zip-0230.html index 53ec3ae06..b086cc137 100644 --- a/rendered/zip-0230.html +++ b/rendered/zip-0230.html @@ -3,7 +3,9 @@ ZIP 230: Version 6 Transaction Format - + + +
      diff --git a/rendered/zip-0231.html b/rendered/zip-0231.html index 1fc75b6b6..208c1eed2 100644 --- a/rendered/zip-0231.html +++ b/rendered/zip-0231.html @@ -3,7 +3,9 @@ ZIP 231: Memo Bundles - + + + @@ -130,53 +132,54 @@

      Memo bundle

      Memo encryption

      During transaction construction, each output with memo data is assigned a 32-byte memo key Kmemo. These keys SHOULD be +class="math inline">\(\mathsf{K^{memo}}\). These keys SHOULD be generated randomly, and MUST NOT be used to encrypt more than one memo within a single transaction. If an output has no memo data, it is assigned the memo key consisting of 32 0xFF -bytes.

      +class="math inline">\(\mathtt{0xFF}\) bytes.

      In note plaintexts of v6-onward transactions, the 512-byte memo field -is replaced by Kmemo .

      +is replaced by \(\mathsf{K^{memo}}\).

      The transaction builder generates a 32-byte salt value salt from a CSPRNG. A new salt MUST be -generated for each memo bundle.

      +class="math inline">\(\mathsf{salt}\) from a CSPRNG. A new salt +MUST be generated for each memo bundle.

      The symmetric encryption key for a memo is derived from its Kmemo as follows:

      -

         encryption_key = PRFKmemoexpand([0xE0] || salt)

      -

      The first byte 0xE0 +class="math inline">\(\mathsf{K^{memo}}\) as follows:

      +

      \(\hspace{2em}\mathsf{encryption\_key} = +\mathsf{PRF^{expand}_{K^{memo}}}([\mathtt{0xE0}] \,||\, +\mathsf{salt})\)

      +

      The first byte \(\mathtt{0xE0}\) should be added to the documentation of inputs to PRFexpand in § 4.1.2 ‘Pseudo +class="math inline">\(\mathsf{PRF^{expand}}\) in § 4.1.2 ‘Pseudo Random Functions’ 7.

      If the generated key is 32 0xFF -bytes, the transaction constructor MAY repeat this procedure with a -different salt, in order to avoid the recipient misinterpreting the -output as having no memo data. Since that has negligible probability, it -alternatively MAY omit this check.

      +class="math inline">\(\mathtt{0xFF}\) bytes, the transaction +constructor MAY repeat this procedure with a different salt, in order to +avoid the recipient misinterpreting the output as having no memo data. +Since that has negligible probability, it alternatively MAY omit this +check.

      Each memo is padded to a multiple of 256 bytes with zeroes, and split into 256-byte chunks. Each memo chunk is encrypted with ChaCha20Poly1305 8 as follows:

         IETF_AEAD_CHACHA20_POLY1305(encryption_key, nonce, memo_chunk)

      -

      where nonce = I2BEOSP88(counter) || [final_chunk] .

      +class="math inline">\(\hspace{2em}\mathsf{IETF\_AEAD\_CHACHA20\_POLY1305}(\mathsf{encryption\_key}, +\mathsf{nonce}, \mathsf{memo\_chunk})\)

      +

      where \(\mathsf{nonce} = +\mathsf{I2BEOSP}_{88}(\mathsf{counter}) \,||\, +[\mathsf{final\_chunk}]\).

      This is a variant of the STREAM construction 9.

        -
      • counter is a big-endian chunk -counter starting at zero and incrementing by one for each subsequent -chunk within a particular memo.
        • -
      • final_chunk is the byte 0x01 -for the final memo chunk, and 0x00 -for all preceding chunks.
        • +
      • \(\mathsf{counter}\) is a +big-endian chunk counter starting at zero and incrementing by one for +each subsequent chunk within a particular memo.
        • +
      • \(\mathsf{final\_chunk}\) is the +byte \(\mathtt{0x01}\) for the final +memo chunk, and \(\mathtt{0x00}\) for +all preceding chunks.

      Finally, the encrypted memo chunks for all memos are combined into a single sequence using an order-preserving shuffle. Memo chunks from @@ -193,8 +196,9 @@

      Memo encryption

      ]

      Memo decryption

      When a recipient decrypts a shielded output, they obtain a memo key -Kmemo. From this they derive -encryption_key as above, and then proceed as follows:

      +\(\mathsf{K^{memo}}\). From this they +derive encryption_key as above, and then proceed as +follows:

      • Set counter = 0 and final_chunk = 0x00.
        • @@ -231,7 +235,7 @@

        Encoding in transactions

        - + Bytes Name Data Type @@ -239,33 +243,33 @@

        Encoding in transactions

        - + 1 fAllPruned uint8 1 if all chunks have been pruned, otherwise 0. - + 32 nonceOrHash byte[32] The nonce for deriving encryption keys, or the overall hash. - + † varies nMemoChunks compactSize The number of memo chunks. - + † varies pruned byte[ceiling(nMemoChunks/8)] +class="math inline">\(\mathsf{ceiling}(\mathtt{nMemoChunks}/8)\)] Bitflags indicating the type of each entry in vMemoChunks. - + † varies vMemoChunks MemoChunk[nMemoChunks] @@ -322,10 +326,11 @@

        Changes to the

      • Change

        Each Sapling or Orchard note plaintext (denoted np) -consists of

        -

           (leadByte ⦂ 𝔹𝕐, d ⦂ 𝔹[ℓd], rseed ⦂ 𝔹𝕐[𝟛𝟚], memo ⦂ 𝔹𝕐[𝟝𝟙𝟚])

        +class="math inline">\(\mathbf{np}\)) consists of

        +

        \(\hspace{2em}(\mathsf{leadByte} \;⦂\; +\mathbb{B^{Y}}, \mathsf{d} \;⦂\; \mathbb{B^{[\ell_{\mathsf{d}}]}}, +\mathsf{rseed} \;⦂\; \mathbb{B^{Y[32]}}, \mathsf{memo} \;⦂\; +\mathbb{B^{Y[512]}})\)

        to

        @@ -333,15 +338,17 @@

        Changes to the version of the transaction in which it will be included; specifically whether that version is pre-v6, or v6-onward.

        Each pre-v6 Sapling or Orchard note plaintext (denoted np) -consists of

        -

           (leadByte ⦂ 𝔹𝕐, d ⦂ 𝔹[ℓd], rseed ⦂ 𝔹𝕐[𝟛𝟚], memo ⦂ 𝔹𝕐[𝟝𝟙𝟚])

        +class="math inline">\(\mathbf{np}\)) consists of

        +

        \(\hspace{2em}(\mathsf{leadByte} \;⦂\; +\mathbb{B^{Y}}, \mathsf{d} \;⦂\; \mathbb{B^{[\ell_{\mathsf{d}}]}}, +\mathsf{rseed} \;⦂\; \mathbb{B^{Y[32]}}, \mathsf{memo} \;⦂\; +\mathbb{B^{Y[512]}})\)

        Each v6-onward Sapling or Orchard note plaintext (denoted np) -consists of

        -

           (leadByte ⦂ 𝔹𝕐, d ⦂ 𝔹[ℓd], rseed ⦂ 𝔹𝕐[𝟛𝟚], Kmemo ⦂ 𝔹𝕐[𝟛𝟚])

        +class="math inline">\(\mathbf{np}\)) consists of

        +

        \(\hspace{2em}(\mathsf{leadByte} \;⦂\; +\mathbb{B^{Y}}, \mathsf{d} \;⦂\; \mathbb{B^{[\ell_{\mathsf{d}}]}}, +\mathsf{rseed} \;⦂\; \mathbb{B^{Y[32]}}, \mathsf{K^{memo}} \;⦂\; +\mathbb{B^{Y[32]}})\)

      In § 5.5 ‘Encodings of Note Plaintexts and Memo Fields’ Changes to the - -8-bit leadByte -88-bit d -64-bit v -256-bit rseed -32-byte Kmemo + +8-bit \(\mathsf{leadByte}\) +88-bit \(\mathsf{d}\) +64-bit \(\mathsf{v}\) +256-bit \(\mathsf{rseed}\) +32-byte \(\mathsf{K^{memo}}\)

      A value consisting of 32 0xFF -bytes for Kmemo is used to -indicate that there is no memo for this note plaintext.

      +class="math inline">\(\mathtt{0xFF}\) bytes for \(\mathsf{K^{memo}}\) is used to indicate +that there is no memo for this note plaintext.

    In § 4.7.2 ‘Sending Notes (Sapling)’ Changes to the

    @@ -423,28 +433,26 @@

    Changes to the

    • Change

      -

      Let np = (leadByte, d, v, rseed, memo) -be the Sapling or Orchard note plaintext. np is -encoded as defined in § 5.5 ‘Encodings of Note Plaintexts and Memo -Fields’.

      +

      Let \(\mathbf{np} = (\mathsf{leadByte}, +\mathsf{d}, \mathsf{v}, \mathsf{rseed}, \mathsf{memo})\) be the +Sapling or Orchard note plaintext. \(\mathbf{np}\) is encoded as defined in § +5.5 ‘Encodings of Note Plaintexts and Memo Fields’.

      to

      -

      Let np be the -encoding of the Sapling or Orchard note plaintext (which may be pre-v6 -or v6-onward), as defined in § 5.5 ‘Encodings of Note Plaintexts and -Memo Fields’.

      +

      Let \(\mathbf{np}\) be the encoding +of the Sapling or Orchard note plaintext (which may be pre-v6 or +v6-onward), as defined in § 5.5 ‘Encodings of Note Plaintexts and Memo +Fields’.

    • Add another normative note to that section:

        -
      • Cenc will be of length -either 580 or 100 bytes, depending on whether np is a -pre-v6 or v6-onward note plaintext.
        • +
      • \(\mathsf{C^{enc}}\) will be of +length either 580 or 100 bytes, depending on whether \(\mathbf{np}\) is a pre-v6 or v6-onward note +plaintext.
    @@ -455,15 +463,17 @@

    Changes to the class="footnote-ref" id="fnref16" role="doc-noteref">16:

      -
    • Replace memo ⦂ 𝔹𝕐[𝟝𝟙𝟚] -with memoOrKey.
      • -
    • Specify that the type of memoOrKey -is 𝔹𝕐[𝟝𝟙𝟚] when decrypting a +
    • Replace \(\mathsf{memo} \;⦂\; +\mathbb{B^{Y[512]}}\) with \(\mathsf{memoOrKey}\).
      • +
    • Specify that the type of \(\mathsf{memoOrKey}\) is \(\mathbb{B^{Y[512]}}\) when decrypting a pre-v6 note ciphertext, or 𝔹𝕐[𝟛𝟚] when decrypting a v6-onward -note ciphertext. In the latter case, it is used as Kmemo to decrypt the memo bundle -as described in Memo bundle.
      • +class="math inline">\(\mathbb{B^{Y[32]}}\) when decrypting a +v6-onward note ciphertext. In the latter case, it is used as \(\mathsf{K^{memo}}\) to decrypt the memo +bundle as described in Memo bundle.

    Applicability

    All of these changes apply identically to Mainnet and Testnet.

    @@ -494,39 +504,29 @@

    Memo chunk size

    is:

    - - - - + + + + - - - - - - - - - - - + - + - + - + @@ -544,39 +544,29 @@

    Memo key size

    size overhead becomes:

    Memo size
    Chunk sizeMemo size ≤ 256 bytesMemo size = 512 bytes
    Chunk size≤ 256 bytes512 bytes
    ========================================================
    Pre-231 20 @ 10240 ( 0.00%) 20 @ 10240 ( 0.00%)
    512 20 @ 11220 (+ 9.57%) 20 @ 11220 (+ 9.57%)
    256 40 @ 12200 (+19.14%) 20 @ 11540 (+12.70%)
    256 20-out 20 @ 6100 (-40.43%)
    - - - - + + + + - - - - - - - - - - - + - + - + - + @@ -596,21 +586,22 @@

    Memo key size

    keys.

    Encryption format

    -

    Including a per-transaction salt in -the derivation of encryptionkey gives protection +

    Including a per-transaction \(\mathsf{salt}\) in the derivation of \(\mathsf{encryption_key}\) gives protection against accidental (or intentional) reuse of Kmemo reuse across multiple +class="math inline">\(\mathsf{K^{memo}}\) reuse across multiple transactions. We do not protect against Kmemo reuse within a transaction; -it is up to the transaction builder to ensure that the same Kmemo is not used to encrypt two -different memos (and if they did so, normal clients would either never -observe the second memo, or would decrypt parts of each memo and get a -nonsensical and potentially insecure “spliced” memo).

    +class="math inline">\(\mathsf{K^{memo}}\) reuse within a +transaction; it is up to the transaction builder to ensure that the same +\(\mathsf{K^{memo}}\) is not used to +encrypt two different memos (and if they did so, normal clients would +either never observe the second memo, or would decrypt parts of each +memo and get a nonsensical and potentially insecure “spliced” memo).

    We do not include commitments to the shielded outputs in the -derivation of encryptionkey -for two reasons:

    +derivation of \(\mathsf{encryption_key}\) for two +reasons:

    • It would force the transaction builder to fully define all shielded outputs before encrypting the memos, which might prevent potential use @@ -620,7 +611,7 @@

      Encryption format

      transaction with a memo bundle and no shielded outputs, as there may be use cases for, e.g. a fully-transparent transaction with encrypted memo, or a ZSA issuance transaction with exposed memo data using a well-known -Kmemo.
      • +\(\mathsf{K^{memo}}\).

    Pruned encoding

    The separation of memo data from note data, and the new ability to diff --git a/rendered/zip-0233.html b/rendered/zip-0233.html index 0c1b530e9..4f8188360 100644 --- a/rendered/zip-0233.html +++ b/rendered/zip-0233.html @@ -3,7 +3,9 @@ ZIP 233: Network Sustainability Mechanism: Burning - + + + @@ -45,8 +47,8 @@

    Terminology

    conflict between this and issuance as defined in ZIP 227.]

    “Burning” - The method by which ZEC/TAZ becomes unavailable for circulation on the network.

    -

    MAX_MONEY, as defined in § 5.3 -‘Constants’ \(\mathsf{MAX\_MONEY}\), as defined +in § 5.3 ‘Constants’ 5, is the total ZEC/TAZ supply cap measured in zatoshi, corresponding to 21,000,000 ZEC. This is slightly larger than the supply cap for the current issuance mechanism, but is @@ -66,9 +68,10 @@

    Motivation

    1. Long Term Consensus Sustainability: By enabling the burning of funds, the network gains the ability to create “headroom” -between the chain value and MAX_MONEY. -This lays necessary groundwork for extending the block subsidy system, -which currently has a clear final end date.
      2. +between the chain value and \(\mathsf{MAX\_MONEY}\). This lays necessary +groundwork for extending the block subsidy system, which currently has a +clear final end date.
    2. Benefits to ZEC Holders: Burning funds reduces the supply of ZEC, benefiting network users in proportion to their holdings without requiring them to opt into any scheme, introducing extra risk, @@ -76,19 +79,21 @@

      Motivation

    Specification

    Burn amount

    -

    Each transaction gains a burn_amount -property, specifying the value in zatoshis that is burned when the -transaction is mined. The burned value subtracts from the remaining -value in the “transparent transaction value pool” as described in § 3.4 -‘Transactions and Treestates’ 8.

    -

    burn_amount does not result in an -output being produced in any chain value pool, and therefore from the -point at which the transaction is applied to the global chain state, -burn_amount is subtracted from the -issued supply. It is unavailable for circulation on the network at least -through to the end of the block in which the transaction is mined. ZIP -234 Each transaction gains a \(\mathsf{burn\_amount}\) property, +specifying the value in zatoshis that is burned when the transaction is +mined. The burned value subtracts from the remaining value in the +“transparent transaction value pool” as described in § 3.4 ‘Transactions +and Treestates’ 8.

    +

    \(\mathsf{burn\_amount}\) does not +result in an output being produced in any chain value pool, and +therefore from the point at which the transaction is applied to the +global chain state, \(\mathsf{burn\_amount}\) is subtracted from +the issued supply. It is unavailable for circulation on the network at +least through to the end of the block in which the transaction is mined. +ZIP 234 9 specifies a potential mechanism by which the burned funds would again become available.

    Changes to ZIP 230 Changes to ZIP 230

    - + @@ -114,7 +119,7 @@

    Changes to ZIP 230

    - + @@ -122,9 +127,9 @@

    Changes to ZIP 230

    Memo size
    Chunk sizeMemo size ≤ 256 bytesMemo size = 512 bytes
    Chunk size≤ 256 bytes512 bytes
    ========================================================
    Pre-231 20 @ 10240 ( 0.00%) 20 @ 10240 ( 0.00%)
    512 20 @ 10900 (+ 6.45%) 20 @ 10900 (+ 6.45%)
    256 40 @ 11560 (+12.89%) 20 @ 11220 (+ 9.57%)
    256 20-out 20 @ 5780 (-43.55%)
    Bytes Name Data Type
    8 burnAmount uint64
    -

    The burn_amount of a transaction is -defined to be the value of the burnAmount field if present, -and otherwise 0.

    +

    The \(\mathsf{burn\_amount}\) of a +transaction is defined to be the value of the burnAmount +field if present, and otherwise 0.

    Notes:

    • If both this ZIP and ZIP 2002 are selected for inclusion in the same @@ -145,17 +150,19 @@

      Changes to the class="footnote-ref" id="fnref13" role="doc-noteref">13, add:

      -

      [NU7 onward] burn_amount MUST be in -the range {0..MAX_MONEY}.

      +

      [NU7 onward] \(\mathsf{burn\_amount}\) MUST be in the +range \(\{ 0 .. \mathsf{MAX\_MONEY} +\}\).

      Modifications relative to ZIP 244 14

      Relative to the sighash algorithm defined in ZIP 244, the sighash algorithm that applies to v6 transactions differs by appending the -encoding of burn_amount to the Common -Transaction Fields that are the input to the digest in T.1: -header_digest \(\mathsf{burn\_amount}\) +to the Common Transaction Fields that are the input to the digest in +T.1: header_digest 15:

      T.1f: burn_amount (8-byte little-endian burn amount)
      diff --git a/rendered/zip-0234.html b/rendered/zip-0234.html index 35ada1278..fac4f75ae 100644 --- a/rendered/zip-0234.html +++ b/rendered/zip-0234.html @@ -3,7 +3,9 @@ ZIP 234: Network Sustainability Mechanism: Issuance Smoothing - + + + @@ -35,7 +37,7 @@

      Terminology

      The terms “Mainnet” and “Testnet” are to be interpreted as described in § 3.12 ‘Mainnet and Testnet’. 4

      -

      The symbol “ ⋅ ” means +

      The symbol “\(\,\cdot\,\)” means multiplication, as described in § 2 ‘Notation’. 5

      “ZEC/TAZ” refers to the native currency of Zcash on a given network, @@ -43,11 +45,12 @@

      Terminology

      The terms “Block Subsidy”, “Issuance”, and “Burning” are to be interpreted as described in ZIP 233. 6

      -

      Let PostBlossomHalvingInterval be as +

      Let \(\mathsf{PostBlossomHalvingInterval}\) be as defined in 7.

      -

      MAX_MONEY, as defined in § 5.3 -‘Constants’ \(\mathsf{MAX\_MONEY}\), as defined +in § 5.3 ‘Constants’ 8, is the total ZEC/TAZ supply cap measured in zatoshi, corresponding to 21,000,000 ZEC. This is slightly larger than the supply cap for the current issuance mechanism, but is @@ -55,13 +58,13 @@

      Terminology

      “Issued Supply” - The Issued Supply at a given height of a block chain is the total ZEC/TAZ value in all chain value pool balances at that height, as calculated by IssuedSupply(height) defined in § 4.17 ‘Chain -Value Pool Balances’. 9

      +class="math inline">\(\mathsf{IssuedSupply}(\mathsf{height})\) +defined in § 4.17 ‘Chain Value Pool Balances’. 9

      “Money Reserve” - The Money Reserve at a given height of a block chain is the total ZEC/TAZ value remaining to be issued, as calculated -by MAX_MONEY − IssuedSupply(height) .

      +by \(\mathsf{MAX\_MONEY} - +\mathsf{IssuedSupply}(\mathsf{height})\).

      Abstract

      This ZIP proposes a change to how nodes calculate the block subsidy.

      @@ -123,9 +126,10 @@

      Requirements

      Specification

      Parameters

      -

      BLOCK_SUBSIDY_FRACTION = 4126/10_000_000_000 = 0.0000004126

      -

      DEPLOYMENT_BLOCK_HEIGHT = TBD

      +

      \(\mathsf{BLOCK\_SUBSIDY\_FRACTION} = 4126 +/ 10\_000\_000\_000 = 0.0000004126\)

      +

      \(\mathsf{DEPLOYMENT\_BLOCK\_HEIGHT} = +\mathsf{TBD}\)

      The block height will be chosen by the following criteria:

      • It is after NU7 activation height.
        • @@ -146,26 +150,30 @@

        Parameters

        calculated up-front). This means with the pre-defined constant parameter approach, issuance will jump up some amount at activation. This amount should be equivalent to all ZEC burnt prior to that height times -BLOCK_SUBSIDY_FRACTION. +\(\mathsf{BLOCK\_SUBSIDY\_FRACTION}\). For example, if a total of 100,000 ZEC were burnt prior to the pre-defined constant activation height, then at activation the issuance would be larger than BTC-style issuance by 100_000 -ZEC ⋅ BLOCK_SUBSIDY_FRACTION , -which we calculate equals 0.04126 ZEC. -This example is chosen to demonstrate that a very large burn amount -(much larger than expected) would elevate issuance by a relatively small -amount. For this reason, we believe a pre-defined constant is a better -approach to achieving Key Objective 6 than a “dynamic latch” logic -because it is so much simpler to implement and reason about.

        -

        MoneyReserveAfter(height)  = The -value of the Money Reserve after the specified block height.

        -

        Issuance Calculation

        -

        At the DEPLOYMENT_BLOCK_HEIGHT, nodes should switch from -the current issuance calculation, to the following:

        +class="math inline">\(100\_000\textsf{ ZEC} \cdot +\mathsf{BLOCK\_SUBSIDY\_FRACTION}\), which we calculate equals +\(0.04126\) ZEC. This example is chosen +to demonstrate that a very large burn amount (much larger than expected) +would elevate issuance by a relatively small amount. For this reason, we +believe a pre-defined constant is a better approach to achieving Key +Objective 6 than a “dynamic latch” logic because it is so much simpler +to implement and reason about.

        BlockSubsidy(height) = ceiling(BLOCK_SUBSIDY_FRACTION ⋅ MoneyReserveAfter(height − 1))

        +class="math inline">\(\mathsf{MoneyReserveAfter}(\mathsf{height}) +=\) The value of the Money Reserve after the specified block +height.

        +

        Issuance Calculation

        +

        At the \(\mathsf{DEPLOYMENT\_BLOCK\_HEIGHT}\), nodes +should switch from the current issuance calculation, to the +following:

        +

        \(\mathsf{BlockSubsidy}(\mathsf{height}) = +\mathsf{ceiling}(\mathsf{BLOCK\_SUBSIDY\_FRACTION} \cdot +\mathsf{MoneyReserveAfter}(\mathsf{height} - 1))\)

        Applicability

        All of these changes apply identically to Mainnet and Testnet.

        Rationale

        @@ -177,20 +185,24 @@

        Rationale

      BLOCK_SUBSIDY_FRACTION

      Let IntendedMoneyReserveFractionRemainingAfterFourYears = 0.5 .

      -

      The value 4126/10_000_000_000 -satisfies the approximation within ±0.002%:

      -

      (1 − BLOCK_SUBSIDY_FRACTION)PostBlossomHalvingInterval ≈ IntendedMoneyReserveFractionRemainingAfterFourYears

      +class="math inline">\(\mathsf{IntendedMoneyReserveFractionRemainingAfterFourYears} += 0.5\).

      +

      The value \(4126 / +10\_000\_000\_000\) satisfies the approximation within \(\pm 0.002\%\):

      +

      \((1 - +\mathsf{BLOCK\_SUBSIDY\_FRACTION})^\mathsf{PostBlossomHalvingInterval} +\approx +\mathsf{IntendedMoneyReserveFractionRemainingAfterFourYears}\)

      This implies that after a period of 4 years around half of Money Reserve will have been issued as block subsidies, thus satisfying Requirement 4.

      The largest possible value in the Money Reserve is MAX_MONEY, in the theoretically possible case -that all issued funds are burned. If this happened, the largest interim -sum in the block subsidy calculation would be MAX_MONEY ⋅ 4126/10_000_000_000 .

      +class="math inline">\(\mathsf{MAX\_MONEY}\), in the theoretically +possible case that all issued funds are burned. If this happened, the +largest interim sum in the block subsidy calculation would be \(\mathsf{MAX\_MONEY} \cdot 4126 / +10\_000\_000\_000\).

      This uses 62.91 bits, which is just under the 63-bit limit for signed two’s complement 64-bit integer amount types.

      The numerator could be brought closer to the limit by using a larger diff --git a/rendered/zip-0235.html b/rendered/zip-0235.html index 4b2213bf9..07a86bd7d 100644 --- a/rendered/zip-0235.html +++ b/rendered/zip-0235.html @@ -3,7 +3,9 @@ ZIP 235: Burn 60% of Transaction Fees - + + + @@ -35,23 +37,24 @@

      Terminology

      The terms “Mainnet” and “Testnet” are to be interpreted as described in § 3.12 ‘Mainnet and Testnet’. 4

      -

      The symbol “ ⋅ ” means -multiplication, as described in § 2 ‘Notation’. [^protocol-notation]

      +

      The symbol “\(\,\cdot\,\)” means +multiplication, as described in § 2 ‘Notation’. 5

      “ZEC/TAZ” refers to the native currency of Zcash on a given network, i.e. ZEC on Mainnet and TAZ on Testnet.

      The terms “Block Subsidy”, “Issuance”, and “Burning” are to be -interpreted as described in ZIP 233. 5

      +interpreted as described in ZIP 233. 6

      Abstract

      This ZIP proposes to burn 60% of transaction fees, while the remaining 40% is directed as before, providing a deflationary effect, and building the groundwork for long-term support of the Zcash network -via the new block subsidy rules proposed by ZIP 234 6.

      +via the new block subsidy rules proposed by ZIP 234 7.

      Motivation

      -

      ZIP 233 (“Network Sustainability Mechanism: Burning” 7) +

      ZIP 233 (“Network Sustainability Mechanism: Burning” 8) describes a method by which ZEC can be burned to support network sustainability.

      By introducing a requirement that a certain proportion of transaction @@ -62,8 +65,8 @@

      Benefits to the Network

      1. Network Sustainability: This mechanism involves temporarily reducing the supply of ZEC, similar to asset burning in -Ethereum’s EIP-1559 8, but with long-term sustainability +Ethereum’s EIP-1559 9, but with long-term sustainability benefits, as the burned funds effectively boost future mining rewards, making it an attractive option for current and future Zcash users.
      2. Incentivizing Transaction Inclusion: By maintaining @@ -98,13 +101,14 @@

        Requirements

        Specification

        Consensus Rule Changes

        For a given block, the coinbase transaction MUST have a burn_amount, as defined in 9, -that is greater than or equal to floor(transactionFees ⋅ 6/10) .

        -

        The version of a coinbase transaction MUST be v6 or later \(\mathsf{burn\_amount}\), as defined in 10.

        +role="doc-noteref">10, that is greater than or equal to +\(\mathsf{floor}(\mathsf{transactionFees} +\cdot 6 / 10)\).

        +

        The version of a coinbase transaction MUST be v6 or later 11.

        Applicability

        All of these changes apply identically to Mainnet and Testnet.

        Rationale

        @@ -117,28 +121,29 @@

        Rationale

        for requiring the coinbase transaction to be v6 or later

        There is no explicit mechanism in prior transaction versions to burn the required funds. Since burn_amount = 0 for transaction versions -prior to v6, absent the rule about the coinbase transaction version it -would be technically possible to satisfy the constraint on burn_amount with earlier versions than v6, -but only when transactionFees = 0. That -would introduce a corner case in the transaction consensus rules that is -not useful, since it is expected that the transactionFees will normally be +class="math inline">\(\mathsf{burn\_amount} = 0\) for transaction +versions prior to v6, absent the rule about the coinbase transaction +version it would be technically possible to satisfy the constraint on +\(\mathsf{burn\_amount}\) with earlier +versions than v6, but only when \(\mathsf{transactionFees} = 0\). That would +introduce a corner case in the transaction consensus rules that is not +useful, since it is expected that the \(\mathsf{transactionFees}\) will normally be non-zero.

        Estimated impact on miners

        Over 100,000 blocks starting at block 2235515, there were 316130 transactions. 60608 of them are categorized as ‘sandblasting’ transactions. The remaining transactions have an average of 5.46 logical -actions (see ZIP 317 11).

        +actions (see ZIP 317 12).

        The total fees paid to miners from those transactions, assuming the ZIP 317 regime, would be 87.86 ZEC. 100,000 blocks is approximately 3 months of blocks. Extrapolating to a year, we would expect 351.44 ZEC in fees paid to miners over a year.

        If 60% of these fees burned, that would be 210.864 ZEC per year. 12

        +href="#fn13" class="footnote-ref" id="fnref13" +role="doc-noteref">13

        Considerations for the Future

        If transaction fees were to increase, further modifications can @@ -161,10 +166,10 @@

        Considerations for the

    Deployment

    The implementation of this ZIP MUST be deployed at the same time or -after ZIP 233 (“NSM: Burning” 13), and ZIP 234 (“NSM: -Issuance Smoothing” 14).

    +after ZIP 233 (“NSM: Burning” 14), and ZIP 234 (“NSM: +Issuance Smoothing” 15).

    References

    @@ -186,37 +191,40 @@

    References

    Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet↩︎

    -

  • ZIP 233: Network Sustainability -Mechanism: Burning

    Zcash Protocol +Specification, Version 2024.5.1 [NU6]. Section 2: Notation↩︎

    • +

  • ZIP 233: Network Sustainability +Mechanism: Burning↩︎

    • -

  • ZIP 234: Network Sustainability -Mechanism: Issuance Smoothing

    ZIP 234: Network Sustainability +Mechanism: Issuance Smoothing↩︎

    • -

  • ZIP 233: Network Sustainability -Mechanism: Burning

    ZIP 233: Network Sustainability +Mechanism: Burning↩︎

    • -

  • EIP-1559: Fee market -change for ETH 1.0 chain↩︎

    • -

  • ZIP 233: Network Sustainability -Mechanism: Burning

    ZIP 233: Network Sustainability +Mechanism: Burning↩︎

    • -

  • ZIP 230: Version 6 Transaction -Format

    ZIP 230: Version 6 Transaction +Format↩︎

    • -

  • ZIP 317: Proportional Transfer -Fee Mechanism

    ZIP 317: Proportional Transfer +Fee Mechanism↩︎

    • -

  • GitHub repository -eigerco/zsf-fee-estimator↩︎

    • -

  • ZIP 233: Network Sustainability -Mechanism: Burning

    ZIP 233: Network Sustainability +Mechanism: Burning↩︎

    • -

  • ZIP 234: Network Sustainability -Mechanism: Issuance Smoothing

    ZIP 234: Network Sustainability +Mechanism: Issuance Smoothing↩︎

    • diff --git a/rendered/zip-0244.html b/rendered/zip-0244.html index e607a6d65..2205c7445 100644 --- a/rendered/zip-0244.html +++ b/rendered/zip-0244.html @@ -3,7 +3,9 @@ ZIP 244: Transaction Identifier Non-Malleability - + + +
    diff --git a/rendered/zip-0253.html b/rendered/zip-0253.html index 6aff55a18..49a248e2f 100644 --- a/rendered/zip-0253.html +++ b/rendered/zip-0253.html @@ -3,7 +3,6 @@ ZIP 253: Deployment of the NU6 Network Upgrade - diff --git a/rendered/zip-0254.html b/rendered/zip-0254.html index 072b4ac87..4a7091e92 100644 --- a/rendered/zip-0254.html +++ b/rendered/zip-0254.html @@ -3,7 +3,6 @@ ZIP 254: Deployment of the NU7 Network Upgrade - diff --git a/rendered/zip-0304.html b/rendered/zip-0304.html index 453038ad0..0d5494607 100644 --- a/rendered/zip-0304.html +++ b/rendered/zip-0304.html @@ -3,7 +3,9 @@ ZIP 304: Sapling Address Signatures - + + +
    diff --git a/rendered/zip-0307.html b/rendered/zip-0307.html index 07a72407c..e7c1cdd9c 100644 --- a/rendered/zip-0307.html +++ b/rendered/zip-0307.html @@ -3,7 +3,9 @@ ZIP 307: Light Client Protocol for Payment Detection - + + +
    diff --git a/rendered/zip-0311.html b/rendered/zip-0311.html index cfec0a94b..08c2a0cdb 100644 --- a/rendered/zip-0311.html +++ b/rendered/zip-0311.html @@ -3,7 +3,9 @@ ZIP 311: Zcash Payment Disclosures - + + +
    diff --git a/rendered/zip-0312.html b/rendered/zip-0312.html index f69ad06eb..3a80ba5bf 100644 --- a/rendered/zip-0312.html +++ b/rendered/zip-0312.html @@ -3,7 +3,9 @@ ZIP 312: FROST for Spend Authorization Multisignatures - + + +
    diff --git a/rendered/zip-0316.html b/rendered/zip-0316.html index 856cf88cc..c7df2fd8a 100644 --- a/rendered/zip-0316.html +++ b/rendered/zip-0316.html @@ -3,7 +3,9 @@ ZIP 316: Unified Addresses and Unified Viewing Keys - + + +
    @@ -646,7 +648,7 @@

    We instantiate \(H_i(u)\) by - \(\mathsf{BLAKE2b‐}(8\ell_L)(\texttt{“UA_F4Jumble_H”} \,||\,\) + \(\mathsf{BLAKE2b‐}(8\ell_L)(\texttt{“UA\_F4Jumble\_H”} \,||\,\) \([i, 0, 0], u),\) with \(\ell_H = 64.\) @@ -656,7 +658,7 @@ as the first \(\ell_R\) bytes of the concatenation of - \([\mathsf{BLAKE2b‐}512(\texttt{“UA_F4Jumble_G”} \,||\, [i] \,||\,\) + \([\mathsf{BLAKE2b‐}512(\texttt{“UA\_F4Jumble\_G”} \,||\, [i] \,||\,\) \(\mathsf{I2LEOSP}_{16}(j), u) \text{ for } j \text{ from}\) \(0 \text{ up to } \mathsf{ceiling}(\ell_R/\ell_H)-1].\)

    diff --git a/rendered/zip-0317.html b/rendered/zip-0317.html index bf2e70936..b8abefbf9 100644 --- a/rendered/zip-0317.html +++ b/rendered/zip-0317.html @@ -3,7 +3,9 @@ ZIP 317: Proportional Transfer Fee Mechanism - + + +
    diff --git a/rendered/zip-0320.html b/rendered/zip-0320.html index 0094e0110..0205af596 100644 --- a/rendered/zip-0320.html +++ b/rendered/zip-0320.html @@ -3,7 +3,9 @@ ZIP 320: Defining an Address Type to which funds can only be sent from Transparent Addresses - + + +
    diff --git a/rendered/zip-0324.html b/rendered/zip-0324.html index 2816bce7c..47003b631 100644 --- a/rendered/zip-0324.html +++ b/rendered/zip-0324.html @@ -3,7 +3,9 @@ ZIP 324: URI-Encapsulated Payments - + + +
    diff --git a/rendered/zip-0401.html b/rendered/zip-0401.html index aaec293e4..4d93fed2c 100644 --- a/rendered/zip-0401.html +++ b/rendered/zip-0401.html @@ -3,7 +3,9 @@ ZIP 401: Addressing Mempool Denial-of-Service - + + +
    diff --git a/rendered/zip-1011.html b/rendered/zip-1011.html index e62e1debf..2aac65bcd 100644 --- a/rendered/zip-1011.html +++ b/rendered/zip-1011.html @@ -3,7 +3,9 @@ ZIP 1011: Decentralize the Dev Fee - + + +
    diff --git a/rendered/zip-2001.html b/rendered/zip-2001.html index 9ab6478b2..5e53fc9ff 100644 --- a/rendered/zip-2001.html +++ b/rendered/zip-2001.html @@ -3,7 +3,9 @@ ZIP 2001: Lockbox Funding Streams - + + +
    diff --git a/rendered/zip-2002.html b/rendered/zip-2002.html index 7a1d7978a..432473a26 100644 --- a/rendered/zip-2002.html +++ b/rendered/zip-2002.html @@ -3,7 +3,9 @@ ZIP 2002: Explicit Fees - + + +
    diff --git a/rendered/zip-2004.html b/rendered/zip-2004.html index a7dec2693..0d00899a4 100644 --- a/rendered/zip-2004.html +++ b/rendered/zip-2004.html @@ -3,7 +3,9 @@ ZIP 2004: Remove the dependency of consensus on note encryption - + + +
    diff --git a/rendered/zip-guide-markdown.html b/rendered/zip-guide-markdown.html index bd3f10743..dc34d5fdf 100644 --- a/rendered/zip-guide-markdown.html +++ b/rendered/zip-guide-markdown.html @@ -3,7 +3,9 @@ ZIP guide-markdown: {Something Short and To the Point} - + + + @@ -126,16 +128,16 @@

    Comparison of ZIPs to RFCs

    places where they are most relevant.

    Using mathematical notation

    -

    Embedded LaTeX x + y is allowed and -encouraged in ZIPs. The syntax for inline math is -“:math:latex -code`" in reStructuredText or "latexcode`” -in Markdown. The rendered HTML will use KaTeX 8, -which only supports a subset of LaTeX, so you will need to double-check -that the rendering is as intended.

    +

    Embedded LaTeX, e.g. \(x + y\) is +allowed and encouraged in ZIPs. The syntax for inline math is +“$latex code$” in either Markdown or (as a non-standard +extension) reStructuredText. This syntax does not work in tables for +reStructuredText; in that case use “:math:`latex code`” +instead.

    +

    The rendered HTML will use KaTeX 8, which only supports a +subset of LaTeX, so you will need to double-check that the rendering is +as intended.

    In general the conventions in the Zcash protocol specification SHOULD be followed. If you find this difficult, don’t worry too much about it in initial drafts; the ZIP editors will catch any inconsistencies in diff --git a/rendered/zip-guide.html b/rendered/zip-guide.html index ccc02ec80..840785f73 100644 --- a/rendered/zip-guide.html +++ b/rendered/zip-guide.html @@ -3,7 +3,9 @@ ZIP guide: {Something Short and To the Point} - + + +

    @@ -79,7 +81,10 @@

    Using mathematical notation

    Embedded \(\LaTeX\) - is allowed and encouraged in ZIPs. The syntax for inline math is ":math:`latex code`" in reStructuredText or "$latex code$" in Markdown. The rendered HTML will use KaTeX 6, which only supports a subset of + , e.g. + \(x + y\) + is allowed and encouraged in ZIPs. The syntax for inline math is "$latex code$" in either Markdown or (as a non-standard extension) reStructuredText. This syntax does not work in tables for reStructuredText; in that case use ":math:`latex code`" instead.

    +

    The rendered HTML will use KaTeX 6, which only supports a subset of \(\LaTeX\!\) , so you will need to double-check that the rendering is as intended.

    In general the conventions in the Zcash protocol specification SHOULD be followed. If you find this difficult, don't worry too much about it in initial drafts; the ZIP editors will catch any inconsistencies in review.