Padding point gen using Try-And-Increment #32
Conversation
|
What is TAI btw? |
|
Try and Increment |
|
Can we just hash the seed once, and then increment the field element? The code will be just a bit simpler, but may take longer to find a point. |
| let hash: [u8; 64] = blake2::Blake2b::digest(&seed[..]).into(); | ||
| let x = F::from_le_bytes_mod_order(&hash); | ||
| if let Some(point) = Affine::<Curve>::get_point_from_x_unchecked(x, false) { | ||
| let point = point.clear_cofactor(); |
There was a problem hiding this comment.
@burdges do we care if it is in the subgroup? Just curious.
There was a problem hiding this comment.
he asked the same question here: #31 (review)
But I guess yes? As the SEED is not in the prime order subgroup, if you add a padding point not in the prime order subgroup you may end-up with the point at infinity right? Which is not managed in the constraints (and primarily that is why the SEED is chosen to be out of the prime subgroup).
There was a problem hiding this comment.
Got it. We cannot compute x+x in the SNARK, only x+y with x != y. As our snark never checks that x != y, we need all our additions to be x != y implicitly.
We have two padding points, the start point hs and the empty point he, maybe equal. We compute (..((hs + x[0]) + x[1]) + .. + x[n]) - hs where the x[i] are either a public key if in the bitfield, or zero=infinity if not in the bitfield, or he no public key exists there.
We need -2 hs to not be a combination of x[i], but n << group_order, so either hs should be outside the prime order subgroup, or else we should've proofs of possession for the public keys.
We should presumably just do proofs of possession, because that'll work for prime order curves by bn254, but if skipped the proofs of possession then he != hs matters, but hs = he + coset_element works.
davxy
changed the title
Although in the Bandersnatch case, with the provided input, it identifies the point on the first iteration (that is primarily why I modified the input string, as otherwise, it was taking 2), my gut feeling is that in general case, by not re-hashing in the loop it may require more time. What can I say for sure is that, given |
TAI success is expected - on average - after two iterations.
For Bandersnatch and the given message it succeeded on the first iteration.
Generated padding point (SW form):
(25353312785503880631115876544961443547556511355876709037985429927235015446936, 48034916494481689813223622984827694955476028581467743482028403440447916980403)With blake2 we can generate an X for a field with at most 512 bits. I guess this is acceptable (at least for all the curves provided by arkworks). Well, for our usage here, we can probably reduce it to 32 bytes....