# ZIP 2005: Ironwood Quantum Recoverability

Status: Proposed

Owners: Daira-Emma Hopwood, Jack Grigg

Snapshot: a34cfc091434275120ff017c92c3b50d3cef623a

Source date: 2026-10-16T02:56:04+01:00

[Source revision](https://github.com/zcash/zips/commit/a34cfc091434275120ff017c92c3b50d3cef623a)

[Official source](https://zips.z.cash/zip-2005) · [Source file](https://github.com/zcash/zips/blob/a34cfc091434275120ff017c92c3b50d3cef623a/zips/zip-2005.md) · [Discussion](https://github.com/zcash/zips/issues/1135)

## Document parts

[Part 1](https://zips.tools/zip/2005) · [Part 2](https://zips.tools/zip/2005?part=2) · [Part 3](https://zips.tools/zip/2005?part=3) · [Part 4](https://zips.tools/zip/2005?part=4)

Reading part 4 of 4. Follow all parts for the complete proposal.

By the argument in <a id="user-content-fnref-bernstein2009-2"></a>
[40](#user-content-fn-bernstein2009), the best known **generic** quantum
attack on a hash function is simply the classical attack of <a id="user-content-fnref-vow1999"></a>
[44](#user-content-fn-vow1999).
(In particular, the Brassard–Høyer–Tapp algorithm <a id="user-content-fnref-bht1997"></a>
[45](#user-content-fn-bht1997) 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 collapsing.

$\mathsf{Extract}_{\mathbb{P}}$ does not interfere with the QROM lift:
it is a deterministic 2-to-1 map on non-identity Pallas points (sending $P$
and $-P$ to the same $x$-coordinate) and does not query
$\mathsf{H^{rcm}}$ or any other random oracle, so it composes with the
underlying random oracle the same way classically and quantumly. The
factor of 2 from the 2-to-1 reduction is already absorbed into the
break-probability bound (each $\mathsf{cm}_x$ has exactly two valid
$\mathsf{cm}$ values, hence exactly two valid $\mathsf{rcm}$ values, as
stated in the Spendability proof above).

This factor-of-2 absorption relies on the
[fibres](https://en.wikipedia.org/wiki/Fiber_%28mathematics%29) $\{P, -P\}$
of $\mathsf{Extract}_{\mathbb{P}}$ forming a **uniform** partition of the
non-identity points of $\mathbb{P}$ — the free $\mathbb{Z}/2$ negation action
gives every fibre for non-identity points exactly size 2 — which is what lets
birthday-style bounds substitute $r_{\mathbb{P}} \to r_{\mathbb{P}}/2$ cleanly.
A non-uniform mapping would not admit such a substitution.

#### QROM lift of the security arguments

The classical-ROM reductions for both
[Spendability](/zip/2005?part=3#thm-spendability-collide) and
[key binding](/zip/2005?part=3#thm-key-binding-rom) satisfy the standard conditions for
a "clean" lift to the quantum random-oracle model:

- *Straight-line.* Neither reduction rewinds the adversary or measures
  intermediate state; both inspect the adversary's classical output and
  bound the probability over the random oracles' randomness.
  Rewinding-based QROM techniques <a id="user-content-fnref-cmsz2021-2"></a>
  [34](#user-content-fn-cmsz2021) <a id="user-content-fnref-cddgs2025-2"></a>
  [36](#user-content-fn-cddgs2025) are therefore
  not needed.

- *No adaptive reprogramming.* Both reductions treat their random
  oracles as fixed random functions throughout; neither reprograms
  responses to adversary-queried inputs.

**Concrete QROM bounds.** By Zhandry's compressed-oracle technique
<a id="user-content-fnref-zhandry2018"></a>
[46](#user-content-fn-zhandry2018) (see also <a id="user-content-fnref-cfhl2021"></a>
[47](#user-content-fn-cfhl2021) for a classical-style derivation),
the classical $q^2 / N$ collision probability
transfers to $O(q^3 / N)$ in QROM: an adversary making at most $q$
quantum queries to a random oracle with output space of size $N$
finds a collision with probability $O(q^3 / N)$. Applied to our
reductions:

- $\varepsilon^{\mathsf{QROM}}_{\mathsf{Spendability}} \leq O\!\left(q_{\mathsf{rcm}}^3 / r_{\mathbb{P}}\right) + \varepsilon^{\mathsf{QROM}}_{\mathsf{kb}}$.

- $\varepsilon^{\mathsf{QROM}}_{\mathsf{kb}} \leq O\!\left(q_{\mathsf{kb}}^3 / r_{\mathbb{P}}\right)$.

These are worst-case theoretical bounds. An adversary that saturates
them would need to mount a BHT-style attack, which is unimplementable
for a 253-bit output (as discussed above, the BHT algorithm would
require a quantum circuit randomly accessing a $2^{92.3}$-bit quantum
memory). In practice the achievable bound remains close to the
classical $q^2 / r_{\mathbb{P}}$, since the best **known** generic
quantum attack is the classical attack of <a id="user-content-fnref-vow1999-2"></a>
[44](#user-content-fn-vow1999) — Bernstein
<a id="user-content-fnref-bernstein2009-3"></a>
[40](#user-content-fn-bernstein2009) is careful to flag this as best-known rather than
provably best.

For the parameters relevant to Zcash ($q_{\mathsf{rcm}},
q_{\mathsf{kb}} \ll 2^{60}$ and $r_{\mathbb{P}} \approx 2^{254}$),
the $O(q^3 / r_{\mathbb{P}})$ worst-case bound is at most
$\sim 2^{-74}$, while the practically achievable
$O(q^2 / r_{\mathbb{P}})$ bound stays closer to $\sim 2^{-134}$.

<a id="effects-of-discrete-logarithm-breaking-attacks-before-the-switch-to-the-recovery-protocol"></a>

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

A practical discrete-logarithm-breaking attack —either by a sufficiently
large quantum computer running Shor's algorithm, or a major advance in
classical cryptanalysis of the discrete logarithm or Diffie–Hellman problems—
would compromise the cryptographic primitives underlying Zcash's shielded
protocols.

Note and value commitments in the Orchard[ZSA] and Sapling protocols are
Pedersen-style and lose binding; the proof systems used in the shielded
protocols (Halo 2 over Vesta in Orchard[ZSA], Groth16 over BLS12-381 in Sapling
or Sprout) lose soundness; and the RedDSA binding and spend authorization
signatures in Orchard[ZSA] and Sapling can be forged. Sprout's note commitments are
SHA-256-based and survive a discrete logarithm break, but the broken proof system
is sufficient to forge JoinSplit statements, and the Ed25519 spend authorization
and JoinSplit signatures can be forged. In addition, the ECDSA signatures used for
transparent spend authentication can be forged.

The combined effect is severe. An adversary can:

- break **Balance** for *any current shielded pool* by forging Groth16 or Halo 2
  proofs of balanced transactions;

- break **Balance** (alternatively) for the *Sapling*, *Orchard*, or
  *Ironwood pools* by forging value-commitment openings or binding signatures;

- break **Spend authentication** (i.e. steal funds, independently of a Balance
  break) for *any current shielded pool* by forging alternative note witnesses
  for any commitment on chain, or by forging Groth16 or Halo 2 proofs of valid
  spends;

- break **Spend authentication** (alternatively) for the *Sapling*, *Orchard*,
  or *Ironwood* pools by forging RedJubjub or RedPallas spend authorization
  signatures;

- break **Spend authentication** for the *transparent pool* by forging
  ECDSA-over-secp256k1 signatures used in scripts, provided that the public key
  has been revealed (i.e. if the address has been spent from previously, or if
  an attack is possible in the period between a transaction being exposed and it
  being confirmed);

- break **Spendability** for *any current shielded pool* via roadblock attacks
  or Faerie Gold attacks, preventing users from spending their own funds;

- break **Privacy** of note plaintexts for *any current shielded pool* by
  finding the $\mathsf{ivk}$ or $\mathsf{sk_{enc}}$ for any **known** shielded
  receiver address, or by breaking the Diffie–Hellman-based note encryption
  (again only for a **known** shielded receiver address).

Attacks against **Balance** for any current shielded pool, and against
**Spend authentication** and **Spendability** for any (potentially unknown)
shielded address, can be performed after finding only a single discrete
logarithm. (More precisely, one logarithm on BLS12-381 suffices for attacks
against Sprout and Sapling, and one on Pallas/Vesta for attacks against Orchard
and Ironwood.)

Note that *any current shielded pool* includes the *Ironwood pool*. The Quantum
Recoverability feature of the *Ironwood pool* does not make the Orchard protocol
secure against quantum attacks. It is still imperative that Zcash switches off
the Orchard, Sapling, and Sprout protocols, **before** attacks using quantum
computers become feasible.

If a balance violation occurred in any pool before its protocol was switched
off, it would not necessarily be detected. The only constraint on such attacks
is the ZIP 209 turnstile mechanism <a id="user-content-fnref-zip-0209"></a>
[48](#user-content-fn-zip-0209). If there were evidence of
balance violation having occurred, confidence in Zcash as a whole could
potentially be undermined despite the turnstile constraints (especially if the
violation was in the largest pool, currently the *Orchard pool*). Therefore,
it will be essential to ensure that the pre-quantum protocols are switched off
well in advance of the potential availability of cryptographically relevant
quantum computers.

Attacks on transparent spend authentication are not addressed by this proposal.
<a id="user-content-fnref-google2025"></a>
[49](#user-content-fn-google2025) discusses these attacks in the context of Bitcoin. For Zcash, we
should note that P2PK and legacy P2MS (non-P2SH) scripts have never been
supported by Zcash wallets, but Zcash is vulnerable to "on-spend" attacks in a
similar way to Bitcoin, with the additional consideration that some Zcash
wallets might be more likely to reuse transparent addresses. The discussion
of Segwit in <a id="user-content-fnref-google2025-2"></a>
[49](#user-content-fn-google2025) is not relevant to Zcash. The possibility of
Quantum Recoverability support for a subset of transparent addresses is
discussed in <a id="user-content-fnref-zips-issue1302"></a>
[50](#user-content-fn-zips-issue1302).

<a id="effects-of-discrete-logarithm-breaking-attacks-after-the-switch-to-the-recovery-protocol"></a>

### Effects of discrete-logarithm-breaking attacks after the switch to the Recovery Protocol

We assume for this section that the legacy Orchard, OrchardZSA (if deployed),
Sapling, and Sprout protocols will be switched off. Any remaining funds in
the *Orchard*, *Sapling*, and *Sprout pools* would be rendered permanently
unspendable.

It is anticipated that from the *Ironwood pool* onward, any future pools would
be quantum-recoverable.

It is possible to enable the Recovery Protocol in advance of switching off the
legacy protocols, but the benefit is only obtained for the protocol as a whole
after the latter has happened.

The Balance, Spend authentication, and Spendability attacks affecting the
*Sprout* (if ZIP 2003 is not deployed first <a id="user-content-fnref-zip-2003"></a>
[51](#user-content-fn-zip-2003)), *Sapling*, *Orchard*,
and *Ironwood* pools, or any future pool using discrete-logarithm-based
cryptography, are possible only while spends using the corresponding legacy
protocols remain enabled.

If the transparent protocol is not switched off, then the situation with respect
to transparent spend authentication is unchanged. Balance for the transparent
protocol cannot be violated directly by a discrete-logarithm break (but funds
created by a balance violation in a shielded pool can be moved into the
transparent pool up to that shielded pool's turnstile limit).

The changes made by ZIP 2005 are only intended to address Balance preservation,
Spend authentication, and Spendability for *Ironwood-pool* notes. The situation
with respect to Privacy is unchanged for any pool.

In particular, the note encryption for *Ironwood*, *Orchard*, *Sapling*, and
*Sprout pools* is subject to "Harvest Now, Decrypt Later" attacks: that is, a
discrete-logarithm-breaking attack can be attempted as long as an adversary has
both the ciphertext (which is published on the block chain) and the receiver
address. Other protocol changes are under consideration to mitigate this risk
for future transfers.

Due to the zero-knowledge property, Groth16 and Halo 2 proofs do not leak
further information relevant to Privacy when addresses are unknown. The same is
true of Sapling or Orchard[ZSA] spend authentication signatures, due to key
rerandomization.

<a id="attacks-addressed-by-the-recovery-protocol"></a>

### Attacks addressed by the Recovery Protocol

The Recovery Statement's $\mathsf{BindKeys}$ constraint pins the key witness via
$\mathsf{PRF^{expand}}$ (modelled as collapsing), not via discrete-logarithm
hardness. So (if no mistakes are made in the design or instantiation), fresh
Balance, Spend authentication, or Spendability attacks against the Recovery Protocol
should require breaking post-quantum binding rather than just discrete logarithms.
Funds in *Ironwood-pool* notes can therefore be spent through the Recovery Protocol
after the switch. However, if the adversary attacked either Spendability (e.g. via a
roadblock attack) or Spend authorization before the switch to the Recovery Protocol,
then it could affect the legitimate holder's ability to spend the funds afterward.
The window between the activation height of this ZIP and the switch is the critical
exposure period for recoverable *Ironwood-pool* funds.

Note that we can precisely identify the set of note commitments for recoverable
notes, even though we cannot decrypt them: the recoverable notes are exactly
the *Ironwood-pool* notes, so their commitments are exactly those in the
*Ironwood pool*'s note commitment tree <a id="user-content-fnref-zip-0229-3"></a>
[5](#user-content-fn-zip-0229).

We can likewise identify the precise set of nullifiers for recoverable notes:
they are exactly the *Ironwood-pool* nullifiers, which form a nullifier set
separate from that of the *Orchard pool* <a id="user-content-fnref-zip-0229-4"></a>
[5](#user-content-fn-zip-0229).

Within the Recovery Statement we also know that the note being spent is
recoverable.

<a id="deployment"></a>

## Deployment

The activation height of this ZIP is the NU6.3 ACTIVATION_HEIGHT
<a id="user-content-fnref-zip-0258"></a>
[52](#user-content-fn-zip-0258).

As far as the author of this ZIP is aware, all existing Zcash wallets already
derive $(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})$ from a spending key
$\mathsf{sk}$ in the way specified for the $\mathsf{use\_qsk} = \mathsf{false}$
case in § 4.2.3 ‘Orchard Key Components’ <a id="user-content-fnref-protocol-updated-orchardkeycomponents-3"></a>
[15](#user-content-fn-protocol-updated-orchardkeycomponents).

FROST distributed key generation requires the $\mathsf{use\_qsk} = \mathsf{true}$
case. There is no significant existing deployment of FROST, so we can
[write this into ZIP 312](https://github.com/zcash/zips/pull/895/files)
from the start.

The part of the protocol that is new is the different input for
$\mathsf{pre\_rcm}$. It would have been possible to use a separate
pq-binding commitment, but $\mathsf{H^{rcm}}$ 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.

Two options were considered for deployment:

1. Deploy this change prior to the next network upgrade. This would
   optimize the time to deployment if there were a significant time
   before the next upgrade. An activation height is still needed, in
   order to identify a height from which wallets must re-scan if they
   are missing recoverable notes due to late deployment.

2. Deploy this change at the same time as the next network upgrade (NU6.3),
   at the same time as v6 transactions.

The second option has been chosen. (The first had been the plan, until
the Orchard circuit soundness vulnerability was discovered.) Deploying at
an upgrade makes the set of recoverable notes easy to identify (they are
exactly the *Ironwood-pool* notes), and it strengthens the case for
migrating funds out of the *Orchard pool*: a migrating user gains both
quantum recoverability and the improvement in supply-integrity confidence
that NU6.3 provides.

This change is enforced from NU6.3: every *Ironwood-pool* output note is a
recoverable note, and no *Sapling* or *Orchard-pool* output note is
<a id="user-content-fnref-zip-0229-5"></a>
[5](#user-content-fn-zip-0229). When a compliant wallet receives a *Sapling* or *Orchard-pool*
note, the associated funds need to be sent to the *Ironwood pool* in order
to make them recoverable.

Note: if we prioritize spending non-recoverable notes, it is
conceivable that an adversary could exploit this to improve
[arity leakage attacks](https://github.com/zcash/zcash/issues/4332).
On the other hand, adversaries can already choose note values to
manipulate the note selection algorithm to some extent.

<a id="references"></a>

## References

<a id="footnote-label"></a>

### 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"](https://www.rfc-editor.org/info/bcp14) [↩](/zip/2005#user-content-fnref-bcp14)

2. [ZIP 200: Network Upgrade Mechanism](/zip/200) [↩](/zip/2005#user-content-fnref-zip-0200)

3. [Zcash Protocol Specification, Version 2026.8.0 [NU6.3]](protocol/nu6_3.pdf#2026.8.0) [↩](/zip/2005#user-content-fnref-protocol-updated) [↩2](/zip/2005#user-content-fnref-protocol-updated-2)

4. [Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 3.12: Mainnet and Testnet](protocol/nu6_3.pdf#networks) [↩](/zip/2005#user-content-fnref-protocol-updated-networks)

5. [ZIP 229: Version 6 Transaction Format](/zip/229) [↩](/zip/2005#user-content-fnref-zip-0229) [↩2](/zip/2005#user-content-fnref-zip-0229-2) [↩3](#user-content-fnref-zip-0229-3) [↩4](#user-content-fnref-zip-0229-4) [↩5](#user-content-fnref-zip-0229-5)

6. [ZIP 226: Transfer and Burn of Zcash Shielded Assets](/zip/226) [↩](/zip/2005#user-content-fnref-zip-0226) [↩2](/zip/2005#user-content-fnref-zip-0226-2) [↩3](/zip/2005#user-content-fnref-zip-0226-3) [↩4](/zip/2005#user-content-fnref-zip-0226-4)

7. [ZIP 227: Issuance of Zcash Shielded Assets](/zip/227) [↩](/zip/2005#user-content-fnref-zip-0227) [↩2](/zip/2005#user-content-fnref-zip-0227-2) [↩3](/zip/2005#user-content-fnref-zip-0227-3)

8. Post-Quantum Zcash ([video](https://www.youtube.com/watch?v=T2B5f297d-Y), [slides](https://docs.google.com/presentation/d/1BHBiSOEO5zt40KWBbRXVMGIIuAcT2hfPWZQ3pT_8tm8/edit?slide=id.g335164f3026_0_113#slide=id.g335164f3026_0_113)). Presentation by Daira-Emma Hopwood at ZconVI. [↩](/zip/2005#user-content-fnref-pq-zcash) [↩2](/zip/2005?part=2#user-content-fnref-pq-zcash-2)

9. [ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling child key derivation](/zip/32#sapling-child-key-derivation) [↩](/zip/2005#user-content-fnref-zip-0032-sapling-child-key-derivation)

10. [ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling internal key derivation](/zip/32#sapling-internal-key-derivation) [↩](/zip/2005#user-content-fnref-zip-0032-sapling-internal-key-derivation)

11. [ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard child key derivation](/zip/32#orchard-child-key-derivation) [↩](/zip/2005#user-content-fnref-zip-0032-orchard-child-key-derivation)

12. [ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard internal key derivation](/zip/32#orchard-internal-key-derivation) [↩](/zip/2005#user-content-fnref-zip-0032-orchard-internal-key-derivation) [↩2](/zip/2005?part=2#user-content-fnref-zip-0032-orchard-internal-key-derivation-2) [↩3](/zip/2005?part=2#user-content-fnref-zip-0032-orchard-internal-key-derivation-3)

13. [ZIP 231: Memo Bundles](/zip/231) [↩](/zip/2005#user-content-fnref-zip-0231) [↩2](/zip/2005#user-content-fnref-zip-0231-2)

14. [ZIP 312: FROST for Spend Authorization Multisignatures](/zip/312) [↩](/zip/2005#user-content-fnref-zip-0312)

15. [Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 4.2.3: Orchard Key Components](protocol/nu6_3.pdf#orchardkeycomponents) [↩](/zip/2005#user-content-fnref-protocol-updated-orchardkeycomponents) [↩2](/zip/2005?part=2#user-content-fnref-protocol-updated-orchardkeycomponents-2) [↩3](#user-content-fnref-protocol-updated-orchardkeycomponents-3)

16. [ZIP 312: FROST for Spend Authorization Multisignatures — Threat Model](/zip/312#threat-model) [↩](/zip/2005#user-content-fnref-zip-0312-threat-model)

17. [SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes](https://github.com/satoshilabs/slips/blob/master/slip-0039.md) [↩](/zip/2005#user-content-fnref-slip-0039)

18. [Zcash Protocol Specification, Version 2026.7.0 [NU6.2]](protocol/protocol.pdf#2026.7.0) [↩](/zip/2005#user-content-fnref-protocol-base)

19. [Zcash Protocol Specification, Version 2026.7.0 [NU6.2]. Section 4.2.3: Orchard Key Components](protocol/protocol.pdf#orchardkeycomponents) [↩](/zip/2005#user-content-fnref-protocol-orchardkeycomponents) [↩2](/zip/2005#user-content-fnref-protocol-orchardkeycomponents-2)

20. [Zcash Protocol Specification, Version 2026.7.0 [NU6.2]. Section 4.7.2: Sending Notes (Sapling)](protocol/protocol.pdf#saplingsend) [↩](/zip/2005#user-content-fnref-protocol-saplingsend) [↩2](/zip/2005#user-content-fnref-protocol-saplingsend-2)

21. [Zcash Protocol Specification, Version 2026.7.0 [NU6.2]. Section 4.7.3: Sending Notes (Orchard)](protocol/protocol.pdf#orchardsend) [↩](/zip/2005#user-content-fnref-protocol-orchardsend) [↩2](/zip/2005#user-content-fnref-protocol-orchardsend-2)

22. [Zcash Protocol Specification, Version 2026.7.0 [NU6.2]. Section 4.20: In-band secret distribution (Sapling and Orchard)](protocol/protocol.pdf#saplingandorchardinband) [↩](/zip/2005#user-content-fnref-protocol-saplingandorchardinband) [↩2](/zip/2005#user-content-fnref-protocol-saplingandorchardinband-2)

23. [Zcash Protocol Specification, Version 2026.7.0 [NU6.2]. Section 5.3: Constants](protocol/protocol.pdf#constants) [↩](/zip/2005#user-content-fnref-protocol-constants)

24. [ZIP 312: FROST for Spend Authorization Multisignatures — Key Generation](/zip/312#key-generation) [↩](/zip/2005#user-content-fnref-zip-0312-key-generation) [↩2](/zip/2005#user-content-fnref-zip-0312-key-generation-2)

25. [BLAKE3: One Function, Fast Everywhere. Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, and Zooko Wilcox, 2020.](https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf) See § 2.1.2 for the `derive_key` mode. [↩](/zip/2005#user-content-fnref-blake3)

26. [ZIP 226: Transfer and Burn of Zcash Shielded Assets — Split Notes](/zip/226#split-notes) [↩](/zip/2005?part=2#user-content-fnref-zip-0226-split-notes)

27. Understanding Zcash Security ([video](https://www.youtube.com/watch?v=f6UToqiIdeY), [slides](https://raw.githubusercontent.com/daira/zcash-security/main/zcash-security.pdf)). Presentation by Daira-Emma Hopwood at Zcon3. [↩](/zip/2005?part=2#user-content-fnref-zcash-security) [↩2](/zip/2005?part=2#user-content-fnref-zcash-security-2)

28. [Computationally binding quantum commitments. Dominique Unruh.](https://eprint.iacr.org/2015/361) Also published in EUROCRYPT 2016, LNCS vol. 9666. [↩](/zip/2005?part=2#user-content-fnref-unruh2015) [↩2](/zip/2005?part=3#user-content-fnref-unruh2015-2)

29. [Collapse-binding quantum commitments without random oracles. Dominique Unruh.](https://eprint.iacr.org/2016/508) Also published in ASIACRYPT 2016, LNCS vol. 10032. [↩](/zip/2005?part=2#user-content-fnref-unruh2016) [↩2](/zip/2005?part=3#user-content-fnref-unruh2016-2) [↩3](/zip/2005?part=3#user-content-fnref-unruh2016-3)

30. [Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 4.7.3: Sending Notes (Orchard)](protocol/nu6_3.pdf#orchardsend) [↩](/zip/2005?part=2#user-content-fnref-protocol-updated-orchardsend)

31. [Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard)](protocol/nu6_3.pdf#concretespendauthsig) [↩](/zip/2005?part=2#user-content-fnref-protocol-updated-concretespendauthsig)

32. [Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.4.1.9: Sinsemilla Hash Function](protocol/nu6_3.pdf#concretesinsemillahash) [↩](/zip/2005?part=2#user-content-fnref-protocol-updated-concretesinsemillahash)

33. [Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.4.1.9: Sinsemilla Hash Function — Security argument](protocol/nu6_3.pdf#sinsemillasecurity) [↩](/zip/2005?part=2#user-content-fnref-protocol-updated-sinsemillasecurity)

34. [Post-Quantum Succinct Arguments: Breaking the Quantum Rewinding Barrier. Alessandro Chiesa, Fermi Ma, Nicholas Spooner, and Mark Zhandr.](https://eprint.iacr.org/2021/334) Also published in FOCS 2021. [↩](/zip/2005?part=2#user-content-fnref-cmsz2021) [↩2](#user-content-fnref-cmsz2021-2)

35. [Collapseability of Tree Hashes. Aldo Gunsing and Bart Mennink.](https://eprint.iacr.org/2022/248) Also published in PQCrypto 2020, LNCS vol. 12100, pp. 524–544. [↩](/zip/2005?part=2#user-content-fnref-gm2022) [↩2](/zip/2005?part=3#user-content-fnref-gm2022-2)

36. [Quantum Rewinding for IOP-Based Succinct Arguments. Alessandro Chiesa, Marcel Dall'Agnol, Zijing Di, Ziyi Guan, and Nicholas Spooner.](https://eprint.iacr.org/2025/947) [↩](/zip/2005?part=2#user-content-fnref-cddgs2025) [↩2](#user-content-fnref-cddgs2025-2)

37. [The Sponge is Quantum Indifferentiable. Gorjan Alagic, Joseph Carolan, Christian Majenz, and Saliha Tokat.](https://eprint.iacr.org/2025/731) [↩](/zip/2005?part=2#user-content-fnref-acmt2025) [↩2](/zip/2005?part=3#user-content-fnref-acmt2025-2)

38. [A Graduate Course in Applied Cryptography (Version 0.6). Dan Boneh and Victor Shoup.](https://toc.cryptobook.us/) See the "reasonable adversary" step in the proof of Theorem 8.4 (Davies–Meyer). [↩](/zip/2005?part=3#user-content-fnref-bs2023)

39. [Indistinguishability of Random Systems. Ueli Maurer.](https://crypto.ethz.ch/publications/files/Maurer02.pdf) Also published in Advances in Cryptology — EUROCRYPT 2002, LNCS vol. 2332, pp. 110–132. [↩](/zip/2005?part=3#user-content-fnref-maurer2002)

40. [Cost analysis of hash collisions: Will quantum computers make SHARCS obsolete? Daniel J. Bernstein.](https://cr.yp.to/hash/collisioncost-20090517.pdf) Presented at SHARCS 2009. [↩](/zip/2005?part=3#user-content-fnref-bernstein2009) [↩2](#user-content-fnref-bernstein2009-2) [↩3](#user-content-fnref-bernstein2009-3)

41. [Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.4.9.7: Coordinate Extractor for Pallas](protocol/nu6_3.pdf#concreteextractorpallas) [↩](/zip/2005?part=3#user-content-fnref-protocol-updated-concreteextractorpallas)

42. [Post-quantum security of the sponge construction. Jan Czajkowski, Leon Groot Bruinderink, Andreas Hülsing, Christian Schaffner, and Dominique Unruh.](https://eprint.iacr.org/2017/771) Also published in PQCrypto 2018, LNCS vol. 10786. [↩](/zip/2005?part=3#user-content-fnref-cbhsu2017)

43. [Classical Proofs for the Quantum Collapsing Property of Classical Hash Functions. Serge Fehr.](https://eprint.iacr.org/2018/887) Also published in TCC 2018, LNCS vol. 11240, pp. 315–338. [↩](/zip/2005?part=3#user-content-fnref-fehr2018)

44. [Parallel collision search with cryptanalytic applications. Paul C. van Oorschot and Michael Wiener.](https://link.springer.com/article/10.1007/PL00003816) [↩](#user-content-fnref-vow1999) [↩2](#user-content-fnref-vow1999-2)

45. [Quantum Algorithm for the Collision Problem. Gilles Brassard, Peter Høyer, and Alain Tapp.](https://arxiv.org/abs/quant-ph/9705002) Also published in LATIN 1998, LNCS vol. 1380, pp. 163–169. [↩](#user-content-fnref-bht1997)

46. [How to Record Quantum Queries, and Applications to Quantum Indifferentiability. Mark Zhandry.](https://eprint.iacr.org/2018/276) Also published in CRYPTO 2019, LNCS vol. 11693. [↩](#user-content-fnref-zhandry2018)

47. [On the Compressed-Oracle Technique, and Post-Quantum Security of Proofs of Sequential Work. Kai-Min Chung, Serge Fehr, Yu-Hsuan Huang, and Tai-Ning Liao.](https://eprint.iacr.org/2020/1305). Also published in EUROCRYPT 2021, LNCS vol. 12826. [↩](#user-content-fnref-cfhl2021)

48. [ZIP 209: Prohibit Out-of-Range Chain Value Pool Balances](/zip/209) [↩](#user-content-fnref-zip-0209)

49. [Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations. Ryan Babbush, Adam Zalcman, Craig Gidney, Michael Broughton, Tanuj Khattar, Hartmut Neven, Thiago Bergamaschi, Justin Drake, and Dan Boneh](https://quantumai.google/static/site-assets/downloads/cryptocurrency-whitepaper.pdf) [↩](#user-content-fnref-google2025) [↩2](#user-content-fnref-google2025-2)

50. [zcash/zips issue 1302: [ZIP 2007] Quantum recoverability of a subset of the transparent protocol](https://github.com/zcash/zips/issues/1302) [↩](#user-content-fnref-zips-issue1302)

51. [ZIP 2003: Disallow version 4 transactions](/zip/2003) [↩](#user-content-fnref-zip-2003)

52. [Deployment of the NU6.3 Network Upgrade)](/zip/258) [↩](#user-content-fnref-zip-0258)

## Citation relationships

Cites: [ZIP 32](https://zips.tools/zip/32), [ZIP 200](https://zips.tools/zip/200), [ZIP 209](https://zips.tools/zip/209), [ZIP 212](https://zips.tools/zip/212), [ZIP 226](https://zips.tools/zip/226), [ZIP 227](https://zips.tools/zip/227), [ZIP 229](https://zips.tools/zip/229), [ZIP 231](https://zips.tools/zip/231), [ZIP 258](https://zips.tools/zip/258), [ZIP 312](https://zips.tools/zip/312), [ZIP 2003](https://zips.tools/zip/2003), [ZIP 2007](https://zips.tools/zip/2007)

Cited by: [ZIP 32](https://zips.tools/zip/32), [ZIP 226](https://zips.tools/zip/226), [ZIP 229](https://zips.tools/zip/229), [ZIP 230](https://zips.tools/zip/230), [ZIP 231](https://zips.tools/zip/231), [ZIP 258](https://zips.tools/zip/258), [ZIP 316](https://zips.tools/zip/316), [ZIP 326](https://zips.tools/zip/326), [ZIP 374](https://zips.tools/zip/374)