#Terminology

The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in BCP 14 [1] when, and only when, they appear in all capitals.

The character § is used when referring to sections of the Zcash Protocol Specification. [2]

The terms "Mainnet" and "Testnet" are to be interpreted as described in § 3.12 ‘Mainnet and Testnet’. [3]

"Jubjub" refers to the elliptic curve defined in § 5.4.9.3 ‘Jubjub’ [6].

A "Newly Allowed Sapling payment address" is a Sapling payment address that would have been invalid prior to the activation of this proposal; that is, it has a diversifier $𝖽$ for which $𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌{𝗁}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(d)=\perp$.

A "Newly Allowed Unified Address" is a Unified Address [20] that contains a Sapling Receiver corresponding to a Newly Allowed Sapling payment address.

A "Newly Allowed Address" is either a Newly Allowed Sapling payment address or a Newly Allowed Unified Address.

Conversely, a "Previously Allowed Address" is an address that would have been valid prior to the activation of this proposal.

#Abstract

In the original design of the Sapling shielded protocol, the "diversifier hash" that maps diversifiers to curve points was an incomplete function, resulting in about half of all diversifiers being invalid. When used with ZIP 32 [19], this also meant that about half of all Sapling diversifier indices are invalid for a given ZIP 32 account.

This proposal modifies the Sapling protocol to make its diversifier hash complete.

#Motivation

TBD

#Requirements

• Every Sapling diversifier must be valid, except possibly with negligible probability.

• The proposal must be compatible with the existing Sapling design in the sense that any previously valid diversifier (or diversifier index) will map to the same curve point. This property is essential in order for previously created addresses and notes to remain valid.

• The algorithm to decrypt a note ciphertext must be well specified for transactions at any block height.

• The compatibility consequences of the proposal must be comprehensively assessed and clearly documented.

#Specification

In general terms, the method used to make the diversifier hash complete while maintaining compatibility is to:

• Define a new complete random-oracle encoding into the large prime-order subgroup of the Jubjub curve, following RFC 9380 [10].

• Define the new diversifier hash to use the incomplete group hash for diversifiers on which it is defined (i.e. does not return $\perp$), and the complete random-oracle encoding otherwise.

The complete random-oracle encoding is considered to be an internal primitive only. It MUST NOT be used for diversifiers on which the incomplete group hash is defined.

#Complete random-oracle encoding

In this section we define a complete random-oracle encoding [11] to the large prime-order subgroup of the Jubjub curve, named \texttt{jubjub\_XMD:BLAKE2b\_ELL2\_RO\_}. The name of this primitive follows the convention established by section 8.10 of RFC 9380 [15]. This name is not by itself sufficient to infer all parameters of the algorithm, which are specified below.

Jubjub is a complete Twisted Edwards curve ([6] and section 4.3.4 of [22]). In that respect it is similar mathematically to the widely deployed Edwards25519 curve; in particular it is birationally equivalent to a particular Montgomery curve [8]. RFC 9380 already defines a parameter suite for Edwards25519 [14], and we specify \texttt{jubjub\_XMD:BLAKE2b\_ELL2\_RO\_} following the same pattern for Jubjub.

The result of the encoding is obtained by adding (as curve points) the results of two maps to the Montgomery curve using the method of section 6.8.2 of RFC 9380 [12] (based on the Elligator 2 mapping originally defined in [21]), and then applying a rational map to obtain a Jubjub curve point.

Let $q_{𝕁}$, $a_{𝕁}$, $d_{𝕁}$, and $h_{𝕁}$ be as defined in [6].

\texttt{jubjub\_XMD:BLAKE2b\_ELL2\_RO\_} is defined as an RFC-9380 hash-to-curve suite [13] with the following parameters:

• encoding type: hash_to_curve

• $E$ (Jubjub curve):

  $a_{𝕁}\cdot v^2+w^2=1+d_{𝕁}\cdot v^2\cdot w^2$

