--- Log opened Fri Sep 21 00:00:15 2018
01:52 -!- pabelanger2 [~pabelange@177.11.44.189] has joined #secp256k1
01:57 -!- pabelanger2 [~pabelange@177.11.44.189] has quit [Remote host closed the connection]
02:09 -!- brackets [~brackets@184.82.232.145] has joined #secp256k1
02:16 -!- brackets [~brackets@184.82.232.145] has quit [Ping timeout: 252 seconds]
02:24 -!- Schepeers [~Schepeers@179.52.55.85] has joined #secp256k1
02:24 -!- deusexbeer [~deusexbee@095-129-172-236-dynamic-pool-adsl.wbt.ru] has joined #secp256k1
02:25 -!- Schepeers [~Schepeers@179.52.55.85] has quit [Remote host closed the connection]
05:56 -!- s3krit [~s3krit@112.0.214.248] has joined #secp256k1
05:56 -!- s3krit [~s3krit@112.0.214.248] has quit [Remote host closed the connection]
08:11 -!- deusexbeer [~deusexbee@095-129-172-236-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 240 seconds]
08:12 -!- deusexbeer [~deusexbee@093-092-181-010-dynamic-pool-adsl.wbt.ru] has joined #secp256k1
08:56 -!- simpoir [~simpoir@118.69.9.71] has joined #secp256k1
08:58 -!- simpoir [~simpoir@118.69.9.71] has quit [Remote host closed the connection]
09:01 -!- everbird23 [~everbird@58.142.41.17] has joined #secp256k1
09:03 -!- everbird23 [~everbird@58.142.41.17] has quit [Remote host closed the connection]
09:45 -!- Matsu__ [~Matsu__@124.199.26.40] has joined #secp256k1
09:49 -!- Matsu__ [~Matsu__@124.199.26.40] has quit [Remote host closed the connection]
13:10 -!- hexchain18 [~hexchain@110.77.230.83] has joined #secp256k1
13:18 -!- hexchain18 [~hexchain@110.77.230.83] has quit [Ping timeout: 246 seconds]
13:33 -!- benjgvps29 [~benjgvps@201.208.61.48] has joined #secp256k1
13:34 -!- benjgvps29 [~benjgvps@201.208.61.48] has quit [Killed (Sigyn (Spam is off topic on freenode.))]
14:27 -!- dserodio26 [~dserodio@ip5f5bf551.dynamic.kabel-deutschland.de] has joined #secp256k1
14:28 < andytoshi> right now in ecmult_context_build we actually use over twice the size of the context in temporary scratch space (which is freed at the end of the call) .. specifically we generate 16k ge_storage's, but to produce them we allocate 16k gej's, ge's and fe's.
14:29 -!- dserodio26 [~dserodio@ip5f5bf551.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection]
14:29 < andytoshi> the ge's we can easily eliminate by going straight from gej to ge_storage, it's just a historical artifact that we have them at all (before co-z and effective affine we used it as a target for gej_set_ge_all)
14:30 < andytoshi> the gej and fe arrays seem allllmost eliminateable, but i'm beginning to think i can't. they're used as part of the co-z logic
14:31 < andytoshi> oh, actually we can eliminate the gej's i think, though it'd be a bit ugly ... we never use their z values, only the zr ratios, so we could just use the final ge_storage to hold the x and y coords
14:31 < sipa> co-z isn't merged
14:31 < andytoshi> i mean effecive affine
14:31 < andytoshi> specifically the z-ratio stuff
14:31 < sipa> ah yes
14:31 < andytoshi> sorry, i had thought that was co-z, but i guess it's just an unnamed subset of EA :)
14:32 < sipa> right
14:32 < sipa> co-z actually switches to different group formulae
14:32 < andytoshi> ah
14:33 < andytoshi> so, we need this array of z-ratios; after computing all the gej's with wrong z values, we multiply all the ratios together, invert that, then get a series of "partial inverses" by multiplying the inverted product by the original ratios, one at a time
14:33 < andytoshi> and we use those to correct the wrong z values
14:33 < sipa> could we use a separate array of z values and one with ge's?
14:33 < andytoshi> and i don't see any way to inline or cache this, it seems like we do need all `len`-many ratios laying around
14:33 < andytoshi> yeah
14:33 < sipa> instead of stuffing things in gejs
14:34 < andytoshi> we could do that
14:34 < sipa> so after the fact you'd just drop the z ratios allocation
14:34 < andytoshi> i will PR to do that actually, as well as PR to eliminate the malloc()s in the batch ge_set_gej code .. then signing context generation will require _no_ scratch space and verify context generation will require far less scratch space
14:34 < andytoshi> yeah
14:35 < andytoshi> but i was hoping i could get rid of all the scratch space without any perf hit :/
14:48 -!- ztane9 [~ztane@189.132.56.198] has joined #secp256k1
14:49 -!- ztane9 [~ztane@189.132.56.198] has quit [Read error: Connection reset by peer]
15:17 -!- Slade27 [~Slade@156.221.104.19] has joined #secp256k1
15:18 -!- Slade27 [~Slade@156.221.104.19] has quit [Remote host closed the connection]
16:33 -!- einar7720 [~einar77@cpe-173-174-82-151.austin.res.rr.com] has joined #secp256k1
16:34 -!- deusexbeer [~deusexbee@093-092-181-010-dynamic-pool-adsl.wbt.ru] has quit [Quit: Konversation terminated!]
16:35 -!- einar7720 [~einar77@cpe-173-174-82-151.austin.res.rr.com] has quit [Remote host closed the connection]
18:02 -!- fefo27 [~fefo@184.170.5.242] has joined #secp256k1
18:03 -!- fefo27 [~fefo@184.170.5.242] has quit [Remote host closed the connection]
18:25 -!- aleksander [~aleksande@156.211.246.70] has joined #secp256k1
18:33 -!- aleksander [~aleksande@156.211.246.70] has quit [Ping timeout: 252 seconds]
18:43 -!- magicman4 [~magicman@196.195.207.7] has joined #secp256k1
18:46 -!- magicman4 [~magicman@196.195.207.7] has quit [Remote host closed the connection]
21:54 < roconnor> andytoshi: the z-ratio stuff isn't used for the multiples of g's (for validation).  The z-ratio stuff is only used for multiplies of a's (for validation).
21:58 < roconnor> Ah sorry I take that back.
22:01 < roconnor> The z-ratios are used to generate the table of multiples of g;  they are thrown away afterwards, but are indeed used during that computation.  my bad.
22:03 < roconnor> You could make an alternate ecmult_context_build that trades time for space whereby you compute multiples of g the old fashion way by working with ge coordinates and computing lots of inverses.  The resulting table will be identical since the multiples of g are all normalized.
22:22 < roconnor> FWIW, in my implementation I'm a actually generating the multiples of g by passing g into the 'a' parameter ecmult and passing '0' into the ng parameter, thus using a 5-bit wnaf to generate the 16-bit odd multiples of g.
23:53 -!- shah3 [~shah@156.205.21.44] has joined #secp256k1
23:57 -!- shah3 [~shah@156.205.21.44] has quit [Remote host closed the connection]
--- Log closed Sat Sep 22 00:00:16 2018