#Terminology

The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 ¹ when, and only when, they appear in all capitals.

The term "network upgrade" in this document is to be interpreted as described in ZIP 200. ²

The character § is used when referring to sections of the Zcash Protocol Specification. ³

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

We use the convention followed in the protocol specification that an $\underline{𝗎𝗇𝖽𝖾𝗋𝗅𝗂𝗇𝖾𝖽}$ variable indicates a byte sequence, and a variable suffixed with $\star$ indicates a bit-sequence encoding of an elliptic curve point.

The term "Zcash Shielded Assets" or "ZSAs" refers to the extension to the Orchard shielded protocol described in ZIPs 226 and 227 ^{5 6}.

The term "Orchard[ZSA]" in this document refers to the Orchard shielded protocol before the deployment of ZSAs, and to the OrchardZSA shielded protocol after the deployment of ZSAs.

The term "recoverable Orchard[ZSA] note" refers to an Orchard or OrchardZSA note that was created according to this proposal.

The term "Recovery Protocol" refers to a potential new shielded protocol that would allow recovery of funds held in recoverable Orchard[ZSA] notes. This ZIP describes the Recovery Protocol in outline but not in detail: many of its design decisions are intentionally left open.

#Abstract

This ZIP proposes a change to the construction of Orchard[ZSA] notes starting with v6 transactions, designed to improve Zcash's long-term resilience against a significant potential threat to its security from quantum computers. It does not by itself make the protocol secure against quantum adversaries, but is intended to support a smoother transition to future versions of Zcash designed to be so.

Specifically, if it were necessary to disable the current Orchard[ZSA] shielded protocol in order to prevent a discrete-log-breaking adversary from stealing or forging funds, this change would make it possible to use a Recovery Protocol to recover existing Orchard funds. This Recovery Protocol is expected to remain secure against discrete-log-breaking and quantum adversaries.

If the Orchard[ZSA] protocol needed to be disabled for this reason, the Sapling protocol would need to be disabled as well, which would make all Sapling funds inaccessible. Sapling funds should be migrated to Orchard in order to take advantage of this change.

#Motivation

If quantum computers —or any other attack that allows finding discrete logarithms on the elliptic curves used in Zcash— were to become practical, it would raise difficult issues for the Zcash community. An adversary able to compute discrete logarithms could cause arbitrary inflation or steal users' funds.

Critically, the note commitment algorithms used by the Sapling and Orchard shielded protocols are not post-quantum binding. This means that even if the proof system were upgraded to one that is believed to be secure against quantum computers, and even if the note commitment tree were to be reconstructed (from public information) to use a suitable hash function, it would still be possible for a quantum or discrete-log-breaking adversary to forge and spend notes that are not actually in the commitment tree — thus breaking the Balance property.

This ZIP proposes a small change to the way Orchard[ZSA] notes are derived. If this change is made in advance of quantum computers becoming viable, then users' Orchard[ZSA] funds could remain safe and recoverable after a post-quantum transition. This would not require any change to the Orchard or proposed OrchardZSA circuits for the time being, and would not require deciding on the particular proof system or note commitment tree hash used in the future protocol.

Recovering Orchard[ZSA] funds after the post-quantum transition would involve checking a more expensive and complicated statement in zero knowledge, but it is expected that this will be entirely practical for the intended usage of recovering funds into another shielded pool. The current privacy properties of Orchard would be retained against pre-quantum adversaries, and also against post-quantum adversaries without knowledge of the notes' addresses. ⁷

To reduce overall protocol complexity and analysis effort, we do not propose a similar change for Sapling. Instead, Sapling funds can be migrated to Orchard in order to make them quantum-recoverable. (Note that this analysis effort needs to include the child and internal key derivations defined in ZIP 32, which differ significantly between Sapling ^{8 9} and Orchard ^{10 11}.)

This proposal is implementable at low risk, and required changes to existing libraries and wallets are small. It can be folded into other changes necessary to implement ZSAs ⁵ and Memo Bundles ¹².

#Requirements

• Orchard[ZSA] notes constructed according to this proposal should be spendable via a Recovery Protocol (to be introduced, potentially, in a future upgrade) that is expected to be secure against discrete-log-breaking and quantum adversaries.
• No particular choice of post-quantum proving system or commitment tree hash should be assumed for that alternate protocol.
• The proposed scheme should be fully compatible with FROST multisignatures ¹³, hardware wallets, and the combination of both.
• The proposed scheme should not require regeneration of existing non-multisignature keys or addresses.
• The changes made to the pre-quantum protocol should not cause a significant regression in performance, applicability, or security against any given adversary class, or require significant re-analysis of that protocol's pre-quantum security.
• The Recovery Protocol should ensure no loss of security against pre-quantum adversaries — including when FROST multisignatures and/or hardware wallets are used. (This is motivated by the fact that there is likely to be a period during which quantum attacks may be possible but very difficult.)
• Recovery of funds from hardware wallets that support this protocol should not require exposing the pre-quantum spend authorizing key $𝖺𝗌𝗄$ to theft.
• The proposal should be compatible with Zcash Shielded Assets with minimal additional complexity ^{5 6}.

#Non-requirements

• It is not required to address discrete-log-breaking or quantum attacks on privacy with this proposal, as long as it does not cause any regression in privacy properties.
• It is not required to add support for the Recovery Protocol to consensus rules now.
• It is not required for spends using the Recovery Protocol to be as efficient as spends using the Orchard, OrchardZSA, or Sapling protocols.
• It is not anticipated that spends using the Recovery Protocol will need to be indistinguishable from non-Recovery spends.

#High-level summary of changes

This subsection and the flow diagram below are non-normative.

In order to support ZSAs ^{5 6} and memo bundles ¹², v6 transactions require in any case a new note plaintext format, with lead byte $\text{hexint}03.$ This gives us an opportunity to change the way that the $𝗉𝗋𝖾\_𝗋𝖼𝗆$ value is computed for this new format, by including all of the note fields in $𝗉𝗋𝖾\_𝗋𝖼𝗆$. The resulting $𝗋𝖼𝗆$ is essentially a random function of the note fields — this allows us to argue that the overall commitment scheme is post-quantum binding, as long as the new derivation of $𝗋𝖼𝗆$ is checked in the Recovery Protocol.

Essentially the same technique also needs to be applied to the function $𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}$ that is used to derive Orchard incoming viewing keys. In order to support existing keys, we have the Recovery Protocol check the derivations of $𝗇𝗄$, $𝖺𝗄$, and $𝗋𝗂𝗏𝗄$ from the secret key $𝗌𝗄$.

Since this derivation of (at least) $𝖺𝗄$ from $𝗌𝗄$ cannot be used in the case of FROST key generation, we also provide an alternative way to derive $𝗋𝗂𝗏𝗄$ which is to be used in that case. This alternative derivation, using a new "quantum spending key" $𝗊𝗌𝗄$ and "quantum intermediate key" $𝗊𝗄$, also supports more efficient use of hardware wallets in the Recovery Protocol. It is described in sections [Usage with FROST] and [Usage with Hardware Wallets].

#Flow diagram for the Orchard and OrchardZSA protocols

This diagram shows, approximately, the derivation of Orchard keys, addresses, notes, note commitments, and nullifiers. All of the flow diagrams in this ZIP omit type conversions between curve points, field elements, byte sequences, and bit sequences, and so are not sufficiently precise to be used directly as a guide for implementation.

---
title: "Key to flow diagrams"
---
graph BT
  classDef default stroke:#111111;
  classDef func fill:#d0ffb8;
  classDef cefunc fill:#a0e0a0;
  classDef sensitive fill:#ffb0b0;
  classDef semi_sensitive fill:#ffb0ff;
  classDef keybox stroke:#808080, fill:#ffffff;
  classDef spacer opacity:0;

  key([sensitive key]):::sensitive ~~~ function:::func
  value([value]) ~~~ cond{{conditional value}}
  dummyA( ) -->|existing| dummyB( )
  dummyC( ) ==>|new| dummyD( )
  dummyE( ) -.->|optional| dummyF( )

The bold lines are changes introduced by this ZIP, which all take the form of additional inputs to derivation functions or alternative derivations. The derivations shown in the box labelled "Potential recovery circuit" are, roughly speaking, those enforced by the [Proposed Recovery Protocol].

