leadByte versions the note plaintext, not the note. The previous design
took leadByte as a parameter of H^{rcm,Orchard} (with internal dispatch
on its value), which created a layering violation between the handling
of note plaintexts vs notes.

* Redefine H^{rcm,Orchard} to take only (rseed, noterepr) and define
  it only for the recoverable-note (leadByte = 0x03) case.
  The leadByte = 0x02 case uses the existing derivation
  rcm = ToScalar^{Orchard}(PRF^{expand}_{rseed}([0x05] || ρ)) unchanged.
* Drop the leadByte byte from the hashed prefix: pre_rcm = [0x0B] || ...
  instead of [0x0B, leadByte] || ....
* At each call site (§4.7.3 Sending Notes, §4.8.3 Dummy Notes,
  §4.20.2/§4.20.3 Decryption), dispatch on leadByte explicitly to choose
  between the legacy and recoverable derivations.
* Simplify the Spendability proof's notetuple to (rseed, noterepr); drop
  the leadByte_i index from notetuple_i in the theorem's "Distinct note
  tuples" condition.
* Add a sentence before the flow diagram noting that it shows the
  recoverable-note case (leadByte = 0x03) and that the legacy case uses
  the existing simpler derivation. Drop the leadByte → pre_rcm edge.
* Update the rationale and the specialised import in the Spendability
  setup to match the new signature.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

A multisignature scheme is a signature scheme that supports signing by
multiple parties with public key aggregation, but does not necessarily
support signing by a threshold of parties.

Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>

Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>

… 0x03.

Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>

Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>

…ion.

Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>

The 0x03 note plaintext format now does not include AssetBase. Drop
AssetBase from:

* the H^{rcm,Orchard} definition (signature and pre_rcm body) in §4.7.3
  and in the specialised import in the Spendability proof;
* the Sending Notes (Orchard) and Dummy Notes (Orchard) procedures: drop
  the "Let AssetBase = V^Orchard" preludes, the "AssetBase★ = ..."
  inline-let lines, and AssetBase★ from the H^{rcm,Orchard} call sites;
  also drop AssetBase★ from "use ... in the inputs to NoteCommit";
* the Decryption procedures (§4.20.2 and §4.20.3): drop the
  "Let AssetBase = V^Orchard" prelude, AssetBase★ from the inline let,
  and from the H^{rcm,Orchard} call sites;
* the Recovery Statement witness's noterepr;
* the rationale's "Repairing note commitments" noterepr;
* the flow diagram (drop AssetBase from the "v, AssetBase" pre_rcm input).

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Per the deployment-option-1 decision (ZIP 2005 deploys Orchard-only,
without ZSAs), reframe places that implied ZIP 2005's scope included
OrchardZSA:

* "It can optionally be done at the same time as changes necessary to
  implement ... ZSAs" -> "It is compatible with ... ZSAs".
* Rename "Flow diagram for the Orchard and OrchardZSA protocols" to
  "Flow diagram for the Orchard protocol" (the diagram shows the 0x03
  recoverable-note case, which is Orchard-only). Update the cross-reference
  to match.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>

…-conditionalise dispatch.

Three follow-ups to the leadByte case-split refactoring:

* Remove the named H^{rcm,Sapling} function (it was a wrapper with two
  unused args around ToScalar^Sapling(PRF^expand_rseed([0x04]))) and
  inline the right-hand side at the call sites in §4.7.2, §4.8.2, §4.20.2,
  and §4.20.3.
* Reduce H^{esk,Sapling}'s signature from (_, _) to (_), matching its
  Canopy-onward call shape H^{esk,protocol}_{rseed}(ρ) at §4.20.2's
  decryption step.
* Replace prose conditions "if Sapling and leadByte = ..." /
  "if Orchard and leadByte = ..." with
  "if protocol = Sapling and leadByte = ..." /
  "if protocol = Orchard and leadByte = ..." in the §4.20.2 and §4.20.3
  rcm dispatches.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…-derivation sites.

Define protocol-specific helpers that bundle the leadByte case-split for
rcm derivation:

* Derive_rcm^{Sapling}_{rseed}(leadByte) dispatches between
  LEOS2IP_{256}(rseed) (leadByte=0x01) and
  ToScalar^Sapling(PRF^expand_rseed([0x04])) (leadByte=0x02).
* Derive_rcm^{Orchard}_{rseed}(leadByte, g★_d, pk★_d, v, ρ, ψ) dispatches
  between the existing legacy derivation
  ToScalar^Orchard(PRF^expand_rseed([0x05] || ρ)) (leadByte=0x02) and
  the new H^{rcm,Orchard}_{rseed}(g★_d, pk★_d, v, ρ, ψ) (leadByte=0x03).

Update the call sites in §4.7.2 / §4.7.3 / §4.8.2 / §4.8.3 / §4.20.2 /
§4.20.3 to invoke the helpers. The §4.20.2 / §4.20.3 decryption dispatch
collapses from a 4-case rcm case-split to a 2-case protocol-conditional
call.

Drop the now-redundant parenthetical noting that H^{rcm,Orchard} is
defined only for the leadByte=0x03 case (H^{rcm,Orchard} is now only
referenced inside Derive_rcm^{Orchard}'s definition).

Update the "which define ..." cross-reference at the order-of-operations
note to name Derive_rcm^{\{Sapling,Orchard\}} rather than H^{rcm,Orchard},
since Derive_rcm is now the primary export of the affected sections.

Harmonize the notation for H^ψ in the rationale: ψ = H^ψ(rseed, ρ) becomes
ψ = H^ψ_{rseed}(ρ). The two forms are equivalent under the protocol-spec
convention; the subscripted form is preferred for consistency.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Replace the abstract ShortHash([h(ak,nk)+rivk] S) form with the
explicit Sinsemilla-commitment definition from § 5.4.1.10:
exhibit S as the rivk-randomization base via GroupHash^P, M' as
SinsemillaHashToPoint over LEBSP(ak) || LEBSP(nk), and the WLOG
scalar-lift M' = [h(ak,nk)] S using a Pedersen-like deterministic h.
Drops two duplicate "verify the exact form" TODOs.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…lift.

Extract_P is a deterministic 2-to-1 map on non-identity Pallas points
and does not query any random oracle, so it composes the same way
classically and quantumly. The factor of 2 from the 2-to-1 reduction
is already absorbed into the break-probability bound.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>