FROST Guide Threshold RedPallas: FROST and its Zcash integration surfaces 5 Re-randomised FROST for spend authorisation 7 Security

6 The aggregate as a spend-authorisation signature

This section instantiates the re-randomised protocol of §5 over the ciphersuite FROST(Pallas, BLAKE2b-512) and composes it with the Orchard protocol. After the ciphersuite comes the section’s main result: the aggregate is an ordinary RedPallas spend-authorisation signature under the shifted group key, and consensus accepts it for an Action exactly when the effective randomiser is the Action’s randomiser. There follow the sign normalisation that makes a threshold group key a spend validating key; the key tree of ZIP 2005 for an Orchard-protocol threshold key, with the lemma that its common secrets are simulable; the order of randomiser, randomised validating key, signature digest and proof that the main result forces; and the threshold construction of an Action in that order. Throughout, $q=p_{\mathsf{Vesta}}$ , $B=G^{\mathsf{SpendAuth}}$ , the effective randomiser is $\hat{\alpha}$ (Definition 5.3) and the randomiser of an Action is $\alpha$ .

6.1 The ciphersuite FROST(Pallas, BLAKE2b-512)

For a point $P$ of the Pallas group write $\underline{P}:=\mathsf{LEBS2OSP}_{256}(P^{\star})$ , the $32$ -byte form of the star encoding (Ironwood Guide, §“Fields, groups, and encodings”, Definition “Star encoding”), and $\mathsf{abst}_{\mathbb{P}}$ for its partial inverse.

Construction 6.1 (FROST(Pallas, BLAKE2b-512)).

The ciphersuite FROST(Pallas, BLAKE2b-512) is the following instance of Definition 4.1, for re-randomised signing.

(a)

Group. The Pallas group $\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})$ , of prime order $q=p_{\mathsf{Vesta}}$ (ZIP 312’s $r_{\mathbb{P}}$ ) and cofactor $1$ , with identity $\mathcal{O}$ and generator

$B=G^{\mathsf{SpendAuth}}=\mathsf{GroupHash}(\texttt{z.cash:Orchard},\texttt{G})$

(Ironwood Guide, §“GroupHash, domain separation, and nothing-up-my-sleeve generators”; Definition “Spend-authorisation and binding-signature instances”), ZIP 312’s $\mathcal{G}^{\mathsf{Orchard}}$ . A random scalar is uniform on $\{0,\dots,p_{\mathsf{Vesta}}-1\}$ .
(b)

Elements. $N_{\mathrm{e}}=32$ and $\mathsf{ser}_{\mathbb{G}}(P):=\underline{P}$ , which is total: $\mathcal{O}^{\star}=\mathrm{LE}_{256}(0)$ . The deserialisation maps a $32$ -byte string $b$ to $\mathsf{abst}_{\mathbb{P}}(\mathsf{LEBS2OSP}_{256}^{-1}(b))$ , and fails if that value is $\bot$ and, in addition, if it is $\mathcal{O}$ . The function $\mathsf{abst}_{\mathbb{P}}$ itself decodes $\mathrm{LE}_{256}(0)$ to $\mathcal{O}$ (step 2 of Definition “Star encoding”); the rejection of the identity is the suite’s, not $\mathsf{abst}_{\mathbb{P}}$ ’s.
(c)

Scalars. $N_{\mathrm{s}}=32$ , $\mathsf{ser}_{\mathbb{F}_{q}}(k):=\mathsf{I2LEOSP}_{256}(k)$ , and $\mathsf{deser}_{\mathbb{F}_{q}}$ fails on a $32$ -byte string whose little-endian integer is not below $p_{\mathsf{Vesta}}$ .
(d)

Hashes. BLAKE2b-512 with a $16$ -byte personalisation, $N_{\mathrm{h}}=64$ , the roles $H_{1}$ to $H_{5}$ as in Table 2.
(e)

Signature encoding and verification as in Definition 4.1, part (e), with these data.
(f)

Randomiser hash. The role $H_{R}$ of Table 2.

Class (Definition 1.1): specified (ZIP 312, Draft).

The data are those of ZIP 312, “FROST(Pallas, BLAKE2b-512)”, which takes the group, the order and the encoding $\mathsf{repr}_{\mathbb{P}}$ from the protocol specification, §“Pallas and Vesta”, and the base point from §“Spend Authorization Signature (Sapling and Orchard)”. The generic element serialisation of RFC 9591, Section 3.1, fails on the identity; this one does not. Three consequences for Theorem 4.11 follow. Its case (2), $R=\mathcal{O}$ , does not arise, the serialisation being total. Its case (1), a zero nonce, remains: a commitment $D_{i}$ or $E_{i}$ equal to $\mathcal{O}$ is serialised in Round One and rejected by $\mathsf{deser}_{\mathbb{G}}$ in check (3) of Round Two. The only identity condition left on the output is the consensus rule $\mathsf{rk}\neq\mathcal{O}$ (Corollary 6.4).

Role	Personalisation	Output
$H_{1}$ , binding factor	FROST_RedPallasR	$\mathrm{ToScalar}$
$H_{2}$ , challenge	Zcash_RedPallasH	$\mathrm{ToScalar}$
$H_{3}$ , nonce	FROST_RedPallasN	$\mathrm{ToScalar}$
$H_{4}$ , message pre-hash	FROST_RedPallasM	$64$ -byte digest
$H_{5}$ , commitment-list pre-hash	FROST_RedPallasC	$64$ -byte digest
$H_{R}$ , randomiser	FROST_RedPallasA	$\mathrm{ToScalar}$

