FIP-0086: Specify and update signature and signature aggregation (#1064)

* FIP-0086: Specify and update signature and signature aggregation

This commit:

1. Specifies the BLS curve used by F3.
2. Specifies the aggregation scheme.
3. Tweaks the aggregation scheme to use all public keys from the
   committee when computing the aggregation coefficients for better
   performance.

This change does not change how F3 consensus works, it just makes the
protocol more efficient.

See filecoin-project/go-f3#592

* Apply suggestions from code review

Co-authored-by: Jorge M. Soares <[email protected]>
Co-authored-by: Masih H. Derkani <[email protected]>

---------

Co-authored-by: Jorge M. Soares <[email protected]>
Co-authored-by: Masih H. Derkani <[email protected]>

FIPS/fip-0086.md

@@ -801,6 +801,23 @@ This protocol uses merkle trees as vector commitments to commit to both (a) the
 
 In this tree, a proof that some value `v` is committed to at index `i` in the merkle tree rooted at `r` comprises the "uncles" (the branches not taken) of the merkle path from `v` to `r` (bottom to top). This algorithm is best described in [code](../resources/fip-0086/merkletree.go).
 
+### Signatures and Signature Aggregation
+
+This protocol uses BLS signatures. Specifically, it uses the BLS12-381 curve where G2 is used for signatures and G1 is used for public keys.
+
+For aggregation, it uses the [BDN][bdn] signature aggregation scheme with BLAKE2X XOF as the hash function to generate the coefficients. Implementations should use [go.dedis.ch/kyber/v4](https://pkg.go.dev/go.dedis.ch/kyber/v4/sign/bdn) for reference.
+
+Signatures and public keys are aggregated by:
+
+1. Collecting all public keys from the committee for the current instance, ordered by power descending.
+  * In cases of equal power, ordered by actor ID ascending.
+2. Computing the coefficients given this set of public keys. The aggregation coefficients depend on all public keys, not just the public keys involved in a particular signature.
+3. Finally, aggregating according to the [BDN][bdn] aggregation scheme.
+
+Implementations should pre-compute the aggregation coefficients and the public key terms at the beginning of each instance as they can be reused for the duration of the instance and are expensive to compute.
+
+[bdn]: https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html
+
 ## Design Rationale
 
 Many possibilities were considered for faster finality. Other options considered include: