Dealer in aggregated range proof implementation should verify shares about bulletproofs HOT 7 CLOSED

I think there's a slight complication.

The ideal flow would be that the dealer decides whether or not the proof shares are trusted (e.g., self-aggregation). If the shares are untrusted, the dealer should

1. Return Ok(proof) if the aggregated proof verifies
2. Otherwise, check each share for validity and return an Err with info about which shares were invalid.

The reason to do this is that verifying the aggregated proof is cheaper than verifying each share individually. However, the dealer can't just call .verify() since that code attempts to replay the proof and generate challenges, which requires having the starting transcript state, which the dealer already destroyed by running the protocol.

One option would be to save the transcript state at the beginning, then pass it to the verify call. Another would be to duplicate the verification logic inside of the dealer, to take account of the fact that the dealer still has all of the challenges at hand. The second option seems less nice.

from bulletproofs.

One option would be to save the transcript state at the beginning

Sounds right to me. Cloning a transcript is a pretty cheap operation and we already support that. (Although, we should probably add tests for that use case.)

from bulletproofs.

Another point: right now, the transcript state is maintained by the protocol orchestrator, and passed in as a parameter to each step of the dealer's work. The alternative would be for the dealer to hold on to the transcript reference until the protocol is complete.

The alternative seems like it might be better, since a) it's one less parameter and b) it would disallow any other code from touching the transcript state while the dealer is active. b) is kind of a fringe benefit, but right now, it's conceivably possible to write code that fed an extra message into the transcript between dealer steps, which would give an invalid proof (since the challenges would not replay).

from bulletproofs.

Maybe this would also be good to do for parameters like the GeneratorsView that's used at the very end? i.e., pass all of them into new, so that once the initial Dealer state is created, the only inputs needed to advance the state are the protocol messages.

@cathieyun WDYT?

from bulletproofs.

I do think it's better to have the transcript passed between the dealer states, instead of being passed in every time (the counterargument for that is that the rng is passed in every time... but that's different in that it doesn't matter if anyone touches the rng in between dealer states).

with regards to challenges - is it possible to (instead of cloning the transcript at the beginning) make a new transcript with the same initial string, and the use that for the verification?

from bulletproofs.

I think we can't make a new transcript except by cloning the initial one, since there's no way for the dealer code to know the customization string -- or even if the state was created by using a customization string, since the RP protocol could be composed into a larger protocol (in the same way that the IPP is composed into the RP protocol).

I'll patch up the dealer states to hold on to their arguments.

from bulletproofs.

makes sense - in that case, I think holding on to a clone of the initial transcript makes sense

from bulletproofs.