Table 2: Hash functions of FROST(Pallas, BLAKE2b-512). Each role maps

x

\mathrm{BLAKE2b\text{-}512}(\mathit{pers},x)

, followed where stated by

\mathrm{ToScalar}(y)=\mathsf{LEOS2IP}_{512}(y)\bmod p_{\mathsf{Vesta}}

(Ironwood Guide, §“Pseudorandom functions and field reductions”, Definition “Field reductions”). The challenge hash

H_{2}

is, as a function, the RedPallas hash

\mathsf{H}^{\circledast}(z)=\mathrm{ToScalar}(\mathrm{BLAKE2b\text{-}512}(% \texttt{Zcash\_RedPallasH},z))

(Ironwood Guide, §“The RedPallas signature scheme”, Definition “RedPallas hash”), so the FROST challenge is the challenge that RedPallas validation recomputes; the other five personalisations carry the prefix FROST_. Source: ZIP 312, “FROST(Pallas, BLAKE2b-512)”.

The reduction $\mathrm{ToScalar}$ is ZIP 312’s “interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo G.Order()”. ZIP 312 records the equality of $H_{2}$ and $\mathsf{H}^{\circledast}$ (protocol specification, §“RedDSA, RedJubjub, and RedPallas”).

Proposition 6.2 (Random-oracle model of the Pallas ciphersuite).

Assume Assumption 4.2 in its form for a suite built from one hash function under distinct personalisations: the map $(\mathit{pers},x)\mapsto\mathrm{BLAKE2b\text{-}512}(\mathit{pers},x)$ is modelled as a random oracle. Its restriction to $\mathit{pers}=\texttt{Zcash\_RedPallasH}$ is the Ironwood Guide’s Assumption “The RedPallas hash as a random oracle”. No further assumption is introduced. Then:

(i)

the hashes $H_{1}$ , $H_{2}$ , $H_{3}$ , $H_{4}$ , $H_{5}$ and $H_{R}$ are independent random oracles;
(ii)

each value of $H_{1}$ , $H_{2}$ , $H_{3}$ and $H_{R}$ at a new input is within statistical distance

$\delta_{512}:=p_{\mathsf{Vesta}}/2^{512}<2^{-257}$

of a uniform scalar, so the suite meets Assumption 4.2 with $\delta=\delta_{512}$ ;
(iii)

the hashes $H_{4}$ and $H_{5}$ are random oracles onto the $64$ -byte strings, so $Q$ queries find a collision of either with probability at most $Q^{2}/2^{513}$ ;
(iv)

the independence of $H_{\mathrm{dkg}}$ that Assumptions 3.5 and 4.2 require holds for every instantiation of $H_{\mathrm{dkg}}$ by BLAKE2b-512 under a $16$ -byte personalisation distinct from the six of Table 2. No such instantiation is specified (ZIP 312, “Key Generation”).

Proof.

(i) The six personalisations are pairwise distinct and all $16$ bytes long, hence prefix-free; Crypto Guide, §“Domain separation and personalisation”, Proposition “Domain separation yields independent oracles”, gives independence. (ii) A value at a new input is $\mathrm{ToScalar}$ of a uniform $64$ -byte string, whose distance from uniform is at most $p_{\mathsf{Vesta}}/2^{512}$ by Math Guide, §“Uniform sampling and the bias of modular reduction”, Proposition “Bias of modular reduction”, with $L=512$ , the bound that the Ironwood assumption records; and $p_{\mathsf{Vesta}}/2^{512}=2^{-258}(1+e)$ with $0<e<2^{-128}$ . (iii) Birthday bound, Math Guide, §“The union bound and a birthday calculation”, Proposition “Birthday bound”: $\binom{Q}{2}2^{-512}\leq Q^{2}/2^{513}$ . (iv) Part (i) applied to seven distinct personalisations. □

At $Q=2^{64}$ the collision bound of part (iii) is $2^{-385}$ .

6.2 Validity of the aggregate

Proposition 6.3 (Aggregates are spend-authorisation signatures).

Let valid key material (Definition 2.5) with group key $Y$ be given over FROST(Pallas, BLAKE2b-512), let $\hat{\alpha}\in\mathbb{F}_{q}$ be an effective randomiser and $m$ a message that every member of the signing set accepts (Definition 5.9). Every run of Construction 5.10 in which every party is honest either fails, in the zero-nonce case of Theorem 4.11, or outputs $(R,z)$ whose encoding

\sigma:=\mathsf{ser}_{\mathbb{G}}(R)\,\|\,\mathsf{ser}_{\mathbb{F}_{q}}(z)

(RFC 9591, Appendix A) is accepted by the validation of the spend-authorisation instance of RedPallas (Ironwood Guide, Construction “RedPallas”, part 3, with base $G^{\mathsf{SpendAuth}}$ ) under $X:=Y+[\hat{\alpha}]G^{\mathsf{SpendAuth}}$ on $M:=m$ . No completed honest run yields an aggregate that validation rejects.

Proof.