• $p$ (field characteristic): $q_{𝕁}$

• $m$ (field extension degree): $1$

• $k$ (target security bits): $256$

• expand_message: expand_message_xmd

• $H$: BLAKE2b-512

• $L$: $64$

• $f$: Twisted Edwards Elligator 2 method (Section 6.8.2) [12]

• $M$ (Montgomery curve birationally equivalent to Jubjub):

  $K\cdot t^2=s^3+J\cdot s^2+s$, where $K=1$ and $J = 40962$

• rational_map: the "generic mapping" defined in RFC 9380 Appendix D.1 [16]

• $Z$: $5$

• h_eff: $h_{𝕁}$

Non-normative notes:

• RFC 9380 denotes Twisted Edwards coordinates as $(v, w)$ rather than $(u, v)$. This is because it uses $u$ for the field element to be mapped.

• The "security level" $k$ in the RFC is taken to be $256$. Although this is greater than the conjectured $125.8$-bit security of the Jubjub curve against generic (e.g. Pollard rho) attacks [23], this design choice is consistent with other instances of extracting a uniformly distributed field element from a hash output in the Sapling protocol, such as $𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ defined in [4], and ${𝖧}^{⊛}$ defined in [5].

• $Z=5$ is the non-square of smallest magnitude in ${𝔽}_{q_{𝕁}}$, as determined using the algorithm in RFC 9380 Appendix H.3 [17].

• The "generic mapping" from the Montgomery form to the Twisted Edwards form of Jubjub defined by [16] is not the same mapping as $𝖬𝗈𝗇𝗍𝖳𝗈𝖢𝗍𝖤𝖽𝗐𝖺𝗋𝖽𝗌$ [9] used in the Sapling circuits. The latter has an extra factor of {}^{+}\kern-0.65em\sqrt{-40964} in the resulting first Twisted Edwards coordinate.

#DiversifyHash

