--- Day changed Thu Mar 01 2018
00:30 < waxwing> s is modulo N, ie the curve group. It has to be because it's a scalar used to multiply (verify is sG ?= R + eP)
00:34 < kallewoof> I thought the pubkeys etc were on the same curve, but they're not.
00:35 < kallewoof> Or at least when doing the modulo calculations the N is different. Don't know if that is the same hing as 'not on same curve' though.
01:52 < waxwing> i don't know what kind of schnorr sig you're looking at if it involves more than one curve? maybe you mean something quite different by "EC schnorr".
02:00 < kallewoof> waxwing: I'm confused too. The secp256k1 curve has a p = F...FFFFFFFE FFFFFC2F and a n = F...FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141. To calculate s you use the latter, but all other operations are done using the former.
02:04 < waxwing> i'd calculate s as k + ex where x is the privkey, e is the hash (say H(R||P||m)) and k is the nonce (R=kG), all of s, k, e and x are mod N, not p. only the coordinates of points are mod p.
02:06 < waxwing> but ymmv on details, that's for sure, just these are all scalars in the curve group, not the finite field that is used for the coordinates of the curve.
02:10 < sipa> kallewoof: what did we tell you? forget there is an EC group underneath :)
02:11 < sipa> p only matters for the group operation itself (whwn implementing adding and doubling and negation of group elements)
02:11 < sipa> n is what matters for schnorr
02:11 < sipa> and for any algorithm built on top
02:26 < sipa> from the perspective of a Schnorr implementation, two things exist: group elements and integers modulo the size of that group
02:26 < sipa> IF that group is an EC group, you need a field which the coordinates of those EC group elements are over
02:28 < sipa> but it doesn't have to be, it could be any prime-sized group
02:36 < kallewoof> sipa: hum... yeah I remember you saying that. I didn't think it'd rear its head in this manner. (I wrote an arith_uint256 with built-in modulo support and expected it to always use the same N, which turned out to be wrong.)
02:37 < kallewoof> Here, btw. It's insanely slow though so probably completely uninteresting: https://github.com/kallewoof/ec
02:57 < sipa> kallewoof: well if you ever want to implement it more efficiently, have a look at libsecp256k1
02:58 < sipa> there are 3 separate data types there (field.h, secp256k1_fe, which is integers mod p, group.h, secp256k1_ge(j), which are group elements, and scalar.h, secp256_scalar, which are integers mod n)
03:48 < kallewoof> sipa: I thought libsecp256k1 didn't have schnorr (yet)
03:50 < kallewoof> sipa: also, I looked at libsecp256k1 and was very confused. I should probably read up on jacobian coords.
03:54 < sipa> kallewoof: yes, but doing what you're doing now using the libsecp256k1 codebase should a lot easier to get soe performance out of
03:55 < sipa> kallewoof: and there's certainly going to be a bit of barrier (jacobian coordinates, indeed), but it's probably more useful too :)
04:04 < kallewoof> sipa: Agreed! I guess I wanted to see it in practice at least once with code that I fully understood. Rewriting arith_uint256 to use a modulus parameter was sufficient, even though it takes 2.4s to convert a privkey to a pubkey and about the same to sign/verify.
04:10 < sipa> haha
04:11 < kallewoof> Hey, it took 14s before I remembered to switch g++ -g to g++ -O3 :P
04:12 < kallewoof> (30s the first try; after optimizing a ton I realized ^)
04:13 < sipa> you won't get very far without jacobian coordinates
04:13 < sipa> computing an inverse after every addition is suicide :)
04:16 < kallewoof> sipa: I noticed, yeah. Didn't realize it'd be quite that big of a deal..
04:18 < sipa> it's a factor 100 speedup or so
04:18 < sipa> using jacobian coordinates
04:24 < kallewoof> Feels like higher, but I probably have unoptimized stuff all over the place. (I did end up filing two PRs to bitcoin for arith_uint256 though, so not all for nothing.)
04:24 < kallewoof> (e.g. v *= v would be 0 because *this = 0 at the top and then b (== *this) is used later)
05:14 < sipa> well arith_uint256 is also many times slower than the optimized field and scalar implementations in libsecp
05:14 < sipa> it only uses pure-C++ 32-bit arithmetiv
05:17 < kallewoof> *nods*
05:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
05:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1     
05:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
05:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1     
11:25 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has joined #secp256k1     
14:15 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Ping timeout: 245 seconds]     
16:00 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection]     
16:00 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1     
17:00 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #secp256k1     
20:10 -!- zmanian [sid113594@gateway/web/irccloud.com/x-puonnaboypxbnliw] has quit [Ping timeout: 240 seconds]     
20:11 -!- eragmus [sid136308@gateway/web/irccloud.com/x-ehywxaykfciongys] has quit [Ping timeout: 256 seconds]     
20:12 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-blqwklbasxbbwebp] has quit [Ping timeout: 240 seconds]     
20:13 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-nuarunkeosuzxyze] has joined #secp256k1     
20:13 -!- zmanian [sid113594@gateway/web/irccloud.com/x-cuzrivpjmnjssbem] has joined #secp256k1     
20:15 -!- eragmus [sid136308@gateway/web/irccloud.com/x-ltyabbdyukpokafi] has joined #secp256k1