Theorem 5.11 gives $[z]B=R+[c]X$ with $c=H_{2}(\mathsf{ser}_{\mathbb{G}}(R)\,\|\,\mathsf{ser}_{\mathbb{G}}(X)\,\|\,m)$ (RFC 9591, Section 4.6), its only exception in this suite being the zero nonce, since $\mathsf{ser}_{\mathbb{G}}$ is total. Validation of $\sigma$ under $X$ on $m$ proceeds as follows.

1.

The first $32$ bytes are $\bar{R}=\underline{R}$ , and $\mathsf{abst}_{\mathbb{P}}(R^{\star})=R$ because the star encoding is canonical and total, $R=\mathcal{O}$ included; so the decoded point is $R\neq\bot$ .
2.

The last $32$ bytes give $S=z$ , an integer below $p_{\mathsf{Vesta}}$ since $z\in\mathbb{F}_{q}$ .
3.

Validation computes $\mathsf{H}^{\circledast}(\bar{R}\,\|\,\underline{X}\,\|\,m)$ , where $\underline{X}=\mathsf{ser}_{\mathbb{G}}(X)$ : the inputs of the FROST challenge in the same order. Since $H_{2}=\mathsf{H}^{\circledast}$ (Table 2), it recomputes $c$ .
4.

The equation $[S]B=R+[c]X$ , whose cofactor is $1$ on Pallas, is the FROST equation of RFC 9591, Appendix B, which holds.

How $R$ was produced does not enter validation. These are the conditions that ZIP 312, “Rationale”, lists. □

ZIP 312, “FROST(Pallas, BLAKE2b-512)”, states that the suite is meant to produce signatures “indistinguishable from RedPallas Orchard Spend Authorization Signatures”. This volume reads that phrase as the statement of format and validation above; the distributional statement, for randomisers of Construction 5.6, is Proposition 7.24.

Corollary 6.4 (The effective randomiser is the Action’s randomiser).

Let $Y=\mathsf{ak}^{\mathbb{P}}=[s]G^{\mathsf{SpendAuth}}$ be the spend validating key of the key of the note that an Action consumes, and let the Action carry $\mathsf{rk}=\mathsf{ak}^{\mathbb{P}}+[\alpha]G^{\mathsf{SpendAuth}}$ (Ironwood Guide, §“Randomised validating keys”, Construction “Randomised validating key”). Then

Y+[\hat{\alpha}]G^{\mathsf{SpendAuth}}=\mathsf{rk}\quad\Longleftrightarrow% \quad\hat{\alpha}=\alpha\ \text{in}\ \mathbb{F}_{p_{\mathsf{Vesta}}}.

Consequently:

(i)

if $\hat{\alpha}=\alpha$ , the aggregate of Proposition 6.3 on the signature digest is valid under $\mathsf{rk}$ ;
(ii)

if $\hat{\alpha}\neq\alpha$ , with $\alpha$ and $\hat{\alpha}$ fixed before the queries to $H_{2}$ whose inputs contain either key, the aggregate is valid under $\mathsf{rk}$ with probability at most $(Q_{2}+2)(1/p_{\mathsf{Vesta}}+\delta_{512})$ in an experiment with at most $Q_{2}$ queries to $H_{2}$ (Proposition 5.2, applied to the key $Y+[\hat{\alpha}]G^{\mathsf{SpendAuth}}$ and the shift $\alpha-\hat{\alpha}\neq 0$ );
(iii)

the consensus rule $\mathsf{rk}\neq\mathcal{O}$ (protocol specification, §“Action Descriptions”; Ironwood Guide, Construction “Verification”, part (1)) fails exactly when $\alpha=-s$ . For $\alpha=\hat{\alpha}$ the output of Construction 5.6, fixed after the key, this has probability at most

$1/p_{\mathsf{Vesta}}+\delta_{512}+q_{h}\cdot 2^{-256},$

with $q_{h}$ the number of queries to $H_{R}$ made by the party that fixed the key (Lemma 5.7).

Hence, up to these probabilities, consensus accepts the aggregate as the Action’s spend-authorisation signature if and only if the effective randomiser equals the Action’s $\alpha$ .

Proof.

The map $k\mapsto[k]G^{\mathsf{SpendAuth}}$ is injective on $\mathbb{F}_{p_{\mathsf{Vesta}}}$ , since $G^{\mathsf{SpendAuth}}$ generates a group of prime order $p_{\mathsf{Vesta}}$ ; and $Y+[\hat{\alpha}]G^{\mathsf{SpendAuth}}-\mathsf{rk}=[\hat{\alpha}-\alpha]G^{% \mathsf{SpendAuth}}$ . Part (i) is Proposition 6.3 with $X=\mathsf{rk}$ . Part (ii) is the cited proposition, whose hypotheses hold: the shifted material is valid key material (Definition 5.3 and the paragraph following it), and $\mathsf{rk}\neq\mathcal{O}$ in an accepted Action. For (iii), $\mathsf{rk}=[s+\alpha]G^{\mathsf{SpendAuth}}$ is $\mathcal{O}$ exactly when $\alpha=-s$ ; a value within statistical distance $\epsilon$ of uniform takes a fixed value with probability at most $1/p_{\mathsf{Vesta}}+\epsilon$ (Math Guide, Theorem “Properties of statistical distance”, part (3)), and Lemma 5.7 gives $\epsilon=\delta_{512}+q_{h}\cdot 2^{-256}$ . □