graph BT
  classDef default stroke:#111111;
  classDef func fill:#d0ffb8;
  classDef cefunc fill:#a0e0a0;
  classDef sensitive fill:#ffb0b0;
  classDef semi_sensitive fill:#ffb0ff;
  classDef circuit stroke:#000000, fill:#fffff0;
  classDef spacer opacity:0;

  PostQC:::circuit
  subgraph PostQC[<div style="margin:1.1em;font-size:20px"><b>Potential recovery circuit</b></div>]
    direction BT
    rivk_ext([rivk_ext]) --> Hrivk_int[H<sup>rivk_int</sup>]:::func
    ak([ak]) --> Hrivk_int[H<sup>rivk_int</sup>]:::func
    nk --> Hrivk_int
    rivk_ext -->|¬is_internal_rivk| rivk
    Hrivk_int -->|is_internal_rivk| rivk{{rivk}}
    rivk --> Commitivk[Commit<sup>ivk</sup>]:::func
    ak([ak]) ----> Commitivk
    nk([nk]) ----> Commitivk
    Commitivk ---> ivk([ivk])
    gd ---> ivkmul[［ivk］g<sub>d</sub>&nbsp;]:::func
    ivk --> ivkmul
    split_flag([split_flag]) --> Hpsi
    rsplit([rsplit]) -->|split_flag| rpsi{{rψ}}
    rsplit ~~~ split_flag
    rseed -->|¬split_flag| rpsi
    rpsi --> Hpsi[H<sup>ψ</sup>]:::func
    rho --> Hpsi
    leadByte([leadByte]) ==> pre_rcm
    v([v, AssetBase]) ===> pre_rcm([pre_rcm])
    pkd ====> pre_rcm
    gd ==> pre_rcm
    psi ===> pre_rcm
    rho([#8239;ρ#8239;]) --> pre_rcm
    v ~~~~ rcm
    ivkmul --> pkd([pk<sub>d</sub>])
    pre_rcm --> Hrcm[H<sup>rcm</sup>]:::func
    rseed([rseed]) --> Hrcm
    Hrcm --> rcm([rcm])
    Hpsi --> psi([#8239;ψ#8239;])
    gd --> NoteCommit:::func
    pkd --> NoteCommit
    v --> NoteCommit
    psi --> NoteCommit
    rcm --> NoteCommit
    rho --> NoteCommit
    cm --> DeriveNullifier:::func
    psi --> DeriveNullifier
    rho --> DeriveNullifier
    nk --> DeriveNullifier
    NoteCommit --> cm([cm])
    DeriveNullifier --> nf([nf])
    cm --> cmx([cm<sub><i>x</i></sub>])
  end

  d([#8239;d#8239;]) --> HashToCurve:::func ------> gd([g<sub>d</sub>])

#Specification

#Usage with FROST

When generating Orchard keys for FROST, $𝖺𝗄$ will be derived jointly from the participants' shares of $𝖺𝗌𝗄$ according to the FROST Distributed Key Generation (DKG) protocol.

This ZIP further constrains FROST key generation for Orchard as follows: participants MUST privately agree on a value $𝗌𝗄$, and then use it with $𝗎𝗌𝖾\_𝗊𝗌𝗄=𝗍𝗋𝗎𝖾$ to derive $𝗇𝗄$, $𝗊𝗌𝗄$, $𝗊𝗄$, and (using the $𝖺𝗄$ output by the DKG protocol) $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$, as specified in § 4.2.3 ‘Orchard Key Components’.

graph BT
  classDef default stroke:#111111;
  classDef func fill:#d0ffb8;
  classDef cefunc fill:#a0e0a0;
  classDef sensitive fill:#ffb0b0;
  classDef semi_sensitive fill:#ffb0ff;
  classDef circuit stroke:#000000, fill:#fffff0;
  classDef spacer opacity:0;

  sk([sk]):::sensitive --> Hnk[H<sup>nk</sup>]:::func ----> nk([nk])
  sk --> Hqsk[H<sup>qsk</sup>]:::func --> qsk([qsk]):::sensitive
  qk ==> Hrivk_ext
  nk ==> Hrivk_ext
  FROST_DKG --> ak([ak]) --> FROST_Sign
  FROST_DKG ~~~ s( ):::spacer ~~~ FROST_Sign
  FROST_DKG --> ask([ask<sub>i</sub>]):::sensitive --> FROST_Sign
  ak ==> Hrivk_ext[H<sup>rivk_ext</sup>]:::func
  Hrivk_ext ==>|use_qsk| rivk_ext([rivk_ext])

  HWW1:::circuit
  subgraph HWW1[<div style="margin:1.6em;font-size:20px"><br><br><br><br><br><br><br><br><br><b>SoK<sup>qsk</sup></b></div>]
    qsk([qsk]):::sensitive ==> Hqk[H<sup>qk</sup>]:::cefunc
    Hqk ==> qk([qk]):::semi_sensitive
  end

The protocol MUST ensure that all participants obtain the same values for $𝖺𝗄$, $𝗇𝗄$, and $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$. (Provided that the participants have followed § 4.2.3, this implies that they have the same $𝗊𝗌𝗄$ and $𝗊𝗄$, by collision resistance of ${𝖧}^{𝗊𝗄}$ and ${𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}$.)

Each participant MUST treat $𝗊𝗌𝗄$ as a secret held at least as securely and reliably as $𝖺𝗌𝗄$. Note that $𝗊𝗌𝗄$ will not be needed to sign unless and until the Recovery Protocol is needed, but it is essential that it be retained, otherwise funds could be lost if and when the current Orchard protocol is disabled.

The Recovery Protocol will still require a RedDSA signature verifiable by the Spend validating key $𝖺𝗄$, in addition to knowledge of $𝗊𝗌𝗄$. Although RedDSA is not secure in the long term against a quantum or discrete-log-breaking adversary, the most likely eventuality is that attacks against it will be difficult for some years after the current Orchard protocol is disabled. During this period, checking this RedDSA signature in the Recovery Protocol will ensure that spend authorization by a $t$-of-$n$ threshold of participants continues to be needed against classical adversaries. This retains the usual advantage of FROST that the parties can sign using their shares without reconstructing the Spend authorizing key $𝖺𝗌𝗄$. Coalitions of fewer than $t$ of the participants will be unable to authorize spends as long as they do not have access to a sufficiently powerful quantum computer.

Note that a quantum adversary may be able to steal the funds with only access to $𝗊𝗌𝗄$, which is held by every participant. Therefore, it is RECOMMENDED that as soon as a fully post-quantum protocol that supports multisignatures is available, all funds held under FROST keys be transferred into that protocol's shielded pool.

#Usage with hardware wallets

The same $𝗎𝗌𝖾\_𝗊𝗌𝗄$ option can help to improve the efficiency of using the Recovery Protocol with hardware wallets. If the keys $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍,$ $𝗇𝗄,$ and $𝖺𝗄$ are generated from $𝗌𝗄,$ then the circuit for the Recovery Protocol will need to prove their correct derivation using ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒},$ ${𝖧}^{𝗇𝗄},$ ${𝖧}^{𝖺𝗌𝗄},$ and $𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼$ as shown in the $𝖲𝗈{𝖪}^{𝗌𝗄}$ box of the diagram below.

graph BT
  classDef default stroke:#111111;
  classDef func fill:#d0ffb8;
  classDef cefunc fill:#a0e0a0;
  classDef sensitive fill:#ffb0b0;
  classDef semi_sensitive fill:#ffb0ff;
  classDef circuit stroke:#000000, fill:#fffff0;
  classDef spacer opacity:0;

  HWW1:::circuit
  subgraph HWW1[<div style="margin:1.1em;font-size:20px"><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><b>SoK<sup>sk</sup></b></div>]
    sk --> Hrivk_legacy[H<sup>rivk_legacy</sup>]:::func ----> rivk_legacy
    DerivePublic --> ak([ak])
    sk([sk]):::sensitive --> Hnk[H<sup>nk</sup>]:::func ----> nk([nk])
    sk --> Hask[H<sup>ask</sup>]:::func --> ask([ask]):::sensitive
    ask --> DerivePublic:::func
  end

  HWW2:::circuit
  subgraph HWW2[<div style="margin:1.6em;font-size:20px"><br><br><br><br><br><br><br><br><br><b>SoK<sup>qsk</sup></b></div>]
    qsk([qsk]):::sensitive ==> Hqk[H<sup>qk</sup>]:::cefunc
    Hqk ==> qk([qk]):::semi_sensitive
  end

  sk -.-> Hqsk[H<sup>qsk</sup>]:::func -.-> qsk
  qk ==> Hrivk_ext[H<sup>rivk_ext</sup>]:::func
  nk([nk]) ==> Hrivk_ext
  ak ==> Hrivk_ext
  Hrivk_ext ==>|use_qsk| rivk_ext{{rivk_ext}}
  rivk_legacy([rivk_legacy]) -->|¬use_qsk| rivk_ext

When $𝗎𝗌𝖾\_𝗊𝗌𝗄$ is used, on the other hand, it is possible for the Recovery Protocol to support spend authorization using a much smaller circuit that only uses ${𝖧}^{𝗊𝗄}$ and a commitment scheme. For example, for some hiding and collapse binding commitment $c={𝖫𝗂𝗇𝗄𝖢𝗈𝗆𝗆𝗂𝗍}_r(𝗊𝗄,𝗌𝗂𝗀𝗁𝖺𝗌𝗁),$ the hardware wallet could prove knowledge of $(𝗊𝗌𝗄,r)$ such that $c={𝖫𝗂𝗇𝗄𝖢𝗈𝗆𝗆𝗂𝗍}_r({𝖧}^{𝗊𝗄}(𝗊𝗌𝗄),𝗌𝗂𝗀𝗁𝖺𝗌𝗁).$ This circuit is relatively small and it might be feasible to do the proof in quite constrained hardware.

The host wallet would be given $𝗇𝗄,$ $𝖺𝗄,$ and $𝗊𝗄$ for use in the main Recovery circuit (discussed later). The commitment $c$ would be a public input opened to $(𝗊𝗄,𝗌𝗂𝗀𝗁𝖺𝗌𝗁)$ in that circuit, ensuring that the hardware wallet has authorized the spend for the correct key. Because $𝖫𝗂𝗇𝗄𝖢𝗈𝗆𝗆𝗂𝗍$ is hiding and the proofs are zero knowledge, no information is leaked about which $𝗊𝗄$ is being used.

Alternatively, if the hardware wallet is unable to support making proofs at all, it could be updated to permit exporting $𝗊𝗌𝗄$. This is less secure against a quantum adversary that is able to obtain $𝗊𝗌𝗄$, but it allows the funds to be transferred to another key or protocol. A quantum adversary would have to break RedDSA in order to steal funds even if it were to obtain $𝗊𝗌𝗄$, since $𝖺𝗌𝗄$ would remain on the hardware wallet.

#Specification Updates

This is written as a set of changes to version 2025.6.1 of the protocol specification, and to the contents of ZIPs at the time of writing in October 2025 (as proposed for the NU6.1 upgrade). It will need to be merged with other changes for v6 transactions (memo bundles ¹² and ZSAs ^{5 6}).

#Changes to the Protocol Specification

Some of the suggested changes to the protocol specification are refactoring to make it easier to consistently specify the rules on allowed note plaintext lead bytes and generation of note components, without duplication between sections. It is suggested to do this refactoring first, independently of the semantic changes for quantum recoverability, and then to simplify this ZIP accordingly.

#§ 3.1 ‘Payment Addresses and Keys’

Add a $\ast$ to the arrows leading to $𝖺𝗌𝗄$ and $𝗋𝗂𝗏𝗄$ in the Orchard key components diagram, with the following note:

$\ast$ The derivations of $𝖺𝗌𝗄$ and $𝗋𝗂𝗏𝗄$ shown are not the only possibility. For further detail see § 4.2.3 ‘Orchard Key Components’.

#§ 3.2.1 ‘Note Plaintexts and Memo Fields’

Replace the paragraph

The field $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$ indicates the version of the encoding of a Sapling or Orchard note plaintext. For Sapling it is $\text{hexint}01$ before activation of the Canopy network upgrade and $\text{hexint}02$ afterward, as specified in [ZIP-212]. For Orchard note plaintexts it is always $\text{hexint}02$.

with

The field $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$ indicates the version of the encoding of a Sapling or Orchard note plaintext.

Let the constants $𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$ and $𝖹𝖨𝖯\mathrm{𝟤𝟣𝟤}𝖦𝗋𝖺𝖼𝖾𝖯𝖾𝗋𝗂𝗈𝖽$ be as defined in § 5.3 ‘Constants’.

Let $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅⦂\{𝖲𝖺𝗉𝗅𝗂𝗇𝗀,𝖮𝗋𝖼𝗁𝖺𝗋𝖽\}$ be the shielded protocol of the note.

Let $𝗁𝖾𝗂𝗀𝗁𝗍$ be the block height of the block containing the transaction having the encrypted note plaintext as an output, and let $𝗍𝗑𝖵𝖾𝗋𝗌𝗂𝗈𝗇$ be the transaction version number.

Define $𝖺𝗅𝗅𝗈𝗐𝖾𝖽𝖫𝖾𝖺𝖽𝖡𝗒𝗍𝖾{𝗌}^{𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅}(𝗁𝖾𝗂𝗀𝗁𝗍,𝗍𝗑𝖵𝖾𝗋𝗌𝗂𝗈𝗇)=$ $\{\begin{array}{cc}\text{setof}\text{hexint}01,& \text{caseif}𝗁𝖾𝗂𝗀𝗁𝗍<𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍\\ \text{setof}\text{hexint}01,\text{hexint}02,& \text{caseif}𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍\le 𝗁𝖾𝗂𝗀𝗁𝗍<𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍+𝖹𝖨𝖯\mathrm{𝟤𝟣𝟤}𝖦𝗋𝖺𝖼𝖾𝖯𝖾𝗋𝗂𝗈𝖽\\ \text{setof}\text{hexint}02,& \text{caseif}𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍+𝖹𝖨𝖯\mathrm{𝟤𝟣𝟤}𝖦𝗋𝖺𝖼𝖾𝖯𝖾𝗋𝗂𝗈𝖽\le 𝗁𝖾𝗂𝗀𝗁𝗍\text{ and }𝗍𝗑𝖵𝖾𝗋𝗌𝗂𝗈𝗇<6\\ \text{setof}\text{hexint}03,& \text{otherwise.}\end{array}$

The $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$ of a Sapling or Orchard note MUST satisfy $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\in 𝖺𝗅𝗅𝗈𝗐𝖾𝖽𝖫𝖾𝖺𝖽𝖡𝗒𝗍𝖾{𝗌}^{𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅}(𝗁𝖾𝗂𝗀𝗁𝗍,𝗍𝗑𝖵𝖾𝗋𝗌𝗂𝗈𝗇)$. Senders SHOULD choose the highest lead byte allowed under this condition.

Non-normative notes:

• Since Orchard was introduced after the end of the [ZIP-212]) grace period, note plaintexts for Orchard notes MUST have $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\ge \mathrm{𝟶}𝚡\mathrm{𝟶𝟸}$.
• It is intentional that the definition of $𝖺𝗅𝗅𝗈𝗐𝖾𝖽𝖫𝖾𝖺𝖽𝖡𝗒𝗍𝖾𝗌$ does not currently depend on $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅$. It might do so in future.

#§ 4.1.2 ‘Pseudo Random Functions’

In the list of places where $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}$ is used:

Replace

• [NU5 onward] in § 4.2.3 ‘Orchard Key Components’, with inputs $[6]$, $[7]$, $[8]$, and with first byte $\text{hexint}82$ (the last of these is also specified in [ZIP-32]);
• in the processes of sending (§ 4.7.2 ‘Sending Notes (Sapling)’ and § 4.7.3 ‘Sending Notes (Orchard)’) and of receiving (§ 4.20 ‘In-band secret distribution (Sapling and Orchard)’) notes, with inputs $[4]$ and $[5]$, and for Orchard $[t]||\underline{\text{ρ}}$ with $t\in \{5,4,9\}$;

with

• [NU5 onward] in § 4.2.3 ‘Orchard Key Components’, with inputs $[\text{hexint}06]$, $[\text{hexint}07]$, $[\text{hexint}08]$, with first byte in $\text{setof}\text{hexint}0C,\text{hexint}0D$ (also specified in {{ reference to this ZIP }}), and with first byte $\text{hexint}82$ (also specified in [ZIP-32]);
• in the processes of sending (§ 4.7.2 ‘Sending Notes (Sapling)’ and § 4.7.3 ‘Sending Notes (Orchard)’) and of receiving (§ 4.20 ‘In-band secret distribution (Sapling and Orchard)’) notes, for Sapling with inputs $[\text{hexint}04]$ and $[\text{hexint}05]$, and for Orchard with first byte in $\text{setof}\text{hexint}05,\text{hexint}04,\text{hexint}09,\text{hexint}0A,\text{hexint}0B$ ($\text{hexint}0A$ and $\text{hexint}0B$ are also specified in {{ reference to this ZIP }});

Add

• in {{ reference to this ZIP }}, with first byte in $\text{setof}\text{hexint}0A,\text{hexint}0B,\text{hexint}0C,\text{hexint}0D$.

Also change the remaining decimal constants to hex for consistency.

#§ 4.2.3 ‘Orchard Key Components’

Add ${\ell }_{𝗊𝗌𝗄}$ and ${\ell }_{𝗊𝗄}$ to the constants obtained from § 5.3 ‘Constants’.

Insert after the definition of $𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$:

Define ${𝖧}_{𝗊𝗄}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}(𝖺𝗄,𝗇𝗄)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗊𝗄}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\text{hexint}0D]||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝖺𝗄)$ $||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝗇𝗄)))$.

