--- Day changed Thu Jun 02 2016 02:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #secp256k1 03:56 -!- jtimon [~quassel@4.28.134.37.dynamic.jazztel.es] has joined #secp256k1 04:24 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds] 06:55 < kanzure> d/win 2 06:55 < kanzure> eoiqjfdofjaod 06:59 < sipa> thank you for the contribution to the discussion 06:59 < kanzure> :( 06:59 < kanzure> i feel really bad about it too 06:59 < kanzure> (no i don't) 08:05 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-ecwuluqyiuwaduog] has quit [Ping timeout: 264 seconds] 08:06 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-izdgswuchwrrbabq] has joined #secp256k1 08:15 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection] 08:15 -!- slackircbridge [~slackircb@45.55.41.36] has joined #secp256k1 09:08 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #secp256k1 09:13 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.] 09:18 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #secp256k1 11:37 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.] 11:40 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #secp256k1 11:46 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection] 11:46 -!- slackircbridge [~slackircb@45.55.41.36] has joined #secp256k1 11:49 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1 12:29 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] 13:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #secp256k1 14:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds] 14:51 < roasbeef> why isn't 'secp256k1_ecmult' called 'secp256k1_ec_doublescalarmult' or something along those lines? 14:53 < sipa> that would have been a clearer name, agree 14:53 < roasbeef> also is there a compile-time flag to increase the size of the pre-computed tables for scalar base mult? 14:54 < sipa> no, but you can change it in the code 14:54 < sipa> it may make sense to change it depending on the platform 14:55 < sipa> the balance between memory/cache access and more calculation is not the same everywhere 14:57 < roasbeef> I see, I'll fiddle around with it then. I'd like to speed up the computation at the cost of memory usage in order to speed up a situation where a client may be computing at times 250k+ points as part of a secure search protocol. 14:59 < sipa> i doubt you can speed it up further for typical x86_64 hardware 15:00 < sipa> making the cache larger makes the time gained for less G additions not weigh up against the loss of more cache misses 15:00 < sipa> maybe you can get 1% or so out of it still 15:00 < sipa> as that hasn't been benchmarked in a while, the optimal value may have changed 15:01 < sipa> if you're talking about embedded hardware however, the optimal value may be very different 15:07 < roasbeef> gotcha, yeah this is just for typical x86_64 hardware 15:08 < roasbeef> fwiw i'm coming over from p256/openssl which uses big ints afaik 15:08 < sipa> i think openssl does have an optimized implementation for p256 15:09 < sipa> s/optimized/specialized/ 15:09 < roasbeef> hmmm would you anticipate secp256k1 having a performance improvement relative to p256 w.r.t point multipliation and maybe addition? 15:10 < sipa> yes 15:10 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1 15:11 < sipa> libsecp256k1 is close to ed25519 in performance 15:15 < roasbeef> great :) 15:15 < sipa> just benchmarked 15:15 < sipa> 255k cycles for an ecdsa secp256k1 verification 15:15 < roasbeef> also the lib implements a faster point-decompression relative to the naive methods right? something something legendre symbol? 15:16 < sipa> 337k cycles for a ecdsa p256 verification in openssl 15:16 < roasbeef> nice 15:17 < sipa> the point decompression libsecp256k is pretty standard 15:18 < roasbeef> I see, did this commit https://github.com/bitcoin-core/secp256k1/commit/646662517fb39afa90788392463b1043fd960c35 result in a speed up? or is it just cosmetic 15:18 < sipa> for our Schnorr signature scheme we're thinking about using 64-byte signatures where the odd/evenness of the R point's Y coordinate is implicit (by requiring that Y is a quadratic residue, rather than even) 15:19 < sipa> roasbeef: no, that's just a refactor/clarification 15:19 < sipa> the actual algorithm used for point decompression (which relies on odd/even as a tie breaker) is unchanged 15:19 < roasbeef> gotcha 15:20 < sipa> the refactor was necessary to implement the Schnorr trick above 15:22 < roasbeef> cool, we're considering using schnorr in our lightning implementation for compact channel authentication proofs (using the same implicit Y coord assumption). also to differentiate/restrict certain points and just have 32 bytes pubkey everywhere instead of 33+ 15:23 < roasbeef> though we don't need the "de-linearization" since we know the counter-party can sign with the advertised keys ahead of time 15:25 < sipa> i plan to work on Schnorr and multisigning support in libsecp256k1 soon 15:25 < sipa> but now i'm too busy with Core and segwit 15:25 < roasbeef> gotcha 15:25 < roasbeef> yeah I have some segwit work I need to finish up too ;) 16:06 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Ping timeout: 260 seconds] 17:16 -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has quit [Ping timeout: 258 seconds] 17:23 -!- andytoshi [~andytoshi@wpsoftware.net] has joined #secp256k1 17:50 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.] 17:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #secp256k1 17:58 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #secp256k1 18:12 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.] 18:13 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #secp256k1 18:24 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.] 18:28 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #secp256k1 19:08 -!- jtimon [~quassel@4.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds] 19:15 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.]