For FROST(Pallas, BLAKE2b-512) the term $1/p_{\mathsf{Vesta}}+\delta_{512}$ of parts (ii) and (iii) is below $2^{-253.9}$ .

Remark 6.5 (Consensus is unchanged).

No consensus rule refers to FROST or to a threshold key. The rules that bear on spend authorisation, $\mathsf{rk}\neq\mathcal{O}$ and validity of the spend-authorisation signature under $\mathsf{rk}$ on the signature digest (Ironwood Guide, §“Verification of a transaction”, Construction “Verification”), read only $\mathsf{rk}$ , the $64$ -byte signature and the digest; validation does not depend on how $R$ was produced (ZIP 312, “Rationale”). The first requirement of ZIP 312, “Requirements”, that every signature produced by following the ZIP be verified successfully as an Orchard spend-authorisation signature under the appropriate validating key, is met by Proposition 6.3. The remark makes no claim about the security of the signers, which is the subject of §7.

6.3 Sign normalisation of a shared key

The spend validating key $\mathsf{ak}^{\mathbb{P}}$ of an Orchard-protocol key has even $y$ -coordinate: the last bit, the $\tilde{y}$ bit, of $\mathsf{repr}_{\mathbb{P}}(\mathsf{ak}^{\mathbb{P}})$ is $0$ . For keys with $\mathsf{use\_qsk}=\mathsf{false}$ the protocol specification, §“Orchard Key Components”, produces this by negating $\mathsf{ask}$ when the bit is $1$ (Ironwood Guide, §“The spending key and the spend-side secrets”, Construction “Spend validating key and sign normalisation”). For keys with $\mathsf{use\_qsk}=\mathsf{true}$ , ZIP 2005’s replacement text for that section (“Changes to the Protocol Specification”, § 4.2.3 “Orchard Key Components”) requires $\mathsf{ak}^{\mathbb{P}}\in\mathbb{P}^{*}$ to be obtained “by any suitably secure method that ensures the last bit of $\mathsf{repr}_{\mathbb{P}}(\mathsf{ak}^{\mathbb{P}})$ is $0$ ”; the published specification does not yet carry that text. The requirement is one of key derivation, not a consensus rule: the Action statement admits either sign (protocol specification, §“Action Statement (Orchard)”; Ironwood Guide, Remark “Sign of $\mathsf{ak}^{\mathbb{P}}$ ”). A full viewing key records only $\mathsf{ak}=\mathsf{Extract}_{\mathbb{P}}(\mathsf{ak}^{\mathbb{P}})$ (Ironwood Guide, §“Viewing keys”, Definition “Full viewing key”), from which a transaction builder recovers the point by the even- $y$ lift. For a group key $\mathit{PK}$ of odd $y$ the lift yields $-\mathit{PK}$ ; the builder forms $\mathsf{rk}=-\mathit{PK}+[\alpha]G^{\mathsf{SpendAuth}}$ , which with $\alpha=\hat{\alpha}$ differs from $\mathit{PK}+[\hat{\alpha}]G^{\mathsf{SpendAuth}}$ by $[2]\mathit{PK}\neq\mathcal{O}$ , and by Proposition 5.2, part (ii), applied to the key $\mathit{PK}+[\hat{\alpha}]G^{\mathsf{SpendAuth}}$ and the shift $-2s\neq 0$ , the aggregate is accepted under $\mathsf{rk}$ with probability at most $(Q_{2}+2)(1/p_{\mathsf{Vesta}}+\delta_{512})$ . The randomised key $\mathsf{rk}$ carries no parity condition. Class (Definition 1.1): specified (ZIP 2005, Proposed, taking effect with NU6.3, which ZIP 258, Draft, deploys; ZIP 258, “ZIP 2005 activation”).

Lemma 6.6 (Negation of key material).

Let shares $\mathit{sk}_{j}$ , coefficient commitments $A_{0},\dots,A_{t-1}$ , verification shares $\mathit{PK}_{j}$ and group key $\mathit{PK}$ be valid key material for the signing key $s$ with sharing polynomial $f$ (Definition 2.5). Then $-\mathit{sk}_{j}$ , $-A_{k}$ , $-\mathit{PK}_{j}$ and $-\mathit{PK}$ are valid key material for $-s$ , with sharing polynomial $-f$ . If $\mathit{PK}\neq\mathcal{O}$ , the last bit of $\mathsf{repr}_{\mathbb{P}}(-\mathit{PK})$ differs from that of $\mathsf{repr}_{\mathbb{P}}(\mathit{PK})$ , and $\mathsf{Extract}_{\mathbb{P}}(-\mathit{PK})=\mathsf{Extract}_{\mathbb{P}}(% \mathit{PK})$ .

Proof.