Replace from "From this spending key" up to and including the line "let $𝖺𝗄={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}({𝖺𝗄}^{\mathbb{P}})$" in the algorithm with:

Under normal circumstances, the Spend authorizing key $𝖺𝗌𝗄⦂{𝔽}_{r_{\mathbb{P}}}^{\ast }$ is derived directly from $𝗌𝗄$. However, this might not be the case for protocols that require distributed generation of shares of $𝖺𝗌𝗄$, such as FROST's Distributed Key Generation ¹⁴ (see {{ reference to the [Usage with FROST] section of this ZIP }} for further discussion). To support this we define an alternative derivation method using an additional "quantum spending key", $𝗊𝗌𝗄$, and "quantum intermediate key", $𝗊𝗄$.

There can also be advantages to not deriving $𝖺𝗌𝗄$ directly from $𝗌𝗄$ for hardware wallets, in order to separate the authority to make proofs for the Recovery Protocol from the spend authorization key that is kept on the device (see {{ reference to the [Usage with hardware wallets] section of this ZIP }}). The derivation from $𝗊𝗌𝗄$ can also be used in that case.

Let $𝗎𝗌𝖾\_𝗊𝗌𝗄⦂𝔹$ be a flag that is set to true when the derivation from $𝗊𝗌𝗄$ is used, or false if $𝖺𝗌𝗄$ is derived directly from $𝗌𝗄$. (In cases where it is desired for the generation of key components to match versions of this specification prior to {{ fill in version }}, $𝗎𝗌𝖾\_𝗊𝗌𝗄$ needs to be set to false.)

Define:

• ${𝖧}^{𝖺𝗌𝗄}(𝗌𝗄)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗌𝗄}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\text{hexint}06]))$
• ${𝖧}^{𝗇𝗄}(𝗌𝗄)=𝖳𝗈𝖡𝖺𝗌{𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗌𝗄}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\text{hexint}07]))$
• ${𝖧}^{𝗋𝗂𝗏𝗄}(𝗌𝗄)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗌𝗄}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\text{hexint}08]))$
• ${𝖧}^{𝗊𝗌𝗄}(𝗌𝗄)={𝗍𝗋𝗎𝗇𝖼𝖺𝗍𝖾}_{32}(𝖯𝖱{𝖥}_{𝗌𝗄}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\text{hexint}0C]))$
• ${𝖧}^{𝗊𝗄}(𝗊𝗌𝗄)=\text{𝖡𝖫𝖠𝖪𝖤𝟤𝗌}\text{-𝟤𝟧𝟨}(\text{“𝚉𝚌𝚊𝚜𝚑\_𝚚𝚔”},𝗊𝗌𝗄)$.

$𝖺𝗌𝗄⦂{𝔽}_{r_{\mathbb{P}}}^{\ast }$, the Spend validating key $𝖺𝗄⦂\{1..q_{\mathbb{P}}-1\}$, the nullifier deriving key $𝗇𝗄⦂{𝔽}_{q_{\mathbb{P}}}$, the optional quantum spending key $𝗊𝗌𝗄⦂{𝔹}^{𝕐[{\ell }_{𝗊𝗌𝗄}/8]}\cup \{\perp \}$ and quantum intermediate key $𝗊𝗄⦂{𝔹}^{𝕐[{\ell }_{𝗊𝗄}/8]}\cup \{\perp \}$ the $𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}$ randomness $𝗋𝗂𝗏𝗄⦂{𝔽}_{r_{\mathbb{P}}}$, the diversifier key $𝖽𝗄⦂{𝔹}^{𝕐[{\ell }_{𝖽𝗄}/8]}$, the $𝖪{𝖠}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ private key $𝗂𝗏𝗄⦂\{1..q_{\mathbb{P}}-1\}$, the outgoing viewing key $𝗈𝗏𝗄⦂{𝔹}^{𝕐[{\ell }_{𝗈𝗏𝗄}/8]}$, and corresponding “internal” keys MUST be derived as follows:

$$ let $𝗇𝗄={𝖧}^{𝗇𝗄}(𝗌𝗄)$
$$ if $𝗎𝗌𝖾\_𝗊𝗌𝗄$:
$$ generate $𝖺𝗌𝗄⦂{𝔽}_{r_{\mathbb{P}}}^{\ast }$ and corresponding $𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ public key ${𝖺𝗄}^{\mathbb{P}}⦂{\mathbb{P}}^{\ast }$
$$ using any suitably secure method that ensures the last bit of ${𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝖺𝗄}_{\mathbb{P}})$ is $0$.
$$ let $𝖺𝗄={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}({𝖺𝗄}_{\mathbb{P}})$
$$ let $𝗊𝗌𝗄={𝖧}^{𝗊𝗌𝗄}(𝗌𝗄)$
$$ let $𝗊𝗄={𝖧}^{𝗊𝗄}(𝗊𝗌𝗄)$
$$ let $𝗋𝗂𝗏𝗄={𝖧}_{𝗊𝗄}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}(𝖺𝗄,𝗇𝗄)$
$$ else:
$$ let mutable $𝖺𝗌𝗄\leftarrow {𝖧}^{𝖺𝗌𝗄}(𝗌𝗄)$
$$ let ${𝖺𝗄}_{\mathbb{P}}=𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼(𝖺𝗌𝗄)$
$$ if the last bit (that is, the $\tilde{y}$ bit) of ${𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝖺𝗄}_{\mathbb{P}})$ is $1$:
$$ set $𝖺𝗌𝗄\leftarrow -𝖺𝗌𝗄$

$$ let $𝖺𝗄={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}({𝖺𝗄}_{\mathbb{P}})$
$$ let $𝗊𝗌𝗄=𝗊𝗄=\perp$ (there are no quantum spending/intermediate keys in this case)
$$ let $𝗋𝗂𝗏𝗄={𝖧}^{𝗋𝗂𝗏𝗄}(𝗌𝗄)$

Add the following notes:

• If $𝖺𝗌𝗄$, $𝖺𝗄$, $𝗇𝗄$, $𝗋𝗂𝗏𝗄$, and $𝗋𝗂𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}$ are not generated as specified in this section, then it may not be possible to recover the resulting notes as specified in {{ reference to this ZIP }} in the event that attacks using quantum computers become practical. In addition, to recover notes it is necessary to retain, or be able to rederive the following information.
  • When $𝗎𝗌𝖾\_𝗊𝗌𝗄$ is $𝖿𝖺𝗅𝗌𝖾$: the secret key $𝗌𝗄$. This will be the case when $𝗌𝗄$ is generated according to [ZIP-32], and the master seed or any secret key and chain code above $𝗌𝗄$ in the derivation hierarchy is retained.
  • When $𝗎𝗌𝖾\_𝗊𝗌𝗄$ is $𝗍𝗋𝗎𝖾$: the combination of the full viewing key $(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄)$, the quantum spending key $𝗊𝗌𝗄$, and the ability to make spend authorization signatures with $𝖺𝗌𝗄$.
  When the latter option is used, see {{ reference to the [Usage with hardware wallets] section of this ZIP }} for recommendations on the storage of, and access to $𝗊𝗌𝗄$ and $𝗊𝗄$.

