--- Log opened Mon Nov 09 00:00:11 2020
02:05 -!- reallll is now known as belcher
02:58 < nickler> elichai2: since keygen is rather trivial (especially since we don't *need* to show uncompressed pubkeys there), we can just do it in ecdsa.c and schnorrsig.c. In any case I think signing + verification should be together.
02:58 < nickler> But a reason to keep keygen.c would be that it could serve as a basic example containing the comments that we don't really want to repeat everywhere (regarding context, memset(seckey), etc).
05:26 < elichai2> nickler: my problem with signing is a signing example is hashing the message. I really don't want to use a 32 byte "message" because it needs to be hashed
05:26 < elichai2> andytoshi: yep. obviously the parsing functions are important
05:31 < elichai2> I could add a copy of lonesha256  (header only, 143 lines) but I don't feel good about it
06:32 < andytoshi> IIRC we were planning to expose sha2, in some sort of modular "you can also provide your own" kinda way
06:33 < elichai2> andytoshi: right. but still we won't expose our sha2 to users, so the examples can't use it
06:34 < andytoshi> i think nickler is working on a variable-length message API change that'll fix this for schnorr
06:35 < nickler> there's a PR for that from last week but for schnorr a 32 byte message would be okay
06:35 < nickler> I suppose the problem is only with ecdsa because it'd look like you don't need to hash the message
06:36 < andytoshi> oh good point that with schnorr you can use whatever as the msghash
06:36 < andytoshi> i'm not too opposed to leaving ecdsa with the current shitty unergonomic api
06:36 < nickler> unsigned char msg_hash[32]; /* hash of a message. No, really this must be hash, not the message itself, even if your message happens to be 32 bytes, etc */
06:36 < andytoshi> esp if you can replace the internal sha2 with your own code if you're worried about codezise
06:41 < nickler> elichai2: I think clearly documenting that ecdsa_sign gets a message hash is fine. It'd be better than what we have now (almost no mention of that issue).
06:42 < elichai2> I guess it's good enough
07:06 -!- Fredia1 [~Sadie@198.147.22.84] has quit [Ping timeout: 246 seconds]
07:13 -!- Fredia1 [~Sadie@198.147.22.84] has joined #secp256k1
07:28 -!- jonatack [~jon@82.102.27.195] has quit [Quit: jonatack]
07:33 -!- jonatack [~jon@88.124.242.136] has joined #secp256k1
07:37 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 256 seconds]
07:39 -!- jonatack [~jon@213.152.162.5] has joined #secp256k1
16:23 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
16:35 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
19:16 -!- Cory [~Cory@unaffiliated/cory] has quit [Read error: Connection reset by peer]
19:24 -!- Cory [~Cory@unaffiliated/cory] has joined #secp256k1
19:53 -!- reallll [~belcher@unaffiliated/belcher] has joined #secp256k1
19:56 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
21:57 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-pqgwfdruhplhobfa] has quit [Ping timeout: 272 seconds]
22:58 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-lesqambwizyhgzeh] has joined #secp256k1
--- Log closed Tue Nov 10 00:00:12 2020