The polynomial $-f$ has degree at most $t-1$ , coefficients $-a_{k}$ and constant term $-s$ ; and $-\mathit{sk}_{j}=(-f)(j)$ , $[-a_{k}]B=-A_{k}$ , $[-\mathit{sk}_{j}]B=-\mathit{PK}_{j}$ and $[-s]B=-\mathit{PK}$ , which are the conditions of Definition 2.5. For $\mathit{PK}=(x,y)\neq\mathcal{O}$ , $-\mathit{PK}=(x,p_{\mathsf{Pallas}}-y)$ . Here $y\neq 0$ , since a point with $y=0$ has order $2$ and the group has odd order; and $p_{\mathsf{Pallas}}$ is odd, so $y$ and $p_{\mathsf{Pallas}}-y$ have opposite parities. The last bit of the star encoding is $y\bmod 2$ (Ironwood Guide, Definition “Star encoding”). The extracted coordinate is $x$ for both points (Ironwood Guide, §“Fields, groups, and encodings”, Lemma “Coordinate extraction identifies opposite points”). □

On the toy curve of Example 4.12, the negated material has $-s=646$ and shares $835$ , $57$ , $246$ ; the group key $\mathit{PK}=(526,125)$ becomes $-\mathit{PK}=(526,884)$ , with the same $x$ -coordinate and the parity of $y$ changed from $1$ to $0$ .

Construction 6.7 (Sign normalisation of key material).

Input: valid key material output by Construction 3.2 or by Construction 3.6. Every party computes $\mathit{PK}$ from public data (Lemma 2.6).

1.

If $\mathit{PK}=\mathcal{O}$ , key generation is repeated: ZIP 2005 requires $\mathsf{ak}^{\mathbb{P}}\in\mathbb{P}^{*}$ , and neither key generation excludes $s=0$ .
2.

Otherwise, if the last bit of $\mathsf{repr}_{\mathbb{P}}(\mathit{PK})$ is $1$ , every participant $P_{j}$ replaces its share $\mathit{sk}_{j}$ by $-\mathit{sk}_{j}$ , and every party replaces each $A_{k}$ , each $\mathit{PK}_{j}$ and $\mathit{PK}$ by its negative.

The test reads public data only, so all parties decide identically without interaction. Output: the resulting key material and $\mathsf{ak}^{\mathbb{P}}:=\mathit{PK}$ . Class (Definition 1.1): the requirement is specified (ZIP 2005, Proposed); the method is this volume’s.

Correctness.

Validity of the output and even $y$ of $\mathsf{ak}^{\mathbb{P}}$ follow from Lemma 6.6; $\mathit{PK}\neq\mathcal{O}$ on output by step (1). □

6.4 The key tree of an Orchard-protocol FROST key

The Ironwood Guide constructs only keys with $\mathsf{use\_qsk}=\mathsf{false}$ (Remark “Scope of the key derivations”). Write $\mathsf{PRFexpand}$ for the Ironwood Guide’s Construction “Expansion function” and $\mathrm{ToBase}$ , $\mathrm{ToScalar}$ for its Definition “Field reductions” (“Pseudorandom functions and field reductions”); $\mathsf{truncate}_{32}$ returns the first $32$ bytes of its input.

Construction 6.8 (Orchard-protocol threshold key).

This is the branch $\mathsf{use\_qsk}=\mathsf{true}$ of ZIP 2005’s replacement for § 4.2.3 “Orchard Key Components”.

1.

Run a key generation (§3) and Construction 6.7; let $\mathsf{ak}^{\mathbb{P}}:=\mathit{PK}$ and $\mathsf{ak}:=\mathsf{Extract}_{\mathbb{P}}(\mathsf{ak}^{\mathbb{P}})$ , non-zero since $\mathsf{ak}^{\mathbb{P}}\neq\mathcal{O}$ (Ironwood Guide, Lemma “Extract vanishes only at the identity”).
2.

The participants privately agree on a spending key $\mathsf{sk}$ , a $32$ -byte string drawn uniformly and independently of the key material.

Every participant computes

	$\displaystyle\mathsf{nk}$	$\displaystyle:=\mathsf{H}^{\mathsf{nk}}(\mathsf{sk})=\mathrm{ToBase}\bigl{(}% \mathsf{PRFexpand}_{\mathsf{sk}}([\mathtt{0x07}])\bigr{)},$
	$\displaystyle\mathsf{qsk}$	$\displaystyle:=\mathsf{H}^{\mathsf{qsk}}(\mathsf{sk})=\mathsf{truncate}_{32}% \bigl{(}\mathsf{PRFexpand}_{\mathsf{sk}}([\mathtt{0x0C}])\bigr{)},$
	$\displaystyle\mathsf{qk}$	$\displaystyle:=\mathsf{H}^{\mathsf{qk}}(\mathsf{qsk})$
		$\displaystyle\phantom{:}=\mathrm{BLAKE3.derive\_key}(\texttt{Zcash ZIP 2005 qk% -derivation v1},\mathsf{qsk},32),$
	$\displaystyle\mathsf{r_{ivk}}$	$\displaystyle:=\mathsf{H}^{\mathsf{rivk\_ext}}_{\mathsf{qk}}(\mathsf{ak},% \mathsf{nk})$
		$\displaystyle\phantom{:}=\mathrm{ToScalar}\bigl{(}\mathsf{PRFexpand}_{\mathsf{% qk}}([\mathtt{0x0D}]\,\\|\,\mathsf{I2LEOSP}_{256}(\mathsf{ak})\,\\|\,\mathsf{I2% LEOSP}_{256}(\mathsf{nk}))\bigr{)},$

where $\mathsf{H}^{\mathsf{qk}}$ is the key-derivation mode of the BLAKE3 hash function with the displayed context string and a $32$ -byte output, ZIP 2005’s derivation, of which no property is used below.

