--- Log opened Wed Jul 31 00:00:26 2019
01:10 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 264 seconds]
01:24 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #secp256k1
01:54 < nickler> elichai: "I see that you do stuff like that all over your 3 PRs" I found two code locations. Anywhere else?
04:18 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
04:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
04:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
04:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
07:01 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-isjyuaalbhbfdvbq] has joined #secp256k1
07:03 < elichai2> nickler: I'm probably misunderstanding you but let's say R=(6*G) and the H(..) equals to 4. is it faster to compute 10*G or just add 4*G to the already existing R(which is 6*G)?
07:16 < sipa> 10*G would save one addition
07:17 < elichai2> but that's a bigger multiplication. (altough I don't understand enough how the context work so maybe with the context this makes 10*G cheaper?)
07:17 < sipa> elichai2: sure, but in practice these numbers are random 256-bit values
07:18 < nickler> and even in the specific case you're referring to their random values
07:18 < nickler> *they're
07:18 < elichai2> because without the context I would assume that 10*G cost more then one addition.
07:18 < sipa> 10 is equally likely to be larger or smaller than the 4
07:19 < elichai2> sipa: the only way it can be smaller is be wrapping around the order, right? (because we're adding something to the k)
07:19 < sipa> elichai2: yes
07:19 < sipa> and it has a 50% chance of wrapping around
07:19 < elichai2> hmm so 50% chance of wrapping and even without the context will probably make the multiplication faster then mul&addition?
07:20 < sipa> yes
07:20 < elichai2> ok. now I get the intuition. Thanks!
07:20 < elichai2> nickler: you can resolve my comment on that matter :)
07:21 < sipa> actually, even if your algorithm was "pick the smaller of a and a+k, multiply, and then if a was picked, add R", that would likely be slower than just always multiplying with a+k
07:21 < sipa> the reason is that the EC multiplication is really optimized, and does less than one addition per bit
07:22 < sipa> (it does do one doubling per bit always though)
07:22 < sipa> but doublings are faster than additions
07:25 < elichai2> doubling is faster? isn't the only difference is that to calc the slope adding requires `(y1-y2)/(x1-x2)` and doubling requires `(3x^2)/(2y)`?
07:26 < elichai2> oh right I forgot that it uses jacobian coordinates
07:27 < sipa> yeah, no divisions involved
07:27 < elichai2> ha. it's a bit unintuitive that multiplying from scratch can be faster then multiplying the missing part and adding but makes sense now
11:17 -!- reallll [~belcher@unaffiliated/belcher] has joined #secp256k1
11:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 258 seconds]
12:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
12:52 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
12:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
12:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
12:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
13:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
13:08 -!- reallll is now known as belcher
13:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
13:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
13:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
13:18 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
13:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
13:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
13:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
13:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
13:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 244 seconds]
13:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
13:51 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
15:00 < elichai2> Is it possible that schnorr signing is slower than ecdsa? even though there's no inversion in schnorr?
15:00 < elichai2> `ecdsa_sign: min 35.9us / avg 36.3us / max 36.9us`, `schnorrsig_sign: min 46.6us / avg 48.9us / max 57.9us`
15:01 < elichai2> or is that because of the quadradic residue check?
15:03 < sipa> yead
15:03 < sipa> it's expected to be slightly slower
15:03 < elichai2> Didn't think quad check is more expensive than modular inversion
15:03 < sipa> we favor verification speed over signing speed
15:03 < sipa> signimg does botd
15:03 < elichai2> Yeah that I understand
15:04 < sipa> *sorry, typing on phone
15:04 < sipa> there's a modulae inversion in the conversion from jacobian to affine
15:04 < sipa> though no scalar inversion
15:12 < elichai2> is ecdsa verification also faster than schnorr verification(though almost the same)? lol. I feel stupid now.   `ecdsa_verify: min 50.2us / avg 52.6us / max 58.9us`  `schnorrsig_verify: min 52.4us / avg 53.9us / max 59.6us`
15:13 < sipa> with gmp enabled or not?
15:13 < elichai2> without
15:13 < elichai2> oh wait. it's on auto
15:13 < elichai2>   bignum                  = gmp
15:13 < elichai2> yep. with
15:15 < elichai2> sipa: I need to give a talk in an hour about some schnorr stuff and I planned to say that it should also be a performance increase because there are no inversions any more but I guess I can't say that?
15:15 < sipa> batch verification!
15:15 < sipa> modular inversions in gmp are very fast
15:17 < elichai2> i'll try running them without gmp (and of course batch verification haha)
15:18 < elichai2> (fairly bitcoin compile secp without gmp)
15:18 < elichai2> yep. without gmp ecdsa verify is slower by a few nano secs
15:18 < sipa> and good luck with the talk
15:19 < elichai2> Thanks :)
15:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
15:28 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
15:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 268 seconds]
15:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
19:00 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-isjyuaalbhbfdvbq] has quit [Quit: Connection closed for inactivity]
21:08 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-dmyodtygbfxbndfz] has joined #secp256k1
23:20 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-dmyodtygbfxbndfz] has quit [Quit: Connection closed for inactivity]
--- Log closed Thu Aug 01 00:00:27 2019