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

[daira]

Follow-up to merged PR #1264. This branch makes the following changes:

Security argument

• Use note-tuple terminology consistently in the Spendability arguments, correcting pre-existing imprecisions in the $\mathsf{notetuple}$ framing.
• Drop $\mathsf{leadByte}$ from the input to $\mathsf{H^{rcm,Orchard}}$. $\mathsf{leadByte}$ versions the note plaintext, not the note. The previous design created a layering violation between the handling of note plaintexts vs notes. The $\mathsf{leadByte} = \mathtt{0x02}$ case retains the existing protocol-spec derivation; the $\mathsf{leadByte} = \mathtt{0x03}$ case uses the new $\mathsf{H^{rcm,Orchard}}$ directly.
• ZIP 2005 is now specified to activate without ZSAs, so drop $\mathsf{AssetBase}$ from the input to $\mathsf{H^{rcm,Orchard}}$.
• Inline $\mathsf{H^{rcm,Sapling}}$ (it was a wrapper around $\mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}_{rseed}}([\mathtt{0x04}]))$ with unused args); reduce the signature of $\mathsf{H^{esk,Sapling}}$ from (_, _) to (_) matching its Canopy-onward call shape; replace if Sapling and leadByte = ... / if Orchard and leadByte = ... with the explicit if protocol = Sapling and ... / if protocol = Orchard and ... form in the prose dispatches.
• Define Derive_rcm^{Sapling,Orchard} helpers that bundle the $\mathsf{leadByte}$ case-split for $\mathsf{rcm}$ derivation. Call sites in §4.7.2 / §4.7.3 / §4.8.2 / §4.8.3 / §4.20.2 / §4.20.3 invoke these helpers instead of dispatching inline. The §4.20.2 / §4.20.3 decryption $\mathsf{rcm}$ derivation collapses from a 4-case case-split to a 2-case protocol-conditional call.
• Pin $\mathsf{ak}$ (up to $y$-sign of $\mathsf{ak}^{\mathbb{P}}$) for Spend Authorization key-binding, in addition to $\mathsf{qk}$. The spend-authorization verification key is randomized from $\mathsf{ak}^{\mathbb{P}}$; the previous motivation enumeration listed only $\mathsf{qk}$. The formal key-binding predicate already pinned $\mathsf{ak}$ via $\mathsf{ivk} = \mathsf{Commit^{ivk}_{rivk}}(\mathsf{ak}, \mathsf{nk})$; the enumeration was incomplete.
• Make the key-binding algebraic setup explicit per §5.4.1.10 'Sinsemilla commitments': exhibit $\mathcal{S}$ as the rivk-randomization base, $M'$ as $\mathsf{SinsemillaHashToPoint}$ over the encoded $(\mathsf{ak}, \mathsf{nk})$, and the WLOG scalar-lift $M' = [h(\mathsf{ak}, \mathsf{nk})], \mathcal{S}$ for a Pedersen-like deterministic $h$. Resolves two duplicate TODOs.

Post-quantum analysis

• Restructure the "Adaptation to the quantum setting" section: promote from ### (inside Security analysis) to ## (top-level, after the formal Spendability argument), so that all quantum analysis follows all classical analysis rather than being sandwiched between the informal and formal arguments. Trim the informal binding argument's quantum mentions and add a forward reference.
• Define the collapsing property as the quantum analog of collision-resistance; survey collapsing for standard hash-function constructions (Unruh on Merkle–Damgård, Czajkowski et al. on sponge, ACMT 2025 on quantum-indifferentiability, Fehr 2018 on HAIFA, Gunsing and Mennink 2022 on tree hashes). Apply Fehr's theorem: modelling $\mathsf{H^{rcm}}$ as collapsing reduces to modelling BLAKE2b's compression function as collapsing.
• State concrete QROM bounds (Zhandry's compressed-oracle technique, with CFHL 2021's classical-style derivation as a co-citation): the classical $q^2 / r_{\mathbb{P}}$ collision probability becomes $O(q^3 / r_{\mathbb{P}})$ in QROM. For Zcash-relevant parameters the worst-case QROM bound is $\sim 2^{-74}$; the practically achievable bound stays closer to the classical $\sim 2^{-134}$ since BHT-style attacks would need the $2^{92.3}$-bit quantum memory shown to be infeasible.
• Resolve three prior TODOs in the security argument: $\mathsf{Extract}_{\mathbb{P}}$ / QROM composition, CBHSU2017 / Unruh literature discussion, and the QROM-lift technical conditions.

Threat analysis

• Draft the "Effects of discrete-log-breaking attacks" sections (before / after the switch, and "Attacks addressed by the Recovery Protocol") — covering the threat across all of Zcash's primitives, what becomes permanently unspendable post-switch (Sapling, Sprout, and non-recoverable Orchard), the out-of-scope status of transparent funds, and the limits of the Recovery Protocol. Replaces a prior TBD; adds ZIP 209, ZIP 2003, and a 2025 Google paper on ECC-cryptocurrency quantum recovery to the references.

Deployment

• Commit to deployment option 1 (deploy in v5 transactions before the next NU, with a $\mathsf{ZIP2005ActivationHeight}$); restructure $\mathsf{allowedLeadBytes}$ accordingly.
• Add a "Proactive movement of funds to recoverable notes" section: wallets SHOULD sweep all non-recoverable funds they control into recoverable Orchard notes once this proposal is deployed. Wallet-internal sends use $\mathtt{0x03}$ immediately; external sends use $\mathtt{0x02}$ until there is wider support for receiving $\mathtt{0x03}$.
• Decouple ZIP 2005 from OrchardZSA in framing prose.

Terminology and housekeeping

• FROST multisignatures → FROST threshold multisignatures (a multisignature scheme is not necessarily a threshold scheme).
• Update Credits and Pull-Request fields.

Bibliography

• Annotate eprint citations with "Also published in …" when the paper also appears at a conference / in a journal, signalling that the linked revision may differ from the named published version. Applied to eleven entries (Unruh 2015/2016, CBHSU 2017, Fehr 2018, Zhandry 2018, CFHL 2021, CMSZ 2021, GM 2022, BHT 1997, Bernstein 2009, Maurer 2002).
• New references introduced by the post-quantum analysis: Fehr 2018 (HAIFA collapsing), Zhandry 2018 (compressed-oracle technique), CFHL 2021 (classical-style derivation), Gunsing and Mennink 2022 (tree-hash collapsing).
• Update the BLAKE3 reference to cite Zooko Wilcox's current name.

Cross-ZIP

• ZIPs 226 / 230 / 231: replace explicit 0x03 references with placeholders ({{ZSALEADBYTE}} / {{LEADBYTE}} / {{MBLEADBYTE}}) since 0x03 is now reserved for ZIP 2005.
• Withdraw ZIP 230 (obsoleted by ZIP 248).

Suggested checks

• Spot-check that Derive_rcm^{Sapling} and Derive_rcm^{Orchard} dispatch correctly and cover the relevant leadByte values.
• The $\mathsf{allowedLeadBytes}$ matrix covers all valid (protocol, height, txVersion) combinations.
• The key-binding algebraic-setup paragraph matches §5.4.1.10 'Sinsemilla commitments' (domain strings, encoding).

🤖 Filed with Claude Code

[ValarDragon]

Reviewed, and it looks great to me! Thank you!

Really glad:

• We are ZIP-cleared on using LeadByte 0x03
• LeadByte is removed from the rcm hash
• We have the deployment strategy were going for in the ZIP
• We removed AssetBase from the rcm hash

[aphelionz]

utACK

[ValarDragon]

Re-approve on assumption that its same as pre-rebase