Apply suggestions from code review

Co-authored-by: teor <teor@riseup.net>

zip-frost.rst

@@ -53,7 +53,7 @@ split between users in a way that a threshold (e.g. 2 out of 3) of them must
 sign the transaction in order to create the final signature. This enables scenarios
 such as users and exchanges sharing custody of a wallet, for example.
 
-FROST is one of such threshold signatures protocols. However, it can't be used as-is
+FROST is one of such threshold signature protocols. However, it can't be used as-is
 since the Zcash protocol also requires re-randomizing public and private keys
 to ensure unlinkability between transactions. This ZIP specifies a variant of
 FROST with re-randomization support.
@@ -62,11 +62,11 @@ FROST with re-randomization support.
 Requirements
 ============
 
-- All signatures generated by following this ZIP MUST be verified successfully
+- All signatures generated by following this ZIP must be verified successfully.
   as Sapling or Orchard spend authorization signatures.
 - The signatures generated by following this ZIP should meet the security criteria
   for Signature with Re-Randomizable Keys as specified in the Zcash protocol [#protocol-concretereddsa]_.
-- Follow the threat model described below.
+- The threat model described below must be taken into account.
 
 Threat Model
 ------------
@@ -75,16 +75,15 @@ In normal usage, a Zcash user follows multiple steps in order to generate a
 shielded transaction:
 
 - The transaction is created.
-- The transaction is signed with a randomized version of the user's spend
+- The transaction is signed with a re-randomized version of the user's spend
   authorization private key.
 - The zero-knowledge proof for the transaction is created with the randomizer
   as an auxiliary (secret) input, among others.
 
 When employing re-randomized FROST as specified in this ZIP, the goal is to
-split the spend authorization private key among multiple participants. This means
+split the spend authorization private key :math:`\mathsf{ask}` among multiple possible signers. This means
 that the proof generation will still be generated by a single participant, likely
-the one that created the transaction in the first place and that will actually
-submit the transaction to the network. Note that his user already controls the
+the one that created the transaction in the first place. Note that this user already controls the
 privacy of the transaction since they are responsible for creating the proof.
 
 This fits well into the "Coordinator" role from the FROST specification. The
@@ -106,8 +105,7 @@ Non-requirements
 ================
 
 - This ZIP does not support removing the Coordinator role, as described in #[FROST]_.
-- This ZIP does not prevent key share holders from breaking the privacy
-  of the transaction.
+- This ZIP does not prevent key share holders from linking the signing operation to a transaction in the blockchain.
 
 
 Specification
@@ -122,7 +120,7 @@ following modifications.
 Randomizer Generation
 '''''''''''''''''''''
 
-A new helper function is defined, which computes RedDSA.GenRandom:
+A new helper function is defined, which computes :math:`\mathsf{RedDSA.GenRandom}`:
 
 ::
 
@@ -163,7 +161,7 @@ Round Two - Signature Share Generation
 ''''''''''''''''''''''''''''''''''''''
 
 In Round Two, the Coordinator generates a random scalar `randomizer` by calling
-`randomizer_generate` and sends it to each signer, over a secret channel,
+`randomizer_generate` and sends it to each signer, over a confidential and authenticated channel,
 along with the message and the set of signing commitments. (Note that this differs
 from regular FROST which just requires an authenticated channel.)
 
@@ -172,7 +170,7 @@ computation of the binding factor. It is specified as the following: ::
 
   Inputs:
   - identifier, Identifier i of the signer.
-    Note: identifier will never equal 0.
+    Note: FROST spec requires that identifier will never equal 0.
   - sk_i, Signer secret key share, a Scalar.
   - group_public_key, public key corresponding to the group signing key,
     an Element in G.
@@ -183,7 +181,7 @@ computation of the binding factor. It is specified as the following: ::
       [(j, hiding_nonce_commitment_j, binding_nonce_commitment_j), ...], a
     list of commitments issued in Round 1 by each signer and sent by the Coordinator.
     Each element in the list indicates the signer identifier j and their two commitment
-    Element values (hiding_nonce_commitment_j, binding_nonce_commitment_j).s
+    Element values (hiding_nonce_commitment_j, binding_nonce_commitment_j).
     This list MUST be sorted in ascending order by signer identifier.
   - randomizer, the randomizer Scalar.
 
@@ -223,7 +221,8 @@ The `verify_signature_share` is changed to incorporate the randomizer,
 as follows: ::
 
   Inputs:
-  - identifier, Identifier i of the signer. Note identifier will never equal 0.
+  - identifier, Identifier i of the signer.
+    Note: identifier will never equal 0.
   - PK_i, the public key for the ith signer, where PK_i = G.ScalarBaseMult(sk_i),
     an Element in G
   - comm_i, pair of Element values in G (hiding_nonce_commitment, binding_nonce_commitment)
@@ -234,7 +233,7 @@ as follows: ::
       [(j, hiding_nonce_commitment_j, binding_nonce_commitment_j), ...], a
     list of commitments issued in Round 1 by each signer, where each element
     in the list indicates the signer identifier j and their two commitment
-    Element values (hiding_nonce_commitment_j, binding_nonce_commitment_j).s
+    Element values (hiding_nonce_commitment_j, binding_nonce_commitment_j).
     This list MUST be sorted in ascending order by signer identifier.
   - group_public_key, public key corresponding to the group signing key,
     an Element in G.
@@ -320,7 +319,7 @@ Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
   - SerializeScalar: Implemented by outputting the little-endian 32-byte encoding
     of the Scalar value.
   - DeserializeScalar: Implemented by attempting to deserialize a Scalar from a
-    32-byte string. This function can fail if the input does not represent a Scalar
+    little-endian 32-byte string. This function can fail if the input does not represent a Scalar
     between the value 0 and G.Order() - 1.
 
 - Hash (`H`): BLAKE2b-512 [#BLAKE]_ (BLAKE2b with 512-bit output and 16-byte personalization string),
@@ -334,7 +333,7 @@ Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
     modulo L = 6554484396890773809930967563523245729705921265872317281365359162392183254199.
     (This is equivalent to :math:`\mathsf{H}^\circledast(m)`, as defined in
     [#protocol-concretereddsa]_ parametrized with [#protocol-jubjub]_.)
-  - H3(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubDi", m)
+  - H3(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubD", m)
   - H4(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubN", m), interpreting
     the 64 bytes as a little-endian integer, and reducing the resulting integer
     modulo L = 6554484396890773809930967563523245729705921265872317281365359162392183254199.
@@ -360,7 +359,7 @@ Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
   - SerializeScalar: Implemented by outputting the little-endian 32-byte encoding
     of the Scalar value.
   - DeserializeScalar: Implemented by attempting to deserialize a Scalar from a
-    32-byte string. This function can fail if the input does not represent a Scalar
+    little-endian 32-byte string. This function can fail if the input does not represent a Scalar
     between the value 0 and G.Order() - 1.
 
 - Hash (`H`): BLAKE2b-512 [#BLAKE]_ (BLAKE2b with 512-bit output and 16-byte personalization string),