Make ZK proofs creation fallible

[fjarri]

Instead of crashing on assertions at the start of each new() in ZK proofs, we can just return a LocalError since the message-making methods are fallible.

[dvdplm]

Link to comment thread leading to this.

[fjarri]

A related thing to consider. Currently we have assert_exponent_range() statements in proof constructors. My initial assumption was that if these ranges are violated the proof would give spurious results. But I'm starting to think that these are rather a part of the set of conditions we are proving - that is, if they are violated, the proof verification fails. So maybe we can just remove them completely?

Specifically it is important for the dec proof. When it is called in Rounds 5, the y parameter is \delta_i which comes from the decryption of a ciphertext (either directly or by summing \alphas which also come from decryptions), and therefore has a range of +-N. If we tried to assert its range, a possible error would be a fault of a remote node, but an unprovable one - unless we assume that П^{dec} proves that y is in the desired range. Which I think it does.

[fjarri]

Continuing the topic of the y parameter in the dec proof. This parameter of this specific proof is kind of special because, even though it's in a secret inputs set, it's not a secret we generated, but the one that we constructed from secrets sent to us ( it's delta_i in Presigning). In other cases, if we see that a secret parameter is out of range it indicates a bug in the code. But if this one is out of range, it means there was some invalid or malicious message.

Now if it is out of range, and we create a proof with it, then it'll fail to verify on the other side, and the other side will think we sent an invalid proof, which is itself a provable offense. So what should we do if one of the alpha_i,j or beta_i,j we received (that sum up to delta_i) is out of range? Can we prove it without disclosing their values? Or perhaps we can disclose them safely if we're planning to halt?

Maybe this even deserves its own issue.

[dvdplm]

Or perhaps we can disclose them safely if we're planning to halt?

If this was the case, that would make our life easier for sure.

Thinking out loud: the party that receives an out-of-range delta_i would certainly not want to continue the protocol right? If the faulty value is ephemeral, i.e. a secret that is re-generated for each operation, then disclosing + abort should be safe. If it's not ephemeral it's trickier I guess, but it still seems like delta_i (a sum of secrets) would be ok to disclose. Worst case we can probably add a specific ZK range proof for this specific problem? Not saying we should start cooking up our own proof, but it's good to know that it is at least possible if we really need to.

Maybe this even deserves its own issue.

Definitely! :)

[fjarri]

Filed #187

[fjarri]

but it still seems like delta_i (a sum of secrets) would be ok to disclose

Just to address that: delta_i is indeed safe to disclose (we're broadcasting it anyway), but we need to pinpoint the specific node that sent a value out of range, so proving that the sum is out of range doesn't do us much good.