[ZIP 312] FROST for Spend Authorization Signatures

[conradoplg]

Adds a ZIP specifying how to use FROST to generate Spend Authorization signatures.

Note that there was a previous round of review on the PR targetting our fork (which will be closed): ZcashFoundation#3

But now this is the "official" submission.

I chose to leave the commit history, let me know if you'd like for me to squash them.

fixes #382

[conradoplg]

Check if some of those can be matched to RedDSA hashes

[conradoplg]

RedDSA basically uses the same function for HR and H2. I don't think we gain anything by making them them equal in this ZIP since FROST already requires a bunch of domain-separated hash functions anyway.

[str4d]

Suggested change

	While key generation is out of scope for this ZIP and the FROST spec [#FROST]_,
	it needs to be consistent with FROST, see [#frost-tdkg]_ for guidance. The spend
	authorization private key :math:`\mathsf{ask}` [#protocol-spendauthsig]_ is the
	particular key that must be used in the context of this ZIP. Note that the
	:math:`\mathsf{ask}` is usually derived from the spending key
	:math:`\mathsf{sk}`, though that is not required. Not doing so allows using
	distributed key generation, since the key it generates is unpredictable. Note
	however that not deriving :math:`\mathsf{ask}` from :math:`\mathsf{sk}` prevents
	using seed phrases to recover the original secret (which may be something
	desirable in the context of FROST).
	While key generation is out of scope for this ZIP and the FROST spec [#FROST]_,
	it needs to be consistent with FROST; see [#frost-tdkg]_ for general guidance.
	To define a spending or viewing key that uses FROST, the Sapling and Orchard key
	trees [#protocol-saplingkeycomponents]_ [#protocol-orchardkeycomponents]_ are
	adjusted as follows:
	- The Spend validating key :math:`\mathsf{ak}` is replaced by the FROST group
	public key `PK` [#frost-protocol]_.
	- The Spend authorizing key :math:`\mathsf{ask}` is replaced by the logical
	signing key that corresponds to the group public key `PK`. By design, this
	key never exists, and instead is represented by each participant's FROST
	signing key share `sk_i`.
	The remaining parts of the Sapling and Orchard key trees are generated from
	a common... (TODO: Finish specifying how the other common parts of the
	Sapling and Orchard key trees are derived for participants, perhaps in terms
	of a common `sk` or a common HD path.)
	(Old remaining content below, which might change after the above TODO.)
	Note that the :math:`\mathsf{ask}` is usually derived from the spending key
	:math:`\mathsf{sk}`, though that is not required. Not doing so allows using
	distributed key generation, since the key it generates is unpredictable. Note
	however that not deriving :math:`\mathsf{ask}` from :math:`\mathsf{sk}` prevents
	using seed phrases to recover the original secret (which may be something
	desirable in the context of FROST).

[str4d]

Moved to #883.

[str4d]

Scanned over this in a pairing with @nuttycom. ACK 6e6893d8323103013163586eb7e3c53e929a14b4 for merging as draft. There are editorial changes that we can make in subsequent PRs; I'll also move my suggestion for keygen to a new PR.