4.

The remainder of § 4.2.3 is unchanged: $\mathsf{ivk}:=\mathsf{Commit}^{\mathsf{ivk}}_{\mathsf{r_{ivk}}}(\mathsf{ak},% \mathsf{nk})$ , the internal keys and the other keys derived from $(\mathsf{ak},\mathsf{nk},\mathsf{r_{ivk}})$ , and the rejection of a key whose $\mathsf{ivk}$ or internal $\mathsf{ivk}$ lies in $\{0,\bot\}$ . On rejection step (2) is repeated with a new $\mathsf{sk}$ , and $\mathsf{ak}^{\mathbb{P}}$ is kept.
5.

The protocol MUST ensure that all participants obtain the same $\mathsf{ak}$ , $\mathsf{nk}$ and $\mathsf{r_{ivk}}$ , which ZIP 2005 calls $\mathsf{rivk\_ext}$ .

The spend authorising key $\mathsf{ask}=s$ stays threshold-shared. Figure 1 shows the tree.

Steps (3) and (5), the agreement of step (2) and the rejection of step (4) quote ZIP 2005, “Usage with FROST” and “Changes to the Protocol Specification”, § 4.2.3; the uniform, independent draw of $\mathsf{sk}$ in step (2) and keeping $\mathsf{ak}^{\mathbb{P}}$ on rejection in step (4) are this volume’s reading of “privately agree” and of the repetition with a new $\mathsf{sk}$ . Step (1) meets the even- $y$ clause of that section by Construction 6.7. Attempts of step (4) are independent, $\mathsf{sk}$ being fresh on each; the volume proves no bound on their rejection probability.

ZIP 2005 names two sources of $\mathsf{ak}^{\mathbb{P}}$ for $\mathsf{use\_qsk}=\mathsf{true}$ : direct generation of an Orchard-protocol $\mathsf{ask}\in\mathbb{F}^{*}_{p_{\mathsf{Vesta}}}$ with $\mathsf{ak}^{\mathbb{P}}=[\mathsf{ask}]G^{\mathsf{SpendAuth}}$ , which a dealer then shares by Construction 3.2; and FROST distributed key generation in which the spend-authorisation material is $t$ -of- $n$ shared, here Construction 3.6. Its “Deployment” states that “FROST distributed key generation requires the $\mathsf{use\_qsk}=\mathsf{true}$ case”. The key-generation section that ZIP 2005 cites for the second method is ZIP 312, “Key Generation”, which leaves key generation out of scope.

The Orchard pool is spend-only by consensus: no transaction increases its value, and every Orchard-pool Action creates its note at the address of the note it consumes (ZIP 258, Draft, “Consensus rules from NU6.3 activation”; Ironwood Guide, §“The Orchard protocol and its two pools”). By consensus, therefore, only a party able to authorise spends for an address can create an Orchard-pool note to it, the consumed side of the Action being possibly a dummy note at that address (ZIP 326, “Rationale for key-generation restrictions”). ZIP 326 (Draft), “Wallet key-generation restrictions”, forbids conforming wallets to send Orchard-pool funds to a key with $\mathsf{use\_qsk}=\mathsf{true}$ ; under that rule such a key, in particular every key from distributed key generation, holds no Orchard-pool notes, and consensus does not enforce the rule. A dealer-shared key with $\mathsf{use\_qsk}=\mathsf{false}$ may spend notes of either pool. This qualifies the statement of §1.1 that both pools are served.

Remark 6.9 (Scope of the ZIP 2005 constraints).

ZIP 2005, “Usage with FROST”, states its constraints for keys whose $\mathsf{ak}$ is derived jointly by distributed key generation, and this volume reads its MUST as binding those keys. A dealer that shares an $\mathsf{ask}$ derived from a spending key, which ZIP 312, “Key Generation”, permits, produces an ordinary key with $\mathsf{use\_qsk}=\mathsf{false}$ , known to the dealer and outside that constraint. A dealer that shares a directly generated $\mathsf{ask}$ may use Construction 6.8.

Remark 6.10 (Custody of the common secrets).

Under Construction 6.8 the spend authorising key $\mathsf{ask}$ is threshold-shared and no signing run assembles it, while $\mathsf{sk}$ , $\mathsf{nk}$ , $\mathsf{r_{ivk}}$ and $\mathsf{qsk}$ are known to every participant. Each participant MUST treat $\mathsf{qsk}$ as a secret held at least as securely and reliably as $\mathsf{ask}$ (ZIP 2005, “Usage with FROST”).

Lemma 6.11 (Viewing material and the signing key).

(a)

For Construction 6.8, the tuple $V:=(\mathsf{sk},\mathsf{nk},\mathsf{qsk},\mathsf{qk},\mathsf{r_{ivk}},\mathsf{% ivk},\ldots)$ , with every key derived from $\mathsf{ak}$ , $\mathsf{nk}$ and $\mathsf{r_{ivk}}$ , is a randomised function of $\mathsf{ak}$ alone, $\mathsf{sk}$ being drawn independently of the key material. Hence, for every experiment in which an adversary receives $V$ together with other inputs, an adversary that receives only the other inputs, $\mathsf{ak}^{\mathbb{P}}$ among them, draws $\mathsf{sk}$ uniformly, computes $V$ with the same rejection, and runs the first, has identical output distribution.
(b)

