Protocol spec: apply ZIP 2005, and related cleanups

[daira]

Completes the application of ZIP 2005's protocol-spec and ZIP changes begun in #1336, together with cleanups that surfaced while applying them. Nothing here changes consensus for previous network upgrades. The new normative text is all under NU6.3 conditionals and reflects that upgrade as-activated.

Applied ZIP 2005 changes

• § 4.1.2, § 4.2.3, and § 5.3: the quantum spending and intermediate keys (qsk, qk) and the use_qsk derivation branch in 'Orchard Key Components', with the named derivation functions H^ask, H^nk, H^rivk, H^qsk, H^qk (BLAKE3 derive_key), and H^rivk_ext; the ℓ_qsk and ℓ_qk constants, placed after ℓ_dk in § 5.3 and in § 2's constants inventory; and the updated PRF^expand usage list. References for BLAKE3, ZIP 226, and ZIP 312 are added to the bibliography.
• § 4.7.2 and § 4.8.2: Derive_rcm^Sapling and H^esk,Sapling, used for the rcm and esk derivations in Sapling sending and dummy notes.
• § 4.20.2 and § 4.20.3: the receive-side re-derivations route through the lead-byte-dependent derivation functions, with the derivation order changed so that rcm can depend on g_d and pk_d, the protocol metavariable bound per pool, and the Orchard-pool guards widened to Orchard-like pools so that Ironwood-pool notes are covered.
• § 3.2.1: the "Let pool" sentence moves directly above the allowedLeadBytes definition, matching its position in the ZIP.
• § 3.2.1 notes: Orchard-pool note plaintexts have lead byte 0x02 exactly (rather than ≥ 0x02; unconditional, since no other lead byte has been allowed since Orchard was introduced), and from NU6.3 a note says that the Orchard-pool and Ironwood-pool allowed lead-byte sets must remain disjoint. Both get Change History entries.
• ZIP 32: ∗ marks on the sk → ask and sk → rivk arrows of the Orchard internal key derivation diagram (matching the protocol spec's key components diagram), with the note explaining that other derivations are possible but may forfeit ZIP 2005 note recovery; the PNG is regenerated with rsvg-convert, whose text layout differs subtly from the original Inkscape export (outer-label size and subscript spacing) — a re-export on that pipeline would restore exact fidelity.
• ZIP 212: the note that ZIP 2005's changes are not reflected there.

Several fixes are synced into ZIP 2005 itself: the use_qsk = false branch regains the deployed "if ask = 0, discard" step; § 4.1.2's usage list no longer lists 0x0A as used, since it is only reserved (for ZIP 226 split notes); a § 2 'Notation' change block is added, with the § 5.3 constant placement made explicit; ρ is defined for both protocols in the receive re-derivations; the § 4.20.2 where-ψ deletion and the § 4.20.3 esk consistency-check replacement (the reason H^esk,Sapling takes an argument at all) are added; the protocol metavariable is bound; the § 3.2.1 lead-byte notes are synced, replacing the ZIP's note that only 0x03 is allowed for Ironwood-pool notes, which did not match the spec's ≥ 0x03 item; and the ZIP 212 note placement follows the precedent of ZIPs 230 and 246.

Cleanups

• ak is typed {1..q_ℙ−1}. 0 is not the affine x-coordinate of any Pallas point in ℙ*, so this was already implied by the decoding rule in § 5.6.4.4, and it is consistent with the Action circuit (ak^ℙ is witnessed as a non-identity point) and with the implementation. This change is unconditional.
• One term each for ask and ak — "Spend authorizing key" and "Spend validating key" — removing the alternative terms "spend authorization private key" and "spend authorization address key". Also unconditional. Fixes [protocol spec] Spec uses inconsistent terms for ask and ak #763.
• The H^* derivation functions get macros, with the protocol and the key subscript as parameters, matching Derive_rcm.
• The § 4.6 pnote scopes the shared rt/enableSpends/enableOutputs components to a given pool from NU6.3, since a transaction can then have bundles in two pools.
• The NU6.2-only verifying-key rule uses \nusixtwoonlyitem, so that it renders as a list item.
• zip-guide and zip-guide-markdown now say that the blank line after a note/warning marker is required for Markdown, rather than implying it in either format.
• AGENTS.md explains why builds go through nix develop -c, gives the form of an open Change History entry, and points at the new scripts/find-section.py, which resolves protocol-spec section numbers to labels, titles, and source lines (or back) from a prior build's aux files. The new scripts/ directory anticipates Reduce clutter in the root directory by moving scripts #1025.
• Sinsemilla terminology: the k-bit groups of a Sinsemilla hash input are called words rather than pieces (§ 5.4.1.9 and the index), matching halo2_gadgets; the Change History records the rename.
• The Change History is rearranged: the entries for the ak type and the Orchard lead-byte note are marked as NU5 changes, and the receive-side entry is reworded.

Both build variants (nu6_3 and the deployed protocol.pdf) are green, and the affected ZIPs are re-rendered.

🤖 Claude Fable 5 and Fable 5.1