Modify the definition of $𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌𝗁$ in ... [#protocol-concretediversifyhash].

\begin{array}{l}
  \mathsf{CompleteHash}(M \;{\small ⦂}\; \mathbb{B}^{{\tiny\mathbb{Y}}[\mathbb{N}]}) \;{\small ⦂}\; \mathbb{J}^{(r)} = \\
  \hspace{2em}\texttt{jubjub\_XMD:BLAKE2b\_ELL2\_RO\_}\mathsf{.hash\_to\_curve}(\texttt{"z.cash:Sapling-gd-jubjub\_XMD:BLAKE2b\_ELL2\_RO\_"}, M) \\
  \\
  \mathsf{IncompleteHash}(M \;{\small ⦂}\; \mathbb{B}^{{\tiny\mathbb{Y}}[\mathbb{N}]}) \;{\small ⦂}\; \mathbb{J}^{(r)} = \\
  \hspace{2em}\mathsf{GroupHash}_U^{\mathbb{J}^{(r)*}}(\texttt{"Zcash\_gd"}, \mathsf{LEBS2OSP_{\ell_d}}(\mathsf{d})) \\[2ex]
\end{array}

\mathsf{DiversifyHash^{Sapling}}(\mathsf{d}) = \begin{cases}
  \mathsf{IncompleteHash}(\mathsf{d}),&\text{ if } \mathsf{IncompleteHash}(\mathsf{d}) \neq \bot \\
  \mathsf{CompleteHash}(\mathsf{d}),  &\text{ if } \mathsf{IncompleteHash}(\mathsf{d}) = \bot \text{ and } \mathsf{CompleteHash}(\mathsf{d}) \neq \bot \hspace{6em} \\
  \mathsf{CompleteHash}(\texttt{""}), &\text{ otherwise}
\end{cases}

#Note Encryption

In [7], TBD

let DiversifyHash be DiversifyHashSapling in section 5.4.1.6 ‘DiversifyHashSapling and DiversifyHashOrchard Hash Functions’

on page 76, or DiversifyHashOrchard in the same section.

Modify the uses of $𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌{𝗁}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ as follows: TBD

#Specification: Compatibility and Deployment

The deployment of this proposal raises compatibility issues that will require coordination and interoperability testing between wallet implementors. These issues arise from the fact that Newly Allowed Addresses will only work for receiving funds in wallets that have upgraded their note decryption procedure to support them.

We believe that these issues will be tractable for the following reason: under the assumption that a wallet implementation only exposes Newly Allowed Addresses after it has upgraded its note decryption procedure (as required by this specification), then it will always be able to receive funds on those addresses.

There are a couple of caveats to the above observation:

• If a seed is shared between wallets, or if it is restored from one wallet implementation to another, the above argument may not hold. Sharing seeds concurrently between wallets is generally not a supported usage model, but the ability to restore a seed from one wallet implementation to another is critical to ensure preservation of funds in the case of data loss or device malfunction, and also helps to avoid user lock-in to a particular wallet implementation. A past version of a wallet counts as a different wallet implementation for this discussion.

• In the case of a host wallet that relies on a connected hardware wallet to guard spend authority, care must be taken to ensure that both wallet implementations support Newly Allowed Addresses if either exposes them. Otherwise, the implementation that lacks this support could either fail to correctly receive a payment sent to a Newly Allowed Address, or be unable to spend notes from such payments.

Note that, according to the specification of the Sapling shielded protocol prior to activation of this proposal, the behaviour of a wallet receiving a decrypted note plaintext with a diversifier that it sees as invalid was well defined: it MUST ignore that note plaintext, as though it were not intended for the wallet. So the user-visible symptom of the situations described above will be that some funds are apparently missing.

These observations apply to scanning using either an incoming viewing key or an outgoing viewing key, because both will perform the check for diversifier validity.

In order to mitigate these issues we impose the following requirements:

• If a wallet implementation cannot reliably determine that the Sapling outputs of transactions mined since the activation height of this proposal have been scanned by an implementation that would correctly receive payments on Newly Allowed Addresses —possibly including past iterations of the same wallet from which state has been preserved— it MUST rescan them.

• If a host wallet and hardware wallet are connected, each SHOULD verify that the other fully supports Newly Allowed Addresses before exposing any such address.

After activation of this proposal, a wallet implementation MAY continue to expose only Previously Allowed Addresses. We nevertheless suggest that wallet implementors consider the simplicity advantages of generating addresses at contiguous ZIP 32 indices.

#Activation height

Let $𝖹𝗂𝗉𝖷𝖷𝖷𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$ be the activation height of this ZIP. This is the first block height at which it is valid for transactions in that block to contain Sapling Output descriptions with notes having a diversifier that would be invalid using the previously defined $𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌{𝗁}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$.

TODO:

• replace XXX with the number of this ZIP;

• specify the activation height.

Before the activation height, all relevant wallets implementing Sapling should be confirmed to have implemented this specification (apart from setting the mainnet height) and to have conducted comprehensive interoperability testing.

#Test Vectors

#jubjub_XMD:BLAKE2b_ELL2_RO_ test vectors

The following test vectors for the \texttt{jubjub\_XMD:BLAKE2b\_ELL2\_RO\_} random-oracle encoding are in the same format as used in Appendix J of RFC 9380 [18]. Note that the RFC denotes Twisted Edwards coordinates as (x, y) rather than $(u, v)$.

suite   = jubjub_XMD:BLAKE2b_ELL2_RO_
dst     = z.cash:Sapling-gd-jubjub_XMD:BLAKE2b_ELL2_RO_

msg     = Everybody's right to beautiful, radiant things
P.x     =
P.y     =
u[0]    =
u[1]    =
Q0.x    =
Q0.y    =
Q1.x    =
Q1.y    =

#DiversifyHash test vectors

TBD

#Reference Implementation

TBD

#References