--- Log opened Tue Aug 20 00:00:45 2019
00:42 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 248 seconds]
01:00 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #secp256k1
05:49 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-hjgejwmrqsgtbbhb] has joined #secp256k1
07:38 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
07:42 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 248 seconds]
08:24 -!- reallll [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
10:03 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
10:28 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit []
10:30 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
10:38 < elichai2> Does it makes any sense that `mpn_gcdext` will return 4?
10:40 < sipa> it returns the number of limbs in the returned value
10:41 < elichai2> Hmm I'm getting `src/num_gmp_impl.h:133: test condition failed: gn == 1` in `secp256k1_ge_set_all_gej_var->secp256k1_fe_inv_var->secp256k1_num_mod_inverse`, and trying to print the gcd inputs I see `gn: 4, u: 0, v: fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f`
10:41 < elichai2> no infinities in the group elements, so I'm not entirely sure what could cause this
10:42 < sipa> my guess is that you're passing in a number equal to the group or
10:42 < sipa> der
10:43 < sipa> since the group order is prime, that's the only way you could have a 256-bit input whose gcd with the group order is over 192 bits in size
10:43 < sipa> or 0
10:43 < sipa> in any case, something without an inverse
10:45 < sipa> s/group order/field size/
10:51 < elichai2> hmm how can I get to a case when I have the group order hmm, i'll try to see, I have a feeling It's because one of the `secp256k1_ecmult(ctx, &u1j, &infj, &zero, &u1);` tricks I wrote
10:52 < sipa> my guess is that you have a gej with z=0
10:52 < sipa> and somehow infinity isn't handled correctly
10:54 < elichai2> i'll add locally a check to `secp256k1_gej_is_infinity` that also checks z!=0
11:07 < elichai2> sipa: found it :) had uninitialized gejs lol.  the thing is every signature can produce up to 4 pubkeys. so I need to "allocate" 4 pubkeys for every one, but in reality all are 2, and I have 2 initialized, 2 unintialized, 2 initialized, 2 uninitialized.... I think I need to accept a pointer to pointers, each one point to 4 pubkeys, and I need to return a list of sizes
11:08 < sipa> that'll do 8t
11:34 < elichai2> Can I assume that converting infinity from ge to gej via `secp256k1_ge_set_all_gej_var` is practically free? (I don't see an easy way to have contingous array of good points, instead I thought i'll initialize them all to infinity so I can still easily batch the conversation)
11:37 < sipa> b. yes
11:37 < sipa> eh, yes
11:37 < sipa> afaik it deals correctly with infinities among the points
11:40 < sipa> what about having a function which you pass an array of 4*n secp256k1_pubkey objects, and an array of n bytes, and it stores the results for point n in array position 4*n...4*n+3, and the byte array receives 2s and 4s, one per key?
11:55 < elichai2> do you find it more readable than `secp256k1_pubkey pubkeys[][4], size_t pubkeys_n[]`?
11:56 < sipa> no, that's ok
11:56 < elichai2> I see that we never use explicit arrays in the public API, is that on purpose?
11:57 < sipa> yes, because you should never use them in C
11:57 < sipa> https://lkml.org/lkml/2015/9/3/428
11:57 < sipa> TL;DR: they don't exist
12:00 < elichai2> I see arrays as a nice way to say "this is a pointer that i'll probably use arithmetics on it" and if you add an integer in there it means "this is a pointer that i'll probably use arithmetics on it and expect it to have at least n locations allocated after it"
12:01 < sipa> right, but in other places in C arrays actually mean arrays
12:01 < sipa> so it's not inconsistent to use them, they're also don't add much, and can be pretty confusing
12:03 < elichai2> yeah.. but on the other hand you have `const secp256k1_pubkey *const *stuff` and you have no idea is this array of pointers? pointer to array? how exactly as the caller do I allocate for this?
12:04 < sipa> that's what comments are for
12:06 < sipa> i think what you want is fn(secp256k1_pubkey (*pubkeys)[4], size_t* counts)
12:06 < sipa> which declares pubkeys as a pointer to (an array of) 4-element pubkey arrays
12:07 < sipa> though you can also just collapse it into a single array
12:07 < sipa> the code is the same, i think
12:19 < elichai2> yeah I think it's actually the same code in reality, though you probably won't be able to use `k[i][1]` but you'll need to do `k[(i*4)+1]`
12:21 < sipa> right
12:21 < sipa> it'll compile to the same thing though
12:27 < andytoshi> we generally use arrays of pointers rather than flat arrays because it's easier to do C++ integration
12:27 < andytoshi> (you need to copy a bunch of pointers with our current APIs ... if we required a pointer to a flat array you'd have to copy the actual data)
12:28 < sipa> yeah, not sure it's worth it here though
12:28 < sipa> 4 is not much
12:29 < sipa> they're also output arguments, not input
12:30 < sipa> you could have the caller allocate bunches of 4 pubkeys, and then construct an array of pointers to those, and then passing a pointer to that array of pointers to arrays... but in practice that'd just be overhead to the caller i imagine
12:34 < elichai2> andytoshi: why can't you pass a pointer to a vector/array from C++ to C? (assuming you reserve the right size)
12:35 < sipa> elichai2: i think andytoshi is talking more about input arguments where the input data is e.g. represented as a vector of vectors; mapping that to a 2d array in C requires copying data, while representing it as an array of pointers to arrays only involves creating a single array of pointers
12:37 < elichai2> oh
12:41 < andytoshi> yeah
12:42 < andytoshi> same story in rust, and probably in pretty-much any other language
12:42 < andytoshi> there are stdlib containers that have all sorts of nice features but which don't map directly to C's "pointer to start of flat memory"
12:42 < elichai2> but in outputs it should be generally fine
12:43 < andytoshi> yeah
12:43 < elichai2> but yeah when I get signatures/messages I use array of pointers, though it's not fun to test (you need to maintain 2 arrays, one with the actual data and another with pointers)
12:44 < andytoshi> yeah, it is annoying when writing C code
12:44 < andytoshi> anyway for outputs i agree that a flat array is better
13:05 < elichai2> do I have to use the `secp256k1_ec_pubkey_parse` to compare 2 `secp256k1_pubkey`s?
13:09 < sipa> hmm the .h file does not state that secp256k1_pubkey objects are comparable
13:11 < elichai2> * I meant the serialize function, not parse
13:15 < sipa> there is an ge_equal function, no?
13:19 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]
13:20 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1
13:26 < elichai2> yeah, so it's either converting to array and memcmp or converting to ge and equal ok
13:41 < elichai2> ha, given different signatures(and different messages) from the same pubkey it will result in 4 different keys (2/4 with only one in common(the actual one))
13:43 < sipa> interesting, indeed
13:45 < elichai2> I tried to add a test that compares the resulting public key and thought it failed because of bad comparison, but no, they only have one pubkey in common(which actually makes sense)
13:50 < sipa> elichai2: make sure you deal correctly with the case where the recovered pubkey is infinity
13:51 < sipa> i believe that just means you won't return an entry for that key
13:51 < sipa> so the returned number can be different from 2 and 4 in that case
13:51 < elichai2> hmm but i'll return the rest?
13:51 < elichai2> right now if any is infinity I fail
13:51 < sipa> no you need to return the rest i believe
13:52 < elichai2> so if any is infinity the signature is invalid?
13:53 < sipa> no
13:53 < sipa> look at the ECDSA equation
13:53 < sipa> you need to return every public key the signature would validate against
13:53 < sipa> f one of those is infinity, than that specific one is not valid
13:53 < sipa> but the other keys may still be valid
13:55 < elichai2> yeah that's what I found (altough I need to adjust my code a bit for that case) what did you mean by: ?`<sipa> no you need to return the rest i believe`
13:55 < elichai2> oh
13:55 < elichai2> I read it wrong lol
13:55 < elichai2> read "no need" instead of "no, you need"
13:56 < sipa> ha
13:56 < sipa> english is hard
13:56 < elichai2> yep :)
13:56 < elichai2> C is easier :P
14:09 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 260 seconds]
14:14 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1
14:47 < elichai2> sipa: do you have an example of 4 pubkey signature/msg? would like to test (only if you can pull it out of somewhere without sitting on the algebra :) )
14:47 < elichai2> nvm found in the code :)
14:48 < sipa> ok!
17:06 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
17:38 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-hjgejwmrqsgtbbhb] has quit [Quit: Connection closed for inactivity]
18:24 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-cooapdoquivenlgb] has joined #secp256k1
21:58 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-cooapdoquivenlgb] has quit [Quit: Connection closed for inactivity]
22:02 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
22:02 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1
--- Log closed Wed Aug 21 00:00:46 2019