For a dealer-shared key with $\mathsf{use\_qsk}=\mathsf{false}$ and $\mathsf{ask}=\pm\mathrm{ToScalar}(\mathsf{PRFexpand}_{\mathsf{sk}}([\mathtt{0x% 06}]))$ derived from $\mathsf{sk}$ , the spending key determines $\mathsf{ask}$ , so no participant may hold $\mathsf{sk}$ . The participants’ $\mathsf{nk}=\mathrm{ToBase}(\mathsf{PRFexpand}_{\mathsf{sk}}([\mathtt{0x07}]))$ and $\mathsf{r_{ivk}}=\mathrm{ToScalar}(\mathsf{PRFexpand}_{\mathsf{sk}}([\mathtt{0% x08}]))$ , hence the full viewing key, are simulated from $\mathsf{ak}^{\mathbb{P}}$ and independent uniform values with the same rejection, at a cost, per key attempt, of the advantage against the Ironwood Guide’s Assumption “Pseudorandomness of PRF expansion” plus the sum of the three reduction distances, below $3\cdot 2^{-257}$ .

Proof.

(a) Every component of $V$ is computed from $\mathsf{sk}$ and $\mathsf{ak}$ , and the rejection test reads only $\mathsf{sk}$ and $\mathsf{ak}$ ; the construction draws $\mathsf{sk}$ independently of the key material, as the simulating adversary does. (b) By the Ironwood Guide’s Lemma “Independence of domain-separated expansions” (“Pseudorandom functions and field reductions”), under Assumption “Pseudorandomness of PRF expansion” and with the three distinct leading bytes $\mathtt{0x06}$ , $\mathtt{0x07}$ , $\mathtt{0x08}$ , the triple $(\mathsf{ask},\mathsf{nk},\mathsf{r_{ivk}})$ is replaced by independent uniform values at the stated cost, each reduction distance being below $2^{-257}$ . After the replacement $\mathsf{nk}$ and $\mathsf{r_{ivk}}$ are independent of $\mathsf{ask}$ , hence of $\mathsf{ak}^{\mathbb{P}}$ , and the simulator draws them and applies the rejection test, which reads $\mathsf{ak}$ , $\mathsf{nk}$ and $\mathsf{r_{ivk}}$ . No property of $\mathsf{H}^{\mathsf{qk}}$ is used. □

Section 7 uses the lemma to give the corrupt participants the common secrets. Class (Definition 1.1): ZIP 2005’s constraints on FROST key generation are specified (ZIP 2005, Proposed); how the participants privately agree on $\mathsf{sk}$ is designed but unspecified: ZIP 2005, “Usage with FROST”, requires only that they agree privately, no specification gives a protocol for it, and the revision of ZIP 312 proposed in pull request 895 publishes one.

Refer to caption — Figure 1: The Orchard-protocol threshold key of Construction 6.8. Red: threshold-shared values; the shares $\mathit{sk}_{1},\dots,\mathit{sk}_{n}$ determine $\mathsf{ask}$ by Lagrange recombination, which no signing run performs (dashed). Amber: secrets common to all participants, derived from the privately agreed spending key $\mathsf{sk}$ : $\mathsf{nk}$ and $\mathsf{qsk}$ from $\mathsf{sk}$ , $\mathsf{qk}$ from $\mathsf{qsk}$ , and $\mathsf{r_{ivk}}$ from $(\mathsf{ak},\mathsf{nk})$ keyed by $\mathsf{qk}$ . Blue: values known to every party, the group key $\mathit{PK}$ , normalised to $\mathsf{ak}^{\mathbb{P}}$ and extracted to $\mathsf{ak}$ . Every edge is labelled by its operation.

6.5 Order of randomiser, validating key and signature digest

Proposition 6.12 (Order of a threshold spend authorisation).

Consider a signing run over an Orchard-protocol threshold key, re-randomised as in Definition 5.3 by an effective randomiser $\hat{\alpha}$ , whose aggregate consensus accepts as the spend-authorisation signature of an Action with randomiser $\alpha$ and randomised validating key $\mathsf{rk}$ , in a transaction with signature digest $m$ . Except with the probabilities of Corollary 6.4 and of Proposition 5.5:

(i)

the randomiser $\hat{\alpha}=\alpha$ is fixed before $\mathsf{rk}$ , which is the function $\mathsf{ak}^{\mathbb{P}}+[\hat{\alpha}]G^{\mathsf{SpendAuth}}$ of it;
(ii)

the key $\mathsf{rk}$ is fixed before $m$ , which commits to it (Ironwood Guide, §“Transaction digests and signatures”, Definition “Signature digest”);
(iii)

the digest $m$ is fixed before any Round Two share, being the message of the binding factors and of the challenge;
(iv)

Round One precedes $\hat{\alpha}$ under Construction 5.6, which hashes the commitment list, and need not precede it for a randomiser fixed before signing, as in Remark 6.13, where (i) to (iii) still hold;
(v)

the Action proof takes $\alpha$ as auxiliary input and $\mathsf{rk}$ as instance, so it follows (i), and it is unconstrained with respect to $m$ and to Round Two, proofs being authorising data outside the digest.

Proof.

