--- Log opened Sat Aug 24 00:00:50 2019
00:11 -!- harding [~harding@cpe-66-91-121-125.hawaii.res.rr.com] has quit [Ping timeout: 248 seconds]
00:30 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-joxtcxnuaoqsficw] has quit [Quit: Connection closed for inactivity]
07:46 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-qjwmqxjtrnjxadgj] has joined #secp256k1
07:48 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
07:48 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1
09:41 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
10:22 < afk11> hi folks. small question about libsecp256k1 and schnorrsig. per here https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1.h#L90, secp256k1_nonce_function takes an algo16 argument, which is NULL for ECDSA. the schnorrsig bip currently passes NULL too, and I notice changing this will cause the tests not to match the bip (algo16 is committed in secp256k1_nonce_function_schnorrsig and is
10:22 < afk11> presently NULL)
10:24 < afk11> I'm curious if the algo16 will be set for schnorrsig, or whether secp256k1_nonce_function_schnorrsig ought to commit to it at all?
10:24 < sipa> so bip schnorr prescribes an exact algorithm for nonce generation
10:25 < sipa> so we can't use our own "pass an algorithm name" approach if we want to be compatible
10:26 < sipa> perhaps we could set an algorithm name, but have nonce_function_schnorrsig verify it's setto the correct schnorr one (and abort if it's wrong or default to the other nomce function), but nlt actually use the algo name in the generation
10:29 < afk11> simply not using it might be easiest. it seems to be a cosmetic issue only (AFAICT it shouldn't matter if you DO generate nonces differently..) but I haven't heard of other implementations committing to the algo16 either.
10:30 < sipa> right; perhaps the algo apprpach is just wrong
10:30 < sipa> and we should treat the nonce gen algorithm as an inherent property of the signature scheme
10:40 < afk11> not sure I follow your last comment - what do you mean exactly?
10:40 < afk11> algo16 wouldn't have an effect, or something else?
10:41 < sipa> it would just disappear
10:41 < sipa> and you're responsible for making sure to use a nomce generation algorithm compatible with your signature scheme
10:42 < sipa> and the default would be; for ecdsa it'd be rfc6979, for schnorr it'd be the bip-schnorr specified one
10:57 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
10:58 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has joined #secp256k1
11:02 < afk11> got it, thanks. it'd be a bc break to remove it from secp256k1_nonce_function, but could kick that down the road if needed and just update the docs to reflect it won't be used? not sure how taboo BC breaks are here :)
11:04 < sipa> BC breaks?
11:05 < sipa> we can just leave the parameter as legacy too, and just define for each nomce function what it's compatible with
11:06 < afk11> bc breaks = backwards compatibility breaks
11:06 < afk11> but the parameter could stay as you suggest
11:09 < afk11> my issue presently is I have code in my language bindings to deal with NULL|string for algo16. but nothing exercises it yet ;) https://github.com/Bit-Wasp/secp256k1-php/blob/ea94d1daba2dcf07a575d294ce2159e73a15d2cc/secp256k1/secp256k1.c#L55
12:25 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-qjwmqxjtrnjxadgj] has quit [Quit: Connection closed for inactivity]
13:15 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
13:15 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
13:16 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
13:16 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
13:16 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
13:17 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
13:17 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
13:18 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
13:18 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
13:18 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
13:30 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
14:09 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-srycbaoqygjvjaiq] has joined #secp256k1
15:23 -!- harding [~harding@cpe-66-91-121-125.hawaii.res.rr.com] has joined #secp256k1
15:29 -!- harding [~harding@cpe-66-91-121-125.hawaii.res.rr.com] has quit [Quit: leaving]
18:48 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-srycbaoqygjvjaiq] has quit [Quit: Connection closed for inactivity]
19:48 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
19:53 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 272 seconds]
20:08 -!- harding [~harding@cpe-66-91-121-125.hawaii.res.rr.com] has joined #secp256k1
--- Log closed Sun Aug 25 00:00:50 2019