Merge branch 'main' into merlin-transcript

Author: hdevalence

docs/notes.md

@@ -614,7 +614,7 @@ The Bulletproofs paper outlines two versions of multi-party computation aggregat
 
 For more information on how the aggregation protocol works and is implemented, see the [protocol notes](../aggregated_range_proof/index.html). 
 
-The aggregated range proof has the same form as the individual range proof, in that the provers (the parties) still perform the same calculations to prove that \\(t(x) = \langle \mathbf{l}(x), \mathbf{r}(x) \rangle \\) and that \\(t_0, \mathbf{l}(x), \mathbf{r}(x)\\) are correct. The difference is that the challenge values are obtained from the dealer, which generates them by combining commitments from all the parties, and that the calculations of different parties are seperated by different powers of the challenge scalars \\(y\\) and \\(z\\).
+The aggregated range proof has the same form as the individual range proof, in that the provers (the parties) still perform the same calculations to prove that \\(t(x) = \langle \mathbf{l}(x), \mathbf{r}(x) \rangle \\) and that \\(t_0, \mathbf{l}(x), \mathbf{r}(x)\\) are correct. The difference is that the challenge values are obtained from the dealer, which generates them by combining commitments from all the parties, and that the calculations of different parties are separated by different powers of the challenge scalars \\(y\\) and \\(z\\).
 
 We will explain how one piece of the aggregated proof is generated for party \\(j\\), and then will show how all of the pieces for all of the \\(m\\) parties can be combined into one aggregated proof.
 
@@ -879,4 +879,4 @@ With these observations, we can simplify the combined \\(m\\)-party statement ab
 \\]
 
 
-[bulletproofs_paper]: https://eprint.iacr.org/2017/1066.pdf
+[bulletproofs_paper]: https://eprint.iacr.org/2017/1066.pdf

docs/range-proof-protocol.md

@@ -128,7 +128,7 @@ The dealer creates the aggregated vector polynomials \\(\mathbf{l}(x), \mathbf{r
 \end{aligned}
 \\]
 
-The the dealer then performs the [inner product argument](../inner_product_proof/index.html) to prove the relation:
+The dealer then performs the [inner product argument](../inner_product_proof/index.html) to prove the relation:
 \\[
 \operatorname{PK}\left\\{
   ({\mathbf{G}}, {\mathbf{H}}' \in {\mathbb G}^{n \cdot m}, P', Q \in {\mathbb G}; {\mathbf{l}}, {\mathbf{r}} \in {\mathbb Z\_p}^{n\cdot m})
@@ -289,4 +289,4 @@ multiplying equation `2` by \\(c\\), and adding it with equation `3`. Finally, t
                       + & \quad {\langle {- \mathbf{l}\_{(j)}(x)} -z\mathbf{1}, {\mathbf{G}\_{(j)}} \rangle}\\\\
                       + & \quad {\langle {- \mathbf{r}\_{(j)}(x)} \circ \mathbf{y}^{-n} y^{-j \cdot n} + z\mathbf{1} + z^{j+2} \cdot \mathbf{y}^{-n} y^{-j \cdot n} \circ {\mathbf{2}}^n, {\mathbf{H}}\_{(j)} \rangle}\\\\
 \end{aligned}
-\\]
+\\]

src/errors.rs

@@ -15,12 +15,15 @@ pub enum ProofError {
     WrongNumBlindingFactors,
     /// This error occurs when attempting to create a proof with
     /// bitsize other than \\(8\\), \\(16\\), \\(32\\), or \\(64\\).
-    #[fail(display = "Invalid bitsize, must have n = 8,16,32,64")]
+    #[fail(display = "Invalid bitsize, must have n = 8,16,32,64.")]
     InvalidBitsize,
     /// This error occurs when attempting to create an aggregated
     /// proof with non-power-of-two aggregation size.
-    #[fail(display = "Invalid aggregation size, m must be a power of 2")]
+    #[fail(display = "Invalid aggregation size, m must be a power of 2.")]
     InvalidAggregation,
+    /// This error occurs when the generators are of the wrong length.
+    #[fail(display = "Invalid generators length, must be equal to n.")]
+    InvalidGeneratorsLength,
     /// This error results from an internal error during proving.
     ///
     /// The single-party prover is implemented by performing

src/range_proof/mod.rs

@@ -79,6 +79,12 @@ impl RangeProof {
         if values.len() != blindings.len() {
             return Err(ProofError::WrongNumBlindingFactors);
         }
+        if generators.n != n {
+            return Err(ProofError::InvalidGeneratorsLength);
+        }
+        if !(n == 8 || n == 16 || n == 32 || n == 64) {
+            return Err(ProofError::InvalidBitsize);
+        }
 
         let dealer = Dealer::new(generators, n, values.len(), transcript)?;
 
@@ -146,6 +152,12 @@ impl RangeProof {
     ) -> Result<(), ProofError> {
         // First, replay the "interactive" protocol using the proof
         // data to recompute all challenges.
+        if gens.n != n {
+            return Err(ProofError::InvalidGeneratorsLength);
+        }
+        if !(n == 8 || n == 16 || n == 32 || n == 64) {
+            return Err(ProofError::InvalidBitsize);
+        }
 
         let m = value_commitments.len();
 

src/util.rs

@@ -105,7 +105,7 @@ pub fn scalar_exp_vartime(x: &Scalar, mut n: u64) -> Scalar {
 }
 
 /// Takes the sum of all the powers of `x`, up to `n`
-/// If `n` is a power of 2, it uses the efficient algorithm with `2*lg n` multiplcations and additions.
+/// If `n` is a power of 2, it uses the efficient algorithm with `2*lg n` multiplications and additions.
 /// If `n` is not a power of 2, it uses the slow algorithm with `n` multiplications and additions.
 /// In the Bulletproofs case, all calls to `sum_of_powers` should have `n` as a power of 2.
 pub fn sum_of_powers(x: &Scalar, n: usize) -> Scalar {