#§ 4.7.2 ‘Sending Notes (Sapling)’

Replace

Let $𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$ be as defined in § 5.3 ‘Constants’.

Let $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$ be the note plaintext lead byte. This MUST be $\text{hexint}01$ if for the next block, $𝗁𝖾𝗂𝗀𝗁𝗍<𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$, or $\text{hexint}02$ if $𝗁𝖾𝗂𝗀𝗁𝗍\ge 𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$.

with

Let $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$ be the note plaintext lead byte, chosen according to § 3.2.1 ‘Note Plaintexts and Memo Fields’ with $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖲𝖺𝗉𝗅𝗂𝗇𝗀$.

Define ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(\_,\_)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\text{hexint}04]))$

Define ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗌𝗄,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(\_,\_)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\text{hexint}05]))$.

(${𝖧}^{𝗋𝖼𝗆,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ and ${𝖧}^{𝖾𝗌𝗄,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ intentionally take arguments that are unused.)

Replace the lines deriving $𝗋𝖼𝗆$ and $𝖾𝗌𝗄$ with

Derive $𝗋𝖼𝗆={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(\perp ,\perp )$

Derive $𝖾𝗌𝗄={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗌𝗄,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(\perp ,\perp )$

#§ 4.7.3 ‘Sending Notes (Orchard)’

Replace

Let $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$ be the note plaintext lead byte, which MUST be $\mathrm{𝟶}𝚡\mathrm{𝟶𝟸}$.

with

Let $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$ be the note plaintext lead byte, chosen according to § 3.2.1 ‘Note Plaintexts and Memo Fields’ with $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖮𝗋𝖼𝗁𝖺𝗋𝖽$.

Define ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,(𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ}[,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star ]))=$ $𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝗋𝖼𝗆))$

where $𝗉𝗋𝖾\_𝗋𝖼𝗆=\{\begin{array}{cc}[\text{hexint}05]||\underline{\text{ρ}},& \text{caseif}𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\text{hexint}02\\ [\text{hexint}0B,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾]||{𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{256}(𝗀{\star }_{𝖽})||{𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{256}(𝗉𝗄{\star }_{𝖽})& \\ \phantom{[\text{hexint}0B,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾]}||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{64}(𝗏)||\underline{\text{ρ}}||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(\text{ψ})& \\ \phantom{[\text{hexint}0B,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾]}[||{𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{256}(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star )],& \text{caseif}𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\text{hexint}03\end{array}$

Define ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗌𝗄,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}})=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\text{hexint}04]||\underline{\text{ρ}}))$.

Define ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}},𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀)=𝖳𝗈𝖡𝖺𝗌{𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([𝗌𝗉𝗅𝗂𝗍\_𝖽𝗈𝗆𝖺𝗂𝗇]||\underline{\text{ρ}}))$. where $𝗌𝗉𝗅𝗂𝗍\_𝖽𝗈𝗆𝖺𝗂𝗇=\{\begin{array}{cc}\text{hexint}09& \text{if }𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀=0\\ \text{hexint}0A& \text{if }𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀=1\text{.}\end{array}$

Insert before the derivation of $𝖾𝗌𝗄$:

Let $𝗀{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝗀}_{𝖽})$, $𝗉𝗄{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝗉{𝗄}_{𝖽})[$, and $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star ={𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾)]$.

and use these in the inputs to $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$.

Replace the lines deriving $𝖾𝗌𝗄$, $𝗋𝖼𝗆$, and $\text{ψ}$ with

Derive $𝖾𝗌𝗄={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗌𝗄,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}})$

Derive $𝗋𝖼𝗆={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,(𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ}[,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star ]))$

Derive $\text{ψ}={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}},𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀)$

#§ 4.8.2 ‘Dummy Notes (Sapling)’

Add

Let ${𝖧}^{𝗋𝖼𝗆,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ be as defined in § 4.7.2 ‘Sending Notes (Sapling)’.

Replace the line deriving $𝗋𝖼𝗆$ with

Derive $𝗋𝖼𝗆={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(\perp ,\perp )$

Correct

A Spend description for a dummy Sapling input note is constructed as follows:

to

A Spend description for a dummy Sapling input note with note plaintext lead byte $\mathrm{𝟶}𝚡\mathrm{𝟶𝟸}$ is constructed as follows:

#§ 4.8.3 ‘Dummy Notes (Orchard)’

Insert before "The spend-related fields ...":

Let $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$ be the note plaintext lead byte, chosen according to § 3.2.1 ‘Note Plaintexts and Memo Fields’ with $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖮𝗋𝖼𝗁𝖺𝗋𝖽$.

Let ${𝖧}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ and ${𝖧}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ be as defined in § 4.7.3 ‘Sending Notes (Orchard)’.

Replace the lines deriving $𝗋𝖼𝗆$ and $\text{ψ}$ with

Let $𝗀{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝗀}_{𝖽})$, $𝗉𝗄{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝗉{𝗄}_{𝖽})[$, and $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star ={𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾)]$.

Derive $𝗋𝖼𝗆={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,(𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ}[,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star ]))$

Derive $\text{ψ}={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}},0)$

and use $𝗀{\star }_{𝖽}$, $𝗉𝗄{\star }_{𝖽}$, and $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star$ in the inputs to $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$.

#§ 4.20.2 and § 4.20.3 ‘Decryption using an Incoming/Full Viewing Key (Sapling and Orchard)’

For both § 4.20.2 and § 4.20.3, replace

Let the constants $𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$ and $𝖹𝖨𝖯\mathrm{𝟤𝟣𝟤}𝖦𝗋𝖺𝖼𝖾𝖯𝖾𝗋𝗂𝗈𝖽$ be as defined in § 5.3 ‘Constants’.

Let $𝗁𝖾𝗂𝗀𝗁𝗍$ be the block height of the block containing this transaction.

with

Let $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅$ and $𝖺𝗅𝗅𝗈𝗐𝖾𝖽𝖫𝖾𝖺𝖽𝖡𝗒𝗍𝖾𝗌$ be as defined in § 3.2.1 ‘Note Plaintexts and Memo Fields’.

Let ${𝖧}^{𝗋𝖼𝗆,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ and ${𝖧}^{\text{esk},𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ be as defined in § 4.7.2 ‘Sending Notes (Sapling)’.

Let ${𝖧}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$, ${𝖧}^{\text{esk},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$, and ${𝖧}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ be as defined in § 4.7.3 ‘Sending Notes (Orchard)’.

Let $𝗁𝖾𝗂𝗀𝗁𝗍$ be the block height of the block containing this transaction, and let $𝗍𝗑𝖵𝖾𝗋𝗌𝗂𝗈𝗇$ be the transaction version.

For § 4.20.3, replace

$$ if $𝖾𝗌𝗄\ge r_{𝔾}$ or $𝗉{𝗄}_{𝖽}=\perp$, return $\perp$

with

$$ if $𝖾𝗌𝗄\ge r_{𝔾}$ or $𝗉{𝗄}_{𝖽}=\perp$ or (for Sapling) $𝗉{𝗄}_{𝖽}\in ̸{𝕁}^{(r)\ast }$ (see note below), return $\perp$

and in the note containing "However, this is technically redundant with the later check that returns $\perp$ if $𝗉{𝗄}_{𝖽}\in ̸{𝕁}^{(r)\ast }$", delete the word "later".

For both § 4.20.2 and § 4.20.3, replace

$$ [Pre-Canopy] if $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\ne \mathrm{𝟶}𝚡\mathrm{𝟶𝟷}$, return $\perp$
$$ [Pre-Canopy] let $\underline{𝗋𝖼𝗆}=𝗋𝗌𝖾𝖾𝖽$
$$ [Canopy onward] if $𝗁𝖾𝗂𝗀𝗁𝗍<𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍+𝖹𝖨𝖯\mathrm{𝟤𝟣𝟤}𝖦𝗋𝖺𝖼𝖾𝖯𝖾𝗋𝗂𝗈𝖽$ and $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\in ̸\{\mathrm{𝟶}𝚡\mathrm{𝟶𝟷},\mathrm{𝟶}𝚡\mathrm{𝟶𝟸}\}$, return $\perp$
$$ [Canopy onward] if $𝗁𝖾𝗂𝗀𝗁𝗍\ge 𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍+𝖹𝖨𝖯\mathrm{𝟤𝟣𝟤}𝖦𝗋𝖺𝖼𝖾𝖯𝖾𝗋𝗂𝗈𝖽$ and $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\ne \mathrm{𝟶}𝚡\mathrm{𝟶𝟸}$, return $\perp$
$$ for Sapling, let $𝗉𝗋𝖾\_𝗋𝖼𝗆=[4]$ and $𝗉𝗋𝖾\_𝖾𝗌𝗄=[5]$
$$ for Orchard, let $\underline{\text{ρ}}={𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝗇{𝖿}^{𝗈𝗅𝖽}$ from the same Action description $)$, $𝗉𝗋𝖾\_𝗋𝖼𝗆=[5]||\underline{\text{ρ}}$, and $𝗉𝗋𝖾\_𝖾𝗌𝗄=[4]||\underline{\text{ρ}}$

with

$$ if $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\in ̸𝖺𝗅𝗅𝗈𝗐𝖾𝖽𝖫𝖾𝖺𝖽𝖡𝗒𝗍𝖾{𝗌}^{𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅}(𝗁𝖾𝗂𝗀𝗁𝗍,𝗍𝗑𝖵𝖾𝗋𝗌𝗂𝗈𝗇)$, return $\perp$
$$ let $\underline{\text{ρ}}={𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝗇{𝖿}^{𝗈𝗅𝖽}$ from the same Action description $)$

For § 4.20.2, replace

$$ [Canopy onward] let $\underline{𝗋𝖼𝗆}=\{\begin{array}{cc}𝗋𝗌𝖾𝖾𝖽,& \text{if }𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=hexint01\\ 𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝗋𝖼𝗆)),& \text{otherwise}\end{array}$
$$ let $𝗋𝖼𝗆={𝖫𝖤𝖮𝖲\mathrm{𝟤}𝖨𝖯}_{256}(\underline{𝗋𝖼𝗆})$ and ${𝗀}_{𝖽}=𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌𝗁(𝖽)$. if $𝗋𝖼𝗆\ge r_{𝔾}$ or (for Sapling) ${𝗀}_{𝖽}=\perp$, return $\perp$
$$ [Canopy onward] if $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\ne hexint01$:
$$ $𝖾𝗌𝗄=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝖾𝗌𝗄))$
$$ if ${𝗋𝖾𝗉𝗋}_{𝔾}(𝖪𝖠.𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼(𝖾𝗌𝗄,{𝗀}_{𝖽}))\ne 𝚎𝚙𝚑𝚎𝚖𝚎𝚛𝚊𝚕𝙺𝚎𝚢$, return $\perp$

$$ let $𝗉{𝗄}_{𝖽}=𝖪𝖠.𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼(𝗂𝗏𝗄,{𝗀}_{𝖽})$

with

$$ let ${𝗀}_{𝖽}=𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌𝗁(𝖽)$; for Sapling, if ${𝗀}_{𝖽}=\perp$, return $\perp$
$$ [Canopy onward] if $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\ne hexint01$:
$$ let $𝖾𝗌𝗄={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗌𝗄,𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅}(\underline{\text{ρ}})$
$$ if ${𝗋𝖾𝗉𝗋}_{𝔾}(𝖪𝖠.𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼(𝖾𝗌𝗄,{𝗀}_{𝖽}))\ne 𝚎𝚙𝚑𝚎𝚖𝚎𝚛𝚊𝚕𝙺𝚎𝚢$, return $\perp$
$$ let $\text{ψ}={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}},0)$ for Orchard or $\perp$ for Sapling

$$ let $𝗉{𝗄}_{𝖽}=𝖪𝖠.𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼(𝗂𝗏𝗄,{𝗀}_{𝖽})$
$$ let $𝗀{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝗀}_{𝖽})$, $𝗉𝗄{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝗉{𝗄}_{𝖽})[$, and $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star ={𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾)]$
$$ let $𝗋𝖼𝗆=\{\begin{array}{cc}{𝖫𝖤𝖮𝖲\mathrm{𝟤}𝖨𝖯}_{256}(𝗋𝗌𝖾𝖾𝖽),& \text{caseif}𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\text{hexint}01\\ {𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,(𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ}[,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star ])),& \text{otherwise}\end{array}$
$$ if $𝗋𝖼𝗆\ge r_{𝔾}$, return $\perp$

(The order of operations has to be altered because the derivation of $𝗋𝖼𝗆$ can depend on ${𝗀}_{𝖽}$ and $𝗉{𝗄}_{𝖽}$.)

For § 4.20.3, replace

$$ [Canopy onward] let $\underline{𝗋𝖼𝗆}=\{\begin{array}{cc}𝗋𝗌𝖾𝖾𝖽,& \text{if }𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=hexint01\\ 𝖳𝗈𝖲𝖼𝖺𝗅𝖺𝗋(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝗋𝖼𝗆)),& \text{otherwise}\end{array}$
$$ let $𝗋𝖼𝗆={𝖫𝖤𝖮𝖲\mathrm{𝟤}𝖨𝖯}_{256}(\underline{𝗋𝖼𝗆})$ and ${𝗀}_{𝖽}=𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌𝗁(𝖽)$
$$ if $𝗋𝖼𝗆\ge r_{𝔾}$ or (for Sapling) ${𝗀}_{𝖽}=\perp$ or $𝗉{𝗄}_{𝖽}\in ̸{𝕁}^{(r)\ast }$ (see note below), return $\perp$

with

$$ let ${𝗀}_{𝖽}=𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌𝗁(𝖽)$; for Sapling, if ${𝗀}_{𝖽}=\perp$, return $\perp$
$$ let $𝗀{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝗀}_{𝖽})[$ and $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star ={𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾)]$
$$ if $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\ne \mathrm{𝟶}𝚡\mathrm{𝟶𝟷}$, let $\text{ψ}={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}},0)$ for Orchard or $\perp$ for Sapling
$$ let $𝗋𝖼𝗆=\{\begin{array}{cc}{𝖫𝖤𝖮𝖲\mathrm{𝟤}𝖨𝖯}_{256}(𝗋𝗌𝖾𝖾𝖽),& \text{caseif}𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\text{hexint}01\\ {𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,(𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ}[,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star ])),& \text{otherwise}\end{array}$
$$ if $𝗋𝖼𝗆\ge r_{𝔾}$, return $\perp$

(Note that there was previously a type error in both § 4.20.2 and § 4.20.3: $𝖳𝗈𝖲𝖼𝖺𝗅𝖺𝗋$ returns an integer, not a byte sequence, and so cannot be assigned to $\underline{𝗋𝖼𝗆}$.)

Delete "where $\text{ψ}=𝖳𝗈𝖡𝖺𝗌{𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([9]||\underline{\text{ρ}}))$".

#§ 5.3 ‘Constants’

Add the definitions

${\ell }_{𝗊𝗌𝗄}⦂\mathbb{N}:=256$
${\ell }_{𝗊𝗄}⦂\mathbb{N}:=256$

#Changes to ZIPs

#ZIP 32

Add a $\ast$ to the arrows leading to $𝖺𝗌𝗄$ and $𝗋𝗂𝗏𝗄$ in the diagram in section ‘Orchard internal key derivation’ ¹¹, with the following note:

$\ast$ The derivations of $𝖺𝗌𝗄$ and $𝗋𝗂𝗏𝗄$ shown in the diagram are not the only possibility. For further detail see § 4.2.3 ‘Orchard Key Components’ in the protocol specification. However, if $𝖺𝗌𝗄$, $𝖺𝗄$, $𝗇𝗄$, $𝗋𝗂𝗏𝗄$, and $𝗋𝗂𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}$ are not generated as in the diagram, then it may not be possible to recover the resulting notes as specified in {{ reference to this ZIP }} in the event that attacks using quantum computers become practical.

#ZIP 212

Add a note before the Abstract:

This ZIP reflects the changes made to note encryption for the Canopy upgrade. It does not include subsequent changes in {{ reference to this ZIP }}.

#ZIP 226

Add the following to the section Note Structure & Commitment:

When § 4.7.3 ‘Sending Notes (Orchard)’ or § 4.8.3 ‘Dummy Notes (Orchard)’ are invoked directly or indirectly in the computation of $\text{ρ}$ and $\text{ψ}$ for an OrchardZSA note, $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$ MUST be set to $\text{hexint}03$.

In section Split Notes, change:

where ${\text{ψ}}^{𝗇𝖿}$ is sampled uniformly at random on ${𝔽}_{q_{\mathbb{P}}}$, ...

to

where ${\text{ψ}}^{𝗇𝖿}$ is computed as ${𝖧}_{𝗋𝗌𝖾𝖾𝖽\_𝗇𝖿}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}},1)=𝖳𝗈𝖡𝖺𝗌{𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽\_𝗇𝖿}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\text{hexint}0A]||\underline{\text{ρ}}))$ for $𝗋𝗌𝖾𝖾𝖽\_𝗇𝖿$ sampled uniformly at random on ${𝔹}^{𝕐[32]}$, ...

#Rationale

#Cryptographic background

This rationale is written primarily for cryptologists and protocol designers familiar with the Zcash shielded protocols. It is recommended to first read the slides of, and/or watch the following presentations:

• Understanding Zcash Security at Zcon3 ¹⁵
• Post-Quantum Zcash at ZconVI ⁷

To understand the modelling of hash function and commitment security against a quantum adversary we also recommend ¹⁶ and ¹⁷.

#Proposed Recovery Protocol

The details of the protocol in this section are subject to change. This description is meant to facilitate analysis of whether the specification changes to be adopted now are likely to be sufficient to securely support a Recovery Protocol.

The proposed Recovery Protocol works, roughly speaking, by enforcing the derivations given in the [Flow diagram for the Orchard and OrchardZSA protocols], and we suggest having that diagram open in another window to refer to it.

Import this definition from § 4.7.3 ‘Sending Notes (Orchard)’:

Let $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$ be the note plaintext lead byte, chosen according to § 3.2.1 ‘Note Plaintexts and Memo Fields’ with $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖮𝗋𝖼𝗁𝖺𝗋𝖽$.

Define ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,(𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ}[,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star ]))=$ $𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝗋𝖼𝗆))$

where $𝗉𝗋𝖾\_𝗋𝖼𝗆=\{\begin{array}{cc}[\text{hexint}05]||\underline{\text{ρ}},& \text{caseif}𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\text{hexint}02\\ [\text{hexint}0B,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾]||{𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{256}(𝗀{\star }_{𝖽})||{𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{256}(𝗉𝗄{\star }_{𝖽})& \\ \phantom{[\text{hexint}0B,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾]}||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{64}(𝗏)||\underline{\text{ρ}}||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(\text{ψ})& \\ \phantom{[\text{hexint}0B,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾]}[||{𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{256}(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star )],& \text{caseif}𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\text{hexint}03\text{.}\end{array}$

Define:

• ${𝖧}_{𝗋\text{ψ}}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}},𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀)=𝖳𝗈𝖡𝖺𝗌{𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}({𝖯𝖱𝖥}_{𝗋\text{ψ}}^{𝖾𝗑𝗉𝖺𝗇𝖽}([𝗌𝗉𝗅𝗂𝗍\_𝖽𝗈𝗆𝖺𝗂𝗇]||\underline{\text{ρ}}))$
  where $𝗌𝗉𝗅𝗂𝗍\_𝖽𝗈𝗆𝖺𝗂𝗇=\{\begin{array}{cc}\text{hexint}09,& \text{caseif}𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀=0\\ \text{hexint}0A,& \text{caseif}𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀=1\text{.}\end{array}$
• ${𝖧}_{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}(𝖺𝗄,𝗇𝗄)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\text{hexint}83]||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝖺𝗄)$ $||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝗇𝗄)))$
• ${𝖧}_{𝗊𝗄}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}(𝖺𝗄,𝗇𝗄)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗊𝗄\phantom{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\text{hexint}84]||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝖺𝗄)$ $||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝗇𝗄)))$
• ${𝒢}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}={𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁}^{\mathbb{P}}(\text{“𝚣.𝚌𝚊𝚜𝚑:𝙾𝚛𝚌𝚑𝚊𝚛𝚍”},\text{“𝙶”})$

A valid instance of a Recovery statement assures that given a primary input:

$\begin{array}{cc}(𝗋{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}& ⦂\{0..q_{\mathbb{P}}-1\},\\ 𝗋𝗄& ⦂𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖯𝗎𝖻𝗅𝗂𝖼),\\ 𝗇𝖿& ⦂{𝔽}_{q_{\mathbb{P}}},\\ 𝖲𝗂𝗀𝖧𝖺𝗌𝗁& ⦂𝖬𝖾𝗌𝗌𝖺𝗀𝖾𝖧𝖺𝗌𝗁)\end{array}$

the prover knows an auxiliary input:

