Put the challenge at the end

[BasileiosKal]

Fix #265

Move the challenge value c at the end of the proof value. Specifically, the proof becomes

proof = (Abar, Bbar, r2^, r3^, (m^_j1, ..., m^_jU), c)

Also change Abar with Bbar in ProofGen and ProofVerify

[BasileiosKal]

Breaking Changes

1. moved the challenge c value at the end of the proof value (requires an update to the proof serialization/de-serialization operations).
2. In ProofGen. At step 11 during C calculation, switched Abar with Bbar. I.e.,

   C = Bbar * r2 + Abar * r3 + ...  -->>  C = Abar * r2 + Bbar * r3 + ...
   

   Also in step 15 and 16 of ProofGen, the following changed (e "moved" from r3^ to r2^)

   15. r2^ = r2 + r4 * c      -->>  r2^ = r2 + r4 * e * c
   16. r3^ = r3 + r4 * e * c  -->>  r3^ = r3 + r4 * c
   

3. In ProofVerify, at step 8, again change Abar with Bbar during C calculation, i.e.,

    C = Bbar * r2^ + Abar * r3^ + ...   -->>   C = Abar * r2^ + Bbar * r3^ + ...
   

[BasileiosKal]

@andrewwhitehead, I'm really sorry, but there are some more changes to review 🙏

[christianpaquin]

Is this captured in any test vectors? Never mind, I see they are part of the PR itself.

[christianpaquin]

Some minor editorial comments. Implemented the update in my library (PR 23); test vectors pass.

[christianpaquin]

Why have in inner parenthesis and have the c out of it?

[BasileiosKal]

Good catch! It was a typo. Fixed. Thanks!

[christianpaquin]

A bit confusing to have the m^_j_i in parenthesis.

[BasileiosKal]

Fixed. Thanks!

[Wind4Greg]

I'm not sure why were are doing the swapping of Abar and Bbar. When I try to map this back to the Revisiting BBS paper it seems like the way we currently have it is a close match and this change seems less like the paper.

Is there another version of the paper with this changed?

Is there a reason for this change?

Note that we also don't seem to cite the "Revisiting BBS" paper in the update.

[BasileiosKal]

Hey Greg 👋 The swapping is mainly for readability. Note that we just want to calculate Abar * a_random_number + Bbar * another_random_number. It is just a bit more sense to have Abar * r2 + Bbar * r3 instead of Bbar * r2 + Abar * r3.

This does not go against the paper. It is just a naming convention. Another way to think of it, is instead of "swapping" Abar and Bbar we "renaming" r2 to r3.

The reason it is a breaking change is that we have deterministic random number generation for testing.

[Wind4Greg]

Implemented and confirmed all test vectors. Note the high level text description still has the parameters in the old order:

The inputted proof value must consist of the following components, in that order:

1. Two (2) valid points of the G1 subgroup, different from the identity point of G1 (i.e., `Abar, Bbar`, in ProofGen)
2. Three (3) integers representing scalars in the range of 1 to r-1 inclusive (i.e., `c, r2^, r3^`, in ProofGen).
3. A number of integers representing scalars in the range of 1 to r-1 inclusive, corresponding to the undisclosed from the proof messages (i.e., `m^_j1, ..., m^_jU`, in ProofGen, where U the number of undisclosed messages).

[BasileiosKal]

Discussed on the WG call on the 10th of July. Test vectors are cross validated by multiple implementations. Merging.