(i) is Corollary 6.4. (ii) and (iii) are the data dependencies of the cited definition and of Construction 4.8, as run in step (3) of Construction 5.10: $\rho_{i}$ takes $H_{4}(m)$ and $c$ takes $m$ . (iv) is the input of $H_{R}$ in Construction 5.6. (v) follows from the Ironwood Guide’s Definition “Authorising-data digest; effecting and authorising data” and “Construction of a transaction”, where signing can precede proving (ZIP 244, “Authorizing Data Commitment”, field A.3a). A randomiser that is a function of $m$ , as under Construction 5.4 with the digest as message, would by (i) and (ii) be a fixed point, which Proposition 5.5 bounds; so that derivation admits no order except with that negligible probability. □

Class (Definition 1.1): the order of Proposition 6.12 under Construction 5.6 is designed but unspecified; no specification composes ZIP 312 with a transaction format.

Remark 6.13 (Randomisers chosen by a transaction constructor).

ZIP 312 derives the randomiser in Round Two (“Randomizer Generation” and “Round Two - Signature Share Generation”), and a derived randomiser equals an $\alpha$ fixed earlier, as Corollary 6.4 requires, only with probability at most $1/p_{\mathsf{Vesta}}+\delta_{512}+q_{h}\cdot 2^{-256}$ (Lemma 5.7). A flow in which the transaction constructor fixes $\alpha$ and $\mathsf{rk}$ before signing, and the Coordinator sends that $\alpha$ as the effective randomiser, respects the order of Proposition 6.12, but no specification or published design states it: its design is an open problem (Definition 1.1), and under it the Coordinator chooses the effective randomiser outright (Remark 5.8).

6.6 Threshold signing of an Action

The single-signer construction is cited, not rebuilt. Each Action draws $\alpha$ by $\mathsf{GenRandom}$ , sets $\mathsf{rsk}:=\mathsf{ask}+\alpha$ and $\mathsf{rk}:=\mathsf{ak}^{\mathbb{P}}+[\alpha]G^{\mathsf{SpendAuth}}$ , proves the Action statement with $\alpha$ as auxiliary input, computes the signature digest and signs it under $\mathsf{rsk}$ (Ironwood Guide, §“Randomised validating keys”, Construction “Randomised validating key”; “Construction of a transaction”, Construction “Ironwood-pool bundle”, steps (5), (7), (10) and (11); protocol specification, §“Sending Notes (Orchard)” and §“Spend Authorization Signature (Sapling and Orchard)”).

Construction 6.14 (Threshold spend authorisation of an Action).

The transaction builder acts as Coordinator: it creates the Action proof and so already controls the privacy of the transaction (ZIP 312, “Threat Model”). For each Action that consumes a note of an Orchard-protocol threshold key (Construction 6.8), in the order of Proposition 6.12, it proceeds as follows.

1.

It runs Round One (Construction 5.10, step (1)) with a signing set $I$ of at least $t$ participants.
2.

It derives the effective randomiser $\hat{\alpha}$ by Construction 5.6, the only designed derivation that respects that order: Proposition 5.5 excludes the Draft derivation, and a constructor-chosen $\alpha$ has no published design (Remark 6.13).
3.

It sets $\alpha:=\hat{\alpha}$ and $\mathsf{rk}:=\mathsf{ak}^{\mathbb{P}}+[\alpha]G^{\mathsf{SpendAuth}}$ .
4.

Once every Action of the transaction is fixed, it computes the one signature digest $m$ of the transaction.
5.

It runs Round Two of Construction 5.10 with message $m$ , each signer performing the message check of Definition 5.9, and aggregates.
6.

At any point after step (3), it proves the Action statement with $\alpha$ as auxiliary input (Ironwood Guide, §“The Action statement”).

These steps replace the draw of $\alpha$ and the single-holder signature in the cited construction; every other Action, dummy spends included, is built as there. No party holds $\mathsf{rsk}$ . The builder alone makes the binding signature (Ironwood Guide, §“The binding signature”). Every threshold-spent Action has its own $\alpha$ and $\mathsf{rk}$ and its own signing run, with fresh nonces and randomiser, all on the one digest $m$ ; since $m$ commits to the $\mathsf{rk}$ of every Action, the Round One and the randomiser of every threshold-spent Action precede $m$ , and hence every Round Two (Proposition 6.12, (i) to (iv), applied to each Action). Class (Definition 1.1): designed but unspecified; the composition of ZIP 312 with the transaction is this volume’s own.

Acceptance.

After normalisation $\mathsf{ak}^{\mathbb{P}}=\mathit{PK}$ , and $\alpha=\hat{\alpha}$ ; so Proposition 6.3 and Corollary 6.4, part (i), give a signature valid under $\mathsf{rk}$ on $m$ , except in the zero-nonce case and when $\mathsf{rk}=\mathcal{O}$ , whose probabilities Theorem 4.11 and Corollary 6.4, part (iii), bound. □

The circuit and the consensus rules are unchanged (Remark 6.5). Both pools of the Orchard protocol use the same RedPallas spend authorisation, so one flow serves an Action of either pool (Ironwood Guide, §“The Orchard protocol and its two pools”; ZIP 229, “Reuse of the Orchard protocol with minimal changes”); which pool’s notes a key may hold is fixed in §6.4.