$\begin{array}{cc}(𝗎𝗌𝖾\_𝗊𝗌𝗄& ⦂𝔹,\\ 𝗂𝗌\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅\_𝗋𝗂𝗏𝗄& ⦂𝔹,\\ 𝗉𝖺𝗍𝗁& ⦂\{0..q_{\mathbb{P}}-1{\}}^{[𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}]},\\ 𝗉𝗈𝗌& ⦂\{0..2^{𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}}-1\},\\ K& ⦂{𝔹}^{[{\ell }_{𝗌𝗄}]},\\ 𝝰& ⦂{𝔽}_{r_{\mathbb{P}}},\\ {𝖺𝗄}^{\mathbb{P}}& ⦂{\mathbb{P}}^{\ast },\\ 𝗇𝗄& ⦂{𝔽}_{q_{\mathbb{P}}},\\ 𝗊𝗄& ⦂{𝔹}^{𝕐[{\ell }_{𝗊𝗄}/8]},\\ {\sigma }_{𝗊𝗌𝗄}& ⦂𝖲𝗈{𝖪}^{𝗊𝗌𝗄}((𝗊𝗄),𝖲𝗂𝗀𝖧𝖺𝗌𝗁),\\ 𝗋𝗂𝗏𝗄& ⦂{𝔽}_{r_{\mathbb{P}}},\\ {\sigma }_{𝗌𝗄}& ⦂𝖲𝗈{𝖪}^{𝗌𝗄}(({𝖺𝗄}^{\mathbb{P}},𝗇𝗄,𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍),𝖲𝗂𝗀𝖧𝖺𝗌𝗁),\\ 𝗋𝗌𝖾𝖾𝖽& ⦂{𝔹}^{𝕐[32]},\\ {𝗀}_{𝖽}& ⦂{\mathbb{P}}^{\ast },\\ 𝗏& ⦂\{0..2^{{\ell }_{𝗏𝖺𝗅𝗎𝖾}}-1\},\\ \text{ρ}& ⦂{𝔽}_{q_{\mathbb{P}}})\end{array}$

where

$\begin{array}{ccc}𝖲𝗈{𝖪}^{𝗊𝗌𝗄}.𝖲𝗍𝖺𝗍𝖾𝗆𝖾𝗇𝗍& =\{𝗊𝗌𝗄⦂{𝔹}^{𝕐[{\ell }_{𝗊𝗌𝗄}/8]}& |𝗊𝗄={𝖧}^{𝗊𝗄}(𝗊𝗌𝗄)\}\\ 𝖲𝗈{𝖪}^{𝗌𝗄}.𝖲𝗍𝖺𝗍𝖾𝗆𝖾𝗇𝗍& =\{𝗌𝗄⦂{𝔹}^{[{\ell }_{𝗌𝗄}]}& |{𝖺𝗄}^{\mathbb{P}}=[{𝖧}^{𝖺𝗌𝗄}(𝗌𝗄)]{𝒢}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}\\ & & \wedge 𝗇𝗄={𝖧}^{𝗇𝗄}\\ & & \wedge 𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍={𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}(𝗌𝗄)\}\end{array}$

such that the following conditions hold:

$\begin{array}{c}\{𝗎𝗌𝖾\_𝗊𝗌𝗄\Rightarrow (𝗋𝗄=𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖱𝖺𝗇𝖽𝗈𝗆𝗂𝗓𝖾𝖯𝗎𝖻𝗅𝗂𝖼(\alpha ,{𝖺𝗄}^{\mathbb{P}})\\ \wedge 𝖲𝗈{𝖪}^{𝗊𝗌𝗄}.𝖵𝖺𝗅𝗂𝖽𝖺𝗍𝖾((𝗊𝗄),𝖲𝗂𝗀𝖧𝖺𝗌𝗁,{\sigma }_{𝗊𝗌𝗄})\\ \wedge 𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍={𝖧}_{𝗊}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}𝗄(𝖺𝗄,𝗇𝗄))\\ \wedge \text{not }𝗎𝗌𝖾\_𝗊𝗌𝗄\Rightarrow 𝖲𝗈{𝖪}^{𝗌𝗄}.𝖵𝖺𝗅𝗂𝖽𝖺𝗍𝖾(({𝖺𝗄}^{\mathbb{P}},𝗇𝗄,𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍),𝖲𝗂𝗀𝖧𝖺𝗌𝗁,{\sigma }_{𝗌𝗄})\\ \wedge 𝗋𝗂𝗏𝗄=\{\begin{array}{cc}𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍& \text{if }𝗂𝗌\_𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅=0\\ {𝖧}_{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}(𝖺𝗄,𝗇𝗄)& \text{if }𝗂𝗌\_𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅=1\end{array}\\ \wedge 𝖺𝗄={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}({𝖺𝗄}^{\mathbb{P}})\\ \wedge \text{let }𝗂𝗏𝗄=𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝗂𝗏𝗄}^{𝗂𝗏𝗄}(𝖺𝗄,𝗇𝗄)\\ \wedge 𝗂𝗏𝗄\in ̸\{0,\perp \}\\ \wedge \text{let }𝗉{𝗄}_{𝖽}=[𝗂𝗏𝗄]{𝗀}_{𝖽}\\ \wedge \text{let }\text{ψ}={𝖧}_{𝗋\text{ψ}}^{\text{ψ}}(\underline{\text{ρ}},𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀)\\ \wedge \text{let }𝗇𝗈𝗍𝖾\_𝗋𝖾𝗉𝗋=({𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝗀}_{𝖽}),{𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝗉{𝗄}_{𝖽}),𝗏,\underline{\text{ρ}},\text{ψ}[,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star ])\\ \wedge \text{let }𝗋𝖼𝗆={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\text{hexint}03,𝗇𝗈𝗍𝖾\_𝗋𝖾𝗉𝗋)\\ \wedge \text{let }𝖼𝗆=𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼𝗆}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗇𝗈𝗍𝖾\_𝗋𝖾𝗉𝗋)\\ \wedge 𝖼𝗆\ne \perp \\ \wedge \text{let }{𝖼𝗆}_x={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}(𝖼𝗆)\\ \wedge \text{let }𝗅𝖾𝖺𝖿=𝖬𝖾𝗋𝗄𝗅𝖾𝖢𝖱𝖧({𝖼𝗆}_x,\text{ρ})\\ \wedge 𝗉𝖺𝗍𝗁\text{ is a path to }𝗅𝖾𝖺𝖿\text{ in the rehashed commitment tree}\\ \wedge 𝗇𝖿=𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾{𝗋}_{𝗇𝗄}(\text{ρ},\text{ψ},𝖼𝗆)\\ \}\end{array}$

and $𝗇𝖿$ is the revealed nullifier.

TODO: finish extending this to ZSAs. We need to add ${\text{ψ}}^{𝗇𝖿}$, and enforce $𝗋𝗌𝖾𝖾𝖽\_𝗇𝖿=𝗋𝗌𝖾𝖾𝖽\_𝗈𝗅𝖽$ only if this is a non-split note.

(We don't need to check the derivation of ${𝗀}_{𝖽}$ from $𝖽$.)

#Cost

Note that in the "$𝗎𝗌𝖾\_𝗊𝗌𝗄$" case, two BLAKE2b compressions are required to compute $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$, and in the "not $𝗎𝗌𝖾\_𝗊𝗌𝗄$" cases, three BLAKE2b compressions in total are required to compute ${𝖧}^{𝖺𝗌𝗄}$, ${𝖧}^{𝗇𝗄}$, and ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}$. Since these cases are mutually exclusive, it is possible to multiplex the same three compression function instances. So, supporting "$𝗎𝗌𝖾\_𝗊𝗌𝗄$" in addition to "not $𝗎𝗌𝖾\_𝗊𝗌𝗄$" costs very little extra.

All of the operations below need to be implemented with complete additions, even if they are incomplete in the current Orchard[ZSA] circuit.

• 9 BLAKE2b-512 compressions:
  • 3 to compute $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$
  • 2 to compute ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}$
  • 2 to compute ${𝖧}^{\text{ψ}}$
  • 2 to compute ${𝖧}^{𝗋𝖼𝗆}$
    • we could potentially save these two by using Poseidon to implement ${𝖧}^{𝗋𝖼𝗆}$, but it seems not worth it.
• 1 use of ${𝖧}^{𝗊𝗄}$
• 1 use of $𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}$ ($𝖲𝗂𝗇𝗌𝖾𝗆𝗂𝗅𝗅𝖺𝖲𝗁𝗈𝗋𝗍𝖢𝗈𝗆𝗆𝗂𝗍$)
• 1 use of $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ ($𝖲𝗂𝗇𝗌𝖾𝗆𝗂𝗅𝗅𝖺𝖢𝗈𝗆𝗆𝗂𝗍$)
• 1 full-width fixed-base Pallas scalar multiplication, $[𝖺𝗌𝗄]{𝒢}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$
• 1 full-width variable-base Pallas scalar multiplication, $[𝗂𝗏𝗄]{𝗀}_{𝖽}$
• 1 Merkle tree path check
• 1 additional use of $𝖬𝖾𝗋𝗄𝗅𝖾𝖢𝖱𝖧$ to compute $𝗅𝖾𝖺𝖿$.

The expensive parts of this are the 9 BLAKE2b compressions.

#Security analysis

Let us consider the security of the Orchard protocol against a discrete-log-breaking adversary — which by definition includes quantum adversaries. Similar attacks apply to the Sapling protocol.

Suppose that the proof system has been replaced by one that is post-quantum knowledge-sound.

#Repairing the note commitment Merkle tree

$𝖬𝖾𝗋𝗄𝗅𝖾𝖢𝖱{𝖧}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ is instantiated using $𝖲𝗂𝗇𝗌𝗂𝗆𝗂𝗅𝗅𝖺𝖧𝖺𝗌𝗁$ ¹⁸. Its collision resistance depends on the discrete log relation problem on the Pallas curve ¹⁹, and so it is not post-quantum collision-resistant or collapsing. However, because the note commitment tree is public, it is possible to re-hash all of its leaves to construct a new Merkle tree using a collapsing hash function. Suppose this has been done.

The post-quantum security of Merkle trees —considered as position-binding vector commitments which is the property required by Zcash ¹⁵— is proven under reasonable assumptions in ²⁰ and ²¹.

Note: when we rehash the commitment tree, we could include both $\text{ρ}$ and ${𝖼𝗆}_x$ for each note (i.e. what is currently the leaf layer becomes $𝖬𝖾𝗋𝗄𝗅𝖾𝖢𝖱𝖧(\text{ρ},{𝖼𝗆}_x)$ where $𝖬𝖾𝗋𝗄𝗅𝖾𝖢𝖱𝖧$ is pq-collision-resistant). This change might not be necessary; it just removes potential complications due to duplicate commitments for the same note.

#Attacks against binding of note commitments

We still face the problem that $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ is not binding against a discrete-log-breaking adversary: given the discrete log relations between bases, we can easily write a linear equation in the scalar field with multiple solutions of the inputs for a given commitment.

This allows an adversary to find two distinct notes corresponding to openings of $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ on the same commitment. They create one note as an output and spend the other note — which may have a greater value, or a value in a different ZSA asset, breaking the Balance property.

#Repairing note commitments

We prefer to fix this without changing $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ itself. Instead we change how $𝗋𝖼𝗆$ is computed to be a hash of $𝗋𝗌𝖾𝖾𝖽$ and $𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋=(𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ}[,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\star ])$, as detailed in the [Specification] section. Specifically, when $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\text{hexint}03$ we have:

$𝗋𝖼𝗆={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝗋𝖼𝗆))$

$\text{where }𝗉𝗋𝖾\_𝗋𝖼𝗆=[\text{hexint}0B,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾]||𝖾𝗇𝖼𝗈𝖽𝖾(𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$

Then we view the output of $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼𝗆}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$ as the point addition of a randomization term $[{𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)]ℛ$, and some other function of $𝗋𝗌𝖾𝖾𝖽$, $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$, and $𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋$.

Without loss of generality, we can write that function as $[f(𝗋𝗌𝖾𝖾𝖽,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)]ℛ$, by expanding each of the Sinemilla bases ${𝒞}_j=𝒬(D)\text{ or }𝒮(j)$ used by $𝖧𝖺𝗌𝗁𝖳𝗈𝖲𝗂𝗇𝗌𝗂𝗆𝗂𝗅𝗅𝖺𝖯𝗈𝗂𝗇𝗍$ as ${𝒞}_j=[c_j]ℛ$ for some $c_j$. That is, $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼𝗆}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)=[{𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)+f(𝗋𝗌𝖾𝖾𝖽,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)]ℛ.$

First we informally argue security in the classical ROM. We will model ${𝖧}^{𝗋𝖼𝗆}$ as a random oracle independent of $f$ with uniform output on ${𝔽}_{r_{\mathbb{P}}}$. This is reasonable because ${𝖧}^{𝗋𝖼𝗆}$ cannot depend on any of the $c_j$, and in any case it is likely to be a conventional hash function not related to the Pallas curve.

The fact that $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ has $\text{ψ}={𝖧}^{\text{ψ}}(𝗋𝗌𝖾𝖾𝖽,\text{ρ})$ as an input does not affect the analysis provided that ${𝖧}^{𝗋𝖼𝗆}$ and ${𝖧}^{\text{ψ}}$ can be treated as independent. In practice both are defined in terms of $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}$, but with strict domain separation, and so the assumption of independence is reasonable as long as BLAKE2b-512 can be modelled as a random oracle. Note that since the input to ${𝖧}^{𝗋𝖼𝗆}$ needs more than one BLAKE2b input block, we require that a HAIFA sponge can be modelled as a random oracle which is justified by ²².

For each ${𝖧}^{𝗋𝖼𝗆}$ oracle query the adversary chooses $𝗋𝗌𝖾𝖾𝖽,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋$ and obtains a "random" $𝗋𝖼𝗆={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$, such that the distribution of $𝗋𝖼𝗆+[f(𝗋𝗌𝖾𝖾𝖽,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)]ℛ$ is computationally indistinguishable from the uniform distribution on ${𝔽}_{r_{\mathbb{P}}}$. Therefore ${𝖼𝗆}_x={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}([{𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)+f(𝗋𝗌𝖾𝖾𝖽,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)]ℛ)$ is computationally indistinguishable from an output of ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}$ applied to uniformly distributed Pallas curve points. The number of such outputs is $({𝔽}_{r_{\mathbb{P}}}+1)/2$ (one for each possible $x$-coordinate of Pallas curve points, plus one for the zero point ${𝒪}_{\mathbb{P}}$ which is mapped to $0$).

Only one point maps to $0$, as opposed to two points mapping to every other possible output of ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}$, but that has negligible effect.

The number of queries needed to find a collision therefore follows a distribution negligibly far from that expected for a collision attack on an ideal hash function mapping from the input domain to a set of size $({𝔽}_{r_{\mathbb{P}}}+1)/2\approx 2^{253}$.

In order to adapt this argument to the quantum setting, we need to consider collapsing hash functions as defined in ^{16 17}.

TODO: ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}$ is not collapsing. Is ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}([{𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)+f(𝗋𝗌𝖾𝖾𝖽,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)]ℛ)$ collapsing?

By the argument in ²³, the best known generic quantum attack on a hash function is simply the classical attack of ²⁴. (In particular, the Brassard–Høyer–Tapp algorithm ²⁵ is entirely unimplementable for a 253-bit output size: to achieve the claimed speed-up, it would require running Grover's algorithm with a quantum circuit that does random accesses to a $2^{92.3}$-bit quantum memory.) Therefore, an output size of 253 bits does not exclude a hash function from being post-quantum collision-resistant. It is possible that there could be better-than-generic quantum attacks against BLAKE2b, but none have been published to our knowledge. In practice, we consider it reasonable to assume that BLAKE2b-512 has the properties needed for ${𝖧}^{𝗋𝖼𝗆}$ to be post-quantum collision-resistant.

TODO: discuss ²⁶ (sponge security), ^{16 17} (collapse-binding property).

The above security argument means that provided we also check the uses of ${𝖧}^{𝗋𝖼𝗆}$ and ${𝖧}^{\text{ψ}}$ in the post-quantum recovery circuit, Orchard note commitments can be considered binding on all of the note fields.

Note that the argument associated with Theorem 5.4.4 in the protocol specification ("A $\perp$ output from $𝖲𝗂𝗇𝗌𝖾𝗆𝗂𝗅𝗅𝖺𝖧𝖺𝗌𝗁𝖳𝗈𝖯𝗈𝗂𝗇𝗍$ yields a nontrivial discrete log relation." and "Since by assumption it is hard to find a nontrivial discrete logarithm relation, we can argue that it is safe to use incomplete additions when computing Sinsemilla inside a circuit.") is not applicable when it is necessary to defend against a discrete-log-breaking or quantum adversary. Therefore, the post-quantum recovery circuit will need to use complete curve additions to implement Sinsemilla.

#Attacks against binding of ivk

The security of Orchard against double-spending also depends on the binding property of $𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}$. Informally, the security argument is that there is only one value of $𝗂𝗏𝗄$ corresponding to a given $({𝗀}_{𝖽},𝗉{𝗄}_{𝖽})$ (which are committed to by the note commitment), and so this binds $𝗇𝗄$ and $𝖺𝗄$ to the correct values for the committed note.

If the binding property of $𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}$ fails, then so do the security arguments for the Balance and Spend Authorization properties, because we can no longer infer that $𝗇𝗄$ and $𝖺𝗄$ are the correct values.

Fortunately, the Orchard protocol specified $𝗋𝗂𝗏𝗄$ to be derived from $𝗌𝗄$.

(There is a complication in that $𝗋𝗂𝗏𝗄$ is derived differently for an "internal IVK".)

We use essentially the same fix as for $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$, with $𝗋𝗂𝗏𝗄$ in place of $𝗋𝖼𝗆$.

There is a complication: contrary to the situation with note commitments, addresses may be used over the long term and it may not be feasible or desirable to switch to new addresses.

#Informal Security Argument

The argument is that if ${𝖧}^{𝗋𝖼𝗆}$ and ${𝖧}^{\text{φ}}$ are random oracles, $𝗋𝖼𝗆$ is an unpredictable function of the note fields. There are two values of $𝖼𝗆$ that match ${𝖼𝗆}_x$ in their $x$-coordinate. Because the output of $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ is of the form $𝖼𝗆=F(𝗇𝗈𝗍𝖾)+[𝗋𝖼𝗆]ℛ$, for any given note we have exactly two values of $𝗋𝖼𝗆$ that will pass the commitment check.

Suppose there are $N$ legitimate notes in the tree. The adversary is trying to find (possibly using a Grover search) a note that will pass the commitment check without actually being a note in the tree. The success probability for each attempt in a classical search is $2N/r_{\mathbb{P}}$ where $r_{\mathbb{P}}$ is the order of the Pallas curve, and that is negligible because $N\le 2^{32}\ll r_{\mathbb{P}}$. This is also infeasible for a quantum adversary using a Grover search.

We're not finished yet because we also have to prove that the nullifier is computed deterministically for a given note.

All of the inputs to $𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾𝗋$ are things we committed to in the protocol so far except $𝗇𝗄$. By the same argument used pre-quantumly, there is only one $𝗂𝗏𝗄$ for a given $({𝗀}_{𝖽},𝗉{𝗄}_{𝖽})$. So in order to just use the existing protocol for this part, we would need to prove that there is only one $𝗇𝗄$ (that is feasible to find) such that $𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝗂𝗏𝗄}^{𝗂𝗏𝗄}(𝖺𝗄,𝗇𝗄)=𝗂𝗏𝗄$. Unfortunately that's not true; $𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}$ is instantiated by $𝖲𝗂𝗇𝗌𝖾𝗆𝗂𝗅𝗅𝖺𝖲𝗁𝗈𝗋𝗍𝖢𝗈𝗆𝗆𝗂𝗍$ which is not post-quantum binding.

There are two cases depending on $𝗎𝗌𝖾\_𝗊𝗌𝗄$ (the adversary can choose to attack either):

• Case $𝗎𝗌𝖾\_𝗊𝗌𝗄=0$: The spender must prove knowledge of $𝗌𝗄$, and that $𝖺𝗄$, $𝗇𝗄$, and $𝗋𝗂𝗏𝗄$ are derived correctly from $𝗌𝗄$. This works because the derivations use post-quantum hashes (and $𝖺𝗌𝗄\to 𝖺𝗄$ is deterministic).
  
  In particular, $𝗂𝗏𝗄$ is an essentially random function of $𝗌𝗄$, and so we expect that an adversary has no better attack than to search for values of $𝗌𝗄$ (possibly using a Grover search) to find one that reproduces a given $𝗂𝗏𝗄$. Since $𝗂𝗏𝗄$ must be an $x$-coordinate of a Pallas curve point (see the note at the end of § 4.2.3 Orchard Key Components), it can take on $(r_{\mathbb{P}}-1)/2$ values. So if there are $T$ targets the success probability for each attempt in a classical search is $2T/(r_{\mathbb{P}}-1)$, which is negligible provided that $T\ll r_{\mathbb{P}}$. This is also infeasible for a quantum adversary using a Grover search for reasonable values of $T$.

• Case $𝗎𝗌𝖾\_𝗊𝗌𝗄=0$: This case is almost the same except that $𝗂𝗏𝗄$ is now an essentially random function of $(𝗇𝗄,𝖺𝗄,𝗊𝗄)$. The success probability in terms of $T$ is also the same as for $𝗎𝗌𝖾\_𝗊𝗌𝗄=0$.

#Security argument for Spendability

DeriveNullifier is based on a Pedersen hash. In the current Orchard protocol, the property that it is infeasible to find two distinct Orchard notes with the same nullifier (including possible nullfiers of split OrchardZSA notes), depends on the collision-resistance of that hash, which would not hold against a discrete-log-breaking adversary.

Does this mean it is possible to break Spendability for the given Recovery circuit? As it turns out, no, but the argument is somewhat involved.

TODO: this argument is too handwavy and depends on the ROM; it needs further work for a quantum adversary. Also it is incomplete because it does not consider split notes.

