Closed jovfer closed 1 year ago
Looks reasonable to me
Addressing this issue is in scope for the latest milestone, as a WG we need to decide whether this procedure change is in fact an improvement on readability of the specification.
See comment here for rational on why we have elected not to proceed with this change.
@tplooker I do agree it's a really minor from the readability standpoint and about 0 from efficiency in runtime. The main benefit is the simplification of an implementation, so it will be just more consistent formula and more consistent codebase. Since the spec is still draft, I'm estimating the change as 0-cost and having long-term benefit makes the tradeoff obvious for me.
PS: re-opening the issue just to increase visibility, fill free to close it back, if the argument above doesn't make sense for you :) PPS: oops, seems like I can't re-open the issue. Hopefully the notifications work fine.
The proof gen procedure defines
D = B * r1 + Q_1 * r2
.Everywhere below it's used with
-
.Can we change the sign of the definition and declare
D = -(B * r1 + Q_1 * r2)
?Then the step 17th will be
17. C2 = D * r3~ + Q_1 * s~ + H_j1 * m~_j1 + ... + H_jU * m~_jU
Then proof verification steps 10, 12 will be:
10. C1 = (Abar + D) * c + A' * e^ + Q_1 * r2^
12. C2 = T * c + D * r3^ + Q_1 * s^ + H_j1 * m^_j1 + ... + H_jU * m^_jU
UPD: as @tplooker mentioned in the related MR #226, this is a breaking changes, as D is a part of serialized proof.