Since each function in the Recovery circuit is deterministic, the free variables that the adversary can control are the sources of the derivation digraph within that circuit and either $𝖲𝗈{𝖪}^{𝗌𝗄}$ or $𝖲𝗈{𝖪}^{𝗊𝗄}$. That is, the adversary can control:

• $(\text{ρ},{𝗀}_{𝖽},𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀,𝗋𝗌𝖾𝖾𝖽,𝗋𝗌𝗉𝗅𝗂𝗍,𝗂𝗌\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅\_𝗋𝗂𝗏𝗄,𝗎𝗌𝖾\_𝗊𝗌𝗄)$ and
  • $𝗌𝗄$, when $𝗎𝗌𝖾\_𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾$;
  • $(𝗇𝗄,𝖺𝗄,𝗊𝗌𝗄)$, when $𝗎𝗌𝖾\_𝗊𝗌𝗄=𝗍𝗋𝗎𝖾$.

As we argued earlier in section [Repairing note commitments], $𝗋𝖼𝗆$ binds $𝗋𝗌𝖾𝖾𝖽$ and $𝗉𝗋𝖾\_𝗋𝖼𝗆$, and all of the other inputs to $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍$ are also included in $𝗉𝗋𝖾\_𝗋𝖼𝗆$. Therefore, given the independence assumption between ${𝖧}^{𝗋𝖼𝗆}$ and $f$ described earlier, $𝖼𝗆$ binds all of the values in the Recovery circuit that the adversary can control.

We can then analyze $𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾𝗋$ in essentially the same way we analyzed $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍$.

First consider $𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀=𝖿𝖺𝗅𝗌𝖾$.

Recall that $𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾𝗋$ is defined in § 4.16 ‘Computing ρ values and Nullifiers’ as:

$𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾{𝗋}_{𝗇𝗄}(\text{ρ},\text{ψ},𝖼𝗆)={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}\left(\right[𝖯𝖱{𝖥}_{𝗇𝗄}^{𝗇𝖿𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\text{ρ})+\text{ψ})mod{q}_{\mathbb{P}}]{𝒦}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}+𝖼𝗆)$

Also recall from [Repairing note commitments] that we have

$𝖼𝗆=[{𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)+f(𝗋𝗌𝖾𝖾𝖽,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)]ℛ.$

When $𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀=𝖿𝖺𝗅𝗌𝖾$, $\text{ψ}$ is determined by $𝗋𝗌𝖾𝖾𝖽$. The nullifier corresponding to $(𝗇𝗄,\text{ρ},𝗋𝗌𝖾𝖾𝖽,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$ is then ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}([{𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)+f(𝗋𝗌𝖾𝖾𝖽,𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)+g(𝗇𝗄,\text{ρ},𝗋𝗌𝖾𝖾𝖽)]ℛ)$

for some $g$ depending on the discrete logarithm of ${𝒦}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ wrt $ℛ$.

The intuition is that an adversary cannot vary any of the inputs it controls without causing an unpredictable change to both $𝖼𝗆$ and $𝗇𝖿$. This is because every such input goes through a function that can be modelled as a random oracle on the way to deriving $𝖼𝗆$ and $𝗇𝖿$:

• $\text{ρ}$ goes through ${𝖧}^{\text{ψ}}$ to derive $\text{ψ}$, and through $𝖯𝖱{𝖥}_{𝗇𝗄}^{𝗇𝖿𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ which is instantiated as Poseidon to derive $𝗇𝖿$;
• ${𝗀}_{𝖽}$ goes through ${𝖧}^{𝗋𝖼𝗆}$;
• because ${𝗀}_{𝖽}\mapsto 𝗉{𝗄}_{𝖽}=[𝗂𝗏𝗄]{𝗀}_{𝖽}$ is 1-1, any change to $𝗂𝗏𝗄$ for a given ${𝗀}_{𝖽}$ results in a change to $𝗉{𝗄}_{𝖽}$, which goes through ${𝖧}^{𝗋𝖼𝗆}$;
• when $𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀=𝖿𝖺𝗅𝗌𝖾$, $𝗋𝗌𝖾𝖾𝖽$ goes through ${𝖧}^{\text{ψ}}$ and then ${𝖧}^{𝗋𝖼𝗆}$;
• $𝗎𝗌𝖾\_𝗊𝗌𝗄$ only has two possible values, and therefore can't increase the adversary's advantage by more than a factor of $2$ provided that both alternatives are otherwise secure;
• when $𝗎𝗌𝖾\_𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾$:
  • $𝗌𝗄$ goes through ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}$;
  • $𝗇𝗄$ goes through ${𝖧}^{𝗇𝗄}$;
  • $𝖺𝗄$ goes through ${𝖧}^{𝖺𝗌𝗄}$;
• when $𝗎𝗌𝖾\_𝗊𝗌𝗄=𝗍𝗋𝗎𝖾$:
  • $𝗊𝗌𝗄$ goes through ${𝖧}^{𝗊𝗄}$ and ${𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}$;
  • $𝗇𝗄$ goes through ${𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}$;
  • $𝖺𝗄$ goes through ${𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}$;

Note that while $f$ and $g$ are individually random oracles on their inputs, their sum modulo $q_{\mathbb{P}}$ could potentially be subject to a meet-in-the-middle attack. This might be possible if the inputs that the adversary can control could be split so that some affect only ${𝖧}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ and $f$, and others affect only $g$. (Note that ${𝖧}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ and $f$ have the same inputs and are each random oracles on all of their inputs.) But $𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋$ includes $\text{ρ}$, and we have already established that $𝗇𝗄$ cannot be varied without affecting $𝗉{𝗄}_{𝖽}$. So with a little work we can see that such splitting is not possible.

TODO $𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀=𝗍𝗋𝗎𝖾$.

An adversary could also attempt to cause a collision in $𝗇𝖿$ by causing a collision on ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}$, but this is also not feasible if ${𝖧}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ can be modelled as a random oracle.

#Effects of discrete-log-breaking attacks before the switch to the Recovery Protocol

TBD: explain that such attacks can break Balance and Spendability, including Spendability for transactions after switching to the Recovery Protocol.

Note that we can identify the precise set of note commitments for recoverable (lead byte $\text{hexint}03$) Orchard notes, since they are the commitments for Orchard outputs of v6 transactions. However, we cannot identify the precise set of nullifiers for recoverable notes: an Orchard action in a v6 transaction could be spending either a recoverable or non-recoverable note, and their nullifier sets are indistinguishable.

On the other hand, within the recovery circuit we know that the note being spent is recoverable.

#Deployment

As far as I'm aware, all existing Zcash wallets already derive $(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄)$ from a spending key $𝗌𝗄$ in the way specified for the $𝗎𝗌𝖾\_𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾$ case in § 4.2.3 Orchard Key Components.

FROST distributed key generation requires the $𝗎𝗌𝖾\_𝗊𝗌𝗄=𝗍𝗋𝗎𝖾$ case. There is no significant existing deployment of FROST, so we can write this into ZIP 312 from the start.

The part of the protocol that is new is the different input for $𝗉𝗋𝖾\_𝗋𝖼𝗆$. It would have been possible to use a separate pq-binding commitment, but ${𝖧}^{𝗋}𝖼𝗆$ is already pq-binding and so doing it this way involves fewer components. This also allows us to avoid any security compromise and use 256-bit cryptovalues for both integrity and randomization, which would otherwise have been difficult.

It is suggested to deploy this change with v6 transactions. That is, every Orchard output of a v6-onward transaction will be a pq-recoverable note. This implies that when the pre-quantum protocol is turned off, v5 and earlier outputs will no longer be spendable. Since v6 already changes the note encryption in order to support memo bundles and ZSAs, this approach to deployment reduces the risk of the kind of difficulties that occurred with ZIP 212, where some wallets were following the old protocol after the Canopy upgrade and sending non-conformant note plaintexts.

When a compliant wallet receives an Orchard note in a v5 or earlier transaction, the associated funds are not pq-recoverable and need to be spent to v6 in order to make them so.

Note: if we prioritize spending non-pq-recoverable notes, it is conceivable that an adversary could exploit this to improve arity leakage attacks. On the other hand, adversaries can already choose note values to manipulate the note selection algorithm to some extent.

#References

#Footnotes

1. Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" ↩

2. ZIP 200: Network Upgrade Mechanism ↩

3. Zcash Protocol Specification, Version 2025.6.1 [NU6.1] or later ↩

4. Zcash Protocol Specification, Version 2025.6.1 [NU6.1]. Section 3.12: Mainnet and Testnet ↩

5. ZIP 226: Transfer and Burn of Zcash Shielded Assets ↩ ↩² ↩³ ↩⁴ ↩⁵

6. ZIP 227: Issuance of Zcash Shielded Assets ↩ ↩² ↩³ ↩⁴

7. Post-Quantum Zcash (video, slides). Presentation by Daira-Emma Hopwood at ZconVI. ↩ ↩²

8. ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling child key derivation ↩

9. ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling internal key derivation ↩

10. ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard child key derivation ↩

11. ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard internal key derivation ↩ ↩²

12. ZIP 231: Memo Bundles ↩ ↩² ↩³

13. ZIP 312: FROST for Spend Authorization Multisignatures ↩

14. ZIP 312: FROST for Spend Authorization Multisignatures — Key Generation ↩

15. Understanding Zcash Security (video, slides). Presentation by Daira-Emma Hopwood at Zcon3. ↩ ↩²

16. Computationally binding quantum commitments. Dominique Unruh. ↩ ↩² ↩³

17. Collapse-binding quantum commitments without random oracles. Dominique Unruh. ↩ ↩² ↩³

18. Zcash Protocol Specification, Version 2025.6.1 [NU6.1]. Section 5.4.1.9: Sinsemilla Hash Function ↩

19. Zcash Protocol Specification, Version 2025.6.1 [NU6.1]. Section 5.4.1.9: Sinsemilla Hash Function — Security argument ↩

20. Post-Quantum Succinct Arguments: Breaking the Quantum Rewinding Barrier. Alessandro Chiesa, Fermi Ma, Nicholas Spooner, and Mark Zhandr. ↩

21. Quantum Rewinding for IOP-Based Succinct Arguments. Alessandro Chiesa, Marcel Dall'Agnol, Zijing Di, Ziyi Guan, and Nicholas Spooner. ↩

22. The Sponge is Quantum Indifferentiable. Gorjan Alagic, Joseph Carolan, Christian Majenz, and Saliha Tokat. ↩

23. Cost analysis of hash collisions: Will quantum computers make SHARCS obsolete? Daniel J. Bernstein. ↩

24. Parallel collision search with cryptanalytic applications. Paul C. van Oorschot and Michael Wiener. ↩

25. Quantum Algorithm for the Collision Problem. Gilles Brassard, Peter Høyer, and Alain Tapp. ↩

26. Post-quantum security of the sponge construction. Jan Czajkowski, Leon Groot Bruinderink, Andreas Hülsing, Christian Schaffner, and Dominique Unruh. ↩